[PATCH 0/3] rpi: Tidy up booting

[Tom Rini]

On Fri, Dec 06, 2024 at 04:56:31PM -0700, Simon Glass wrote:
> Hi Tom,
> 
> On Fri, 6 Dec 2024 at 16:52, Tom Rini <trini at konsulko.com> wrote:
> >
> > 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.
> 
> OK, but let's drop that patch since it doesn't support decompression, right?

No? No one has done all of the work required (remove fdt_high /
initrd_high) and this also solves the larger kernel issue.

> > > > > 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.
> 
> I mean in the sense that it puts the devicetree in the middle of RAM.

Which and where? Or do you mean it being exacerbated by disabling
relocation (which is why I keep going on and on about removing that from
platforms that do it)? Most platforms will load to the "middle" and
that's why you must not disable relocation because it's only a problem
when, well, relocation is disabled and U-Boot says "Gee, you're going to
break but you told me you want that, so, alright then."

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