Re: [QUESTION] SpacemiT K1: Incorrect RAM detection with unpopulated CS1

[Michael Opdenacker <michael.opdenacker@rootcommit.com>]

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