[opensuse-arm] U-Boot v2014.01

newer
[opensuse-arm] Chromebook SD card...

older
[opensuse-arm] FOSDEM 2014

Andreas Färber

27 Jan 2014 27 Jan '14

00:10

Hello, I've prepared a u-boot package update to v2014.01 and successfully tested it on the Toradex Colibri T20. However, the mlo-ext2.patch is causing some trouble. Due to the added ext4 support, the am335xevm SPL is 112 bytes too large. I managed to get it down to 104 bytes by avoiding a duplicate boot_mode assignment, but not further. The only way I managed to get it to compile was by commenting out that patch. Is it possible a) to commit u-boot v2014.01 despite am335xevm failing or b) to drop that patch in favor of a three-partition layout? https://build.opensuse.org/request/show/215180 is pending as preparation, rebased on the current v2013.10. Thanks, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Show replies by thread

Alexander Graf

27 Jan 27 Jan

07:05

New subject: [opensuse-arm] Re: U-Boot v2014.01

On 27.01.2014, at 01:10, Andreas Färber wrote:

...

Hello,

I've prepared a u-boot package update to v2014.01 and successfully tested it on the Toradex Colibri T20.

However, the mlo-ext2.patch is causing some trouble. Due to the added ext4 support, the am335xevm SPL is 112 bytes too large. I managed to get it down to 104 bytes by avoiding a duplicate boot_mode assignment, but not further. The only way I managed to get it to compile was by commenting out that patch.

Is it possible a) to commit u-boot v2014.01 despite am335xevm failing or

Yes. But we still need to fix it eventually. Does it get compiled with -Os? Do we compile in FAT and EXT support in parallel by accident?

...

b) to drop that patch in favor of a three-partition layout?

No. No more FAT please. Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Andreas Färber

10:11

New subject: [opensuse-arm] Re: U-Boot v2014.01

Am 27.01.2014 08:05, schrieb Alexander Graf:

...

On 27.01.2014, at 01:10, Andreas Färber wrote:

...
Hello,

I've prepared a u-boot package update to v2014.01 and successfully tested it on the Toradex Colibri T20.

However, the mlo-ext2.patch is causing some trouble. Due to the added ext4 support, the am335xevm SPL is 112 bytes too large. I managed to get it down to 104 bytes by avoiding a duplicate boot_mode assignment, but not further. The only way I managed to get it to compile was by commenting out that patch.

Is it possible a) to commit u-boot v2014.01 despite am335xevm failing or

Yes. But we still need to fix it eventually.

OK thanks, will clean my WIP up. https://build.opensuse.org/package/show/home:a_faerber:branches:Base:System/...

...

Does it get compiled with -Os?

No clue. :)

...

Do we compile in FAT and EXT support in parallel by accident?

Yes, you even reused CONFIG_SPL_FAT_SUPPORT for ext. ;)

...

...
b) to drop that patch in favor of a three-partition layout?

No. No more FAT please.

I rather had the non-optional raw mode in mind. We're going to need raw placed blobs for the ODROID-XU, too, it seems. In particular I am not so happy about you guys hardcoding OMAP4 hacks in generic code that is being reused by all u-boot-* packages with SPL. Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Alexander Graf

10:31

New subject: [opensuse-arm] Re: U-Boot v2014.01

On 27.01.2014, at 11:11, Andreas Färber wrote:

...

Am 27.01.2014 08:05, schrieb Alexander Graf:

...
On 27.01.2014, at 01:10, Andreas Färber wrote:

...
Hello,

I've prepared a u-boot package update to v2014.01 and successfully tested it on the Toradex Colibri T20.

However, the mlo-ext2.patch is causing some trouble. Due to the added ext4 support, the am335xevm SPL is 112 bytes too large. I managed to get it down to 104 bytes by avoiding a duplicate boot_mode assignment, but not further. The only way I managed to get it to compile was by commenting out that patch.

Is it possible a) to commit u-boot v2014.01 despite am335xevm failing or

Yes. But we still need to fix it eventually.

OK thanks, will clean my WIP up.

https://build.opensuse.org/package/show/home:a_faerber:branches:Base:System/...

...
Does it get compiled with -Os?

No clue. :)

...
Do we compile in FAT and EXT support in parallel by accident?

Yes, you even reused CONFIG_SPL_FAT_SUPPORT for ext. ;)

...
...
b) to drop that patch in favor of a three-partition layout?

No. No more FAT please.

I rather had the non-optional raw mode in mind. We're going to need raw placed blobs for the ODROID-XU, too, it seems.

So the normal boot workflow with SPL is: proprietary -> SPL -> u-boot.bin "Usually" the proprietary bit is on ROM somewhere so we don't have to worry. Some times it's split in multiple pieces with one piece that we do need to worry about (like on Arndale). SPL is at a hard offset on SD. u-boot.bin is in an ext2/3/4 partition. I suppose you're suggesting to move u-boot.bin to a hard offset on SD as well? That definitely works, just makes updating harder.

...

In particular I am not so happy about you guys hardcoding OMAP4 hacks in generic code that is being reused by all u-boot-* packages with SPL.

Uh - where exactly do we have OMAP4 hacks in generic code? Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Andreas Färber

10:45

New subject: [opensuse-arm] Re: U-Boot v2014.01

Am 27.01.2014 11:31, schrieb Alexander Graf:

...

On 27.01.2014, at 11:11, Andreas Färber wrote:

...
In particular I am not so happy about you guys hardcoding OMAP4 hacks in generic code that is being reused by all u-boot-* packages with SPL.

Uh - where exactly do we have OMAP4 hacks in generic code?

The bulk of mlo-ext2.patch is in common/spl/spl_mmc.c! spl_mmc_load_image() is being patched with + boot_mode = MMCSD_MODE_FAT; /* Fix OMAP4 boot */ And the 8 bytes I could save were due to my - boot_mode = spl_boot_mode(); +// boot_mode = spl_boot_mode(); Similarly, FAT handling code had been partially commented out in favor of ext2: - err = mmc_load_image_fat(mmc, CONFIG_SPL_FAT_LOAD_PAYLOAD_NAME); +// err = mmc_load_image_fat(mmc, CONFIG_SPL_FAT_LOAD_PAYLOAD_NAME); + err = mmc_load_image_ext2(mmc, "u-boot.bin"); /* We use u-boot.bin file on first partition */ It really sucks that it's all a gross local hack that none of you upstreamed with proper CONFIG_* guards since 2012. My .gnu.hash patch I immediately submitted upstream after verifying that u-boot-am335xevm builds without mlo-ext2.patch. Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Alexander Graf

11:00

New subject: [opensuse-arm] Re: U-Boot v2014.01

On 27.01.2014, at 11:45, Andreas Färber wrote:

...

Am 27.01.2014 11:31, schrieb Alexander Graf:

...
On 27.01.2014, at 11:11, Andreas Färber wrote:

...
In particular I am not so happy about you guys hardcoding OMAP4 hacks in generic code that is being reused by all u-boot-* packages with SPL.

Uh - where exactly do we have OMAP4 hacks in generic code?

The bulk of mlo-ext2.patch is in common/spl/spl_mmc.c!

spl_mmc_load_image() is being patched with + boot_mode = MMCSD_MODE_FAT; /* Fix OMAP4 boot */

Where is that an OMAP4 hack? It just sets the boot mode to FAT (which we reuse for ext2) rather than raw.

...

And the 8 bytes I could save were due to my - boot_mode = spl_boot_mode(); +// boot_mode = spl_boot_mode();

Similarly, FAT handling code had been partially commented out in favor of ext2:

- err = mmc_load_image_fat(mmc, CONFIG_SPL_FAT_LOAD_PAYLOAD_NAME); +// err = mmc_load_image_fat(mmc, CONFIG_SPL_FAT_LOAD_PAYLOAD_NAME); + err = mmc_load_image_ext2(mmc, "u-boot.bin"); /* We use u-boot.bin file on first partition */

It really sucks that it's all a gross local hack that none of you upstreamed with proper CONFIG_* guards since 2012. My .gnu.hash patch I immediately submitted upstream after verifying that u-boot-am335xevm builds without mlo-ext2.patch.

That one's slightly less controversial too ;). Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Andreas Färber

11:12

New subject: [opensuse-arm] Re: U-Boot v2014.01

Am 27.01.2014 12:00, schrieb Alexander Graf:

...

On 27.01.2014, at 11:45, Andreas Färber wrote:

...
Am 27.01.2014 11:31, schrieb Alexander Graf:

...
On 27.01.2014, at 11:11, Andreas Färber wrote:

...
In particular I am not so happy about you guys hardcoding OMAP4 hacks in generic code that is being reused by all u-boot-* packages with SPL.

Uh - where exactly do we have OMAP4 hacks in generic code?

The bulk of mlo-ext2.patch is in common/spl/spl_mmc.c!

spl_mmc_load_image() is being patched with + boot_mode = MMCSD_MODE_FAT; /* Fix OMAP4 boot */

Where is that an OMAP4 hack? It just sets the boot mode to FAT (which we reuse for ext2) rather than raw.

It affects more than just "MLO". I expect mlo-ext2.patch to only affect TI stuff, not Tegra, ODROID, and whomever comes along. It should really be split in two otherwise, one for configs/omap{3_beagle,4_common}.h and one for common SPL fiddling. Fixing "OMAP4 boot" by touching common code in a patch that is applied to all linked packages is simply not OK. Same for the huge sunxi patch - why can't that live in Contrib:sunxi rather than me having to count my fingers for how that patch was created and what to do with it on update. Patches just changing boot.scr are much less of a hassle. [...]

...

...
It really sucks that it's all a gross local hack that none of you upstreamed with proper CONFIG_* guards since 2012. My .gnu.hash patch I immediately submitted upstream after verifying that u-boot-am335xevm builds without mlo-ext2.patch.

That one's slightly less controversial too ;).

If it's so controversial then why are we carrying it and allowing it to hold up updating our generic U-Boot for, e.g., the rpi_b? :) Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Alexander Graf

11:19

New subject: [opensuse-arm] Re: U-Boot v2014.01

On 27.01.2014, at 12:12, Andreas Färber wrote:

...

Am 27.01.2014 12:00, schrieb Alexander Graf:

...
On 27.01.2014, at 11:45, Andreas Färber wrote:

...
Am 27.01.2014 11:31, schrieb Alexander Graf:

...
On 27.01.2014, at 11:11, Andreas Färber wrote:

...
In particular I am not so happy about you guys hardcoding OMAP4 hacks in generic code that is being reused by all u-boot-* packages with SPL.

Uh - where exactly do we have OMAP4 hacks in generic code?

The bulk of mlo-ext2.patch is in common/spl/spl_mmc.c!

spl_mmc_load_image() is being patched with + boot_mode = MMCSD_MODE_FAT; /* Fix OMAP4 boot */

Where is that an OMAP4 hack? It just sets the boot mode to FAT (which we reuse for ext2) rather than raw.

It affects more than just "MLO". I expect mlo-ext2.patch to only affect

It predates SPL. That's why it's called MLO. It really is supposed to be generic.

...

TI stuff, not Tegra, ODROID, and whomever comes along. It should really be split in two otherwise, one for configs/omap{3_beagle,4_common}.h and one for common SPL fiddling. Fixing "OMAP4 boot" by touching common code in a patch that is applied to all linked packages is simply not OK.

Yes. They really should be separate patches. I agree. It's just naturally grown this way because OMAP4 was the first upstream u-boot we were running with ext2 /boot.

...

Same for the huge sunxi patch - why can't that live in Contrib:sunxi rather than me having to count my fingers for how that patch was created and what to do with it on update.

IIRC It was an attempt to move towards a single code base :).

...

Patches just changing boot.scr are much less of a hassle.

[...]

...
...
It really sucks that it's all a gross local hack that none of you upstreamed with proper CONFIG_* guards since 2012. My .gnu.hash patch I immediately submitted upstream after verifying that u-boot-am335xevm builds without mlo-ext2.patch.

That one's slightly less controversial too ;).

If it's so controversial then why are we carrying it and allowing it to hold up updating our generic U-Boot for, e.g., the rpi_b? :)

I take no rpi support over FAT /boot any time :). But they really shouldn't conflict. Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Andreas Färber

12:06

New subject: [opensuse-arm] Re: U-Boot v2014.01

Am 27.01.2014 12:19, schrieb Alexander Graf:

...

On 27.01.2014, at 12:12, Andreas Färber wrote:

...
Am 27.01.2014 12:00, schrieb Alexander Graf:

...
On 27.01.2014, at 11:45, Andreas Färber wrote:

...
Am 27.01.2014 11:31, schrieb Alexander Graf:

...
On 27.01.2014, at 11:11, Andreas Färber wrote:

...
In particular I am not so happy about you guys hardcoding OMAP4 hacks in generic code that is being reused by all u-boot-* packages with SPL.

Uh - where exactly do we have OMAP4 hacks in generic code?

The bulk of mlo-ext2.patch is in common/spl/spl_mmc.c!

spl_mmc_load_image() is being patched with + boot_mode = MMCSD_MODE_FAT; /* Fix OMAP4 boot */

Where is that an OMAP4 hack? It just sets the boot mode to FAT (which we reuse for ext2) rather than raw.

It affects more than just "MLO". I expect mlo-ext2.patch to only affect

It predates SPL. That's why it's called MLO. It really is supposed to be generic.

...
TI stuff, not Tegra, ODROID, and whomever comes along. It should really be split in two otherwise, one for configs/omap{3_beagle,4_common}.h and one for common SPL fiddling. Fixing "OMAP4 boot" by touching common code in a patch that is applied to all linked packages is simply not OK.

Yes. They really should be separate patches. I agree. It's just naturally grown this way because OMAP4 was the first upstream u-boot we were running with ext2 /boot.

...
Same for the huge sunxi patch - why can't that live in Contrib:sunxi rather than me having to count my fingers for how that patch was created and what to do with it on update.

IIRC It was an attempt to move towards a single code base :).

Getting sunxi patches into upstream u-boot.git might be a better way forward? The patch hasn't really shrunk much with the new version. :/ [...]

...

...
...
...
It really sucks that it's all a gross local hack that none of you upstreamed with proper CONFIG_* guards since 2012. My .gnu.hash patch I immediately submitted upstream after verifying that u-boot-am335xevm builds without mlo-ext2.patch.

That one's slightly less controversial too ;).

If it's so controversial then why are we carrying it and allowing it to hold up updating our generic U-Boot for, e.g., the rpi_b? :)

I take no rpi support over FAT /boot any time :). But they really shouldn't conflict.

I guess most of us prefer one's board(s) working over someone else's filesystem. :) Once a board works, there's no strong reason to zypper-update the bootloader. https://build.opensuse.org/request/show/215263 If you can clean up the patch and restore the build so that we can get it submitted into Factory, I'll be happy. Even more so if you could create a u-boot fork on openSUSE GitHub similar to qemu, so that the next rebase will be less painful. quilt setup refused to work with our %prep section and I didn't find out why, thus as mentioned in .changes I sat down manually reworking some of the .patch files in the editor, which might explain my mood... Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Alexander Graf

12:16

New subject: [opensuse-arm] Re: U-Boot v2014.01

On 27.01.2014, at 13:06, Andreas Färber wrote:

...

Am 27.01.2014 12:19, schrieb Alexander Graf:

...
On 27.01.2014, at 12:12, Andreas Färber wrote:

...
Am 27.01.2014 12:00, schrieb Alexander Graf:

...
On 27.01.2014, at 11:45, Andreas Färber wrote:

...
Am 27.01.2014 11:31, schrieb Alexander Graf:

...
On 27.01.2014, at 11:11, Andreas Färber wrote:

> In particular I am not so happy about you guys hardcoding OMAP4 hacks in > generic code that is being reused by all u-boot-* packages with SPL.

Uh - where exactly do we have OMAP4 hacks in generic code?

The bulk of mlo-ext2.patch is in common/spl/spl_mmc.c!

spl_mmc_load_image() is being patched with + boot_mode = MMCSD_MODE_FAT; /* Fix OMAP4 boot */

Where is that an OMAP4 hack? It just sets the boot mode to FAT (which we reuse for ext2) rather than raw.

It affects more than just "MLO". I expect mlo-ext2.patch to only affect

It predates SPL. That's why it's called MLO. It really is supposed to be generic.

...
TI stuff, not Tegra, ODROID, and whomever comes along. It should really be split in two otherwise, one for configs/omap{3_beagle,4_common}.h and one for common SPL fiddling. Fixing "OMAP4 boot" by touching common code in a patch that is applied to all linked packages is simply not OK.

Yes. They really should be separate patches. I agree. It's just naturally grown this way because OMAP4 was the first upstream u-boot we were running with ext2 /boot.

...
Same for the huge sunxi patch - why can't that live in Contrib:sunxi rather than me having to count my fingers for how that patch was created and what to do with it on update.

IIRC It was an attempt to move towards a single code base :).

Getting sunxi patches into upstream u-boot.git might be a better way forward? The patch hasn't really shrunk much with the new version. :/

The last thing I remember from Dirk somewhere on this mailing list was "please remove it, I'll maintain a fork in the SunXi contrib".

...

[...]

...
...
...
...
It really sucks that it's all a gross local hack that none of you upstreamed with proper CONFIG_* guards since 2012. My .gnu.hash patch I immediately submitted upstream after verifying that u-boot-am335xevm builds without mlo-ext2.patch.

That one's slightly less controversial too ;).

If it's so controversial then why are we carrying it and allowing it to hold up updating our generic U-Boot for, e.g., the rpi_b? :)

I take no rpi support over FAT /boot any time :). But they really shouldn't conflict.

I guess most of us prefer one's board(s) working over someone else's filesystem. :) Once a board works, there's no strong reason to zypper-update the bootloader.

https://build.opensuse.org/request/show/215263

If you can clean up the patch and restore the build so that we can get it submitted into Factory, I'll be happy.

Sorry, I won't get around to anything except for KVM and QEMU patches for the next few days. I'm moving houses tomorrow and will try to squeeze in as many patch reviews as I can in between so that I don't miss the next merge window. Guillaume, do you have some spare time atm?

...

Even more so if you could create a u-boot fork on openSUSE GitHub similar to qemu, so that the next rebase will be less painful. quilt setup refused to work with our %prep section and I didn't find out why, thus as mentioned in .changes I sat down manually reworking some of the .patch files in the editor, which might explain my mood...

Welcome to the wonderful world of rpm packaging :). I'll be happy to apply our git based workflow to u-boot as soon as I've got some air to breathe again. Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Guillaume Gardet

12:53

New subject: [opensuse-arm] Re: U-Boot v2014.01

Le 27/01/2014 13:16, Alexander Graf a écrit :

...

On 27.01.2014, at 13:06, Andreas Färber wrote:

...
Am 27.01.2014 12:19, schrieb Alexander Graf:

...
On 27.01.2014, at 12:12, Andreas Färber wrote:

...
Am 27.01.2014 12:00, schrieb Alexander Graf:

...
On 27.01.2014, at 11:45, Andreas Färber wrote:

...
Am 27.01.2014 11:31, schrieb Alexander Graf: > On 27.01.2014, at 11:11, Andreas Färber wrote: > >> In particular I am not so happy about you guys hardcoding OMAP4 hacks in >> generic code that is being reused by all u-boot-* packages with SPL. > Uh - where exactly do we have OMAP4 hacks in generic code? The bulk of mlo-ext2.patch is in common/spl/spl_mmc.c!

spl_mmc_load_image() is being patched with + boot_mode = MMCSD_MODE_FAT; /* Fix OMAP4 boot */ Where is that an OMAP4 hack? It just sets the boot mode to FAT (which we reuse for ext2) rather than raw. It affects more than just "MLO". I expect mlo-ext2.patch to only affect It predates SPL. That's why it's called MLO. It really is supposed to be generic.

...
TI stuff, not Tegra, ODROID, and whomever comes along. It should really be split in two otherwise, one for configs/omap{3_beagle,4_common}.h and one for common SPL fiddling. Fixing "OMAP4 boot" by touching common code in a patch that is applied to all linked packages is simply not OK. Yes. They really should be separate patches. I agree. It's just naturally grown this way because OMAP4 was the first upstream u-boot we were running with ext2 /boot.

...
Same for the huge sunxi patch - why can't that live in Contrib:sunxi rather than me having to count my fingers for how that patch was created and what to do with it on update. IIRC It was an attempt to move towards a single code base :). Getting sunxi patches into upstream u-boot.git might be a better way forward? The patch hasn't really shrunk much with the new version. :/ The last thing I remember from Dirk somewhere on this mailing list was "please remove it, I'll maintain a fork in the SunXi contrib".

...
[...]

...
...
...
...
It really sucks that it's all a gross local hack that none of you upstreamed with proper CONFIG_* guards since 2012. My .gnu.hash patch I immediately submitted upstream after verifying that u-boot-am335xevm builds without mlo-ext2.patch. That one's slightly less controversial too ;). If it's so controversial then why are we carrying it and allowing it to hold up updating our generic U-Boot for, e.g., the rpi_b? :) I take no rpi support over FAT /boot any time :). But they really shouldn't conflict. I guess most of us prefer one's board(s) working over someone else's filesystem. :) Once a board works, there's no strong reason to zypper-update the bootloader.

https://build.opensuse.org/request/show/215263

If you can clean up the patch and restore the build so that we can get it submitted into Factory, I'll be happy. Sorry, I won't get around to anything except for KVM and QEMU patches for the next few days. I'm moving houses tomorrow and will try to squeeze in as many patch reviews as I can in between so that I don't miss the next merge window.

Guillaume, do you have some spare time atm?

Not much time ATM. What is needed here? Guillaume

...

...
Even more so if you could create a u-boot fork on openSUSE GitHub similar to qemu, so that the next rebase will be less painful. quilt setup refused to work with our %prep section and I didn't find out why, thus as mentioned in .changes I sat down manually reworking some of the .patch files in the editor, which might explain my mood... Welcome to the wonderful world of rpm packaging :). I'll be happy to apply our git based workflow to u-boot as soon as I've got some air to breathe again.

Alex

-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Andreas Färber

28 Jan 28 Jan

09:47

New subject: [opensuse-arm] Re: U-Boot v2014.01

Am 27.01.2014 13:53, schrieb Guillaume Gardet:

...

Le 27/01/2014 13:16, Alexander Graf a écrit :

...
On 27.01.2014, at 13:06, Andreas Färber wrote:

...
https://build.opensuse.org/request/show/215263

If you can clean up the patch and restore the build so that we can get it submitted into Factory, I'll be happy. Sorry, I won't get around to anything except for KVM and QEMU patches for the next few days. I'm moving houses tomorrow and will try to squeeze in as many patch reviews as I can in between so that I don't miss the next merge window.

Guillaume, do you have some spare time atm?

Not much time ATM. What is needed here?

https://build.opensuse.org/package/show/Base:System/u-boot-am335xevm This is failing with the mlo-ext2.patch (that Alex, Dirk and you all have rebased in the past), now leading to an SPL too large for SRAM. As mentioned earlier, I was able to get that down to 104 bytes by avoiding a duplicate variable assignment: [ 390s] ld.bfd: u-boot-spl section `.u_boot_list' will not fit in region `.sram' [ 390s] ld.bfd: region `.sram' overflowed by 104 bytes What's needed is to change the patch in whatever way necessary to get the SPL code size small enough. Alex' suggestion was to replace FAT support with ext support instead of just adding the latter. A lesser priority once our build is fixed would be to overhaul the patch in such a way that some CONFIG_SPL_EXT_SUPPORT is used rather than reusing CONFIG_SPL_FAT_SUPPORT and mentions of hacks for OMAP4 be dropped, so that this can be submitted upstream and dropped as patch with the next U-Boot update. Even the environment changes (fatload vs. ext2load or load) could be upstreamed that way. Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Guillaume Gardet

13:58

New subject: [opensuse-arm] Re: U-Boot v2014.01

Le 27/01/2014 11:11, Andreas Färber a écrit :

...

Am 27.01.2014 08:05, schrieb Alexander Graf:

...
On 27.01.2014, at 01:10, Andreas Färber wrote:

...
Hello,

I've prepared a u-boot package update to v2014.01 and successfully tested it on the Toradex Colibri T20.

However, the mlo-ext2.patch is causing some trouble. Due to the added ext4 support, the am335xevm SPL is 112 bytes too large. I managed to get it down to 104 bytes by avoiding a duplicate boot_mode assignment, but not further. The only way I managed to get it to compile was by commenting out that patch.

Is it possible a) to commit u-boot v2014.01 despite am335xevm failing or Yes. But we still need to fix it eventually. OK thanks, will clean my WIP up.

https://build.opensuse.org/package/show/home:a_faerber:branches:Base:System/...

...
Does it get compiled with -Os? No clue. :)

Yes, -Os is used for building SPL, so we cannot size down SPL using compiler option. Guillaume

...

...
Do we compile in FAT and EXT support in parallel by accident? Yes, you even reused CONFIG_SPL_FAT_SUPPORT for ext. ;)

...
...
b) to drop that patch in favor of a three-partition layout? No. No more FAT please. I rather had the non-optional raw mode in mind. We're going to need raw placed blobs for the ODROID-XU, too, it seems.

In particular I am not so happy about you guys hardcoding OMAP4 hacks in generic code that is being reused by all u-boot-* packages with SPL.

Andreas

-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Guillaume Gardet

14:35

New subject: [opensuse-arm] Re: U-Boot v2014.01

Le 28/01/2014 10:47, Andreas Färber a écrit :

...

Am 27.01.2014 13:53, schrieb Guillaume Gardet:

...
Le 27/01/2014 13:16, Alexander Graf a écrit :

...
On 27.01.2014, at 13:06, Andreas Färber wrote:

...
https://build.opensuse.org/request/show/215263

If you can clean up the patch and restore the build so that we can get it submitted into Factory, I'll be happy. Sorry, I won't get around to anything except for KVM and QEMU patches for the next few days. I'm moving houses tomorrow and will try to squeeze in as many patch reviews as I can in between so that I don't miss the next merge window.

Guillaume, do you have some spare time atm? Not much time ATM. What is needed here? https://build.opensuse.org/package/show/Base:System/u-boot-am335xevm

This is failing with the mlo-ext2.patch (that Alex, Dirk and you all have rebased in the past), now leading to an SPL too large for SRAM.

As mentioned earlier, I was able to get that down to 104 bytes by avoiding a duplicate variable assignment:

[ 390s] ld.bfd: u-boot-spl section `.u_boot_list' will not fit in region `.sram' [ 390s] ld.bfd: region `.sram' overflowed by 104 bytes

What's needed is to change the patch in whatever way necessary to get the SPL code size small enough. Alex' suggestion was to replace FAT support with ext support instead of just adding the latter.

Good idea. We could also disable CONFIG_SPL_OS_BOOT since we do not boot Linux directly. I will give a try.

...

A lesser priority once our build is fixed would be to overhaul the patch in such a way that some CONFIG_SPL_EXT_SUPPORT is used rather than reusing CONFIG_SPL_FAT_SUPPORT and mentions of hacks for OMAP4 be dropped, so that this can be submitted upstream and dropped as patch with the next U-Boot update. Even the environment changes (fatload vs. ext2load or load) could be upstreamed that way.

I agree. We should upstream all our patches when possible. But this patch is not upstreamable without a big clean-up. ;) Guillaume

...

Andreas

-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Guillaume Gardet

15:34

New subject: [opensuse-arm] Re: U-Boot v2014.01

Le 28/01/2014 15:35, Guillaume Gardet a écrit :

...

Le 28/01/2014 10:47, Andreas Färber a écrit :

...
Am 27.01.2014 13:53, schrieb Guillaume Gardet:

...
Le 27/01/2014 13:16, Alexander Graf a écrit :

...
On 27.01.2014, at 13:06, Andreas Färber wrote:

...
https://build.opensuse.org/request/show/215263

If you can clean up the patch and restore the build so that we can get it submitted into Factory, I'll be happy. Sorry, I won't get around to anything except for KVM and QEMU patches for the next few days. I'm moving houses tomorrow and will try to squeeze in as many patch reviews as I can in between so that I don't miss the next merge window.

Guillaume, do you have some spare time atm? Not much time ATM. What is needed here? https://build.opensuse.org/package/show/Base:System/u-boot-am335xevm

This is failing with the mlo-ext2.patch (that Alex, Dirk and you all have rebased in the past), now leading to an SPL too large for SRAM.

As mentioned earlier, I was able to get that down to 104 bytes by avoiding a duplicate variable assignment:

[ 390s] ld.bfd: u-boot-spl section `.u_boot_list' will not fit in region `.sram' [ 390s] ld.bfd: region `.sram' overflowed by 104 bytes

What's needed is to change the patch in whatever way necessary to get the SPL code size small enough. Alex' suggestion was to replace FAT support with ext support instead of just adding the latter. Good idea. We could also disable CONFIG_SPL_OS_BOOT since we do not boot Linux directly. I will give a try.

Fixed that way. See SR #215393: https://build.opensuse.org/request/show/215393 No time to clean-up mlo-ext2.patch. Guillaume

...

...
A lesser priority once our build is fixed would be to overhaul the patch in such a way that some CONFIG_SPL_EXT_SUPPORT is used rather than reusing CONFIG_SPL_FAT_SUPPORT and mentions of hacks for OMAP4 be dropped, so that this can be submitted upstream and dropped as patch with the next U-Boot update. Even the environment changes (fatload vs. ext2load or load) could be upstreamed that way. I agree. We should upstream all our patches when possible. But this patch is not upstreamable without a big clean-up. ;)

Guillaume

...
Andreas

-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

3766

Age (days ago)

3767

Last active (days ago)

List overview

Download

14 comments

3 participants

participants (3)

Alexander Graf
Andreas Färber
Guillaume Gardet