On 27.01.2014, at 11:11, Andreas Färber <afaerber@suse.de> wrote:
Am 27.01.2014 08:05, schrieb Alexander Graf:
On 27.01.2014, at 01:10, Andreas Färber <afaerber@suse.de> 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