u-boot: OpenRD Ultimate fails to build

U-Boot Vagrant Cascadian 4 participants 9 messages Mar 21, 2015 – Apr 10, 2015

Share & tools

Vagrant Cascadian

author

2015-03-21 14:53 UTC #0 lore raw

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>

drEagle

2015-03-26 02:57 UTC #1 lore raw

Hi Vagrant,

Le 21/03/2015 15:53, Vagrant Cascadian a ?crit :

Quoted 3 lines

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

Vagrant Cascadian

author

2015-04-03 21:46 UTC #2 lore raw

Quoted 6 lines · drEagle

Le 21/03/2015 15:53, Vagrant Cascadian a ?crit :
Quoted 3 lines
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:

include/configs/openrd.h +2 -2

index b6f80af..2f1e174 100644
@@ -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.

drEagle

2015-04-04 16:13 UTC #3 lore raw

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Le 03/04/2015 23:46, Vagrant Cascadian a ?crit :

Quoted 35 lines · drEagle

Quoted 6 lines
Le 21/03/2015 15:53, Vagrant Cascadian a ?crit :
Quoted 3 lines
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:
include/configs/openrd.h +2 -2
index b6f80af..2f1e174 100644
@@ -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

Quoted 2 lines

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

Rick Thomas

2015-04-05 10:50 UTC #8 lore raw

In reply to Vagrant Cascadian

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

Quoted 41 lines · Vagrant Cascadian

Quoted 6 lines · drEagle
Le 21/03/2015 15:53, Vagrant Cascadian a ?crit :
Quoted 3 lines
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:
include/configs/openrd.h +2 -2
index b6f80af..2f1e174 100644
@@ -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

Tom Rini

2015-04-07 00:39 UTC #4 lore raw

In reply to drEagle

Quoted 39 lines · drEagle

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Le 03/04/2015 23:46, Vagrant Cascadian a ?crit :
Quoted 35 lines · drEagle
Quoted 6 lines
Le 21/03/2015 15:53, Vagrant Cascadian a ?crit :
Quoted 3 lines
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:
include/configs/openrd.h +2 -2
index b6f80af..2f1e174 100644
@@ -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

Quoted 8 lines

Quoted 2 lines
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.

Signature · 8 lines

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>

drEagle

2015-04-08 05:24 UTC #5 lore raw

[U-Boot] KIRKWOOD - PARTITIONS and BOOTSTRAP

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi,

Le 07/04/2015 02:39, Tom Rini a ?crit :

Quoted 13 lines · drEagle

Quoted 12 lines
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Le 03/04/2015 23:46, Vagrant Cascadian a ?crit :
Quoted 8 lines · drEagle
Quoted 6 lines
Le 21/03/2015 15:53, Vagrant Cascadian a ?crit :
Quoted 3 lines
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.

...

Quoted 11 lines

Quoted 8 lines
Quoted 2 lines
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-----

Tom Rini

2015-04-08 15:50 UTC #6 lore raw

[U-Boot] KIRKWOOD - PARTITIONS and BOOTSTRAP

Quoted 48 lines · drEagle

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hi,
Le 07/04/2015 02:39, Tom Rini a ?crit :
Quoted 13 lines · drEagle
Quoted 12 lines
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Le 03/04/2015 23:46, Vagrant Cascadian a ?crit :
Quoted 8 lines · drEagle
Quoted 6 lines
Le 21/03/2015 15:53, Vagrant Cascadian a ?crit :
Quoted 3 lines
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.
...
Quoted 11 lines
Quoted 8 lines
Quoted 2 lines
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.

Quoted 7 lines

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.

Signature · 8 lines

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>

Rick Thomas

2015-04-10 10:47 UTC #7 lore raw

[U-Boot] KIRKWOOD - PARTITIONS and BOOTSTRAP

In reply to drEagle

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

Quoted 77 lines · drEagle

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hi,
Le 07/04/2015 02:39, Tom Rini a ?crit :
Quoted 13 lines · drEagle
Quoted 12 lines
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Le 03/04/2015 23:46, Vagrant Cascadian a ?crit :
Quoted 8 lines · drEagle
Quoted 6 lines
Le 21/03/2015 15:53, Vagrant Cascadian a ?crit :
Quoted 3 lines
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.
...
Quoted 11 lines
Quoted 8 lines
Quoted 2 lines
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