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