All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tom Rini <trini@konsulko.com>
To: "Pali Rohár" <pali@kernel.org>
Cc: Simon Glass <sjg@chromium.org>, u-boot@lists.denx.de
Subject: Re: Broken support for 4GB DDR on 32-bit platforms
Date: Mon, 16 May 2022 08:31:43 -0400	[thread overview]
Message-ID: <20220516123143.GI3901321@bill-the-cat> (raw)
In-Reply-To: <20220513230006.ep5qdhuu6k5ado2l@pali>

[-- Attachment #1: Type: text/plain, Size: 2616 bytes --]

On Sat, May 14, 2022 at 01:00:06AM +0200, Pali Rohár wrote:

> Hello! I tried to enable support for 2GB+ of DDR memory (with 4GB DDR3)
> on powerpc P2020 board in 32-bit addressing mode and U-Boot crashed
> during startup.
> 
> I figured out that issue is not powerpc specific, but rather generic to
> all 32-bit platforms. U-Boot stores memory size into phys_size_t type
> (gd->ram_size) and last mapped memory address increased by one byte into
> phys_addr_t type (gd->ram_top).
> 
> Despite size 4GB fits into 32-bit addressing mode, it does not fit into
> above two variables, and it overflows to zero. U-Boot then see zero RAM
> size and crashes.
> 
> I tried to workaround this issue by changing both phys_size_t and
> phys_addr_t types to 64-bit. But it did not helped because U-Boot on
> many places cast gd->ram_size or gd->ram_top to ulong type, which is
> 32-bit on 32-bit platforms.
> 
> Next I changed ulong parameters of board_get_usable_ram_top() function
> to u64.
> 
> This still was not enough because config value CONFIG_MAX_MEM_MAPPED is
> ignored on one important place -- in function get_effective_memsize().
> This config value takes effect only when also CONFIG_VERY_BIG_RAM is
> set.
> 
> Finally With this change I was able to start U-Boot with more than 2GB
> of DDR memory inserted in SODIMM slot on P2020.
> 
> How to fix issues with gd->ram_size and gd->ram_top? That +1 byte is
> really stupid limitation. Changing phys_size_t and phys_addr_t types
> unconditionally to 64-bit? Or something else?
> 
> And what is the purpose of CONFIG_VERY_BIG_RAM config option? Why is
> CONFIG_MAX_MEM_MAPPED check skipped in get_effective_memsize() function,
> but is not skipped on many more places?

So, there's two parts to this, as I recall it all.  First, even on 64bit
platforms we contain ourselves to 32bit address space and even then
something within the "old" 2GB window.  We then set a CONFIG option to
not mess with the memory node in DT which has the real value.  Second,
for 32bit platforms which can support 4GB memory, or more, some further
games need to be played, typically I believe around initializing the
memory controller (I'm more confident of that for dra7xx_evm, which I
don't have the big memory version of, just a small memory one) so that
Linux can do whatever needs doing to enable "36bit" typically address
support.  Looking at the other P*36BIT* configs might give you some more
clues about what to do on your platform, or at least who might still be
able to explain and test things on the PowerPC side.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

  reply	other threads:[~2022-05-16 12:31 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-13 23:00 Broken support for 4GB DDR on 32-bit platforms Pali Rohár
2022-05-16 12:31 ` Tom Rini [this message]
2022-05-16 21:56   ` Pali Rohár
2022-05-17 15:52     ` Tom Rini
2022-05-17 16:00       ` Pali Rohár
2022-05-17 16:38         ` Tom Rini
2022-05-18 10:58           ` Pali Rohár
2022-05-18 12:16             ` Tom Rini
2022-05-18 12:17               ` Pali Rohár
2022-05-18 12:19                 ` Tom Rini
2022-05-18 13:19                   ` Pali Rohár
2022-05-18 15:18                     ` Tom Rini
2022-05-18 15:27                       ` Pali Rohár
2022-05-18 15:35                         ` Tom Rini
2022-05-19  9:39                           ` Pali Rohár

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220516123143.GI3901321@bill-the-cat \
    --to=trini@konsulko.com \
    --cc=pali@kernel.org \
    --cc=sjg@chromium.org \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.