Re: [PATCH 1/5] kernel.bbclass: move uImage handling to separate task

From: Koen Kooi <koen@dominion.thruhere.net>
To: Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH 1/5] kernel.bbclass: move uImage handling to separate task
Date: Mon, 19 Dec 2011 10:03:14 +0100	[thread overview]
Message-ID: <10033E42-FF15-4A1D-A8BC-799D1650E3C4@dominion.thruhere.net> (raw)
In-Reply-To: <CADkTA4Nx9Z_3iFzd6FbkbwiYANUL6B4BXsW7_4LngeqcED7DRQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1797 bytes --]

Op 19 dec. 2011, om 02:39 heeft Bruce Ashfield het volgende geschreven:

> On Sun, Dec 18, 2011 at 4:19 PM, Koen Kooi <koen@dominion.thruhere.net> wrote:
>> 
>> Op 18 dec. 2011, om 21:27 heeft Bruce Ashfield het volgende geschreven:
>> 
>>> On Sun, Dec 18, 2011 at 3:13 PM, Koen Kooi <koen@dominion.thruhere.net> wrote:
>>>> 
>>>> Op 18 dec. 2011, om 20:47 heeft Dmitry Eremin-Solenikov het volgende geschreven:
>>>> 
>>>>> As per org.oe.dev and meta-oe's kernel.bbclass move uImage creation to
>>>>> separate task from do_deploy. This way the do_install task can also
>>>>> benefit from generated uImage.
>>>>> 
>>>>> The only major feature of oe-core's version (not to recreate uImage
>>>>> if it exists) is retained in this patch.
>>>> 
>>>> I still don't agree with that behaviour. The in-kernel uImage code is just like the in-kernel defconfigs: useless for people who aren't kernel developers.
>>> 
>>> In that case, shouldn't people doing u-boot development (or other
>>> non-kernel developers),
>>> be building a uImage via something that isn't in kernel.bbclass ?
>> 
>> I use the kernel.bbclass in meta-oe, that does what I need.
> 
> ok. I was just trying to wrap my head around the use case, since I'm missing
> something, and that would help me understand what is missing in the in kernel
> uImage generation scripts. With that, we could see about getting
> changes upstream
> to address deficiencies.

The biggest problem is that "upstream" is $vendor in a lot of cases, so fixing it once in OE is more productive than patching N vendor kernels. I agree that mainline should have the working version, but for my current project mainline doesn't even have support for this SoC and won't have till devicetree has cured worldpeace.

regards,

Koen

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 169 bytes --]