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@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxx>. > > > > > > Signed-off-by: Geert Uytterhoeven <geert+renesas@xxxxxxxxx> > > > --- > > > 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
