I have L4T24.1 on EMMC with other software, so I installed L4T24.2 on SD card by:
sudo tar xpf Tegra210_Linux_R24.2.0_aarch64.tbz2
cd Linux_for_Tegra/rootfs/
sudo tar xpf ../../Tegra_Linux_Sample-Root-Filesystem_R24.2.0_aarch64.tbz2
cd ../
sudo ./apply_binaries.sh
sudo ./flash.sh jetson-tx1 mmcblk1p1
but tx1 crashed in reboot loop with serial console print:
[ 15:30:27 ] Root device found: mmcblk1p1
Rootdevice found: /dev/mmcblk1p1
[ 9.571441] EXT4-fs (mmcblk1p1): 1 orphan inode deleted
[ 9.578457] EXT4-fs (mmcblk1p1): recovery complete
[ 9.788589] EXT4-fs (mmcblk1p1): mounted filesystem with ordered data mode. Opts: (null)
[ 15:30:27 ] Rootfs mounted over mmcblk1p1
[ 15:30:27 ] Switching from initrd to actual rootfs
[ 10.128171] init: plymouth-upstart-bridge main process (161) terminated with status 1
[ 10.138324] init: plymouth-upstart-bridge main process ended, respawning
[ 10.162466] init: plymouth-upstart-bridge main process (171) terminated with status 1
[ 10.172126] init: plymouth-upstart-bridge main process ended, respawning
[ 10.199269] init: plymouth-upstart-bridge main process (174) terminated with status 1
[ 10.209006] init: plymouth-upstart-bridge main process ended, respawning
[ 10.218207] init: ureadahead main process (164) terminated with status 5
[ 11.488598] Unable to handle kernel NULL pointer dereference at virtual address 0000002c
[ 11.499091] pgd = ffffffc00007d000
[ 11.504835] [0000002c] *pgd=000000017fc05003, *pmd=000000017fc06003, *pte=00e0000050041407
[ 11.515410] Internal error: Oops: 96000045 [#1] PREEMPT SMP
[ 11.523042] Enter nvdumper_crash_setup_regs
[ 11.530698] nvdumper: all registers are saved.
[ 11.530700] nvdumper: all registers are saved.
[ 11.530702] nvdumper: all registers are saved.
[ 11.550034] nvdumper: all registers are saved.
[ 11.556342] Modules linked in: bnep rfcomm bluedroid_pm
[ 11.563415] CPU: 2 PID: 421 Comm: krfcommd Not tainted 3.10.96-tegra #1
[ 11.571769] task: ffffffc0fdcde740 ti: ffffffc0f6738000 task.ti: ffffffc0f6738000
[ 11.581033] PC is at rfcomm_add_listener+0xa8/0x10c [rfcomm]
[ 11.588461] LR is at rfcomm_add_listener+0x98/0x10c [rfcomm]
[ 11.595858] pc : [<ffffffbffc008bb4>] lr : [<ffffffbffc008ba4>] pstate: 80000145
[ 11.605026] sp : ffffffc0f673bdc0
I have yet to put L4T on an SD card under 24.2, but some details about SD card mount might help you. First, you might consider only flashing to mmcblk0p1, which puts boot loader and configuration there. Then edit extlinux.conf with a new entry which can boot to SD card. Avoid putting more configuration on the SD card…mmcblk1p1 may be doing more than you wanted it to do if you are keeping R24.1 on eMMC. Basically, you would only put a rootfs on SD card and use the existing eMMC for mounting it.
Does your existing R24.1 still boot after removing the SD card?
Incidentally, you probably want to use “sudo ./flash.sh -S 14580MiB jetson-tx1 mmcblk0p1” so you get the maximum use of eMMC. The content on SD card would be independent of this when using mmcblk0p1.
Fortunately, this is my 2nd TX1 and I did not put much on it. I removed the SD card and could not boot to 24.1 on EMMC. I installed 24.2 on EMMC and was able to boot to it. I added 2nd config to extlinux.conf to boot to SD card and still got the same crash, but I was able to boot to default 24.2 on EMMC.
I did the same for 24.1 on the same SD card without issue, the SD card was ext4 formatted.
It appears there are bugs in 24.2 flash.sh or somewhere else for SD card installation.
On the SD card, make sure it is ext4 format. Default on most of those cards is VFAT, which does not have the ability to preserve all Linux file type traits. Strange things tend to happen when files are only partially correct.
Does the version pointing to SD card from eMMC extlinux.conf fail in the same exact way as from when you flashed to mmcblk1p1? If not, can you post another serial console log?
Note that some of the failures on the original appear to be file system corruption. You could put the SD on a desktop Linux host and run fsck.ext4 on that partition.
Regarding the extlinux.conf, are there any modifications other than pointing root to “/dev/mmcblk1p1”?
It may be that if something had been wrong with the file system and there was journal recovery that fsck.ext4 would not find any issues after mount had recovered the journal. I guess part of the question is why it needed recovery in the first place…this is always suspicious on boot failures because a clean file system with previous issues only means the partition is not corrupt…files or changes which caused the need to recover may still be damaged.
On extlinux.conf, did you change both “LABEL” and “MENU LABEL”? I doubt it would matter if you see something obviously from the correct entry, it’s just a case of being thorough.
In terms of originally creating the SD card, was this done from your host machine? Basically if the SD card is partitioned as type GPT (such as from gparted or gdisk) then the first partition would be the target. Using “sdb1” as the example, you would normally unpack sample rootfs from the sdb1 mount point using sudo. The apply_binaries.sh script would then be called with alternate arguments (also sudo) to name sdb1 as the unpack point. If sdb1 is mounted on “/mnt”, then something like this:
sudo ./apply_binaries -r /mnt
sudo umount /mnt
Is this how the SD card partition was created, or from the earlier flash to mmcblk1p1?
flash.sh does two things. One, it copies what is in the rootfs. However, it first makes some changes to some boot-related files, so it is not a direct copy of what is in the sample rootfs plus apply_binaries.sh. Changing the boot target under flash.sh (such as mmcblk0p1 versus mmcblk1p1) changes what goes where. You may find unpacking sample rootfs and using apply_binaries.sh on the SD rootfs more reliable and with fewer surprises than switching to mmcblk1p1 during flash.
I as well as at you had problems in attempt to launch 24.2 with SD of a card. pay attention that in relation to prior versions for start of system 24.2. the additional file / boot/initrd is necessary and it is also necessary to specify it in extlinux.conf. I installed system on eMMC and the extlinux.conf and initrd File I copy from eMMC on SD a card (to the similar place) and then I modify extlinux.conf replacing mmcblk0p1 with mmcblk1p1. The system is loaded, but unfortunately works very slowly :(, and I alas didn’t find the solution yet - can at you it will turn out. (For the 32nd bit jetpack 2.1 version this method allows to load system with eMMC in the absence of SD of a card, and system with SD of a card if it is set and everything works without notes).https://devtalk.nvidia.com/default/topic/965192/jetson-tx1/jetpack-2-3-for-jetson-tx1-released-with-l4t-r24-2-ubuntu-16-04-64-bit-cuda-8-and-tensorrt/3