[PATCH/RFC] ARM: boot: Relax kernel image alignment for RZ/A with CS3 SDRAM

[PATCH/RFC] ARM: boot: Relax kernel image alignment for RZ/A with CS3 SDRAM

[Geert Uytterhoeven]

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(-)

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


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH/RFC] ARM: boot: Relax kernel image alignment for RZ/A with CS3 SDRAM

[Russell King - ARM Linux admin]

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
> 
> 

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH/RFC] ARM: boot: Relax kernel image alignment for RZ/A with CS3 SDRAM

[Uwe Kleine-König]

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

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH/RFC] ARM: boot: Relax kernel image alignment for RZ/A with CS3 SDRAM

[Russell King - ARM Linux admin]

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? ;)

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH/RFC] ARM: boot: Relax kernel image alignment for RZ/A with CS3 SDRAM

[Uwe Kleine-König]

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?

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH/RFC] ARM: boot: Relax kernel image alignment for RZ/A with CS3 SDRAM

[Geert Uytterhoeven]

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

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH/RFC] ARM: boot: Relax kernel image alignment for RZ/A with CS3 SDRAM

[Geert Uytterhoeven]

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

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH/RFC] ARM: boot: Relax kernel image alignment for RZ/A with CS3 SDRAM

[Nicolas Pitre]

[-- Attachment #1: Type: text/plain, Size: 1512 bytes --]

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

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH/RFC] ARM: boot: Relax kernel image alignment for RZ/A with CS3 SDRAM

[Russell King - ARM Linux admin]

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.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH/RFC] ARM: boot: Relax kernel image alignment for RZ/A with CS3 SDRAM

[Geert Uytterhoeven]

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

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel