[PATCH 0/3] rpi: Tidy up booting

[Tom Rini]

On Fri, Dec 06, 2024 at 04:41:37PM -0700, Simon Glass wrote:
> Hi Tom,
> 
> On Fri, 6 Dec 2024 at 12:41, Tom Rini <trini at konsulko.com> wrote:
> >
> > 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.
> 
> No, it doesn't support decompression, although I have to wonder why
> that patch was never applied.

See Peter's response elsewhere about having a lot of things to do and
not a lot of time. I know he's intended to pick up and post a Pi PR for
a while.

> > > 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).
> 
> Well rpi is a bit unusual...

Sure, but not in this case? Lots of examples of multiple models with
different memory sizes, and especially with 32bit platforms smaller (by
current standards) overall DDR.

-- 
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/aa3a0a51/attachment.sig>