From: Marcelo Manzo <marcelomanzo@gmail.com>
To: qemu-devel@nongnu.org, qemu-arm@nongnu.org
Cc: "Peter Maydell" <peter.maydell@linaro.org>,
"Philippe Mathieu-Daudé" <philmd@mailo.com>,
"Marcelo Manzo" <marcelomanzo@gmail.com>
Subject: [PATCH 1/2] hw/arm/raspi4b: fix guest never seeing more than ~1 GiB of RAM
Date: Sun, 26 Jul 2026 10:41:11 -0400 [thread overview]
Message-ID: <20260726144112.56321-2-marcelomanzo@gmail.com> (raw)
In-Reply-To: <20260726144112.56321-1-marcelomanzo@gmail.com>
raspi4_modify_dtb() decides whether to add a second memory node above
the 1 GiB peripheral hole by checking info->ram_size -- but that field
is the boot loader's RAM budget for loading the kernel/initrd/dtb
image, itself always capped to at most UPPER_RAM_BASE - vcram_size by
raspi_base_machine_init(). Since that capped value can never exceed
UPPER_RAM_BASE by construction, the condition was never true for any
raspi4b configuration, and the second node was never added: the guest
never saw more than ~1 GiB of its nominal RAM, regardless of the
machine's actual size.
board_ram_size(info->board_id), computed one line above in the same
function, is the value that was actually needed -- the board's real
total RAM, not the boot loader's own budget for where it's allowed to
place the kernel image.
Confirmed via direct measurement inside the guest ("free -h" /
/proc/meminfo) on raspi4b's default 2 GiB configuration, before and
after:
before: MemTotal: 943524 kB (~921 MiB)
after: MemTotal: 1905824 kB (~1861 MiB)
Also verified against two real, unmodified Raspberry Pi OS releases
(Debian 11/Bullseye and Debian 13/Trixie): both now report ~1.8 GiB of
usable RAM instead of ~900 MiB, with clean boots, working SSH, and no
kernel errors on either.
Signed-off-by: Marcelo Manzo <marcelomanzo@gmail.com>
---
hw/arm/raspi4b.c | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/hw/arm/raspi4b.c b/hw/arm/raspi4b.c
index b92840e1b6..ca246ebb35 100644
--- a/hw/arm/raspi4b.c
+++ b/hw/arm/raspi4b.c
@@ -64,7 +64,19 @@ static void raspi4_modify_dtb(const struct arm_boot_info *info, void *fdt)
ram_size = board_ram_size(info->board_id);
- if (info->ram_size > UPPER_RAM_BASE) {
+ /*
+ * Bug: this used to compare info->ram_size (the boot-loader's RAM
+ * budget for loading the kernel/initrd/dtb, itself capped to at most
+ * UPPER_RAM_BASE - vcram_size by raspi_base_machine_init()) rather
+ * than the board's actual total RAM computed just above. Since that
+ * capped value can never exceed UPPER_RAM_BASE by construction, this
+ * condition was never true for any raspi4b configuration -- the
+ * second memory node was never added, and the guest never saw more
+ * than ~1 GiB regardless of the machine's nominal RAM size. Confirmed
+ * via direct measurement: default -m 2G returns ~916 MiB from
+ * "free -h" inside the guest, not 2 GiB.
+ */
+ if (ram_size > UPPER_RAM_BASE) {
raspi_add_memory_node(fdt, UPPER_RAM_BASE, ram_size - UPPER_RAM_BASE);
}
}
--
2.47.1
next prev parent reply other threads:[~2026-07-26 14:41 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-26 14:41 [PATCH 0/2] hw/arm/raspi4b: fix guest RAM capped at ~1 GiB regardless of machine size Marcelo Manzo
2026-07-26 14:41 ` Marcelo Manzo [this message]
2026-07-26 14:41 ` [PATCH 2/2] tests/functional/aarch64: add raspi4b full-RAM regression test Marcelo Manzo
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=20260726144112.56321-2-marcelomanzo@gmail.com \
--to=marcelomanzo@gmail.com \
--cc=peter.maydell@linaro.org \
--cc=philmd@mailo.com \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
/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.