rmandrad
May 28, 2026, 7:15am
1
Hi,
so i am testing the 2026-07-bpi uboot with the r4pro
I copied from @frank-w lastest CI build
bpi-r4pro_sdmmc_8GB_fip.bin & bpi-r4pro_sdmmc_8GB_bl2.img
sudo dd if=bpi-r4pro_sdmmc_8GB_fip.bin bs=1M status=progress conv=notrunc,fsync of=/dev/mmcblk0p4
&
sudo dd if=bpi-r4pro_sdmmc_8GB_bl2.img bs=1M status=progress conv=notrunc,fsync of=/dev/mmcblk0p1
the result is that although 8G DRAM is identified i only get 3GB
NOTICE: BL2: v2.14.0(release):5ef7f379-bpi-r4pro-sdmmc
NOTICE: BL2: Built : 23:51:59, May 27 2026
NOTICE: WDT: [40000000] Software reset (reboot)
NOTICE: CPU: MT7988
NOTICE: EMI: DDR4 4BG mode
NOTICE: EMI: Using DDR unknown settings
NOTICE: EMI: complex R/W mem test passed
NOTICE: DRAM: 8192MB
NOTICE: LVTS: Enable thermal HW reset
NOTICE: Located partition 'fip' at 0x680000, size 0x200000
NOTICE: BL2: Booting BL31
NOTICE: BL31: v2.14.0(release):5ef7f379-bpi-r4pro-sdmmc
NOTICE: BL31: Built : 23:52:02, May 27 2026
U-Boot 2026.07-rc2-bpi-g20f56ff6d378-dirty (May 27 2026 - 23:50:22 +0000)
CPU: MediaTek MT7988
Model: Bananapi BPI-R4 Pro
DRAM: 8 GiB (total 3 GiB)
Core: 60 devices, 25 uclasses, devicetree: separate
MMC: mmc@11230000: 0
Loading Environment from nowhere... OK
In: serial@11000000
Out: serial@11000000
Err: serial@11000000
=> board_late_init...
bootmedia:sd
Net: MediaTek MT7988 built-in switch
BPI-R4P> printenv ram_gb
ram_gb=8
anything that i missed ?
rmandrad
May 28, 2026, 7:27am
2
i tried the 2026-04 version and the ram is correctly being identified with 8GB … so it seems is an issue with the 2026-07 version @frank-w ?
frank-w
May 28, 2026, 7:54am
3
I flashed 2026-07-rc2 yesterday for r4pro and did not noticed an error,but not looked close to ram detection. I’m away from my board next days,so cannot test again.
1 Like
frank-w
May 28, 2026, 9:17am
4
Could you do bdinfo,i guess there is a regression with recent lmb changes (only first bank is recognized). And please test 2026-07-bpi
If this works you can try cherrypicking this:
committed 07:20PM - 13 Mar 26 UTC
Revert commit eb052cbb896f ("lmb: add and reserve memory above ram_top")
and com… mit 1a48b0be93d4 ("lmb: prohibit allocations above ram_top even from
same bank"). These are based on incorrect premise of the first commit, that
"U-Boot does not use memory above ram_top". While U-Boot itself indeed does
not and should not use memory above ram_top, user can perfectly well use
that memory from the U-Boot shell, for example to load content in there.
Currently, attempt to use that memory to load large image using TFTP ends
with "TFTP error: trying to overwrite reserved memory...". With this change
in place, the memory can be used again.
Fixes: eb052cbb896f ("lmb: add and reserve memory above ram_top")
Fixes: 1a48b0be93d4 ("lmb: prohibit allocations above ram_top even from same bank")
Reported-by: Yuya Hamamachi <[email protected] >
Signed-off-by: Marek Vasut <[email protected] >
Edit,oh,you are already on 2026-07-rc2…mhm,then it seems not the cause.
Seems we have to change mem-map
Currently this is used:
// SPDX-License-Identifier: GPL-2.0-only
#include <asm/armv8/mmu.h>
static struct mm_region mediatek_mem_map[] = {
{
/* DDR */
.virt = CONFIG_MTK_MEM_MAP_DDR_BASE_PHY,
.phys = CONFIG_MTK_MEM_MAP_DDR_BASE_PHY,
.size = CONFIG_MTK_MEM_MAP_DDR_SIZE,
.attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) | PTE_BLOCK_OUTER_SHARE,
}, {
.virt = 0x00000000UL,
.phys = 0x00000000UL,
.size = CONFIG_MTK_MEM_MAP_MMIO_SIZE,
.attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
PTE_BLOCK_NON_SHARE |
PTE_BLOCK_PXN | PTE_BLOCK_UXN
}, {
/* List terminator */
show original
And we need to do something like this for mt7988:
static struct mm_region mt7988_mem_map[] = {
{
.virt = 0x40000000UL,
.phys = 0x40000000UL,
.size = 0xc0000000UL,
.attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
PTE_BLOCK_OUTER_SHARE,
}, {
.virt = 0x100000000ULL,
.phys = 0x100000000ULL,
.size = 0x140000000ULL,
.attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
PTE_BLOCK_OUTER_SHARE,
},
...
struct mm_region *mem_map = mt7988_mem_map;
1 Like
rmandrad
May 28, 2026, 12:08pm
5
the actual code seems correct; you had an override that was removed by
bddd6bbef3d (arm: mediatek: mt7988: drop dram_init_banksize()
I am testing with the code back in init.c
+int dram_init_banksize(void)
+{
+ /* Report the full detected DRAM size to later stages. */
+ gd->bd->bi_dram[0].start = gd->ram_base;
+ gd->bd->bi_dram[0].size = gd->ram_size;
+
+ return 0;
+}
+
rmandrad
May 28, 2026, 12:28pm
6
bdinfo shows now
MT7988> bdinfo
boot_params = 0x0000000000000000
DRAM bank = 0x0000000000000000
-> start = 0x0000000040000000
-> size = 0x0000000200000000
flashstart = 0x0000000000000000
flashsize = 0x0000000000000000
flashoffset = 0x0000000000000000
baudrate = 115200 bps
relocaddr = 0x00000000fff75000
reloc off = 0x00000000be175000
Build = 64-bit
current eth = ethernet@15110100
ethaddr = (not set)
IP addr = 192.168.0.19
fdt_blob = 0x00000000ff7fb400
lmb_dump_all:
memory.count = 0x1
memory[0] [0x40000000-0x23fffffff], 0x200000000 bytes, flags: none
reserved.count = 0x1
reserved[0] [0xfe7fb3f0-0xffffffff], 0x1804c10 bytes, flags: no-overwrite
devicetree = separate
arch_number = 0x0000000000000000
TLB addr = 0x00000000ffff0000
irq_sp = 0x00000000ff7fb3f0
sp start = 0x00000000ff7fb3f0
Early malloc usage: ca0 / 4000
frank-w
May 28, 2026, 4:23pm
7
How did bdinfo look before? So basicly you have restored the old function (revert the commit) and all works again?
committed 11:39PM - 06 Apr 26 UTC
Drop override of dram_init_banksize() weak function for mt7988. This is
effectiv… ely the same as the default implementation, so we do not need
to override it.
Reviewed-by: Julien Stephan <[email protected] >
Tested-by: Julien Stephan <[email protected] >
Link: https://patch.msgid.link/[email protected]
Signed-off-by: David Lechner <[email protected] >
rmandrad
May 28, 2026, 5:30pm
8
yep i restored the init function
the bdinfo before
boot_params = 0x0000000000000000
DRAM bank = 0x0000000000000000
-> start = 0x0000000040000000
-> size = 0x00000000c0000000
flashstart = 0x0000000000000000
flashsize = 0x0000000000000000
flashoffset = 0x0000000000000000
baudrate = 115200 bps
relocaddr = 0x00000000fff17000
reloc off = 0x00000000be117000
Build = 64-bit
current eth = ethernet@15110100
ethaddr = 6e:85:02:d3:5d:fc
IP addr = 192.168.0.19
fdt_blob = 0x00000000ff7faaf0
lmb_dump_all:
memory.count = 0x1
memory[0] [0x40000000-0xffffffff], 0xc0000000 bytes, flags: none
reserved.count = 0x2
reserved[0] [0x46000000-0x460000b0], 0xb1 bytes, flags: none
reserved[1] [0xfe7faae0-0xffffffff], 0x1805520 bytes, flags: no-overwrite
devicetree = separate
arch_number = 0x0000000000000000
TLB addr = 0x00000000ffff0000
irq_sp = 0x00000000ff7faae0
sp start = 0x00000000ff7faae0
Early malloc usage: da8 / 4000
version
U-Boot 2026.07-rc2-bpi-g6a1580973a11-dirty (May 27 2026 - 14:39:18 +0000)
1 Like
frank-w
May 28, 2026, 5:53pm
9
Thanks,can you report a regression to the autor of the breaking commit and tested-by user? Seems also test was not reliable.
This is a significant find regarding the 2026-07-rc2 build. It seems the removal of the bank size initialization function is definitely causing the address space to be truncated. Restoring the init.c code as you mentioned is probably the most reliable workaround for now. Thanks for documenting the bdinfo comparison; it makes the regression very easy to verify for others testing this version.
2 Likes
rmandrad
May 29, 2026, 7:00am
11
1 Like
frank-w
May 29, 2026, 4:20pm
12
thank you very much rudy, have added your commit to my u-boot repo
would you send it as fix to u-boot-ML?
rmandrad
May 29, 2026, 4:50pm
13
sure, in fact all that triggered this was that i wanted to have KASLR enabled and only the 2026-07-bpi repo has RNG enabled no clue it is an rc repo
frank-w
May 29, 2026, 5:56pm
14
Yes ML stands for mailinglist,why do you hate it?
Just export your commit (with additional fixes-tag) with git format-patch -1 commitid, run scripts/checkpatch.pl and get_maintainer.pl and then send the patchfile via git send-email filename.
Have you tested kaslr? I can also add the rng patches to latest stable 2026-04-bpi,but have not yet tested kdaslr yet,so added only to the rc branch
1 Like
rmandrad
May 29, 2026, 6:43pm
15
kaslr is working fine thx to RNG with no crashes to date… i haven’t look into yet how to test it.
i used mailing list in the past but it is a pain imho … kind of reminds me of the 1980’s bbs … i will do it tomorrow
rmandrad
June 2, 2026, 4:27pm
16
1 Like
… give me the details on how to do it ? i am guessing is a mailing list which i hate to use