I guess frank you discovered how to compile bl2 
to work with 8GB?
I forgot one thing… Compilation should be done only on Intel/amd structure as atf uses cross compiling and all compilation on arm units fails
Yes i did crosscompile on amd64 host,but it seemed my old atf code missed something (got only 4gb recognized).with new atf code i needed to remove build dir to no get build errors,but then 8gb are detected
Should be ok, I’ve build it many times on aarch64.
With @frank-w’s new release, and the following script:
split() {
local in="$1"
local model="${2:-bpi-r4}"
local base="$(basename "${in}" .img)"
dd "if=${in}" bs=1024 count=17 "of=${base}-gpt.img"
dd "if=${in}" bs=1024 skip=6656 count=$((1024*44-6656)) "of=${base}-uboot-recovery.img"
dd "if=${in}" bs=1048576 skip=45 count=$((51-45)) "of=${base}-uboot-snand.img"
dd "if=${in}" bs=1048576 skip=52 "of=${base}-rest.img"
cp -f "${model}_sdmmc_8GB_bl2.img" "${base}-sdmmc-bl2.img"
dd "if=/dev/zero" "of=${base}-sdmmc-bl2.img" seek=$(((6656-17)*1024-1)) bs=1 count=1
cp -f "${model}_spim-nand_ubi_8GB_bl2.img" "${base}-spim-nand-bl2.img"
dd "if=/dev/zero" "of=${base}-spim-nand-bl2.img" seek=$((1024*1024-1)) bs=1 count=1
cp -f "${model}_emmc_8GB_bl2.img" "${base}-emmc-bl2.img"
dd "if=/dev/zero" "of=${base}-emmc-bl2.img" seek=$((1024*1024-1)) bs=1 count=1
rm -f "${base}-new.img"
cat "${base}-"{gpt,sdmmc-bl2,uboot-recovery,spim-nand-bl2,uboot-snand,emmc-bl2,rest}".img" > "${base}-new.img"
rm "${base}-"{gpt,sdmmc-bl2,uboot-recovery,spim-nand-bl2,uboot-snand,emmc-bl2,rest}".img"
}
gunzip "path-to-openwrt-sdcard-image.img.gz"
split "path-to-openwrt-image.img"
# flash path-to-openwrt-image-new.img
I managed to get 8GB to show up. Should we figure out how/what to upstream to OpenWrt next? What was the missing piece of the puzzle compared to your earlier release/
To be honest i do not undestand why such big script is needed when using my binaries (looks like you disassemble full image instead of replacing the bl2 only)…it should be a simple dd replacing openwrt bl2 with mine. Hardcoded offsets and overwriting something in the bl2.img looks somehow strange. Maybe you can comment why it is needed from your PoV?
Imho it does not make sense to create 8gb images where only bl2 differs. As 4gb works on both boards it would be enough if openwrt releases 8gb bl2 for all boot devices and tutorial to replace the 4gb bl2 in image and system.
Exactly i prefer to stay with 4gb images to create/compile and change later bl2 if needed for sd or emmc
Eric i dont know what happen on my aarch64 - maybe os or some libraries differ but this year i was not successful to compile bl2 on my standard dev env orangepi5+. I did IT on my laptop. Copy 1:1.
You’re absolutely right. I disassembled the sdcard image and replaced all 3 bl2 sections of the image. The hardcoded offsets are in the OpenWrt image building makefile.
I do this because that is the most surefire way to make sure a person who’s new to the device will get a working device to spec. This prevents:
- following the OpenWrt instructions and getting a different RAM capacity than expected
- picking the wrong bl2 to flash (there are 9 on your uboot release page)
- wondering why booting from each boot source gives a different amount of detected ram (because it was not obvious to me each source had a different bl2)
- and as a corollary, the method for flashing nand using the bootloader involves copying the bl2 from an unloaded bl2 of the sdcard
None of these are necessary – and you could say that it’s all rookie mistakes – but reduces the amount of problems a new user who wants to get up and running quickly would encounter. The tradeoff would be needing a different sdcard image.
I think it’s worth it, especially since in my case I have had to get documentation from this forum, OpenWrt docs, and the OpenWrt forum to assemble a set of instructions that can work. This would also hopefully reduce the number of times experienced folk have to answer repeated questions (on all the different sources of information).
But ultimately at the end of the day it’s for you and the other maintainers who should make a call on what’s desirable – few people would have the deep and intimate knowledge of the hardware as you would.
1 Like
by the way - my offer of trying to get this upstreamed to OpenWrt still stands. I would want a smooth user experience for users of this hardware. I’ll start with the commits I can identify from your uboot repository which affects bl2 and 8G RAM; may need you to chime in later on (or with @\dangowrt) if the OpenWrt maintainers have questions
2 Likes
Some neat way to include this directly into openwrt build env, maybe a patch or something?
I would very much appreciate a 8G image. Not only because it would be convenient, but also less error prone for users like myself.
I wasn’t able to make it work for emmc at all, because I got a permission error (as root) for /dev/mmcblk0boot0 from NAND when i try:
dd if=bl2emmc.img of=/dev/mmcblk0boot0
I could only make it work on when booting from sdcard and the aforementioned release (2025.01) of the bl2. not sure what to do for NAND and emmc.
i also tried it with the reconstructed image using the script by @lowjoel shell. this also only worked when booting from sdcard. Flashing this to NAND seemed to work, but on boot from NAND i got “system halt”.
with the latest release of the bl2 files (Release Build for branch 2025-04-bpi (2025.04) · frank-w/u-boot · GitHub) it boots, but the memory is show as 4G not 8G.
If a dedicated image could “just” make it work that would be great.
You used bpi-r4 8g_bl2.img?
It could be possible that 2025-04 files are broken because i only rebased 2025-01 patches and cleaned up pipeline to use only mtk-atf-2025. But this atf source was also used for 8g bl2 in 2025-01 so at least this should work.
yes, bpi-r4_sdmmc_8GB_bl2.img, bpi-r4_emmc_8GB_bl2.img and bpi-r4_spim-nand_ubi_8GB_bl2.img respectively
How is debug uart output on sdmmc? The 8g bl2 should not differ to 2025-01 uboot if i have no error in pipeline,but have not noticed one.
For nand i suggest writing from uboot.
For emmc i guess you need to set partconf and maybe bootbus. And imho linux blocks write access to boot partitions (maybe set force_ro to 0). Do you see them?
Edit: seems like i have to cleanup the bl2/fip files before running atf build again
edit2: could you try the new binaries from here:
hi i just tried them. unfortunately the 8G won’t get detected even on boot from sd card. I booted into uboot from sd and selected flashed to nand (because i feelt lucky) but still booted to openwrt to check the memory which was still at 4G 
sd-boot.log (92.4 KB)
Thats strange because ci pipeline looks good
Atf is built with DDR4_4BG_MODE=1 and renamed to bpi-r4_sdmmc_8GB_bl2.img afterwards. Or do you checked ram from nand boot? But your log shows sdcard boot and it looks like you have not replaced bl2 here
NOTICE: BL2: v2.12.0(release):d50bccad1-bpi-r4-sdmmc
NOTICE: BL2: Built : 11:36:00, May 25 2025
NOTICE: WDT: Cold boot
NOTICE: WDT: disabled
NOTICE: CPU: MT7988
NOTICE: EMI: Using DDR unknown settings
NOTICE: EMI: Detected DRAM size: 4096 MB
Build time is 4 days ago…you do not have to boot openwrt…you see detected ram in bl2 and uboot too.
Hi sorry for the late response come, i tried it on the weekend and got it to work after numerous attempts … 
it looks like my cheap usb sdcard-reader fooled me… 
i seems to make unreliable writes with dd. I will try to look for a new one…
one thing that i noticed are bad block notices. this doesn’t happen if i flash the rom linked on the bpi documentation, but this is a really old release.
The mtk sdk uses propritary nmbm for some kind of wear leveling,but mainline uboot does not,so maybe crc checks or similar are different.