[OE-core] [PATCH 2/9] kernel.bbclass: move uImage handling to separate task

[Bruce Ashfield]

On Thu, Dec 15, 2011 at 2:09 PM, Tom Rini <tom.rini at gmail.com> wrote:
> On Thu, Dec 15, 2011 at 6:55 AM, Bruce Ashfield
> <bruce.ashfield at gmail.com> wrote:
> [snip]
>> If no one minds the tiny bit of extra complexity, this was the approach that I
>> was thinking about when reading this thread.
>>
>> I can report for fact, that the uImages that were being generated by
>> the existing
>> rules were binary blobs of silent boot death on the powerpc boards that I was
>> using during initial development. The in tree images worked perfectly.
>>
>> For everything I've done in the past, I've always used in tree uImages
>> or patched the
>> kernel tree itself to generated images that worked for the board in question.
>>
>> The difference in approach could likely be chalked up to a guy just
>> trying to get a
>> kernel to boot, and someone working more closely with the bootloader -> kernel
>> handoff.
>>
>> I think a variable, or some other switch, to support the two workflows
>> is a reasonable
>> compromise.
>
> Part of the history[1], and I was surprised at the time too, was that
> for ARM at least, rmk had said that you should not use the uImages
> generated by the kernel.  So the question is, has this changed?  Is
> this an ARM-only thing?'

I've been booting uImages generated by the kernel on ARM boards since nearly
2008. So it may be more of a per-board thing now .. or something else entirely.

Cheers,

Bruce

>
> [1]: http://lists.linuxtogo.org/pipermail/openembedded-devel/2008-November/007096.html
>
> --
> Tom
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"