Greetings,
I'm reviving this thread as the issue Alper reported in December is
still there...
On 12/22/25 1:32 PM, Alper Ak wrote:
Hi,
I'm working on Orange Pi RV2 board which uses the SpacemiT K1 SoC. I'm
currently using the bananapi-f3_defconfig as a base since there is no
mainline support for Orange Pi RV2 yet.
The Problem is U-Boot reports 4GB RAM on my 2GB board. I think the CS1
register shows enabled with valid density even when no physical RAM is
populated. This causes U-Boot to report double the actual RAM. Also,
If I don't set "mem=2G" in the kernel command line, it causes a kernel
panic.
I'm sharing U-Boot, bdinfo and DDR register dump output:
U-Boot 2026.01-rc4 (Dec 10 2025 - 15:28:43 +0000)
DRAM: 4 GiB
Core: 21 devices, 9 uclasses, devicetree: separate
Loading Environment from nowhere... OK
In: serial@d4017000
Out: serial@d4017000
Err: serial@d4017000
Net: No ethernet found.
Hit any key to stop autoboot: 0
=> bdinfo
boot_params = 0x0000000000000000
DRAM bank = 0x0000000000000000
-> start = 0x0000000000000000
-> size = 0x0000000080000000
DRAM bank = 0x0000000000000001
-> start = 0x0000000100000000
-> size = 0x0000000080000000
flashstart = 0x0000000000000000
flashsize = 0x0000000000000000
flashoffset = 0x0000000000000000
baudrate = 115200 bps
relocaddr = 0x000000007ff81000
reloc off = 0x000000007fd81000
Build = 64-bit
current eth = unknown
eth-1addr = (not set)
IP addr = <NULL>
fdt_blob = 0x000000007ef5ed20
lmb_dump_all:
memory.count = 0x2
memory[0] [0x0-0x7fffffff], 0x80000000 bytes, flags: none
memory[1] [0x100000000-0x17fffffff], 0x80000000 bytes, flags: none
reserved.count = 0x4
reserved[0] [0x0-0x7ffff], 0x80000 bytes, flags: no-map
reserved[1] [0x7df5b000-0x7df5dfff], 0x3000 bytes, flags: no-notify,
no-overwrite
reserved[2] [0x7df5ed10-0x7fffffff], 0x20a12f0 bytes, flags: no-overwrite
reserved[3] [0x100000000-0x17fffffff], 0x80000000 bytes, flags: no-overwrite
devicetree = separate
serial addr = 0x00000000d4017000
width = 0x0000000000000004
shift = 0x0000000000000002
offset = 0x0000000000000000
clock = 0x0000000000e2b328
boot hart = 0x0000000000000000
firmware fdt= 0x0000000000279b18
=> md.l 0xC0000200 1
c0000200: 000f0001 ....
=> md.l 0xC0000208 1
c0000208: 800f0001 ....
I think this seems to be board independent and appears to originate
from the code at "arch/riscv/cpu/k1/dram.c".
I have the same problem on my OrangePi R2S board with 2 Go of RAM.
U-Boot believes my board has 4 GB of RAM. It seems most K1 boards should
be impacted!
This seems to happen because the code in arch/riscv/cpu/k1/dram.c
unconditionally adds the value read from CS1, even if CS1 is unpopulated:
phys_size_t ddr_get_density(void)
{
phys_size_t cs0_size = ddr_map_size(readl((void *)DDR_BASE + 0x200));
phys_size_t cs1_size = ddr_map_size(readl((void *)DDR_BASE + 0x208));
phys_size_t ddr_size = cs0_size + cs1_size;
return ddr_size;
}
Looking at the corresponding vendor U-Boot code [1], this is conditional
indeed:
cs0_size = map_format_size(readl((void*)0xc0000000 + 0x200));
if (ddr_cs_num > 1) {
cs1_size = map_format_size(readl((void*)0xc0000000 + 0x208));
}
ddr_size = cs0_size + cs1_size;
However, if you add such code and set ddr_cs_num to 1, this works well
with my 2 GB Orange Pi R2S board, but breaks my Orange Pi RV2 with 8 GB
(U-Boot seeing 4 GB instead of 8 GB).
How should we address this issue in a clean way?
Note that I've done my tests loading mainline U-Boot from FSBL.bin built
from the vendor U-Boot code.
Thanks in advance for your insights.
Michael.
[1] https://github.com/orangepi-xunlong/u-boot-orangepi.git, branch
v2022.10-ky
--
Michael Opdenacker, Root Commit
Embedded Linux Training and Consulting. Yocto Ambassador.
https://rootcommit.com
