[PATCH 0/3] rpi: Tidy up booting

Tom Rini trini at konsulko.com
Fri Dec 6 20:41:30 CET 2024


On Fri, Dec 06, 2024 at 12:17:49PM -0700, Simon Glass wrote:
> Hi Tom,
> 
> On Fri, 6 Dec 2024 at 07:08, Tom Rini <trini at konsulko.com> wrote:
> >
> > On Fri, Dec 06, 2024 at 06:11:10AM -0700, Simon Glass wrote:
> >
> > > This series allows rpi to boot a compressed Ubuntu kernel with ~100MB
> > > ramdisk, by expanding the available space.
> > >
> > > It also tidies up some strange behaviour with the provided FDT, where a
> > > separate pointer is maintained to it, even though U-Boot has copied it
> > > and placed it in its own space. This avoids strange bugs where it
> > > accidentally gets overwritten when loading a file into memory.
> > >
> > >
> > > Simon Glass (3):
> > >   rpi: Update environment to support booti and large initrd
> > >   fdt: Allow expanding the devicetree during relocation
> > >   rpi: Use the U-Boot control FDT for fdt_addr
> > >
> > >  board/raspberrypi/rpi/rpi.c   | 20 ++++++++------------
> > >  board/raspberrypi/rpi/rpi.env | 10 ++++++----
> > >  common/board_f.c              |  6 ++++--
> > >  dts/Kconfig                   | 11 +++++++++++
> > >  4 files changed, 29 insertions(+), 18 deletions(-)
> >
> > My feedback here is the same feedback I gave the last person that wanted
> > to update the Pi addresses, and I forget if they came back and did that
> > (and it's in Peter / Matthias' queue) or not. Disabling device tree
> > relocation is a bug and must be removed.
> >
> > After that, given the range of memory sizes available on Pi platforms,
> > allocating the kernel / initrd / kernel decompression buffer at run
> > time, ala mach-apple would make life easier in the long run.
> 
> Yes, of course, but for now, this resolves the problem and I don't
> believe it creates any other problem.

Yes. I think you missed that:
https://patchwork.ozlabs.org/project/uboot/patch/20240723193430.3050251-1-walter.lozano@collabora.com/
is also outstanding and should solve the problem.

> The solution should not be board-specific though. Once I have the
> bootstd files stuff is finished, I believe that bootstd will be able
> to do this and I plan to do this. Then the variables will be unused
> for rpi and we can just drop them for any bootstd boards.
> 
> As of now, we have 390 boards using bootstd and 381 using distro
> scripts, so it is progress!

Yes, it will be interesting to see what the future holds, and any of the
solutions handle some of the trickier corner cases that lead to the
current situation. Or perhaps the best outcome is that in current times,
those corner cases don't really appear anymore (with 512MiB DDR being
the lower bound for example on all the Pi families).

-- 
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/20241206/0b57e558/attachment.sig>


More information about the U-Boot mailing list