It gets through MB1 and MB2 boot stages, then fails, so early boot works. The video shows it did indeed boot, it just had issues with the user space environment. I will ask some questions which might be relevant:
- What is the exact byte size of your host side “
Linux_for_Tegra/system.img.raw” file after the flash?
- Is there anything at all unusual about the host PC itself?
- Was first boot setup done entirely on the Jetson, and without using the “
l4t_create_default_user.sh” script?
- Does this succeed from the host side:
sudo mount -o loop bootloader/system.img.raw /mnt
# ...edit "/mnt/boot/extlinux/extlinux.conf", remove any
# occurrence of the word "quiet".
# Use "cd" to exit "/mnt" and go back to "Linux_for_Tegra/"
sudo umount /mnt
There is something more unusual we could try. It is possible to flash on command line and reuse an existing image of the rootfs. The edited system.img.raw can be converted to system.img using this, assuming you are in “Linux_for_Tegra/bootloader/” of the host PC:
./mksparse --fillpattern=0 system.img.raw system.img
(you could just rename system.img.raw to system.img, but then flash would take a lot longer)
The reason for asking about the exact byte size of system.img.raw is that command line flash of any size other than default requires specifically naming the size.
It is possible to complete first boot setup in other ways as well, and normally one does this to the “Linux_for_Tegra/rootfs/” directory, and this is then generated into a system.img, but you loopback mount the edited system.img.raw on “Linux_for_Tegra/rootfs/”, complete the l4t_create_default_user.sh, and umount it, followed by conversion of the system.img.raw to system.img. What this will do is to give you exact control of the image to be flashed.
Normally the Linux_for_Tegra/rootfs/ is a “nearly” exact match to the final system.img, but minor edits occur based on the flash target. Making sure there is no “quiet” in the system.img, along with making sure first boot setup is complete in the actual system.img, then reusing that image, means you are pretty much guaranteed there is nothing being altered. If the fault is in the rootfs image, then you have a copy on the host which should have been correct.
This can also be command line flashed to reuse the image with an initrd flash.
I am convinced that at least the Linux kernel is running, and you would not have reached a desktop (working or not) if boot was not going significantly into user space. If the failure is one of the first boot setup, then editing like this will guarantee first boot setup if the image has the “l4t_create_default_user.sh” complete (and logging is guaranteed ok by removing “quiet” from extlinux.conf; you couldn’t guarantee this in the “Linux_for_Tegra/rootfs/boot/extlinux/extlinux.conf” since it is one of the boot files which might be changed during a normal flash).
Even if you don’t do all of this, then you could flash fresh, but use the “bootloader/l4t_create_default_user.sh” to complete the first boot setup and remove that from the boot before the flash even begins. You don’t have to do the loopback image edit, but you probably already have the image, and other than any edits you might make, it is known this is the exact match to the flashed content (you can control exactly what to change prior to flash reusing the image, but you won’t know that exactly nothing changed if flashing normally).
