Boot from SD Card

Linuxdev and Maghoumi,

Let me clarify a little: I installed Jetpack 2.2.1 on eMMC and Jetpack 2.1 on SD. Jetpack 2.2.1 on eMMC could boot normally and enter ubuntu desktop, Jetpack 2.1 on SD could boot normally except neither terminal nor ubuntu desktop could be launched (I could ssh to it successfully though). I used two extlinux.conf files to switch between these boot sources. Here is a log I just got after boot from SD:

ubuntu@tegra-ubuntu:~ df -H -T Filesystem Type Size Used Avail Use% Mounted on /dev/root ext4 32G 2.6G 28G 9% / devtmpfs devtmpfs 1.9G 4.1k 1.9G 1% /dev none tmpfs 4.1k 0 4.1k 0% /sys/fs/cgroup none tmpfs 405M 959k 404M 1% /run none tmpfs 5.3M 0 5.3M 0% /run/lock none tmpfs 2.1G 0 2.1G 0% /run/shm none tmpfs 105M 0 105M 0% /run/user ubuntu@tegra-ubuntu:~ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
mmcblk0rpmb 179:16 0 4M 0 disk
mmcblk0 179:0 0 14.7G 0 disk
├─mmcblk0p1 179:1 0 14G 0 part
├─mmcblk0p2 179:2 0 2M 0 part
├─mmcblk0p3 179:3 0 4M 0 part
├─mmcblk0p4 179:4 0 2M 0 part
├─mmcblk0p5 179:5 0 6M 0 part
├─mmcblk0p6 179:6 0 4M 0 part
├─mmcblk0p7 179:7 0 6M 0 part
├─mmcblk0p8 179:8 0 2M 0 part
├─mmcblk0p9 179:9 0 2M 0 part
├─mmcblk0p10 179:10 0 20M 0 part
├─mmcblk0p11 179:11 0 64M 0 part
├─mmcblk0p12 179:12 0 64M 0 part
├─mmcblk0p13 179:13 0 4M 0 part
├─mmcblk0p14 179:14 0 2M 0 part
├─mmcblk0p15 179:15 0 6M 0 part
├─mmcblk0p16 259:0 0 6M 0 part
├─mmcblk0p17 259:1 0 2M 0 part
└─mmcblk0p18 259:2 0 496M 0 part
mmcblk1 179:32 0 29.8G 0 disk
└─mmcblk1p1 179:33 0 29.8G 0 part /
ubuntu@tegra-ubuntu:~ ls /media/ eMMC ubuntu@tegra-ubuntu:~ sudo mount /dev/mmcblk0p1 /media/eMMC
[sudo] password for ubuntu:
ubuntu@tegra-ubuntu:~ cd /media/eMMC/boot/extlinux/ ubuntu@tegra-ubuntu:/media/eMMC/boot/extlinux ls
extlinux.conf extlinux.conf.emmc extlinux.conf.orig extlinux.conf.sd
ubuntu@tegra-ubuntu:/media/eMMC/boot/extlinux$ cat extlinux.conf
TIMEOUT 30
DEFAULT sdcard

MENU TITLE p2371-2180 eMMC boot options

LABEL primary
MENU LABEL primary kernel
LINUX /boot/Image
FDT /boot/tegra210-jetson-tx1-p2597-2180-a01-devkit.dtb
APPEND fbcon=map:0 console=tty0 console=ttyS0,115200n8 androidboot.modem=none androidboot.serialno=P2180A00P00940c003fd androidboot.security=non-secure tegraid=21.1.2.0.0 ddr_die=2048M@2048M ddr_die=2048M@4096M section=256M memtype=0 vpr_resize usb_port_owner_info=0 lane_owner_info=0 emc_max_dvfs=0 touch_id=0@63 video=tegrafb no_console_suspend=1 debug_uartport=lsport,0 earlyprintk=uart8250-32bit,0x70006000 maxcpus=4 usbcore.old_scheme_first=1 lp0_vec={lp0_vec} nvdumper_reserved={nvdumper_reserved} core_edp_mv=1125 core_edp_ma=4000 gpt android.kerneltype=normal androidboot.touch_vendor_id=0 androidboot.touch_panel_id=63 androidboot.touch_feature=0 androidboot.bootreason=pmc:software_reset,pmic:0x0 root=/dev/mmcblk0p1 rw rootwait

LABEL sdcard
MENU LABEL sdcard kernel
LINUX /boot/Image
FDT /boot/tegra210-jetson-tx1-p2597-2180-a01-devkit.dtb
APPEND fbcon=map:0 console=tty0 console=ttyS0,115200n8 androidboot.modem=none androidboot.serialno=P2180A00P00940c003fd androidboot.security=non-secure tegraid=21.1.2.0.0 ddr_die=2048M@2048M ddr_die=2048M@4096M section=256M memtype=0 vpr_resize usb_port_owner_info=0 lane_owner_info=0 emc_max_dvfs=0 touch_id=0@63 video=tegrafb no_console_suspend=1 debug_uartport=lsport,0 earlyprintk=uart8250-32bit,0x70006000 maxcpus=4 usbcore.old_scheme_first=1 lp0_vec={lp0_vec} nvdumper_reserved={nvdumper_reserved} core_edp_mv=1125 core_edp_ma=4000 gpt android.kerneltype=normal androidboot.touch_vendor_id=0 androidboot.touch_panel_id=63 androidboot.touch_feature=0 androidboot.bootreason=pmc:software_reset,pmic:0x0 root=/dev/mmcblk1p1 rw rootwait
ubuntu@tegra-ubuntu:/media/eMMC/boot/extlinux$

Hopefully it’s clear now.

I have two nodes, one with L4T 24.1 I installed with the older jetpack and one with 24.2 which I installed with the newer jetpack on their emmc. I followed instructions and I have no problem when I’m using my SD card on the node that has the same version of L4T on its emmc, it boots to SD card perfectly and I checked it boots up to the sd card. But when I try to boot up the node that has a different version of L4t (installed with different jetpack) in the internal emmc, it never boots: Here is the log I when I tried to put the sd card of 24.1 to the one that has 24.2 on emmc:

1823 bytes read in 436 ms (3.9 KiB/s)
p2371-2180 eMMC boot options
1: SD Card
2: internal EMMC
Enter choice: 1: SD Card
Retrieving file: /boot/Image
19400088 bytes read in 923 ms (20 MiB/s)
append: fbcon=map:0 console=tty0 console=ttyS0,115200n8 androidboot.modem=none androidboot.serialno=P2180A00P00940c003fd androidboot.security=non-secure tt
Retrieving file: /boot/tegra210-jetson-tx1-p2597-2180-a01-devkit.dtb
304910 bytes read in 511 ms (582 KiB/s)
## Flattened Device Tree blob at 82000000
Booting using the fdt blob at 0x82000000
reserving fdt memory region: addr=80000000 size=20000
Using Device Tree in place at 0000000082000000, end 000000008204d70d
Can’t create DT prop nvidia,emc-save-restore-mod-regs to copy
Can’t create DT node emc-table@102000 to copy
Can’t create DT prop reg to copy
ERROR: could not update sku property FDT_ERR_NOSPACE.
ERROR: board-specific fdt fixup failed: FDT_ERR_NOSPACE
– must RESET the board to recover.

FDT creation failed! hanging…### ERROR ### Please RESET the board ###

After some googling, it seems this error is due to the difference device tree of the internal emmc (needed before rootfs get mounted from sd card) and the sd card. Did I get it right? is there any easy solution? Does this mean I only can use my sd card on the same version of that jetpack installed on emmc?

I see I missed replying to @Dalvik’s post…for the GUI not showing up, see if this checks out:

sha1sum -c /etc/nv_tegra_release

For the device tree question from @reza_azimi, the device tree would probably differ between R24.1 if 32-bit user space (this is optional depending on sample rootfs for R24.1) versus R24.2 (which is always 64-bit user space). The extlinux.conf FDT key/value pair does give you the possibility of using different dtb files depending on which you choose. If the extlinux.conf is on eMMC, then both dtb files would need to be there; if the extlinux.conf is on SD card, then you might expect to need FDT files there…best safety is to put both FDT files on both SD and eMMC. Use the FDT entry to try and use the right dtb filefor R24.1 versus R24.2. If this still fails, then you could start looking for other causes.

Thank you linuxdev for reply, let me clarify something, I am using the 64 bit version of R24.1 and the extlinux files exist on both SD card and emmc, but whenever SD card is in place it first read the extlinux.conf from SSD and from the difference between the two (emmc doesn’t have SD card and the SD card one has SD card option), I am sure I’m using the SD card one.

So here is what I did, I have a SD card that boots to the R24.1(64 bit) just fine on the machine that has 24.1 on their emmc. I renamed the dtb file on the sd card and added “new” to it and modified the extlinux.conf accordingly. Then I copy the new dtb file on the emmc of a node with 24.2.1 so it has 2 .dtb file in the /boot directory of mmc, its original one and one for the R24.1 for the SD card, also I copied the one in the emmc to the SD card /boot. Still, I can’t boot :(. I can see in the logs that it’s trying to read the new dtb file which exists on both emmc and SD card. I don’t want to mess anything on the emmc of my working nodes since I have alot of stuff on them. Is there anything else I need to copy that I didn’t understand (except tegra210-jetson-tx1-p2597-2180-a01-devkit.dtb)?

Is there a chance the uboot has a different structure between these two since they belong to two different jetpack and that’s why it can’t boot? the boot directory of 24.2.1 has an extra efi directory and its initrd file is 6.6 MB compare to 0 on 24.1.

here is the log, you can see it tries to use the tegra210-jetson-tx1-p2597-2180-a01-devkit-new.dtb which exists on both emmc and SD card. One more thing that confuse me more is that I can use this SD card on the nodes that has originally 24.1 on their emmc and doesn’t have the tegra210-jetson-tx1-p2597-2180-a01-devkit-new.dtb on their emmc which means its existence on the SD card should be enough.

p2371-2180 eMMC boot options
1:      SD Card
2:      internal EMMC
Enter choice: 1:        SD Card
Retrieving file: /boot/Image
19400088 bytes read in 922 ms (20.1 MiB/s)
append: fbcon=map:0 console=tty0 console=ttyS0,115200n8 androidboot.modem=none androidboot.serialno=P2180A00P00940c003fd androidboot.security=non-t
Retrieving file: /boot/tegra210-jetson-tx1-p2597-2180-a01-devkit-new.dtb
304910 bytes read in 432 ms (688.5 KiB/s)
## Flattened Device Tree blob at 82000000
   Booting using the fdt blob at 0x82000000
   reserving fdt memory region: addr=80000000 size=20000
   Using Device Tree in place at 0000000082000000, end 000000008204d70d
Can't create DT prop nvidia,emc-save-restore-mod-regs to copy
Can't create DT node emc-table@102000 to copy
Can't create DT prop reg to copy
ERROR: could not update sku property FDT_ERR_NOSPACE.
ERROR: board-specific fdt fixup failed: FDT_ERR_NOSPACE
 - must RESET the board to recover.

FDT creation failed! hanging...### ERROR ### Please RESET the board ###

First, just a tip when working with more than one location which might have the extlinux.conf under different circumstances. The “MENU LABEL” line could have “SD”, “MMC”, “USB”, or “SATA” added to the label depending on which file you are talking about. There would never be doubt under serial console which one is actually booting. Have all support files as exact duplicates on all boot directories, though naming might differ. E.G., if the dtb file is the same, don’t rename it…have different dtb modifications using different names…place all files of all names on all “/boot” partitions (some won’t be used, but if something unexpected occurs, you’ll be glad you have copies on all devices).

Comment: If R24.1 is on eMMC, then boot to SD probably uses eMMC extlinux.conf, and eMMC “/boot” files. Any files you add to eMMC with alternate names is not a risk…feel free to experiment if the original extlinux.conf entry remains and serial console is used to select alternate boot entries. If flash were to SD, then this would no longer work, the boot loader would look at SD card “/boot” and extlinux.conf.

At the point where it says it read so many bytes while retrieving the dtb file you are guaranteed that read failure is not a problem. Should the same file name on any other “/boot” be a duplicate of this file, then you don’t even care for now if it was the right version…they’d all be the same for that name.

I don’t know what the dtb file changes were, but it seems that if the file is read but breaks during use that the edits are wrong.

I’ve not seen this before, but it seems pretty descriptive in the boot log:

ERROR: could not update sku property FDT_ERR_NOSPACE.
ERROR: board-specific fdt fixup failed: FDT_ERR_NOSPACE

I’m thinking something about partitioning or memory reserve left no room for the device tree. Can anyone at NVIDIA share the specific meaning of “FDT_ERR_NOSPACE” during boot loader read of the dtb?

I copied my Image and dtb file (renamed it and boot on both SD and emmc), didn’t work.
Somewhere I read I need a initrd entry on my extlinux.conf, didn’t work.
When I put the 24.1 SD card on a machine that has 24.1 using the jetpack without the renamed files of SD card, it is working so my guess is the copying files to emmc shouldn’t be the solution since it tries to read them from SD card on the working machines and working machines doesn’t have the renamed files of SD card on their emmc.

I found the same error here:
https://devtalk.nvidia.com/default/topic/979351/fdt-creation-failed-can-t-get-new-kernel-compiled-from-source-to-boot-/

Apparently, it is something related to the jetpack version installed on the emmc, the last message author said he used the latest jetpack and its working. It’s the same error that I’m getting and my SD card works on the nodes with the same jetpack.

Is there any Nvidia documentation about dual boot TX1 boards with different versions?

The R24.1 does not use the INITRD entry, R24.2.1 does. There is no dtb file in the INITRD, but code there could conceivably be related to whether the INITRD works because the firmware needs to match. Simply leave out the INITRD entry on the R24.1 case, use the default INITRD for R24.2.1.

I am still wondering what the meaning was for:

ERROR: could not update sku property FDT_ERR_NOSPACE.
ERROR: board-specific fdt fixup failed: FDT_ERR_NOSPACE

If anyone can comment this might provide a clue as to why the FDT file was found but unable to load.