I just followed the correct procedure to boot Android (using jedroid instructions) to SATA and with u-boot/extlinux set to boot root=/dev/sda1 and using my custom kernel that boots fine on emmc the boot logs stop right when u-boot gets to loading zImage. Ubuntu boots just fine with the l4t kernel on the same sata drive.
What could this possibly be? Am i missing something needed in my defconfig to recognize the tegra-sata.0? This tegra-sata.0 is not in my /sys/devices/block/platform/ and sda1 is not in /dev/block/ so something is wrong.
I did notice digging around that my android tegra kernel source has no ata includes directory with sata defines in the dts includes directory but in l4t kernel source there is an includes ata directory. I tried to add the ata includes directory to my android kernel but still no tegra-sata.0 in sys.
Could someone please shed some light on booting Android to SATA? Is there some patches I am missing? I have all my init files and fstab set for tegra-sata.0 the only problem is there is no tegra-sata.0 node created by my kernel.
Ubuntu boots just fine with the l4t kernel on the same sata drive.
I don’t know about Jedroid, but probably the first thing I’d wonder about is if your boot loader is the one from L4T R21.4 (which I know is capable of handing off to SATA), and what, within extlinux.conf, are the Jedroid kernel parameters (and if they match the standalone Jedroid install parameters, other than root device)? What was the source of determining the kernel “APPEND” line in extlinux.conf?
Basically, zImage should be readable if the boot loader hands off, even if the rest of the boot is not successful. Once zImage is being read, having the correct kernel arguments probably limits failure possibilities to firmware or init.
Okay I am using uboot I will try the updated uboot from 21.4. Thanks for the tip. Now would i use the same fastboot.bin from 21.4? My flash script has -L bootloader set to uboot but my cfg loads fastboot.bin as the boot loader.
fastboot.bin is actually used in recovery mode internally (apparently called the 3pserver). This is not permanently installed during the flash process, but it is used to temporarily enable flashing hardware even when u-boot is the final boot loader. So flash R21.4 using defaults (other than perhaps “-S 14580MiB”), and you will get u-boot.
Once flashed, you no longer need a flash to install a new kernel or firmware.
Well I tried an updated u-boot and android didnt boot properly so i tried to set the bootloader to u-boot instead of fastboot and still no boot. No serial logs cause the boot process didnt even start.
When you say flash using defaults im not sure there is a default for android.
I am using the more freely open-source jetson tree from the ara project:
Now my DTB is appended with the ara kernel source so that may be my issue. Now i am building the NVIDIA sources linked here at nvidia devtalk to see if I get different results or hopefully a tegra-sata.0 in /sys/devices/platform/
Any ideas why there wouldn’t even be a tegra-sata.0 device in /sys?
By “default” I mean default for flashing L4T R21.4. You can install a working L4T in eMMC, and still aim the boot loader to run Android on sda1. Whatever would be in the boot directory of sda1 would instead be in boot of eMMC…this is where u-boot would look for files prior to mounting any alternate root partition. This includes the kernel and any firmware or dtb. Finding extlinux.conf and files pointed at in eMMC, you can still name your root partition as sda1 (an edit of extlinux.conf). What makes it Android versus L4T is not the boot loader, but where the boot loader transfers to root partition at; so long as the kernel image and firmware were from Android, it won’t care that the image is located in boot of eMMC or sda1.
You should be able to run an ordinary L4T install with no issue, side-by-side with Android. If you determine you no longer want L4T, you could simply leave the boot partition on eMMC in tact and remove everything else…just don’t point the extlinux.conf entry to mmcblk0p1 anymore (FYI, depending on the boot loader is set up, it may be that you need to state “mmcblk1p1” instead of “sda1”…I believe at one point in time stating mmcblk1p1 in extlinux.conf would search both SD card and SATA, picking the first one with a bootable file system).
About extlinux.conf…the APPEND argument is the set of arguments passed to the kernel as it boots. The defaults in extlinux.conf apply to L4T. You could do everything correct, but use the wrong kernel argumets, and it wouldn’t boot. You have to look at your Android kernel boot arguments and use those in the APPEND line of the Android boot section of extlinux.conf.
Just some notes, as I’m not sure if the above is an excerpt, the whole extlinux.conf file, etc.
I suggest just flashing an ordinary eMMC install of JTK1, e.g.:
sudo ./flash.sh
Add a duplicate of that default entry, but you’d have to rename the LABEL and MENU LABEL of the alternate entry (use serial console to select the entry to boot until you have tested). Advice: Leave the original L4T as default until you’ve tested Android…then you can swap the entry LABEL and MENU LABEL.
Although I suspect they are the same thing, I’d double check to be sure the dtb file is the same between Android and L4T…these can also be renamed before placing in /boot in order to have independent entries if you so desire.
The Jedroid should have a file somewhere (perhaps even an extlinux.conf file of its own if it uses u-boot) with an APPEND line which you can duplicate for your own APPEND line. The only edit would be what you seem to have already found, the “root=/dev/sda1” entry, which would replace mmcblk0p1.
Don’t bother with figuring out the sample extlinux files for “jetson-tk1_extlinux.conf.emmc” versus “jetson-tk1_extlinux.conf.nfs” versus “jetson-tk1_extlinux.conf.sdcard” versus “jetson-tk1_extlinux.conf.usb”. These are mainly about the “root=” APPEND line which you are already dealing with.
If the Android install has something in /lib/firmware/ (and I don’t know if it does), you may want a copy of this both in eMMC and on the SATA drive (the reason being that I don’t know which files would need access before or after handing off to the kernel).