[PATCH] arm64: versal2: Populate DRAM banks before page table size calculation

Tom Rini trini at konsulko.com
Tue Dec 9 16:50:17 CET 2025


On Tue, Dec 09, 2025 at 03:57:50PM +0100, Michal Simek wrote:
> 
> 
> On 12/9/25 15:43, Tom Rini wrote:
> > On Tue, Dec 09, 2025 at 03:17:45PM +0100, Michal Simek wrote:
> > 
> > > From: Pranav Sanwal <pranav.sanwal at amd.com>
> > > 
> > > Move DRAM bank detection from fdtdec to custom implementation to
> > > ensure memory banks are populated before get_page_table_size() is
> > > called during MMU initialization.
> > > 
> > > The current fdtdec-based approach populates gd->bd->bi_dram[] too
> > > late in the boot sequence, causing get_page_table_size() to be
> > > called with unpopulated DRAM information. This prevents dynamic
> > > page table sizing based on actual memory configuration.
> > > 
> > > Parse /memory nodes in dram_init() to fill versal2_mem_map[]
> > > early enough for MMU setup. Supports up to
> > > CONFIG_NR_DRAM_BANKS (36) non-contiguous banks with high memory
> > > regions (>4GB) and use __weak get_page_table_size implementation
> > > to estimate page table size based on the populated DRAM banks.
> > > 
> > > Signed-off-by: Pranav Sanwal <pranav.sanwal at amd.com>
> > > Signed-off-by: Michal Simek <michal.simek at amd.com>
> > [snip]
> > > diff --git a/include/dm/ofnode.h b/include/dm/ofnode.h
> > > index 120393426dbf..5be9513f5238 100644
> > > --- a/include/dm/ofnode.h
> > > +++ b/include/dm/ofnode.h
> > > @@ -1886,4 +1886,6 @@ int ofnode_copy_node(ofnode dst_parent, const char *name, ofnode src,
> > >    */
> > >   int ofnode_delete(ofnode *nodep);
> > > +ofnode get_next_memory_node(ofnode mem);
> > 
> > This function is in lib/fdtdec.c and so we should have the declaration
> > in include/fdtdec.h and while it doesn't have a kernel-doc comment
> > today, it should. If you want to in v2 make 1/2 add the prototype and
> > comment and 2/2 use it in mach-versal that might be a good split.
> 
> We will do. And do you have any issue with logic in this patch?
> Pretty much we don't want u-boot to be relocated inside the memory bank
> where it was initially loaded and we didn't find a better way to do it.

It sounds like it's a bit of a generic arm64 problem? But this is
probably the right step forward until a second SoC hits it and maybe we
see a better place to change things more generally.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20251209/823d8df6/attachment.sig>


More information about the U-Boot mailing list