Hi Tom, On Fri, 6 Dec 2024 at 17:52, Tom Rini <[email protected]> wrote: > > On Fri, Dec 06, 2024 at 05:10:39PM -0700, Simon Glass wrote: > > Hi Tom, > > > > On Fri, 6 Dec 2024 at 17:00, Tom Rini <[email protected]> wrote: > > > > > > 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> > > > > > > > > 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/[email protected]/ > > > > > > > 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. > > > > No, that is a separate issue. We need kernel_comp_addr and kernel_comp_size > > Yes, those are required for automatic decompression, which is handy. But > the highest priority is removing fdt_high / initrd_high because those > lead to so much time being wasted by everyone. Your time digging in to > and making patch #2 for example.
Can you remind me why fdt_high is so bad, or even what it is supposed to help with? Perhaps file an issue? I'm not necessarily offering to do it, but if I understand it better, then it is more likely that I will take it on. > > > > > > > > > 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." > > > > No, the rpi relocates. I just mean that it puts the DT at about 512MB > > in RAM, which is annoying. > > I guess we've once again lost some details. With fdt_high=0xffffffff we > do not relocate the device tree we're going to pass to the OS from > wherever it happens to be at the time. That is what I mean by > relocation. Looking at a Pi 4 here real quick, it has > fdtcontroladdr=3aea8b30. But if you mean fdt_addr, yes, that's around > 512MiB (fdt_addr=2eff2d00) and likely the previous stage throwing it > there for the OS as a likely always accessible option. Yes. Regards, SImon
