Boot Android from SATA sda1 with u-boot

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.

CONFIG_SCSI_MULTI_LUN=y
CONFIG_ATA=y
CONFIG_SATA_AHCI=y
CONFIG_SATA_AHCI_PLATFORM=y
CONFIG_SATA_AHCI_TEGRA=y

CONFIG_TEGRA_SATA_IDLE_POWERGATE is not set

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.

I will post my kernel args also in a bit…

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:

The flash command and kernel args are set as:

./flash.sh -L bootloader/ardbeg/u-boot.bin jetson-tk1 sda1

I kept my android kernel zImage in /boot on sdcard also for sda1 boot and my rootfs for android is all setup for tegra-sata.0 in init and fstab

and

TIMEOUT 30
DEFAULT primary

MENU TITLE Jetson-TK1 USB boot options

LABEL primary
MENU LABEL primary kernel
LINUX zImage
FDT tegra124-pm375.dtb
APPEND console=ttyS0,115200n8 console=tty1 no_console_suspend=1 lp0_vec=2064@0xf46ff000 video=tegrafb mem=1862M@2048M memtype=255 ddr_die=2048M@2048M section=256M pmuboard=0x0177:0x0000:0x02:0x43:0x00 vpr=151M@3945M tsec=32M@3913M otf_key=c75e5bb91eb3bd947560357b64422f85 usbcore.old_scheme_first=1 core_edp_mv=1150 core_edp_ma=4000 tegraid=40.1.1.0.0 debug_uartport=lsport,3 power_supply=Adapter audio_codec=rt5640 modem_id=0 android.kerneltype=normal usb_port_owner_info=0 fbcon=map:1 commchip_id=0 usb_port_owner_info=0 lane_owner_info=6 emc_max_dvfs=0 touch_id=0@0 tegra_fbmem=32899072@0xad012000 board_info=0x0177:0x0000:0x02:0x43:0x00 root=/dev/sda1 rw rootwait

for extlinux.conf

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.

Thanks for the clarification linuxdev, your knowledge is very helpful!

So for Android boot args in extlinux.conf my ara emmc boot keeps the default l4t and jedroid has this in extlinux.conf:

TIMEOUT 30
DEFAULT primary

MENU TITLE Jetson-TK1 SD Card boot options

LABEL primary
MENU LABEL primary kernel
LINUX zImage
FDT tegra124-pm375.dtb
APPEND androidboot.hardware=jedroid init=init console=ttyS0,115200n8 console=tty1 vmalloc=500M no_console_suspend=1 lp0_vec=2064@0xf46ff000 video=tegrafb mem=1862M@2048M memtype=255 ddr_die=2048M@2048M section=256M pmuboard=0x0177:0x0000:0x02:0x43:0x00 vpr=151M@3945M tsec=32M@3913M otf_key=c75e5bb91eb3bd947560357b64422f85 usbcore.old_scheme_first=1 core_edp_mv=1150 core_edp_ma=4000 tegraid=40.1.1.0.0 debug_uartport=lsport,3 power_supply=Adapter audio_codec=rt5640 modem_id=0 android.kerneltype=normal usb_port_owner_info=0 fbcon=map:1 commchip_id=0 usb_port_owner_info=0 lane_owner_info=6 emc_max_dvfs=0 touch_id=0@0 tegra_fbmem=32899072@0xad012000 board_info=0x0177:0x0000:0x02:0x43:0x00 root=/dev/sda1 rw rootwait

As you can see the difference is here: androidboot.hardware=jedroid init=init

So MAYBE I have to set the correct hardware since my builds are plain jetson not jedroid:

Use this perhaps?

androidboot.hardware=jetson init=init

Just some notes, as I’m not sure if the above is an excerpt, the whole extlinux.conf file, etc.

  1. I suggest just flashing an ordinary eMMC install of JTK1, e.g.:
    sudo ./flash.sh

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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).