| Message ID | 20191113102729.29303-1-geert+renesas@glider.be (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [PATCH/RFC] ARM: boot: Relax kernel image alignment for RZ/A with CS3 SDRAM | expand |
On Wed, Nov 13, 2019 at 11:27:29AM +0100, Geert Uytterhoeven wrote: > The RZA2MEVB sub board has 64 MiB of SDRAM at 0x0C000000 (CS3 space). > Hence the mask for CONFIG_AUTO_ZRELADDR needs to be changed, otherwise > the system will crash because it will try to decompress a zImage or > uImage to a non-RAM garbage address. > > Based on a patch in the BSP by Chris Brandt <chris.brandt@renesas.com>. > > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> > --- > No idea what to do with the rest of the comment, or if this breaks > existing platforms. We occasionally have discussions about this - the last one was a big one in Edinburgh, and the answer is we can't change this in mainline. They've also come up on the mailing lists as well. I'm not going to rehash this old argument yet again - the comment details the reason for it, and is there to prevent exactly this. If someone is silly enough to come up with a platform that violates the documented 32-bit ARM booting protocol, then they can't expect the kernel to bend to their platform's requirements at the expense of already merged platforms. Sorry. > > Thanks for your comments! > --- > arch/arm/boot/compressed/head.S | 8 ++++---- > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S > index 93dffed0ac6e02b4..cfee6bd1e7a0a582 100644 > --- a/arch/arm/boot/compressed/head.S > +++ b/arch/arm/boot/compressed/head.S > @@ -231,10 +231,10 @@ not_angel: > * address. > * > * This alignment is a balance between the requirements of > - * different platforms - we have chosen 128MB to allow > + * different platforms - we have chosen 64MB to allow > * platforms which align the start of their physical memory > - * to 128MB to use this feature, while allowing the zImage > - * to be placed within the first 128MB of memory on other > + * to 64MB to use this feature, while allowing the zImage > + * to be placed within the first 64MB of memory on other > * platforms. Increasing the alignment means we place > * stricter alignment requirements on the start of physical > * memory, but relaxing it means that we break people who > @@ -242,7 +242,7 @@ not_angel: > * of this range. > */ > mov r4, pc > - and r4, r4, #0xf8000000 > + and r4, r4, #0xfc000000 > /* Determine final kernel image address. */ > add r4, r4, #TEXT_OFFSET > #else > -- > 2.17.1 > >
On Wed, Nov 13, 2019 at 11:27:29AM +0100, Geert Uytterhoeven wrote: > The RZA2MEVB sub board has 64 MiB of SDRAM at 0x0C000000 (CS3 space). This wording is misleading. You don't adapt the limit because 128 MiB > the amount of RAM on that platform but because the alignment of the CS3 space isn't a multiple of 128 MiB. So I suggest: On the RZA2MEVB the SDRAM's base is at 0x0C000000 which isn't aligned to 128 MiB. So to ensure the assumptions of the decompressor are valid the used alignment must be decreased. > Hence the mask for CONFIG_AUTO_ZRELADDR needs to be changed, otherwise > the system will crash because it will try to decompress a zImage or > uImage to a non-RAM garbage address. > > Based on a patch in the BSP by Chris Brandt <chris.brandt@renesas.com>. > > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> > --- > No idea what to do with the rest of the comment, or if this breaks > existing platforms. I would assume that it indeed breaks existing platforms. So maybe better make this configurable, default to 128 MiB and select it to 64 MiB on the affected platform? If the resulting kernel supports also other machines a warning (at compile time) might be a good idea. Best regards Uwe
On Wed, Nov 13, 2019 at 11:40:37AM +0100, Uwe Kleine-König wrote: > On Wed, Nov 13, 2019 at 11:27:29AM +0100, Geert Uytterhoeven wrote: > > The RZA2MEVB sub board has 64 MiB of SDRAM at 0x0C000000 (CS3 space). > > This wording is misleading. You don't adapt the limit because 128 MiB > > the amount of RAM on that platform but because the alignment of the CS3 > space isn't a multiple of 128 MiB. So I suggest: > > On the RZA2MEVB the SDRAM's base is at 0x0C000000 which isn't > aligned to 128 MiB. So to ensure the assumptions of the > decompressor are valid the used alignment must be decreased. > > > Hence the mask for CONFIG_AUTO_ZRELADDR needs to be changed, otherwise > > the system will crash because it will try to decompress a zImage or > > uImage to a non-RAM garbage address. > > > > Based on a patch in the BSP by Chris Brandt <chris.brandt@renesas.com>. > > > > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> > > --- > > No idea what to do with the rest of the comment, or if this breaks > > existing platforms. > > I would assume that it indeed breaks existing platforms. So maybe better > make this configurable, default to 128 MiB and select it to 64 MiB on > the affected platform? If the resulting kernel supports also other > machines a warning (at compile time) might be a good idea. Are we going back to non-multi-platform kernels? ;)
Hello Russell, On Wed, Nov 13, 2019 at 10:39:19AM +0000, Russell King - ARM Linux admin wrote: > On Wed, Nov 13, 2019 at 11:27:29AM +0100, Geert Uytterhoeven wrote: > > The RZA2MEVB sub board has 64 MiB of SDRAM at 0x0C000000 (CS3 space). > > Hence the mask for CONFIG_AUTO_ZRELADDR needs to be changed, otherwise > > the system will crash because it will try to decompress a zImage or > > uImage to a non-RAM garbage address. > > > > Based on a patch in the BSP by Chris Brandt <chris.brandt@renesas.com>. > > > > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> > > --- > > No idea what to do with the rest of the comment, or if this breaks > > existing platforms. > > We occasionally have discussions about this - the last one was a big > one in Edinburgh, and the answer is we can't change this in mainline. > They've also come up on the mailing lists as well. > > I'm not going to rehash this old argument yet again - the comment > details the reason for it, and is there to prevent exactly this. > > If someone is silly enough to come up with a platform that violates > the documented 32-bit ARM booting protocol, then they can't expect > the kernel to bend to their platform's requirements at the expense of > already merged platforms. While I agree to your conclusion I think the last paragraph isn't a valid justification. The "32-bit ARM booting protocol"[1] doesn't mention an alignment, it only states "The kernel should be placed in the first 128MiB of RAM." And if this is done on a platform where RAM starts at 0x0C000000 this results in writes to [0x0b000000, 0x0c000000]. Best regards Uwe [1] that's Documentation/arm/booting.rst, right?
Hi Uwe, On Wed, Nov 13, 2019 at 11:40 AM Uwe Kleine-König <u.kleine-koenig@pengutronix.de> wrote: > On Wed, Nov 13, 2019 at 11:27:29AM +0100, Geert Uytterhoeven wrote: > > The RZA2MEVB sub board has 64 MiB of SDRAM at 0x0C000000 (CS3 space). > > This wording is misleading. You don't adapt the limit because 128 MiB > > the amount of RAM on that platform but because the alignment of the CS3 > space isn't a multiple of 128 MiB. So I suggest: Yeah, because of the "at 0x0C000000". > On the RZA2MEVB the SDRAM's base is at 0x0C000000 which isn't > aligned to 128 MiB. So to ensure the assumptions of the > decompressor are valid the used alignment must be decreased. Thanks, sounds better! Gr{oetje,eeting}s, Geert
Hi Russell, On Wed, Nov 13, 2019 at 11:39 AM Russell King - ARM Linux admin <linux@armlinux.org.uk> wrote: > On Wed, Nov 13, 2019 at 11:27:29AM +0100, Geert Uytterhoeven wrote: > > The RZA2MEVB sub board has 64 MiB of SDRAM at 0x0C000000 (CS3 space). > > Hence the mask for CONFIG_AUTO_ZRELADDR needs to be changed, otherwise > > the system will crash because it will try to decompress a zImage or > > uImage to a non-RAM garbage address. > > > > Based on a patch in the BSP by Chris Brandt <chris.brandt@renesas.com>. > > > > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> > > --- > > No idea what to do with the rest of the comment, or if this breaks > > existing platforms. > > We occasionally have discussions about this - the last one was a big > one in Edinburgh, and the answer is we can't change this in mainline. > They've also come up on the mailing lists as well. > > I'm not going to rehash this old argument yet again - the comment > details the reason for it, and is there to prevent exactly this. Sorry, I wasn't aware of that discussion. I had a chat about this at ELC-E with Arnd, and he was open to this change. > If someone is silly enough to come up with a platform that violates > the documented 32-bit ARM booting protocol, then they can't expect > the kernel to bend to their platform's requirements at the expense of > already merged platforms. Documentation/arm/booting.rst: 1. The kernel should be placed in the first 128MiB of RAM: check. 2. A safe location is just above the 128MiB boundary from start of RAM: oops. Not all platforms have more than 128 MiB of RAM... An alternative is to fall to the builtin 4 MiB of SRAM, or the 8 MiB of HyperRAM on RZA2MEVB, but doing that requires using XIP. Which brings us to your response in the other email: > Are we going back to non-multi-platform kernels? ;) Good question! ;-) 1. CONFIG_AUTO_ZRELADDR=n 2. CONFIG_XIP_KERNEL=y What do you suggest? Thanks! Gr{oetje,eeting}s, Geert
On Wed, 13 Nov 2019, Uwe Kleine-König wrote: > On Wed, Nov 13, 2019 at 11:27:29AM +0100, Geert Uytterhoeven wrote: > > The RZA2MEVB sub board has 64 MiB of SDRAM at 0x0C000000 (CS3 space). > > This wording is misleading. You don't adapt the limit because 128 MiB > > the amount of RAM on that platform but because the alignment of the CS3 > space isn't a multiple of 128 MiB. So I suggest: > > On the RZA2MEVB the SDRAM's base is at 0x0C000000 which isn't > aligned to 128 MiB. So to ensure the assumptions of the > decompressor are valid the used alignment must be decreased. > > > Hence the mask for CONFIG_AUTO_ZRELADDR needs to be changed, otherwise > > the system will crash because it will try to decompress a zImage or > > uImage to a non-RAM garbage address. > > > > Based on a patch in the BSP by Chris Brandt <chris.brandt@renesas.com>. > > > > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> > > --- > > No idea what to do with the rest of the comment, or if this breaks > > existing platforms. > > I would assume that it indeed breaks existing platforms. So maybe better > make this configurable, default to 128 MiB and select it to 64 MiB on > the affected platform? If the resulting kernel supports also other > machines a warning (at compile time) might be a good idea. Better yet could involve fetching the actual physical RAM start address from the DTB when present. This 128 MB mask was just a shortcut to keep things simple. Nicolas
On Wed, Nov 13, 2019 at 02:32:19PM +0100, Geert Uytterhoeven wrote: > Hi Russell, > > On Wed, Nov 13, 2019 at 11:39 AM Russell King - ARM Linux admin > <linux@armlinux.org.uk> wrote: > > On Wed, Nov 13, 2019 at 11:27:29AM +0100, Geert Uytterhoeven wrote: > > > The RZA2MEVB sub board has 64 MiB of SDRAM at 0x0C000000 (CS3 space). > > > Hence the mask for CONFIG_AUTO_ZRELADDR needs to be changed, otherwise > > > the system will crash because it will try to decompress a zImage or > > > uImage to a non-RAM garbage address. > > > > > > Based on a patch in the BSP by Chris Brandt <chris.brandt@renesas.com>. > > > > > > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> > > > --- > > > No idea what to do with the rest of the comment, or if this breaks > > > existing platforms. > > > > We occasionally have discussions about this - the last one was a big > > one in Edinburgh, and the answer is we can't change this in mainline. > > They've also come up on the mailing lists as well. > > > > I'm not going to rehash this old argument yet again - the comment > > details the reason for it, and is there to prevent exactly this. > > Sorry, I wasn't aware of that discussion. > I had a chat about this at ELC-E with Arnd, and he was open to this change. > > > If someone is silly enough to come up with a platform that violates > > the documented 32-bit ARM booting protocol, then they can't expect > > the kernel to bend to their platform's requirements at the expense of > > already merged platforms. > > Documentation/arm/booting.rst: > 1. The kernel should be placed in the first 128MiB of RAM: check. > 2. A safe location is just above the 128MiB boundary from start of RAM: > oops. Not all platforms have more than 128 MiB of RAM... > > An alternative is to fall to the builtin 4 MiB of SRAM, or the 8 MiB of > HyperRAM on RZA2MEVB, but doing that requires using XIP. > Which brings us to your response in the other email: > > > Are we going back to non-multi-platform kernels? ;) > > Good question! ;-) > > 1. CONFIG_AUTO_ZRELADDR=n > 2. CONFIG_XIP_KERNEL=y If you're using an XIP kernel, you are by definition not using the decompressor.
Hi Russell, On Wed, Nov 13, 2019 at 6:04 PM Russell King - ARM Linux admin <linux@armlinux.org.uk> wrote: > On Wed, Nov 13, 2019 at 02:32:19PM +0100, Geert Uytterhoeven wrote: > > On Wed, Nov 13, 2019 at 11:39 AM Russell King - ARM Linux admin > > <linux@armlinux.org.uk> wrote: > > > On Wed, Nov 13, 2019 at 11:27:29AM +0100, Geert Uytterhoeven wrote: > > > > The RZA2MEVB sub board has 64 MiB of SDRAM at 0x0C000000 (CS3 space). > > > > Hence the mask for CONFIG_AUTO_ZRELADDR needs to be changed, otherwise > > > > the system will crash because it will try to decompress a zImage or > > > > uImage to a non-RAM garbage address. > > > > > > > > Based on a patch in the BSP by Chris Brandt <chris.brandt@renesas.com>. > > > > > > > > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> > > > > --- > > > > No idea what to do with the rest of the comment, or if this breaks > > > > existing platforms. > > > > > > We occasionally have discussions about this - the last one was a big > > > one in Edinburgh, and the answer is we can't change this in mainline. > > > They've also come up on the mailing lists as well. > > > > > > I'm not going to rehash this old argument yet again - the comment > > > details the reason for it, and is there to prevent exactly this. > > > > Sorry, I wasn't aware of that discussion. > > I had a chat about this at ELC-E with Arnd, and he was open to this change. > > > > > If someone is silly enough to come up with a platform that violates > > > the documented 32-bit ARM booting protocol, then they can't expect > > > the kernel to bend to their platform's requirements at the expense of > > > already merged platforms. > > > > Documentation/arm/booting.rst: > > 1. The kernel should be placed in the first 128MiB of RAM: check. > > 2. A safe location is just above the 128MiB boundary from start of RAM: > > oops. Not all platforms have more than 128 MiB of RAM... > > > > An alternative is to fall to the builtin 4 MiB of SRAM, or the 8 MiB of > > HyperRAM on RZA2MEVB, but doing that requires using XIP. > > Which brings us to your response in the other email: > > > > > Are we going back to non-multi-platform kernels? ;) > > > > Good question! ;-) > > > > 1. CONFIG_AUTO_ZRELADDR=n > > 2. CONFIG_XIP_KERNEL=y > > If you're using an XIP kernel, you are by definition not using the > decompressor. Sure. I mean we may need 3 different setups for RZ/A: 1. multiplatform, 2. CONFIG_AUTO_ZRELADDR=n, 3. CONFIG_XIP_KERNEL=y. Gr{oetje,eeting}s, Geert
diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S index 93dffed0ac6e02b4..cfee6bd1e7a0a582 100644 --- a/arch/arm/boot/compressed/head.S +++ b/arch/arm/boot/compressed/head.S @@ -231,10 +231,10 @@ not_angel: * address. * * This alignment is a balance between the requirements of - * different platforms - we have chosen 128MB to allow + * different platforms - we have chosen 64MB to allow * platforms which align the start of their physical memory - * to 128MB to use this feature, while allowing the zImage - * to be placed within the first 128MB of memory on other + * to 64MB to use this feature, while allowing the zImage + * to be placed within the first 64MB of memory on other * platforms. Increasing the alignment means we place * stricter alignment requirements on the start of physical * memory, but relaxing it means that we break people who @@ -242,7 +242,7 @@ not_angel: * of this range. */ mov r4, pc - and r4, r4, #0xf8000000 + and r4, r4, #0xfc000000 /* Determine final kernel image address. */ add r4, r4, #TEXT_OFFSET #else
The RZA2MEVB sub board has 64 MiB of SDRAM at 0x0C000000 (CS3 space). Hence the mask for CONFIG_AUTO_ZRELADDR needs to be changed, otherwise the system will crash because it will try to decompress a zImage or uImage to a non-RAM garbage address. Based on a patch in the BSP by Chris Brandt <chris.brandt@renesas.com>. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> --- No idea what to do with the rest of the comment, or if this breaks existing platforms. Thanks for your comments! --- arch/arm/boot/compressed/head.S | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)