Which preloader image to use?

xbgmsharp · January 7, 2018, 9:22am

There is multiple image available and wonder which one should i use?

BPI-R2-720P-2k.img.gz
BPI-R2-EMMC-boot0-DDR1600-0k-0905.img.gz

frank-w · January 7, 2018, 9:39am

first is uboot-image (not preloader) for SD-card and must begin at 2k (skip 2048 byte) as the name says.

http://fw-web.de/dokuwiki/doku.php?id=en/bpi-r2/uboot#update_uboot

second one is preloader for emmc (0k) which must be written to boot0-partition starting at byte 0 (from beginning)

http://fw-web.de/dokuwiki/doku.php?id=en/bpi-r2/storage#install_os_on_emmc

maybe it’s needed also for SD-card…have used my SD-Cards with jessie image and replaced only uboot, kernel and OS-files

the 0k/2k says where the image starts, see https://github.com/BPI-SINOVOIP/bpi-tools/blob/master/bpi-bootsel#L230 for details

for SD-Card-image https://github.com/BPI-SINOVOIP/BPI-R2-bsp/blob/3823964822219743e0fe785e04832813726862a1/scripts/bootloader.sh#L26 is the reference, here preloader_iotg7623Np1_emmc.bin is used

LeXa2 · May 5, 2019, 2:04am

A lot of time had passed since Jan 2018 and I think it is just the right time to revive this thread. So, what is the current situation w.r.t. preloader(s) for R2? Is there a single convenient place provided by vendor where I would find up-to-date preloader? Should I use the same preloader for EMMC and for SD card?

Asking this as I’m continuing my work on integrating R2 support into OpenWRT build system in a more “upstream-able” way compared to what is being offered by the vendor and I need to know what preloader(s) to use for this. Including binary blob into OpenWRT git tree is not an option so I’m looking for some “vendor official storage place” to fetch required files from at OpenWRT’s build time using OpenWRT’s built-in build system facilities.

LeXa2 · May 5, 2019, 3:22am

While waiting for the answer I went through all the available preloaders in https://github.com/BPI-SINOVOIP/BPI-files/tree/master/SD/100MB and https://github.com/BPI-SINOVOIP/BPI-R2-bsp/tree/master/mt-pack/mtk/bpi-r2/bin (including changes available in tag v1.2.1 but missing from master branch). Some of them were preloader-only files but some other turned out to be SDMMC_BOOT+BRYLT+preloader+uboot combos. Thus I used HxD hex editor and “normalized” all filed to contain only preloader and then went on and compared all them.

Result is pretty interesting as most of them turned out to be identical:

There 4 are identical: BPI-R2-720P-DDR1600-2k.img == BPI-R2-EMMC-boot0-DDR1600-0k.img == BPI-R2-preloader-2k.img == preloader_iotg7623Np1_sd_1600M.bin

These 7 are identical: BPI-R2-1080P-2k.img == BPI-R2-2k-EMMC-20180320.img == BPI-R2-2k-SD-20180320.img == BPI-R2-720P-2k.img == BPI-R2-EMMC-boot0-0k.img == preloader_iotg7623Np1_emmc.bin == preloader_iotg7623Np1_sd_1333M.bin

There are three “exceptions” that are uniq:

mtk-bpi-r2-preloader-emmc.bin
mtk-bpi-r2-preloader-sd.bin
BPI-R2-EMMC-boot0-DDR1600-0k-0905.img

Ones with name starting with “mtk-bpi-r2-preloader” came from this thread/repo: BananaPI BPI-R2 Openwrt18.06 Demo Image and Source Code Release 2019-03-06

Looking at file names it looks like that (a) preloader is the same for SD and EMMC and (b) main difference between preloaders is the speed that RAM gets initialized to, i.e. DDR1333 vs DDR1600.

Nevertheless, while these findings are interesting et al I still would like to get the “official” response from vendor representatives regarding where to look for “official” preloader image and - if there are two versions available differing in DDR freq - which one should I use?

LeXa2 · May 31, 2019, 3:48am

@garywang @Jackzeng @sinovoip Ping! I’m still looking for an official answer on my question above. May I ask you to comment on this please?

LeXa2 · June 16, 2019, 9:39pm

So, thanks to the “great support” from the vendor side, I have to continue my quest on investigating which bootloader does what. So far I had found 5 different preloader binaries for BPi R2 that were provided by the vendor at different times in different repos.

Here are my findings:

General behavior:

In case preloader is stored in eMMC and I do a “cold start” (disconnect power from the board, wait for at least 10 seconds, connect power back, press and hold power button) then board fails to boot unless I press the reset button while keep holding power button. Another way to make board boot is to release power button and then press and hold it again. Key point is not to disconnect power from the board between first and second presses on power button. Position of boot switch have no effect on this behavior.
The only thing boot switch does is a definition of a default source for preloader. If boot switch is set to SD then board first tries to init SD card and read preloader from it. In case SD card is not found (failed to init) then eMMC is used as a fallback. If boot switch is set to eMMC then SD card is ignored and eMMC is always used as a source.
Some versions of preloaders place four characters “eMMC” at memory address 0x81dffff0 to signal that u-boot was loaded from eMMC. Other preloaders do not touch memory at this area at all. It means that in case board was initially booted up with a preloader that set these four bytes to “eMMC” and then a reboot was done loading another preloader (due to: another SD card inserted, preloader updated on eMMC, you name it) that does not touch memory at 0x81dffff0 then chances are that memory at this address would still have “eMMC” no matter what was the real source for loading u-boot. Power cycling the board seems to reset bytes at this address back to FFFFFFFF. In other words - detection of the boot media based on the contents of the memory at this address is not reliable. The only fix is if vendor would release an updated preloader that will set memory at address 0x81dffff0 to some predefined value like "SD " if u-boot is loaded from the SD card.

Preloaders:

mtk-bpi-r2-preloader-sd.bin

This one was published here as a part of vendor’s attempt on OpenWrt 18.06 port for BPi R2. It is hardcoded to search and load u-boot from the SD card no matter the position of SD/eMMC switch or if the preloader was loaded from SD or eMMC. After booting to u-boot with this preloader memory at 0x81dffff0 is always ffffffff after the power cycle. In other words this one is only to be used with SD cards.

mtk-bpi-r2-preloader-emmc.bin

This is another one that was published here as a part of vendor’s attempt on OpenWrt 18.06 port for BPi R2. It is hardcoded to search and load u-boot from the eMMC no matter the position of SD/eMMC switch or if the preloader was loaded from SD or eMMC. After booting to u-boot with this preloader memory at 0x81dffff0 is always 434d4d65 (“eMMC”). In other words this one is only to be used with eMMC.

BPI-R2-720P-2k.img

Also known as: BPI-R2-1080P-2k.img, BPI-R2-2k-EMMC-20180320.img, BPI-R2-2k-SD-20180320.img, BPI-R2-720P-2k.img, BPI-R2-EMMC-boot0-0k.img, preloader_iotg7623Np1_emmc.bin, preloader_iotg7623Np1_sd_1333M.bin
This one is kind-a universal. Position of the boot switch seems to be ignored by the preloader. Instead no matter where the preloader was loaded from if an SD card is inserted then u-boot will be loaded from it. No checks performed to verify if what was loaded from SD card is really a u-boot binary or not. In case SD card is not inserted this preloader loads u-boot from eMMC. Memory at address 0x81dffff0 is always initialized to ffffffff after the power cycle no matter what was the boot media source for preloader or u-boot.

BPI-R2-720P-DDR1600-2k.img

Also known as: BPI-R2-720P-DDR1600-2k.img, BPI-R2-EMMC-boot0-DDR1600-0k.img, BPI-R2-preloader-2k.img, preloader_iotg7623Np1_sd_1600M.bin. Behavior is exactly the same as with one above (BPI-R2-720P-2k.img).

BPI-R2-EMMC-boot0-DDR1600-0k-0905.img

Available here. Behavior is exactly the same as for mtk-bpi-r2-preloader-emmc.bin.

frank-w · July 22, 2019, 1:33pm

@sinovoip is this string set via the preloader or where does it came from? can you set this string to SD if booted from SD? why is it only changed on power-cycle?

LeXa2 · August 12, 2019, 8:35am

Preloaders update:

BPI-R2-EMMC-boot0-DDR1600-20190722-0k.img.gz

Also known as: BPI-R2-preloader-DDR1600-20190722-2k.img.gz
This preloader was published here. Release highlight is the change of maximum u-boot binary size from 300000 to 524288 bytes. It allows to use u-boot with more features compiled in (like fatwrite support or pci + sata ahci). Preloader codebase seems to originate from BPI-R2-720P-2k.img instead of more recently released mtk-bpi-r2-preloader-emmc.bin/mtk-bpi-r2-preloader-sd.bin: no “eMMC” signature placed to 0x81dffff0 and “Boot from SD Card!!” or “Boot from eMMC!!” are printed in the bootlog to indicate the device u-boot is loaded from. More recent preloaders print “Load u-boot from SD Card...” or “Load u-boot from eMMC...” instead.

Except for increased u-boot load size behavior is the same as for BPI-R2-720P-2k.img. It makes this one a bad choice for enforced eMMC-only boot cases (for boards having hardware boot switch set to eMMC position) as preloader will always to load u-boot from SD card if one is inserted. No boot signatures are checked on SD card in such cases meaning that inserting any SD card without u-boot on it would lead to boot hang/failure.

frank-w · September 26, 2019, 11:52pm

@sinovoip can you add boot-signature (string of booted device to memory-address 0x81dffff0) to the recent preloaders? eMMC for emmc-image and SD to the sd-preloader

frank-w · October 15, 2019, 4:41pm

Ping to push thread on top for @sinovoip

frank-w · November 4, 2019, 6:17am

@sinovoip have you changed preloaders (at least for emmc)?

I guess sd-preloader cannot be changed if it is also loaded on emmc (like on r64) and will override emmc-string.

sinovoip · November 4, 2019, 6:34am

we have update BPI-R2 , please check it.

frank-w · November 4, 2019, 6:51am

As this differs from eMMC string,how can we now check for bootsevice in uboot? Which address is set to which byte (i guess 0xea).this should work too if sd is available but boot from emmc

it looks like you read boot signature from first bytes (SDMMC_BOOT vs. EMMC_BOOT) of mmc-device…but how is this passed to uboot?

sinovoip · November 4, 2019, 7:42am

The uboot code doesn’t need to change, just like before

frank-w · November 4, 2019, 7:46am

We should have EMMC string on memory address 0x81dffff0?

sinovoip · November 4, 2019, 8:00am

yes, R2 have update this code.

frank-w · November 4, 2019, 8:25am

Thank you, we will try this one: https://github.com/BPI-SINOVOIP/BPI-files/blob/master/SD/100MB/BPI-R2-EMMC-boot0-DDR1600-20191024-0k.img.gz

@LeXa2 can you try it too?

edit:

echo 0 > /sys/block/mmcblk1boot0/force_ro
gunzip -c BPI-R2-EMMC-boot0-DDR1600-20191024-0k.img.gz  | dd of=/dev/mmcblk1boot0 bs=1024 seek=0

seems to work well:

BPI-R2> md.b 0x81dffff0 4
81dffff0: 65 4d 4d 43                                        eMMC

i can also load bigger uboot (2020-01 with ahci-support, so it looks good so far)

LeXa2 · November 6, 2019, 8:27am

Sure will do, but not today - in a middle of house move right now. Probably would be able to test it on Friday.

frank-w · December 9, 2019, 7:37pm

Have you tested it? From my PoV it looks good

gamedeveloper · December 10, 2019, 12:27pm

Nice question, I would like to know deeply. Please clear it.