All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Pali Rohár" <pali@kernel.org>
To: Tom Rini <trini@konsulko.com>, Simon Glass <sjg@chromium.org>,
	u-boot@lists.denx.de
Subject: Broken support for 4GB DDR on 32-bit platforms
Date: Sat, 14 May 2022 01:00:06 +0200	[thread overview]
Message-ID: <20220513230006.ep5qdhuu6k5ado2l@pali> (raw)

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?

             reply	other threads:[~2022-05-13 23:00 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-13 23:00 Pali Rohár [this message]
2022-05-16 12:31 ` Broken support for 4GB DDR on 32-bit platforms Tom Rini
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=20220513230006.ep5qdhuu6k5ado2l@pali \
    --to=pali@kernel.org \
    --cc=sjg@chromium.org \
    --cc=trini@konsulko.com \
    --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.