[U-Boot] u-boot: OpenRD Ultimate fails to build

[U-Boot] u-boot: OpenRD Ultimate fails to build

[Vagrant Cascadian]

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:

  OBJCOPY u-boot.srec
  OBJCOPY u-boot.bin
u-boot.bin exceeds file size limit:
  limit:  393216 bytes
  actual: 407068 bytes
  excess: 13852 bytes
Makefile:834: recipe for target 'u-boot.bin' failed
make: *** [u-boot.bin] Error 1


Full build log:

  https://buildd.debian.org/status/fetch.php?pkg=u-boot&arch=armel&ver=2015.04~rc3%2Bdfsg1-1&stamp=1425849560


If you've got an openrd_ultimate and want to ensure it keeps working in
Debian (and obviously mainline)... please let me know!


live well,
  vagrant
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150321/43abebf2/attachment.sig>

[U-Boot] u-boot: OpenRD Ultimate fails to build

[drEagle]

Hi Vagrant,

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.

Take care also that the MMC/SDIO kirkwood driver has been renamed and is now mainline (MVEBU_MMC).
Default define is in SheevaPlug config file.

guruplug_mvfs_and_mmc.diff and openrd-mmc.diff still refer to an old driver.
These 2 patches may both been removed.

Guruplug has no need of the kirkwood MMC driver, cause the MMC/uSD slot they get is an USB hardware.
OpenRD and derivatives must use the newer (MVEBU_MMC) driver.

Enjoy
G?rald

[U-Boot] u-boot: OpenRD Ultimate fails to build

[Vagrant Cascadian]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150403/fded70cf/attachment.sig>

[U-Boot] u-boot: OpenRD Ultimate fails to build

[drEagle]

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

[U-Boot] u-boot: OpenRD Ultimate fails to build

[Tom Rini]

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.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150406/f7c080da/attachment.sig>

[U-Boot] KIRKWOOD - PARTITIONS and BOOTSTRAP

[drEagle]

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

[U-Boot] KIRKWOOD - PARTITIONS and BOOTSTRAP

[Tom Rini]

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.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150408/544008ff/attachment.sig>

[U-Boot] KIRKWOOD - PARTITIONS and BOOTSTRAP

[Rick Thomas]

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 at lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster at lists.debian.org
> Archive: https://lists.debian.org/5524BB92.4000906 at doukki.net
> 
> 

[U-Boot] u-boot: OpenRD Ultimate fails to build

[Rick Thomas]

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