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(-)
The existing values don't provide for decompressing an arm64 boot-image. Add those values and move things apart a bit so that a 50MB kernel can be accomodated.
Signed-off-by: Simon Glass sjg@chromium.org ---
board/raspberrypi/rpi/rpi.env | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/board/raspberrypi/rpi/rpi.env b/board/raspberrypi/rpi/rpi.env index 30228285edd..d26e451cf7b 100644 --- a/board/raspberrypi/rpi/rpi.env +++ b/board/raspberrypi/rpi/rpi.env @@ -69,9 +69,11 @@ fdt_high=ffffffff initrd_high=ffffffff #endif kernel_addr_r=0x00080000 -scriptaddr=0x02400000 -pxefile_addr_r=0x02500000 -fdt_addr_r=0x02600000 -ramdisk_addr_r=0x02700000 +kernel_comp_addr_r=0x02000000 +kernel_comp_size=0x02000000 +scriptaddr=0x05400000 +pxefile_addr_r=0x05500000 +fdt_addr_r=0x05600000 +ramdisk_addr_r=0x05700000
boot_targets=mmc usb pxe dhcp
Some boards set fdt_high to -1 which means that the FDT is not relocated in boot_relocate_fdt().
A comment in that function says that we assume there is space after the existing fdt to use for padding, with the padding size set to CONFIG_SYS_FDT_PAD
However, there is no guarantee that this space is available. If using the control FDT, then global_data is immediately above it, so expanding the FDT and adding FDT properties will cause U-Boot to fail.
Add a new Kconfig option to provide the required space, enabling it by default.
Signed-off-by: Simon Glass sjg@chromium.org ---
common/board_f.c | 6 ++++-- dts/Kconfig | 11 +++++++++++ 2 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/common/board_f.c b/common/board_f.c index 8baaa2341a3..ed30aeeab23 100644 --- a/common/board_f.c +++ b/common/board_f.c @@ -553,8 +553,10 @@ static int reserve_fdt(void) * section, then it will be relocated with other data. */ if (gd->fdt_blob) { - gd->boardf->fdt_size = - ALIGN(fdt_totalsize(gd->fdt_blob), 32); + int size = fdt_totalsize(gd->fdt_blob); + + gd->boardf->fdt_size = ALIGN(size + CONFIG_OF_EXPAND, + 32);
gd->start_addr_sp = reserve_stack_aligned( gd->boardf->fdt_size); diff --git a/dts/Kconfig b/dts/Kconfig index 41a758e83a6..360611edd01 100644 --- a/dts/Kconfig +++ b/dts/Kconfig @@ -219,6 +219,17 @@ config OF_OMIT_DTB This is used for boards which normally provide a devicetree via a runtime mechanism (such as OF_BOARD), to avoid confusion.
+config OF_EXPAND + hex # "Amount to allow the control FDT to expand" + default SYS_FDT_PAD if OF_LIBFDT + default 0 + help + Some boards make use of the control FDT to boot an OS, thus when + image_setup_libfdt() adds extra things to the end of the FDT, there + needs to be enough space. + + Set this to the number of bytes of extra space required for the FDT. + config DEFAULT_DEVICE_TREE string "Default Device Tree for DT control" depends on OF_CONTROL
On Fri, Dec 06, 2024 at 06:11:12AM -0700, Simon Glass wrote:
[snip]
A comment in that function says that we assume there is space after the existing fdt to use for padding, with the padding size set to CONFIG_SYS_FDT_PAD
However, there is no guarantee that this space is available. If using the control FDT, then global_data is immediately above it, so expanding the FDT and adding FDT properties will cause U-Boot to fail.
This sounds like a generic issue and should be fixed outside of a "Pi" series.
diff --git a/dts/Kconfig b/dts/Kconfig index 41a758e83a6..360611edd01 100644 --- a/dts/Kconfig +++ b/dts/Kconfig @@ -219,6 +219,17 @@ config OF_OMIT_DTB This is used for boards which normally provide a devicetree via a runtime mechanism (such as OF_BOARD), to avoid confusion.
+config OF_EXPAND
- hex # "Amount to allow the control FDT to expand"
No "# ..." because the help explains what to do here, if needed.
- default SYS_FDT_PAD if OF_LIBFDT
- default 0
A "default 0" is almost always wrong.
- help
Some boards make use of the control FDT to boot an OS, thus whenimage_setup_libfdt() adds extra things to the end of the FDT, thereneeds to be enough space.Set this to the number of bytes of extra space required for the FDT.
We should just use SYS_FDT_PAD directly and not add a new option.
Hi Tom,
On Fri, 6 Dec 2024 at 07:13, Tom Rini trini@konsulko.com wrote:
On Fri, Dec 06, 2024 at 06:11:12AM -0700, Simon Glass wrote:
[snip]
A comment in that function says that we assume there is space after the existing fdt to use for padding, with the padding size set to CONFIG_SYS_FDT_PAD
However, there is no guarantee that this space is available. If using the control FDT, then global_data is immediately above it, so expanding the FDT and adding FDT properties will cause U-Boot to fail.
This sounds like a generic issue and should be fixed outside of a "Pi" series.
Yes and I know you keep asking for multiple smaller series, but I've explained that keeping track of all that for months at a time is too challenging for me.
diff --git a/dts/Kconfig b/dts/Kconfig index 41a758e83a6..360611edd01 100644 --- a/dts/Kconfig +++ b/dts/Kconfig @@ -219,6 +219,17 @@ config OF_OMIT_DTB This is used for boards which normally provide a devicetree via a runtime mechanism (such as OF_BOARD), to avoid confusion.
+config OF_EXPAND
hex # "Amount to allow the control FDT to expand"No "# ..." because the help explains what to do here, if needed.
OK
default SYS_FDT_PAD if OF_LIBFDTdefault 0A "default 0" is almost always wrong.
In this case it is correct, since it means not to add any extra space for the FDT.
helpSome boards make use of the control FDT to boot an OS, thus whenimage_setup_libfdt() adds extra things to the end of the FDT, thereneeds to be enough space.Set this to the number of bytes of extra space required for the FDT.We should just use SYS_FDT_PAD directly and not add a new option.
I thought I read somewhere that fdt_high == -1 should not be used. So for most boards, this padding is not needed?
Regards, Simon
On Fri, Dec 06, 2024 at 12:18:07PM -0700, Simon Glass wrote:
Hi Tom,
On Fri, 6 Dec 2024 at 07:13, Tom Rini trini@konsulko.com wrote:
On Fri, Dec 06, 2024 at 06:11:12AM -0700, Simon Glass wrote:
[snip]
A comment in that function says that we assume there is space after the existing fdt to use for padding, with the padding size set to CONFIG_SYS_FDT_PAD
However, there is no guarantee that this space is available. If using the control FDT, then global_data is immediately above it, so expanding the FDT and adding FDT properties will cause U-Boot to fail.
This sounds like a generic issue and should be fixed outside of a "Pi" series.
Yes and I know you keep asking for multiple smaller series, but I've explained that keeping track of all that for months at a time is too challenging for me.
Yes, and it's also too challenging to review for the rest of us.
diff --git a/dts/Kconfig b/dts/Kconfig index 41a758e83a6..360611edd01 100644 --- a/dts/Kconfig +++ b/dts/Kconfig @@ -219,6 +219,17 @@ config OF_OMIT_DTB This is used for boards which normally provide a devicetree via a runtime mechanism (such as OF_BOARD), to avoid confusion.
+config OF_EXPAND
hex # "Amount to allow the control FDT to expand"No "# ..." because the help explains what to do here, if needed.
OK
default SYS_FDT_PAD if OF_LIBFDTdefault 0A "default 0" is almost always wrong.
In this case it is correct, since it means not to add any extra space for the FDT.
Which is still wrong? Because we don't allow for this particular device tree in memory to be read-only and so the question is "Do you want to break things on some platforms or not?".
helpSome boards make use of the control FDT to boot an OS, thus whenimage_setup_libfdt() adds extra things to the end of the FDT, thereneeds to be enough space.Set this to the number of bytes of extra space required for the FDT.We should just use SYS_FDT_PAD directly and not add a new option.
I thought I read somewhere that fdt_high == -1 should not be used. So for most boards, this padding is not needed?
That's also true, and gets back to why putting multiple patches in a single series is a Bad Idea. The function in question isn't doing some check for if we've disabled device tree relocation for the OS, it's early on, it's reserving our control fdt, yes? And then the problem ends up being later on, we use the control fdt for the OS, and modify it, but haven't ensured there's enough space for said modifications to not stomp on something else? That is a much bigger generic problem, no?
Hi Tom,
On Fri, 6 Dec 2024 at 12:49, Tom Rini trini@konsulko.com wrote:
On Fri, Dec 06, 2024 at 12:18:07PM -0700, Simon Glass wrote:
Hi Tom,
On Fri, 6 Dec 2024 at 07:13, Tom Rini trini@konsulko.com wrote:
On Fri, Dec 06, 2024 at 06:11:12AM -0700, Simon Glass wrote:
[snip]
A comment in that function says that we assume there is space after the existing fdt to use for padding, with the padding size set to CONFIG_SYS_FDT_PAD
However, there is no guarantee that this space is available. If using the control FDT, then global_data is immediately above it, so expanding the FDT and adding FDT properties will cause U-Boot to fail.
This sounds like a generic issue and should be fixed outside of a "Pi" series.
Yes and I know you keep asking for multiple smaller series, but I've explained that keeping track of all that for months at a time is too challenging for me.
Yes, and it's also too challenging to review for the rest of us.
diff --git a/dts/Kconfig b/dts/Kconfig index 41a758e83a6..360611edd01 100644 --- a/dts/Kconfig +++ b/dts/Kconfig @@ -219,6 +219,17 @@ config OF_OMIT_DTB This is used for boards which normally provide a devicetree via a runtime mechanism (such as OF_BOARD), to avoid confusion.
+config OF_EXPAND
hex # "Amount to allow the control FDT to expand"No "# ..." because the help explains what to do here, if needed.
OK
default SYS_FDT_PAD if OF_LIBFDTdefault 0A "default 0" is almost always wrong.
In this case it is correct, since it means not to add any extra space for the FDT.
Which is still wrong? Because we don't allow for this particular device tree in memory to be read-only and so the question is "Do you want to break things on some platforms or not?".
helpSome boards make use of the control FDT to boot an OS, thus whenimage_setup_libfdt() adds extra things to the end of the FDT, thereneeds to be enough space.Set this to the number of bytes of extra space required for the FDT.We should just use SYS_FDT_PAD directly and not add a new option.
I thought I read somewhere that fdt_high == -1 should not be used. So for most boards, this padding is not needed?
That's also true, and gets back to why putting multiple patches in a single series is a Bad Idea. The function in question isn't doing some check for if we've disabled device tree relocation for the OS, it's early on, it's reserving our control fdt, yes? And then the problem ends up being later on, we use the control fdt for the OS, and modify it, but haven't ensured there's enough space for said modifications to not stomp on something else? That is a much bigger generic problem, no?
It seems that people are already aware of the problem this patch addresses, but since it is specific to fdt_high, which should not be used, it seems unnecessary to worry about it.
I'm going to drop this patch.
Regards, Simon
Hi Tom,
On Mon, 9 Dec 2024 at 11:07, Simon Glass sjg@chromium.org wrote:
Hi Tom,
On Fri, 6 Dec 2024 at 12:49, Tom Rini trini@konsulko.com wrote:
On Fri, Dec 06, 2024 at 12:18:07PM -0700, Simon Glass wrote:
Hi Tom,
On Fri, 6 Dec 2024 at 07:13, Tom Rini trini@konsulko.com wrote:
On Fri, Dec 06, 2024 at 06:11:12AM -0700, Simon Glass wrote:
[snip]
A comment in that function says that we assume there is space after the existing fdt to use for padding, with the padding size set to CONFIG_SYS_FDT_PAD
However, there is no guarantee that this space is available. If using the control FDT, then global_data is immediately above it, so expanding the FDT and adding FDT properties will cause U-Boot to fail.
This sounds like a generic issue and should be fixed outside of a "Pi" series.
Yes and I know you keep asking for multiple smaller series, but I've explained that keeping track of all that for months at a time is too challenging for me.
Yes, and it's also too challenging to review for the rest of us.
diff --git a/dts/Kconfig b/dts/Kconfig index 41a758e83a6..360611edd01 100644 --- a/dts/Kconfig +++ b/dts/Kconfig @@ -219,6 +219,17 @@ config OF_OMIT_DTB This is used for boards which normally provide a devicetree via a runtime mechanism (such as OF_BOARD), to avoid confusion.
+config OF_EXPAND
hex # "Amount to allow the control FDT to expand"No "# ..." because the help explains what to do here, if needed.
OK
default SYS_FDT_PAD if OF_LIBFDTdefault 0A "default 0" is almost always wrong.
In this case it is correct, since it means not to add any extra space for the FDT.
Which is still wrong? Because we don't allow for this particular device tree in memory to be read-only and so the question is "Do you want to break things on some platforms or not?".
helpSome boards make use of the control FDT to boot an OS, thus whenimage_setup_libfdt() adds extra things to the end of the FDT, thereneeds to be enough space.Set this to the number of bytes of extra space required for the FDT.We should just use SYS_FDT_PAD directly and not add a new option.
I thought I read somewhere that fdt_high == -1 should not be used. So for most boards, this padding is not needed?
That's also true, and gets back to why putting multiple patches in a single series is a Bad Idea. The function in question isn't doing some check for if we've disabled device tree relocation for the OS, it's early on, it's reserving our control fdt, yes? And then the problem ends up being later on, we use the control fdt for the OS, and modify it, but haven't ensured there's enough space for said modifications to not stomp on something else? That is a much bigger generic problem, no?
It seems that people are already aware of the problem this patch addresses, but since it is specific to fdt_high, which should not be used, it seems unnecessary to worry about it.
I'm going to drop this patch.
I forgot to mention one other thing that I noticed.
If someone uses U-Boot with this series, but does not erase fdt_high from the environment, then it will not boot. It seems like a bit of a trap, to me.
Regards, Simon
The fdt_addr variable is used in extlinux as a fallback devicetree if none is provided by the boot command.
The existing mechanism uses the devicetree provided to U-Boot, but in its original, unrelocated position. For the rpi_4 I am using, this is at 2b35ef00 which is not a convenient place in memory, if the ramdisk is large.
U-Boot already deals with this sort of problem by relocating the FDT to a safe address.
So use the control-FDT address instead.
Remove the existing comment, which is confusing, since the FDT is not actually passed unmodified to the kernel: U-Boot adds various things using its FDT-fixup mechanism.
Note that board_get_usable_ram_top() reduces the RAM top for boards with less RAM. This behaviour is left unchanged as there is no other mechanism for U-Boot to handle this.
Signed-off-by: Simon Glass sjg@chromium.org ---
board/raspberrypi/rpi/rpi.c | 20 ++++++++------------ 1 file changed, 8 insertions(+), 12 deletions(-)
diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c index 9122f33d88d..8f6ab1b1b9b 100644 --- a/board/raspberrypi/rpi/rpi.c +++ b/board/raspberrypi/rpi/rpi.c @@ -3,6 +3,8 @@ * (C) Copyright 2012-2016 Stephen Warren */
+#define LOG_CATEGORY LOGC_BOARD + #include <config.h> #include <dm.h> #include <env.h> @@ -325,19 +327,10 @@ static void set_fdtfile(void) env_set("fdtfile", fdtfile); }
-/* - * If the firmware provided a valid FDT at boot time, let's expose it in - * ${fdt_addr} so it may be passed unmodified to the kernel. - */ +/* Allow U-Boot to use its control FDT with extlinux if one is not provided */ static void set_fdt_addr(void) { - if (env_get("fdt_addr")) - return; - - if (fdt_magic(fw_dtb_pointer) != FDT_MAGIC) - return; - - env_set_hex("fdt_addr", fw_dtb_pointer); + env_set_hex("fdt_addr", (ulong)gd->fdt_blob); }
/* @@ -572,7 +565,10 @@ int ft_board_setup(void *blob, struct bd_info *bd) { int node;
- update_fdt_from_fw(blob, (void *)fw_dtb_pointer); + if (blob == gd->fdt_blob) + log_debug("Same FDT: nothing to do\n"); + else + update_fdt_from_fw(blob, (void *)gd->fdt_blob);
node = fdt_node_offset_by_compatible(blob, -1, "simple-framebuffer"); if (node < 0)
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.
Hi Tom,
On Fri, 6 Dec 2024 at 07:08, Tom Rini trini@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.
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!
Regards, Simon
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@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-wa... 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).
Hi Tom,
On Fri, 6 Dec 2024 at 12:41, Tom Rini trini@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@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-wa... 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.
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...
Regards, Simon
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@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@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-wa... 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.
Hi Tom,
On Fri, 6 Dec 2024 at 16:52, Tom Rini trini@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@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@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-wa... 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?
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.
Regards, Simon
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@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@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@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-wa... 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."
Hi Tom,
On Fri, 6 Dec 2024 at 17:00, Tom Rini trini@konsulko.com 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 trini@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@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@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-wa... 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
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.
Regards, Simon
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 trini@konsulko.com 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 trini@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@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@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-wa... 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.
> 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.
Hi Tom,
On Fri, 6 Dec 2024 at 17:52, Tom Rini trini@konsulko.com 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 trini@konsulko.com 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 trini@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@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@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-wa... > 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
On Sat, Dec 07, 2024 at 04:51:34PM -0700, Simon Glass wrote:
Hi Tom,
On Fri, 6 Dec 2024 at 17:52, Tom Rini trini@konsulko.com 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 trini@konsulko.com 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 trini@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@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@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-wa... > > 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.
There's nothing to take on? The fdt_high and initrd_high environment variables are documented, along with the other relevant bootm variables. In general, at least bootm_low / bootm_size are useful and the correct way to solve the problem of "ensure device tree and initrd are where the OS can see them", when we are NOT in the use case of "we have an API to cooperate on this task". The problem is that for in hind sight extremely bad reasons, we allowed for the magic value of -1 to mean "Do not move the device tree" (or initrd). In the latter case, it's a boot time optimization that's quite useful and handy at least on the processors of the time. In the case of the former, man years (I'm not exaggerating at this point) of engineering time has been wasted over the device tree being in an unaligned or about to be overwritten location and we (U-Boot) don't fix it. The only remaining problem really is to remove fdt_high / initrd_high from the platforms that disabled relocation before I finally got all of my tooling right such that when a new platform did set it, I would see it and go off on an explanatory-rant about why that needs to be fixed.
Hi Tom,
On Sun, 8 Dec 2024 at 09:15, Tom Rini trini@konsulko.com wrote:
On Sat, Dec 07, 2024 at 04:51:34PM -0700, Simon Glass wrote:
Hi Tom,
On Fri, 6 Dec 2024 at 17:52, Tom Rini trini@konsulko.com 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 trini@konsulko.com 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 trini@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@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@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-wa... > > > 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.
There's nothing to take on? The fdt_high and initrd_high environment variables are documented, along with the other relevant bootm variables. In general, at least bootm_low / bootm_size are useful and the correct way to solve the problem of "ensure device tree and initrd are where the OS can see them", when we are NOT in the use case of "we have an API to cooperate on this task". The problem is that for in hind sight extremely bad reasons, we allowed for the magic value of -1 to mean "Do not move the device tree" (or initrd). In the latter case, it's a boot time optimization that's quite useful and handy at least on the processors of the time. In the case of the former, man years (I'm not exaggerating at this point) of engineering time has been wasted over the device tree being in an unaligned or about to be overwritten location and we (U-Boot) don't fix it. The only remaining problem really is to remove fdt_high / initrd_high from the platforms that disabled relocation before I finally got all of my tooling right such that when a new platform did set it, I would see it and go off on an explanatory-rant about why that needs to be fixed.
OK, yes it seems like fdt_high is a hack. But 'git grep fdt_high |grep fffff |wc' shows 74 matches, so it is still there.
Going back to my patch, do you have any comments about it? I am not about to boil the fdt_high ocean, sorry, but I will happily drop the fdt_high on rpi, since it seems unnecessary, at least for 64-bit kernels. I do see that kernels <4.2 require fdt_high on arm so that the kernel and FDT are within the same 512MB section. Is that still a concern?
I'll also add myself as a rpi maintainer since the current ones seem pretty busy.
I am planning to continue with the bootstd work, part of which will be to drop the need for these variables. If there are constraints, we can specify those either in the kernel FIT or in U-Boot's config, and implement them in C code (with tests), not scripts, variables, etc.
Regards, Simon
On Sun, Dec 08, 2024 at 04:06:47PM -0700, Simon Glass wrote:
[snip]
OK, yes it seems like fdt_high is a hack. But 'git grep fdt_high |grep fffff |wc' shows 74 matches, so it is still there.
Yes, it's something that needs to be done.
Going back to my patch, do you have any comments about it? I am not about to boil the fdt_high ocean, sorry, but I will happily drop the fdt_high on rpi, since it seems unnecessary, at least for 64-bit kernels. I do see that kernels <4.2 require fdt_high on arm so that the kernel and FDT are within the same 512MB section. Is that still a concern?
I'm not asking you to remove fdt_high from everyone, sorry if I gave that impression. For Pi the best option would be to set bootm_size to 512MB so that everything stays within that area, on all Pis and remove fdt_high and initrd_high in all cases there.
I'll also add myself as a rpi maintainer since the current ones seem pretty busy.
If they agree, sure.
I am planning to continue with the bootstd work, part of which will be to drop the need for these variables. If there are constraints, we can specify those either in the kernel FIT or in U-Boot's config, and implement them in C code (with tests), not scripts, variables, etc.
At the high level, yes, something like the approach EFI takes where there's not a need to relocate things after loading them to memory would remove the need for the variables that say where things go specifically, and only have the need for knowing what memory the OS will be able to see initially.
participants (2)
-
Simon Glass -
Tom Rini