[BPI-R4] Successfully upgraded 8GB RAM on BPI-R4

lowjoel · April 6, 2025, 12:05am

I reconstructed the Openwrt sdcard image using your patched bl2. Did a power cycle (seems like bl2 is only used for cold boot), and while I do get to userspace I’m still seeing 4gb memory. Any way to debug this without UART (I have not got one yet)?

I checked Openwrt main branch and it seems they have upgraded to uboot 2025.01, which contains mediatek-openwrt/arm-trusted-firmware@e0907706 where DDR4_4BG_MODE defaults to 1. Your other commit to add AVAIL_DRAM_SIZE := 1024 2048 4096 however doesn’t yet exist.

I’ll hold onto the patch until we figure out why the bl2 I got from your repo still doesn’t detect 8gb RAM.

frank-w · April 6, 2025, 6:42am

I only applied the known changes for 8gb…possibly i missed something as i could not test it (will get a 8gb and 2g5 phy board next week).

But defaulting to 4bg-mode will break the 4g versions of r4.so i don’t think it will be the case.

But everyone can see changes and the ci pipeline to follow whats done to build the files…maybe someone having 8gb working sees the missing part

Debugging this without uart is imho impossible.

sinovoip · April 7, 2025, 3:09am

frank-w · April 7, 2025, 5:18pm

got my r4 with 8GB ram today

tested image with default ram-setting: 4GB shown but working so far
flashed 8gb variant from my repo, still 4GB
noticed that i had 2 dram-settings set (DRAM_USE_COMB=1 DDR4_4BG_MODE=1) and dropped the USE_COMB=1, but then i see this:

NOTICE:  EMI: DDR4 4BG mode                                                                                                                       
NOTICE:  EMI: Using DDR3 settings                                                                                                                 
NOTICE:  EMI: Detected DRAM size: 0 MB

@tombpi @drozdi70 @wwwing any idea? possibly my mtk-atf version is too old, i see some changes in mtk-original atf, tried using latest atf but failed due to missing files

make: *** No rule to make target 'plat/mediatek/common/drivers/efuse/mtk_efuse.c', needed by '/media/data_ext/git/uboot/u-boot/build/mt7988/release/bl2/mtk_efuse.o'.  Stop.

same for plat/mediatek/common/drivers/mmc/mtk-sd.c, plat/mediatek/common/drivers/spi/mtk_spi.c, plat/mediatek/mt7988/drivers/wdt/mtk_wdt.c

last one has multiple conflicts when i try to cherry-pick from my old tree

Dot_Brian · April 7, 2025, 8:27pm

Unfortunately, I also wasn’t able to get my BPi-R4 to recognize the full 8GB of RAM using the 8GB variant from your repo.

Now, I must say I have far less experience than you when it comes to using OpenWrt with BPi, so what I’m going to share below might be obvious to you, but I’m posting it anyway in case it helps someone who just received their new board.

My goal was to run OpenWrt from the eMMC. From my testing, the only way I managed to get all 8GB recognized was:

The fastest and most straightforward method is using the official image from the BPi documentation specifically made for the R4-8GB:

The advantage is that you can be up and running with full RAM support within minutes. The downside is that the image is based on a relatively old version of OpenWrt (I believe it’s 21.02) and it’s a snapshot, which makes updating packages via opkg a bit tricky.

The second option works with any OpenWrt version and allows to use the full 8GB:
I used the official OpenWrt Firmware Selector and picked the latest stable release, 24.10. After selecting the packages I needed, I wrote the image to an SD card and used it to install OpenWrt to the NAND using U-Boot, and from NAND to eMMC.

This results in OpenWrt 24.10 being installed to eMMC (also on SD and Nand) but initially, only 4GB of RAM is detected.

To fix that, I booted OpenWrt again from NAND and re-flashed the BL2 partition of the eMMC using the bl2_emmc_8g.img file (same one included in the snapshot 21.02 files I mentioned above).

Here’s the process I used while booted into NAND:

echo 0 > /sys/block/mmcblk0boot0/force_ro
dd if=bl2_emmc_8g.img of=/dev/mmcblk0boot0
mmc bootpart enable 1 1 /dev/mmcblk0

After rebooting from eMMC, the system properly detected the full 8GB while still running the stable OpenWrt 24.10.

That’s how I got it working using prebuilt images. It would definitely be ideal to learn how to build them properly and update your repo to support the R4-8GB variant out of the box.

Besides @tombpi @drozdi70 @wwwing I believe @meehien might also be able to help, since they mentioned in the thread below that they managed to build the BL2 image themselves:

Tombpi · April 8, 2025, 3:15am

Maybe check the RDA, RDB, RDC resistors on the PCB. There is a small chance that the wrong components were installed at the factory.

wwwing · April 8, 2025, 3:28am

Liujie suggested to close DRAM_USE_COMB=1 He builded a BL2 for Openwrt 21 version, for 8GB RAM, you can refer it: bl2 8g.rar - Google Drive

frank-w · April 8, 2025, 4:31am

You mean drop this?

I got it working with new atf code after some hassle (incomplete make clean) and poweroff issue.

drozdi70 · April 8, 2025, 4:19pm

for SD card write this (starting from SD card)

dd if=bl2sd.img of=/dev/mmcblk0p1

for eMMC write this (starting from NAND)

dd if=bl2emmc.img of=/dev/mmcblk0boot0
dd if=openwrt-mediatek-filogic-bananapi_bpi-r4-sdcard.img of=/dev/mmcblk0 (or antoher image)
mmc bootpart enable 1 1 /dev/mmcblk0

old versions but still working for my board. I noticed that recently arm-trusted-firmware-mediatek package has some issues and not compiling well bl2 files. Now my board is in pieces and Im focused on some other projects. I will check out that later

Files can be taked from here

drozdi70 · April 8, 2025, 4:36pm

General idea is folllowing in arm-trusted-firmware-mediatek package:

openwrt/package/boot/arm-trusted-firmware-mediatek/Makefile add support DDR4_4BG_MODE:=1 (in sections Trusted-Firmware-A/mt7988-*comb)

it should be also enabled DRAM_USE_COMB:=1

dram-configs.mk files for mt7988 add 4096 to AVAIL_DRAM_SIZE

./arm-trusted-firmware-mediatek-mt7988-sdmmc-comb/arm-trusted-firmware-mediatek-2024.01.17~bacca82a/plat/mediatek/mt7988/drivers/dram/dram-configs.mk
./arm-trusted-firmware-mediatek-mt7988-spim-nand-ubi-comb/arm-trusted-firmware-mediatek-2024.01.17~bacca82a/plat/mediatek/mt7988/drivers/dram/dram-configs.mk
./arm-trusted-firmware-mediatek-mt7988-emmc-comb/arm-trusted-firmware-mediatek-2024.01.17~bacca82a/plat/mediatek/mt7988/drivers/dram/dram-configs.mk
./arm-trusted-firmware-mediatek-mt7988-ram-comb/arm-trusted-firmware-mediatek-2024.01.17~bacca82a/plat/mediatek/mt7988/drivers/dram/dram-configs.mk

more or less

!!! Just one thing… I heard that changes in arm-trusted-firmware-mediatek package as above could impact that image you compile could not work for users with 4GB board. Please validate it…

frank-w · April 8, 2025, 8:55pm

updated pipeline+release

drozdi70 · April 11, 2025, 8:20pm

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

frank-w · April 11, 2025, 8:36pm

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

ericwoud · April 12, 2025, 4:08am

Should be ok, I’ve build it many times on aarch64.

lowjoel · April 12, 2025, 4:26am

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/

frank-w · April 12, 2025, 6:26am

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.

drozdi70 · April 12, 2025, 6:34am

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.

lowjoel · April 12, 2025, 7:35am

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.

lowjoel · April 13, 2025, 1:08am

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

Phelan_Ward_Kell · May 9, 2025, 4:59am

Some neat way to include this directly into openwrt build env, maybe a patch or something?