Hello Robert,
thanks for the answer. So may i sumarize how the BBAI boots:
The Am5729 on the BBAI boots like:
- Reset Vector in the Arm start from an internal firmware.
- The internal firmware knows how to read some sectors from SD/MMC
- The internal firmware loads the MLO/SPL from the SD/MMC
sudo dd if=./u-boot/MLO of=${DISK} count=2 seek=1 bs=128k
- The MLO loads u-boot.img also from some sectors on the SD/MMC
These are correct, the "sector" is documented and the same as am335x,
am57xx also supports reading the files from FAT file system.
sudo dd if=./u-boot/u-boot.img of=${DISK} count=4 seek=1 bs=384k
- u-boot.img loads uEnv.txt also from some sectors
For BeagleBoard.org, u-boot.img looks for /boot/extlinux/extlinux.conf
and then "uEnv.txt" in multiple locations on FAT, EXTx, and BTRFS..
For mainline u-boot, u-boot.img looks for /boot/extlinux/extlinux.conf
then /boot/uEnv.txt in multiple locations on fat/extX... (BTRFS not
built by default)
- u-boot loads kernel/fdt and initrd from the target partitions boot folder
For BeagleBoard.org, uEnv.txt set's the variables that load specific
kernel/initrd/dtb.
For Mainline, either it uses the generic extlinux.conf vales, or just
loads /boot/uImage...(aka defaults..)
- Linux starts.
Is this correct?
About the pinmux stuff nuked from mainline:
Does it mean, the kernel passed FDT from u-boot can be parsed from the kernel but any pinmuxing (say: set pins to i2c) can't be done from the kernel? Or is this FDT parsed from u-boot and pinmux set? As far as i know: u-boot has basic hardware knowledge in it [3][4]. Can only at this stage the pinmux be changed?
For "AM57xx", u-boot.img "Must" set the pinmux , while we update it in
teh device-tree, it's not teh 100% approved way..
On early versions of the BBB, the SD card had a partition 1 (W95 FAT32) and FS FAT16 and bootflag set. This partition contained MLO and u-boot.img. Like modern PC systems with their EFI partition. I still have images from 2014 with Angstrom linux which have this setup.
And 90% of the customer issues we faced at BeagleBoard.org, was
customers who "formatted" the FAT32 partition to get more space, and
then angrily returned it to the retailer as defective..
Why did u-boot/TI/whoever switch back to bootloaders in sectors like it was before EFI hit the PC system? Is this something that is different from SOC to SOC?
THUS, I nuked the split fat/ext4 partition as a support nightmary..
Customer failure returns dropped, I consider the sector method a
success for end user reliability of these specific SBC's....
Regards,
