[PATCH] Fix detection of odd memory configurations on sunxi
Andre Przywara
andre.przywara at arm.com
Tue Oct 7 01:09:37 CEST 2025
On Sun, 5 Oct 2025 17:16:35 +0100
Andre Przywara <andre.przywara at arm.com> wrote:
Hi,
> On Sun, 05 Oct 2025 08:10:27 +0200
> Jernej Škrabec <jernej.skrabec at gmail.com> wrote:
>
> Hi,
>
> > Dne nedelja, 5. oktober 2025 ob 02:40:21 Srednjeevropski poletni čas je Andre Przywara napisal(a):
> > > On Mon, 11 Aug 2025 09:35:19 +0200
> > > Rudi Horn <dyn-git at rudi-horn.de> wrote:
> > >
> > > Hi Rudi,
> > >
> > > thanks for sending a patch to address this long-standing issue!
> > >
> > > But ... ;-)
> > >
> > > > I encountered a bug where u-boot detects that my OrangePI zero 3 (with
> > > > 1.5GB) has 2GB and crashes.
> > >
> > > As Jernej already said, this is a known limitation: we simply don't
> > > support not-power-of-2 DRAM sizes at the moment.
> > >
> > > > The orangepi u-boot source code contains an additional
> > > > modification in the `mctl_calc_size` which removes a quarter of the
> > > > memory the
> > > > calculated last address cannot be written to:
> > > >
> > > > https://github.com/orangepi-xunlong/u-boot-orangepi/blob/v2024.01/arch/arm/mach-sunxi/dram_sun50i_h616.c#L1365-L1368
> > > >
> > > > I'm not entirely sure if there is some specific logic that applies to this
> > > > modifier, but it does fix the issue on my system.
> > >
> > > So can someone shed some light on how this is supposed to work? If I
> > > understand the code correctly, it checks for *aliasing* between the
> > > first and the last word of DRAM, which doesn't make much sense to me: I
> > > would expect a simple write/verify to see if the last quarter of DRAM
> > > is for real, or to check for a known aliasing pattern with this "odd"
> > > setup (as in: last quarter is aliased to first or third quarter or
> > > something), but checking those two words for aliasing seems wrong.
> >
> > Hm... I've never tested this patch on HW, so you might have a point. Still,
> > I think testing for aliasing makes sense. Just writing and reading might
> > not be enough due to possible caching (not necessarily in CPU).
>
> Sure, aliasing trumps verifying, but it might be easier to test the
> latter?
>
> > I should have some board with non-power-of-2 RAM size somewhere. I'll try
> > to find it and test this.
>
> I just realised that my Cubie A7A has 12GB(!) of DRAM, so I can actually do
> some experiments here, in U-Boot proper, after boot0 has initialised the DRAM:
> [5912]DRAM SIZE =12288 MBytes, para1 = a11a, para2 = 30001001, dram_tpr13 = 10065
So I did some experiments on my board:
I booted boot0 from SD card, to let it initialise all 12GB of DRAM,
then to go to FEL. After that I loaded U-Boot into DRAM and started it.
I hacked U-Boot to assume 16GB of DRAM, and mapped all memory above 4GB
as device (non-cacheable). The observations are:
- Memory beyond the 12GB real DRAM contains one of two distinct 32
byte long patterns, which alternate every 512MB:
35fffffc0: 66666666 66666666 66666666 66666666 ffffffffffffffff
35fffffd0: 66666666 66666666 66666666 66662626 ffffffffffff&&ff
35fffffe0: 66666666 66666666 66666666 66666666 ffffffffffffffff
35ffffff0: 66666666 66666666 66666666 66662626 ffffffffffff&&ff
360000000: 99999999 99999999 99999999 99999999 ................
360000010: 99999999 99999999 99999999 9b9b9999 ................
360000020: 99999999 99999999 99999999 99999999 ................
360000030: 99999999 99999999 99999999 9b9b9999 ................
- values written there are ignored, the content stays at this initial pattern
- with caches enabled, writes seem to stick, but that's in the cache only
- this pattern does not appear anywhere else in DRAM
So this means any aliasing test wouldn't work, but we can do an
accessibility test, I think the algorithm should be:
bool test_last_quarter(size_t size)
{
uintptr_t addr = CFG_SYS_SDRAM_BASE + size / 4 * 3;
uint32_t orig, val;
orig = readl(addr);
writel(~orig, addr);
val = readl(addr);
writel(orig, addr);
return ~orig == val;
}
This would be SPL code, so with the MMU and thus caches off, and since
all accesses go to the same memory address on the same core, we
shouldn't need extra barriers (I think even the _relaxed versions
should work).
Can someone test this on a board with an "odd" memory size? It worked
on a normal 4GB board (passing the test), and failed on my 12GB board,
albeit running only in U-Boot proper.
If this works, I will send a proper patch.
Cheers,
Andre
>
> > > And indeed the code also fires on a board with 512MB and 4GB, capping
> > > the memory there as well (resulting in 384 MB and 3GB, respectively).
> > > This is somewhat expected, as we never would expect aliasing between
> > > those two particular words, I'd say.
> > >
> > > So since I don't have a board with an "uneven" DRAM size, can you
> > > please test some ideas to detect this RAM setup?
> > > - Read the content of the first word to not exist (@1.5GB), then write
> > > something else there, and see if you can read this back? Don't forget
> > > a write barrier (dsb();) when doing so.
> > > - Write some test pattern to some known good DRAM locations, like the
> > > beginning of DRAM, @512MB, @1GB, and see if any of those values pop
> > > up @1.5GB, to see if there is an aliasing pattern?
> > > - Can you post the exact label on that DRAM chip, so that we can see if
> > > we find a datasheet? I'd be curious about the actual organisation of
> > > the DRAM array.
> > >
> > > Jernej, do you happen to know how those DRAM chips are organised? Do
> > > they just feature a non-power-of-2 number of rows or columns?
> >
> > I don't know details how such chips are organized internally. However,
> > number of rows and columns was never power-of-2.
>
> Ah right, brain fart on my end, those are of course the exponents in the
> calculation, so result in the eventual power-of-2 number. I then wonder
> where the factor of 3 comes in, are there 6 banks, or 3 ranks (doubt
> that)? I could not find a datasheet of one of those 12Gbit Samsung
> chips yet.
>
> > Btw, I think I saw 3 GB DRAM boards too somewhere, but not sure where.
> > Quick search confirms that 24 Gb DRAM chips also exists, so I would leave
> > this check as general 3/4 size fixup, not limited to any capacity.
>
> Oh, definitely, the only constant here would be the 3/4th. So the plan
> would be to detect some oddity (either through aliasing or because of
> missing DRAM cells at the end), then assume it's 3/4 of the detected
> capacity.
>
> Cheers,
> Andre
>
> >
> > >
> > > Oh, and also this patch was heavily malformed - line breaks and spaces
> > > instead of tabs. Please try to fix this. Simplest is probably "git
> > > format-patch", then sending this via "git send-email". Your email
> > > server seems to be postfix, so you could just give the SMTP details and
> > > credentials to git.
> > >
> > > Cheers,
> > > Andre
> > >
> > >
> > > >
> > > > I propose the following patch, but am open to any further suggestions.
> > > >
> > > > Thanks,
> > > > Rudi Horn
> > > >
> > > > Note: Submitted in my personal capacity and is not affiliated with my
> > > > employer.
> > > >
> > > >
> > > > From 2199f3b28e5fc853ed1921586358c33f3f1502d3 Mon Sep 17 00:00:00 2001
> > > > From: Rudi Horn <dyn-git at rudi-horn.de>
> > > > Date: Mon, 11 Aug 2025 08:58:34 +0200
> > > > Subject: [PATCH] arch: arm: mach-sonxi: Fix detection of odd memory
> > > > configurations
> > > >
> > > > Fix detection of odd memory configurations. Previously 1.5GB devices were
> > > > incorrectly detected as 2GB devices, causing u-boot to crash.
> > > >
> > > > Signed-off-by: Rudi Horn <dyn-git at rudi-horn.de>
> > > > ---
> > > > arch/arm/include/asm/arch-sunxi/dram.h | 1 +
> > > > arch/arm/mach-sunxi/dram_dw_helpers.c | 10 +++++++++-
> > > > arch/arm/mach-sunxi/dram_helpers.c | 8 ++++++++
> > > > 3 files changed, 18 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/arch/arm/include/asm/arch-sunxi/dram.h
> > > > b/arch/arm/include/asm/arch-sunxi/dram.h
> > > > index 0eccb1e6c28..7580421ca77 100644
> > > > --- a/arch/arm/include/asm/arch-sunxi/dram.h
> > > > +++ b/arch/arm/include/asm/arch-sunxi/dram.h
> > > > @@ -44,6 +44,7 @@
> > > > unsigned long sunxi_dram_init(void);
> > > > void mctl_await_completion(u32 *reg, u32 mask, u32 val);
> > > > bool mctl_mem_matches(u32 offset);
> > > > +bool mctl_mem_matches_upto(u32 offset);
> > > > bool mctl_mem_matches_base(u32 offset, ulong base);
> > > >
> > > > #endif /* _SUNXI_DRAM_H */
> > > > diff --git a/arch/arm/mach-sunxi/dram_dw_helpers.c
> > > > b/arch/arm/mach-sunxi/dram_dw_helpers.c
> > > > index 24767354935..5bcd2672465 100644
> > > > --- a/arch/arm/mach-sunxi/dram_dw_helpers.c
> > > > +++ b/arch/arm/mach-sunxi/dram_dw_helpers.c
> > > > @@ -146,5 +146,13 @@ unsigned long mctl_calc_size(const struct
> > > > dram_config *config)
> > > > u8 width = config->bus_full_width ? 4 : 2;
> > > >
> > > > /* 8 banks */
> > > > - return (1ULL << (config->cols + config->rows + 3)) * width *
> > > > config->ranks;
> > > > + unsigned long size = (1ULL << (config->cols + config->rows + 3))
> > > > * width * config->ranks;
> > > > +
> > > > + /* some memory configurations such as 1.5GB rely on this to
> > > > compute the correct size */
> > > > + if (!mctl_mem_matches_upto(size)) {
> > > > + size = (size * 3) / 4;
> > > > + debug("capping memory at 0x%lx\n", size);
> > > > + }
> > > > +
> > > > + return size;
> > > > }
> > > > diff --git a/arch/arm/mach-sunxi/dram_helpers.c
> > > > b/arch/arm/mach-sunxi/dram_helpers.c
> > > > index 83dbe4ca98f..68c75fa07a6 100644
> > > > --- a/arch/arm/mach-sunxi/dram_helpers.c
> > > > +++ b/arch/arm/mach-sunxi/dram_helpers.c
> > > > @@ -61,4 +61,12 @@ bool mctl_mem_matches(u32 offset)
> > > > {
> > > > return mctl_mem_matches_base(offset, CFG_SYS_SDRAM_BASE);
> > > > }
> > > > +
> > > > +/*
> > > > + * Test if memory at offset matches memory at end of DRAM
> > > > + */
> > > > +bool mctl_mem_matches_upto(u32 offset)
> > > > +{
> > > > + return mctl_mem_matches_base(offset - sizeof(u32),
> > > > CFG_SYS_SDRAM_BASE);
> > > > +}
> > > > #endif
> > > > --
> > > > 2.43.0
> > > >
> > >
> > >
> >
> >
> >
> >
> >
>
>
More information about the U-Boot
mailing list