[PATCH 0/3] rpi: Tidy up booting

[Tom Rini]

On Sun, Dec 08, 2024 at 04:06:47PM -0700, Simon Glass wrote:

[snip]
> OK, yes it seems like fdt_high is a hack. But 'git grep fdt_high |grep
> fffff |wc' shows 74 matches, so it is still there.

Yes, it's something that needs to be done.

> Going back to my patch, do you have any comments about it? I am not
> about to boil the fdt_high ocean, sorry, but I will happily drop the
> fdt_high on rpi, since it seems unnecessary, at least for 64-bit
> kernels. I do see that kernels <4.2 require fdt_high on arm so that
> the kernel and FDT are within the same 512MB section. Is that still a
> concern?

I'm not asking you to remove fdt_high from everyone, sorry if I gave
that impression. For Pi the best option would be to set bootm_size to
512MB so that everything stays within that area, on all Pis and remove
fdt_high and initrd_high in all cases there.

> I'll also add myself as a rpi maintainer since the current ones seem
> pretty busy.

If they agree, sure.

> I am planning to continue with the bootstd work, part of which will be
> to drop the need for these variables. If there are constraints, we can
> specify those either in the kernel FIT or in U-Boot's config, and
> implement them in C code (with tests), not scripts, variables, etc.

At the high level, yes, something like the approach EFI takes where
there's not a need to relocate things after loading them to memory would
remove the need for the variables that say where things go specifically,
and only have the need for knowing what memory the OS will be able to
see initially.

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