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 <tr...@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 <tr...@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.loz...@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
signature.asc
Description: PGP signature
