Using custom boaard
jetpack 4.6.4
i flashed using the command sudo ./flash.sh --no-systemimg jetson-nano-devkit-emmc mmcblk0p1
after that i used application rootONSD-card-master.zip and run the scripts sudo ./copy-rootfs-ssd.sh and sudo ./setup-service.sh
after that im able to boot from sd card after powering off
but when i run sudo reboot the device gets booted from emmc and when runing df -h , sd card is not mounted
Hi amb018753,
It seems you are using the custom carrier board with both internal eMMC and SD supported.
Boot device/order is configured in u-boot.
Is that the tool released from your vendor?
If so, I’m not clear about that tool so that I would suggest you asking the help from your vendor.
how to configure in u-boot
the issue is not there in another flashed device of jp 4.6
and also when its powwered ON SD card is mounted on /
but when its checked after sudo reboot the sd is not mounted by checking df -h
It is stored in boot_targets variable.
e.g.
# setenv boot_targets 'mmc1 mmc0 usb0 nvme0 pxe dhcp'
# saveenv
You can find more details in the following link.
Boot Sequence and Sysboot Configuration Files
OK, but which is the file to make the change , could you please say
It is the commands which should be run. in u-boot during boot up. Please interrupt the boot up process and run those commands.
i checked this
printenv boot_targets
boot_targets=mmc1 mmc0 usb0 nvme0 pxe dhcp
but its booting from emmc
I’ll share the logs for both power-cycle and reboot
board1_px_sd_card_inserted_power_Cycle.txt (20.0 KB)
board1_px_sd_card_inserted_reboot.txt (42.4 KB)
[ 7.624679] mmcblk1: error -84 transferring data, sector 2, nr 6, cmd response 0x900, card status 0x0
[ 7.693387] Bridge firewalling registered
[ 7.702078] mmc1: Data CRC error
[ 7.702081] sdhci: =========== REGISTER DUMP (mmc1)===========
[ 7.702086] sdhci: Sys addr: 0x00000000 | Version: 0x00000303
[ 7.702090] sdhci: Blk size: 0x00007200 | Blk cnt: 0x00000000
[ 7.702093] sdhci: Argument: 0x00000002 | Trn mode: 0x00000013
[ 7.702098] sdhci: Present: 0x01fb0000 | Host ctl: 0x00000013
[ 7.702101] sdhci: Power: 0x00000001 | Blk gap: 0x00000000
[ 7.702105] sdhci: Wake-up: 0x00000000 | Clock: 0x00000007
[ 7.702108] sdhci: Timeout: 0x0000000e | Int stat: 0x00000000
[ 7.702112] sdhci: Int enab: 0x02ff100b | Sig enab: 0x02fc100b
[ 7.702115] sdhci: AC12 err: 0x00000000 | Slot int: 0x00000000
[ 7.702119] sdhci: Caps: 0x376cd08c | Caps_1: 0x10006f77
[ 7.702123] sdhci: Cmd: 0x0000113a | Max curr: 0x00000000
[ 7.702125] sdhci: Host ctl2: 0x00003001
[ 7.702131] sdhci: ADMA Err: 0x00000000 | ADMA Ptr: 0x00000000ffefe410
[ 7.702160] sdhci: ===========================================
[ 7.702246] mmcblk1: error -84 transferring data, sector 2, nr 6, cmd response 0x900, card status 0x0
[ 7.702259] blk_update_request: I/O error, dev mmcblk1, sector 2
[ 7.703761] Buffer I/O error on dev mmcblk1, logical block 0, async page read
Hi
is there any changes that we can do
waiting for your response
If there is an error on mmcblk1, then it might be the SD card itself failing.
Yes SD card is not mounted
so while powering up this isssue is not occuring
only in reboot it happens
There some misunderstanding in this topic.
Some added notes…
There are essentially two variants of the Nano module. One does not have eMMC, but it does have the SD card slot on the module itself, not on the carrier board. Those are what “dev kits” have. There are also Nano modules which have eMMC, and those models of module do not have an SD card slot on the module itself.
There are also two variants of carrier board for Nanos. The “dev kit” variant does not have any SD card slot on it (the slot is on the module). Only third parties manufacture or sell the Nano carrier board variant which has the SD card slot on the carrier board. You would not find a combination of a dev kit module (with SD card slot) and a third party carrier board.
If the SD card slot is on the module itself (for Nanos), then the boot chain is different than if the SD card slot is on the carrier board. Moving the slot from module to carrier board is not as simple as just moving hardware from one location to the next. There will be changes in device tree and power (and power has its own device tree changes).
Furthermore, the actual boot software differs between a dev kit with SD card slot on the module, versus booting to eMMC on a commercial module that does not have its own SD card slot. The movement of the SD card slot from module to carrier board requires changes to boot software and to the carrier board and to the device tree. You might find for example that the order of bringing up power rails differs, or that a driver not needed except in Linux is now needed in the boot chain.
If you built the carrier board, then you’ll have to make sure that the reboot provides the driver in the boot chain and not just in Linux. You’ll also have to be sure the device tree finds that hardware. If all of that is correct, but the boot order for bringing up power rails is wrong, then it can still fail. However, NVIDIA has no knowledge of the workings of the custom carrier board, nor of the customizations you might have made to boot chain. Describing the schematic might allow seeing issues like a need to change power delivery or part of boot software to support the SD card slot on carrier board during boot stages.
If you only use the SD card slot after Linux loads, then there is rarely any issue. Mostly. However, the Linux kernel inherits an environment (there is a literal set of environment variables the kernel has access to). If the Linux kernel relies on environment to be set up during boot chain, then it is still possible for the Linux kernel to fail to find or use the SD card slot on the carrier board. Perhaps you’ve added changes which get put into the boot environment and which are inherited by the Linux kernel only when cold booting. I couldn’t say for sure, but if you know everything that was required to make the SD card visible during cold boot, and can see some part of it is missing in soft boot, then you have an answer.
One thing that comes to mind is that sometimes devices need “training” to step through clocks and rail voltages in order to be set up at optimum speed. This would always occur during a cold boot. It is possible that a soft reboot skips training since the hardware is already set up; however, if one assumes the hardware is set up, but it gets reset, then unreliable clock timings might still exist (but only on soft boot).
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.