I feel we gain the greatness of unified kernel but we make separate images that handle the u-boot quirks. We push down the stack so to speak. The only diff of each image being load addr's.

The exynos5 kernel requires FIT images, so an extra dimension of complexity. Well, at least for chromebook. Anyhow, fit images is a move in the right direction but not all u-boot support that so....

The problem statement is different u-boot are different, and we cannot have unified images.

We have a rootfs and make images for boards based on uboot quirks. Lucky if we can simplify load addr's, but we just have to test.

-Jon Disnard
Fas: parasense
Irc: masta

On Mar 26, 2013 8:31 PM, "Graeme Russ" <graeme.russ@gmail.com> wrote:
Hi Brendan,

On Wed, Mar 27, 2013 at 12:13 PM, Brendan Conoboy <blc@redhat.com> wrote:
> On 03/26/2013 06:09 PM, Graeme Russ wrote:
>>
>> I've had a quick glance at the U-Boot source and I think the newer
>> 'FIT' image may be a better path to follow. In common/image.c you will
>> find fit_image_get_load() and in common/cmd_bootm.c you will find
>> bootm_start() and bootm_load_os(). Teasing apart these functions, it
>> looks like fit_image_get_load() looks for a "load" property
>> (FIT_LOAD_PROP) in the FDT first, then in the FIT image (if the FDT
>> returns a NULL load address).
>>
>> Now you can set properties in the FDT in U-Boot (fdt set <path> <prop>
>> [<val>])
>>
>> So have a common FIT image with a common FDT and use U-Boot to tweak
>> the FDT properties such as the kernel load address
>
>
> I'd love to, but we don't ship uboot for a number of our boards.  We are
> limited to the functionality provided by the firmware provided.  FIT is not
> universal.

Well at least you can have a common image for all U-Boot boards :)

I suppose the 64-byte header per-board would work. Ugly, but not as
ugly as some of the other options.

You could also make a small mod to U-Boot to allow the load address of
legacy images to be changed via a command to make the hack slightly
less ugly

Regards,

Graeme
_______________________________________________
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm