Basicly bootrom calls bl2 (first part of atf) from bl2 partition (mmc) or offset 0x0 (spi nand/nor). This bl2 calls bl31 (second part of atf) which is packed with uboot into a fip (fip-partition on mmc or special offsets on nand/nor). Bl31 starts the uboot.
Bl2 (img file) contains the typical sdmmc_boot/emmc_boot header.
these files are started with EMMC_BOOT and SPINAND! respectively.
And the last question, did i get it right: the openwrt-mediatek-filogic-bananapi_bpi-r3-device-preloader.bin is a bl2; and the openwrt-mediatek-filogic-bananapi_bpi-r3-emmc-device-bl31-uboot.fip is a bl31+uboot in a single file.
Afair emmc is similar (but not verified yet). Nand/nor are different as there is no mbr/gpt before.
Sd and emmc gpt have i created with gpt-tool i’ve got from mtk. But daniel creates gpt in openwrt directly,have not yet took a deeper look into it (but i guess i need to do to avoid the issue in my image completely instead of fixing it afterwards).
On spi devices bl2 starts at offset 0x0
Imho only r2pro uses a spl uboot (with raminit blob), mtk do raminit and basic setup in bl2 without uboot and then calls “full” uboot with bl31. @dangowrt pls correct me if i’m wrong
Most magic is done here:
Afaik daniel has newer source of atf which does not use propritary bromimage tool from mtk
mhm…compared the json from mtk gpt-tool…and it looks like emmc has no bl2 partition…yes, bl2 needs to be on boot0 hardware partition…else there is no difference (except a dummy-partition from 0 to 33 to block the gpt itself which is present on emmc, but disabled for sdmmc)
I’ve briefly looked into the code. @frank-w and @dangowrt, would you please confirm or disprove the next concept:
bl2_boot_{devtype}.c are a parts of the implementations of the bl2-loader, responsible for loading the bl31 and the exact methon/device type is selected according to the boot header? (i.e bl2_boot_mmc.c - is for the EMMC_BOOT header; bl2_boot_snand.c is for the SPINAND! header; etc)
And therefore EMMC_BOOT uses the same method as the SDMMC_BOOT?
Yes the bl2_boot* is the bl2 as suggested by the name which loads the fip as next stage.
Spi devices from bpi-r3 are the spim-nand/nor.
Afair bootheader (e.g. sdmmc_boot) are only picked by bootrom and not from bl2 (it is header before bl2 afair added by bromimage tool to bl2.bin to get bl2.img).
Part of my r3-atf branch in u-boot-repo
But i look for a way to create gpt without it as the tool depends on python2 (no py3 support) and it seems to cause the gpt issue i fixed with the sgdisk export+import.
But i need to create the partitions to same offsets (at least bl2 and fip) to not break bootchain. I know a way with parted which i use for bpi-r2pro,but i want a way without installing additional tools (ok (s)gdisk needs to be installed too)
The change I’ve added to support using U-Boot’s mkimage instead of the binary-only bromimage tool was merged in @hackpascal’s TF-A sources on github as well:
So just use those, that’s also what we are doing for OpenWrt by now:
Hi,
I am looking for a little clarification.
If I start from a BPI-R3 where one has wiped the SPI-NOR, SPI-NAND, eMMC with all zeros.
Put the dip switches in boot from SD card mode.
Will it boot?
Or, does the boot process first need to read a small boot loader from SPI-NOR or SPI-NAND or eMMC before it can boot the SD Card?
R3 (and others) has bootrum which checks all bootable devices for the bl2 header…there is a page of output when it does not found it,if it found that header on the selected device it load it,then bl2 loads the fip (bl31+uboot)
Dip switches on r3 are bit tricky as c and d are important. One sets the spi chipselect,the other switches sd or emmc to mmc controller
