| Message ID | 87sicgc2cl.fsf@aikidev.net |
|---|---|
| State | RFC |
| Delegated to: | Tom Rini |
| Headers | show |
-----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-----
I have a couple of ShevaPlugs, one OpenRD Base and one OpenRD Ultimate. If you’ll guide me thru the process, I’ll be glad to help with testing. The ShevaPlugs are currently idle, while the Base and Ultimate are occupied doing useful work. So I’d prefer to start with the SheevaPlugs if that’s OK with you. Rick On Apr 3, 2015, at 2:46 PM, Vagrant Cascadian <vagrant@debian.org> wrote: > 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. > > > live well, > vagrant
On Sat, Apr 04, 2015 at 06:13:18PM +0200, drEagle wrote: > -----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. It's possible that by removing some CONFIG options things can fit under the size limit and not require env to be moved.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, Le 07/04/2015 02:39, Tom Rini a écrit : > On Sat, Apr 04, 2015 at 06:13:18PM +0200, drEagle wrote: >> -----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. >>> ... >>> 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. > > It's possible that by removing some CONFIG options things can fit under > the size limit and not require env to be moved. I do not agree with a stay in the past situation. I have proposed these refresh to help kirkwood plugs become useable. This is a platform that was looking promising and had also been not so user frendly in the beginning. The features like the sheevaplug MMC/SD driver was a pain. UBOOT have greatly gain in a peace of software more robust that in was few years ago. For Kirkwood Sheevaplugs we have also a device, SD cards, which was simply unuseable. So I decided to get this driver upstream. So what now ? USB layer get fixed. IDE layer get fixed. UBIFS is a new standard. EXT4 support helpfull. DEVICETREE is needed for linux kernel support. What I proposed is to get a refresh for : - - The NAND partitions (with a possible study to be friendly with most distributions around) - - To discuss about the better BOOTSTRAP method (I may used a script, propose defaults ENV. We may need to boot from IDE, USB, NAND, NET, ...) It's an open discussion to get a friendly users, understand with the lesser patch in each distribution, with the most possibility afford. I do not think that, all around customisation is the solution. Enjoy Gérald -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVJLuSAAoJEIoWzNw2mnfM+E4H/je+trD4WIb4Fgm01IZxZyev 0i7Z7F9Yf7pENUmh+IWdjycVMbOTXfHfA4/NXkUTF/TPK8xoE7Qv/tDqoqbeQ1Tl ZU2OtKu9HU8mKivj+2ljNSCoiahx9Kv22zU6VjNTlp0Xc423yiU9OjaFHpIQg6g3 BhFzbCIvM/SWRvUfpLtmGVuYR66hOIaKvFtg0k3MoD9ZdHXbQE9G3ywGGg6M3CVU D6+OdWg8E5UyL6Ion3aBYYlieZRzCS3hvo2/QwT95XfFG9LHmt4wG6cTC5SQtmdZ t/bUVFgB0OOderKN0kV4AVBn88rcdro5e+CkA4qKqYWn6hm2cb2YBIbs/XQDfKI= =J7kX -----END PGP SIGNATURE-----
On Wed, Apr 08, 2015 at 07:24:34AM +0200, drEagle wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Hi, > > Le 07/04/2015 02:39, Tom Rini a écrit : > > On Sat, Apr 04, 2015 at 06:13:18PM +0200, drEagle wrote: > >> -----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. > >>> > ... > >>> 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. > > > > It's possible that by removing some CONFIG options things can fit under > > the size limit and not require env to be moved. > > I do not agree with a stay in the past situation. > I have proposed these refresh to help kirkwood plugs become useable. > This is a platform that was looking promising and had also been not so user frendly in the beginning. > The features like the sheevaplug MMC/SD driver was a pain. > UBOOT have greatly gain in a peace of software more robust that in was few years ago. > For Kirkwood Sheevaplugs we have also a device, SD cards, which was simply unuseable. > > So I decided to get this driver upstream. > > So what now ? > USB layer get fixed. > IDE layer get fixed. > UBIFS is a new standard. > EXT4 support helpfull. > DEVICETREE is needed for linux kernel support. > > What I proposed is to get a refresh for : > - - The NAND partitions (with a possible study to be friendly with most distributions around) > - - To discuss about the better BOOTSTRAP method (I may used a script, propose defaults ENV. We may need to boot from IDE, USB, NAND, NET, ...) > > It's an open discussion to get a friendly users, understand with the lesser patch in each distribution, with the most possibility afford. > > I do not think that, all around customisation is the solution. I am fine with whatever the general community of users for these parts wants to do of course. And more functionality being used is better for everyone IMHO. The only thing I would really make a hard suggestion on is making sure that when growing the partitions to make sure it's got as much room as feasible for future growth.
I have an OpenRD base and ultimate, as well as a couple of sheevaplug machines, that I would be willing to use to help test anything that might make it possible to install and run Debian Jessie on these machine types. I’m an experienced sysadmin and I’ve worked in the past as a software tester, but I’m not much of a kernel or uboot hacker. If you can provide detailed instructions, I’ll give it a try and provide detailed reports on my results. Let me know what you’d like me to test. Enjoy! Rick On Apr 7, 2015, at 10:24 PM, drEagle <drEagle@DOUKKI.NET> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Hi, > > Le 07/04/2015 02:39, Tom Rini a écrit : >> On Sat, Apr 04, 2015 at 06:13:18PM +0200, drEagle wrote: >>> -----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. >>>> > ... >>>> 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. >> >> It's possible that by removing some CONFIG options things can fit under >> the size limit and not require env to be moved. > > I do not agree with a stay in the past situation. > I have proposed these refresh to help kirkwood plugs become useable. > This is a platform that was looking promising and had also been not so user frendly in the beginning. > The features like the sheevaplug MMC/SD driver was a pain. > UBOOT have greatly gain in a peace of software more robust that in was few years ago. > For Kirkwood Sheevaplugs we have also a device, SD cards, which was simply unuseable. > > So I decided to get this driver upstream. > > So what now ? > USB layer get fixed. > IDE layer get fixed. > UBIFS is a new standard. > EXT4 support helpfull. > DEVICETREE is needed for linux kernel support. > > What I proposed is to get a refresh for : > - - The NAND partitions (with a possible study to be friendly with most distributions around) > - - To discuss about the better BOOTSTRAP method (I may used a script, propose defaults ENV. We may need to boot from IDE, USB, NAND, NET, ...) > > It's an open discussion to get a friendly users, understand with the lesser patch in each distribution, with the most possibility afford. > > I do not think that, all around customisation is the solution. > > Enjoy > Gérald > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQEcBAEBCAAGBQJVJLuSAAoJEIoWzNw2mnfM+E4H/je+trD4WIb4Fgm01IZxZyev > 0i7Z7F9Yf7pENUmh+IWdjycVMbOTXfHfA4/NXkUTF/TPK8xoE7Qv/tDqoqbeQ1Tl > ZU2OtKu9HU8mKivj+2ljNSCoiahx9Kv22zU6VjNTlp0Xc423yiU9OjaFHpIQg6g3 > BhFzbCIvM/SWRvUfpLtmGVuYR66hOIaKvFtg0k3MoD9ZdHXbQE9G3ywGGg6M3CVU > D6+OdWg8E5UyL6Ion3aBYYlieZRzCS3hvo2/QwT95XfFG9LHmt4wG6cTC5SQtmdZ > t/bUVFgB0OOderKN0kV4AVBn88rcdro5e+CkA4qKqYWn6hm2cb2YBIbs/XQDfKI= > =J7kX > -----END PGP SIGNATURE----- > > > -- > To UNSUBSCRIBE, email to debian-arm-REQUEST@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org > Archive: https://lists.debian.org/5524BB92.4000906@doukki.net > >
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