From: Orgad Shaneh <orgads@gmail.com>
To: tsbogend@alpha.franken.de
Cc: linux-mips@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [PATCH] MIPS: OCTEON: use the free memory below the kernel
Date: Tue, 27 Oct 2026 06:02:27 +0000 [thread overview]
Message-ID: <20261027060227.2687979-1-orgads@gmail.com> (raw)
plat_mem_setup() asks bootmem only for memory above _end. The kernel
is loaded at 0x1100000, so whatever bootmem has free below _text is
never added to memblock. On a CN6335 board with the Cavium bootloader
that is 14MB, 0x200000-0xffffff:
before: node 0: [mem 0x0000000001100000-0x0000000001cc6fff]
after: node 0: [mem 0x0000000000200000-0x0000000000ffffff]
node 0: [mem 0x0000000001100000-0x0000000001cc6fff]
Claim it before the main loop, in 1MB pieces since the holes there are
small and unaligned. It counts towards max_memory like the rest, and a
piece inside the crash kernel range, which is added on its own, is
skipped as the main loop does. bootmem never hands out what the
bootloader reserved (the exception vectors, its named blocks, the
kernel image itself), so only free memory is claimed.
Assisted-by: LLM
Signed-off-by: Orgad Shaneh <orgads@gmail.com>
---
Tested on mips-next with cavium_octeon_defconfig (KEXEC=y, CRASH_DUMP=n)
on a CN6335 board, 4GB, Cavium U-Boot 1.1.1: "Memory:" goes from
4023588K/4169492K to 4037924K/4183828K available. Built with KEXEC=n
and CRASH_DUMP=y as well.
arch/mips/cavium-octeon/setup.c | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/arch/mips/cavium-octeon/setup.c b/arch/mips/cavium-octeon/setup.c
index 7497be7b9431..2b1bc8fafac5 100644
--- a/arch/mips/cavium-octeon/setup.c
+++ b/arch/mips/cavium-octeon/setup.c
@@ -1022,6 +1022,27 @@ void __init plat_mem_setup(void)
* which is handled by memblock
*/
cvmx_bootmem_lock();
+ /*
+ * The loop below only takes memory above the kernel. Claim what
+ * bootmem has free below it as well, 1MB at a time: the holes the
+ * bootloader leaves there are small and not aligned to
+ * mem_alloc_size.
+ */
+ while (total < max_memory) {
+ memory = cvmx_bootmem_phy_alloc(0x100000, 0,
+ __pa_symbol(&_text),
+ 0x100000,
+ CVMX_BOOTMEM_FLAG_NO_LOCKING);
+ if (memory < 0)
+ break;
+#ifdef CONFIG_KEXEC
+ /* The crash kernel range is already added */
+ if (memory < crashk_end && memory + 0x100000 > crashk_base)
+ continue;
+#endif
+ memblock_add(memory, 0x100000);
+ total += 0x100000;
+ }
while (total < max_memory) {
memory = cvmx_bootmem_phy_alloc(mem_alloc_size,
__pa_symbol(&_end), -1,
--
2.53.0
reply other threads:[~2026-10-27 6:02 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20261027060227.2687979-1-orgads@gmail.com \
--to=orgads@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=tsbogend@alpha.franken.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox