From mboxrd@z Thu Jan 1 00:00:00 1970 From: drEagle Date: Sat, 04 Apr 2015 18:13:18 +0200 Subject: [U-Boot] u-boot: OpenRD Ultimate fails to build In-Reply-To: <87sicgc2cl.fsf@aikidev.net> References: <878ueqbdwg.fsf@aikidev.net> <5513759B.9040606@doukki.net> <87sicgc2cl.fsf@aikidev.net> Message-ID: <55200D9E.9010205@doukki.net> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Le 03/04/2015 23:46, Vagrant Cascadian a ?crit : > On 2015-03-25, drEagle wrote: >> Le 21/03/2015 15:53, Vagrant Cascadian a ?crit : >>> It seems that OpenRD Ultimate with u-boot 2015.04-rc3 and newer no >>> longer builds from source, both in Debian and with mainline git. It >>> appears to have overgrown the size limits set for it: >> >> Looks like the NAND partition map had to be changed to give more space for u-boot. > > The following patch gets it to build by moving the env addr and offset > later. This might cause problems with new or existing u-boot > installations on openrd if the environment needs to be at a specific > location. I have no hardware to test, so no way of confirming this > directly: > > diff --git a/include/configs/openrd.h b/include/configs/openrd.h > index b6f80af..2f1e174 100644 > --- a/include/configs/openrd.h > +++ b/include/configs/openrd.h > @@ -72,12 +72,12 @@ > /* > * max 4k env size is enough, but in case of nand > * it has to be rounded to sector size > */ > #define CONFIG_ENV_SIZE 0x20000 /* 128k */ > -#define CONFIG_ENV_ADDR 0x60000 > -#define CONFIG_ENV_OFFSET 0x60000 /* env starts here */ > +#define CONFIG_ENV_ADDR 0x80000 > +#define CONFIG_ENV_OFFSET 0x80000 /* env starts here */ > /* > * Environment is right behind U-Boot in flash. Make sure U-Boot > * doesn't grow into the environment area. > */ > #define CONFIG_BOARD_SIZE_LIMIT CONFIG_ENV_OFFSET > > > I'll likely remove openrd_ultimate from future uploads to Debian if I > can't get confirmation about how to fix this properly. The same may be a problem for SHEEVAPLUG and GURUPLUG, may be also all KIRKWOOD derivatives. We need to get a more robust and compatible way to define the NAND PARTS, the BOOTLOAD and the NAND UPGRADE. Each distribution has differents needs. It's a discution needed upstream because it ill impact all distribution and users. G?rald -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVIA2eAAoJEIoWzNw2mnfMARsH/AyoItE9b11eGbv06rDfRNyP fnQx8Tfjj6tR+900rbivADLQt3FaeXiHzRHzw5yuwANL1+Es6DOWn5SaSfOJi8+2 x/vTownVs509Dmw625OJINudEOdo7Gl1NAB8g6aYOC4t/Bc99m++12/TAIR63HNA 72PgK6h+1skNJMORRIIefOjqjwBKK0IUAGtX4yWw6dvwt57Z1lt/djvauMT55b0L VTcfA9X4kr4luvc/Xat7Z/S01K5UO+RHzeFHketFADRh/zL0dbyIBBl5brewzroT zR9C2vwLutogWnk5IqTAIoxiCNfGl7WYClirT0UgupYLYZOaWFyBOi9ZdqUPYPU= =mfV8 -----END PGP SIGNATURE-----