Which preloader image to use?


(xbgmsharp) #1

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

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


(Alexey Loukianov) #3

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.


(Alexey Loukianov) #4

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?


(Alexey Loukianov) #5

@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?


BPI-R2 new image: OpenWrt 18.06.2 source code fork
(Alexey Loukianov) #6

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.


Boot fails with self-build u-boot