Re: [RFC oe-core] mkcard: Add a script to parition and format an SD Card

[Joel A Fernandes <agnel.joel@gmail.com>]

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

On Tue, Aug 30, 2011 at 12:47 PM, Koen Kooi <koen@dominion.thruhere.net>
wrote:
>
> Op 30 aug. 2011, om 18:46 heeft Jason Kridner het volgende geschreven:
>
>> On Mon, Aug 29, 2011 at 7:08 PM, Joel A Fernandes <agnel.joel@gmail.com>
wrote:
>>> On Mon, Aug 29, 2011 at 4:03 PM, Jason Kridner <jkridner@beagleboard.org>
wrote:
>>>>>>>
>>>>>>> This script is BSP specific and shouldn't live in the OE-core layer.
>>>>>>
>>>>>> The only issue is this script is used from within the IMAGE_CMD_sdimg
>>>>>> code which lives in OE-core (meta/classes/image_types.
>>>>>
>>>>> classes shouldn't be calling external scripts
>>>>>
>>>>
>>>> Is the right approach to add parameters to the IMAGE_CMD_sdimg class
>>>> such that it can be used generically to produce SD card images,
>>>> instead of trying to move this to meta-ti?  Should it perhaps be a bit
>>>> closer to what is being done by the Linaro image tools [1]?
>>>>
>>>> [1] https://wiki.linaro.org/Source/ImageBuilding
>>>>
>>>
>>> Don't the Linaro scripts need to run on the target?
>>
>> No.
>>
>>> Does it fit well
>>> with OE(-core) ?
>>
>> I don't know, but I hoped that others would comment to help figure it
>> out.  I think it is a common challenge not just for ARM architectures.
>> I'm not sure if the approach is general enough or not, but it does go
>> beyond the BeagleBoard.
>>
>> My primary concerns about leaving it in the BSP are:
>> 1) that there is some room for non-BeagleBoard specific optimizations
>> to the card layout and
>> 2) there may be improvements to the tools that make it easier to
>> create images for systems with different boot requirements.
>>
>> Also, I think we might want to move to an ext3 partition only in the
>> future or other such layout optimizations.  I'd like that to be
>> something that can be parameterized by the BSP.
>
> I think you're missing the point:
>
> The *script* needs to go into the BSP, you are free to extend the
bbclasses with code to deal with sd cards internally in OE-core.
>
>

Hi Koen,

Can you suggest how we proceed with extending the bbclass?

I have tried both .bbappend and BBCLASSEXTEND and didn't get it to work.

I could create a new class and inherit the oe-core one from it with tweaks.

Here is complete IRC discussion between me and bluelightning on the
reasoning to extend the image.bbclass:

* cminyard (~cminyard@pool-173-57-155-71.dllstx.fios.verizon.net) has joined
#oe
<joelagnel> I'd like to extend a bbclass in oe-core with tweaks in another
layer
<joelagnel> What is the right way to do so? .bbappend ? BBCLASSEXTEND?
<GNUtoo|work> JaMa|Wrk, btw I've also another patch:
<GNUtoo|work> at eukrea we use ubifs, and had the exact same issue than the
freerunner ubifs issue, at least it seems
<GNUtoo|work> we fixed it
<GNUtoo|work> so if the patch arrived, it should fix it for you too
<GNUtoo|work> joelagnel, BBCLASSEXTEND seem for recipes
<joelagnel> I've seen it for classes in meta-oe:
<joelagnel> ../meta-openembedded/meta-oe/classes/gnome.bbclass:BBCLASSEXTEND
+= "native"
<joelagnel> GNUtoo|work, but it doesn't do what I want
<joelagnel> I can create a new class, inherit from the oe-core one and put
my code there, but I think that'll get rejected ;)
<GNUtoo|work> ok
<GNUtoo|work> maybe ask in the list
<joelagnel> everyone here on long weekend holiday? ;)
* hollisb (~hollisb@c-24-20-193-174.hsd1.or.comcast.net) has joined #oe
<bluelightning> joelagnel: I don't think bbclassextend is what you want
<bluelightning> what tweaks do you want to apply?
<joelagnel> bluelightning, can I name a class in an upper layer with the
same filename as that of a lower layer, and still be able to inherit the
lower layer one?
<bluelightning> I don't think you can do it that way no
<bluelightning> if it's the same name it will just replace it effectively
<bluelightning> the most likely result in that case is you'll get a circular
reference
<joelagnel> BlindMan, there was some talk about moving my changes
(IMAGE_CMD_sdimg) to the bsp layer
<joelagnel>
https://github.com/joelagnel/oe-core/blob/db4c960da57e8e0ae4741eea703a4e163c589efa/meta/classes/image_types.bbclass
<joelagnel> sorry I meant bluelightning ;)
<joelagnel> need coffee!!! :-D
<joelagnel> and need .bbclassappend ;)
* msm (~msm@192.88.168.35) has joined #oe
<bluelightning> hmm; this is an interesting one
<bluelightning> I recall the discussion on the mailing list... I do wonder
whether we ought to try to find a way to get this into oe-core itself
* phdeswer has quit (Ping timeout: 276 seconds)
<joelagnel> bluelightning, I'm copying in a ubi file into the rootfs which I
don't think is generic enough
<joelagnel> also all sorts of assumptions are made about bootloader file
names (U-boot, uEnv, user.txt) etc
<bluelightning> hmm
<bluelightning> is this only likely to be applicable to one machine then?
<joelagnel> bluelightning, yeah. specially the bootloader environment files
etc make assumptions about the machine (i2c bus names etc)
<joelagnel> bluelightning, also Richard was suggesting that this was
attempted before but requires special mounts etc which is true
<joelagnel> we need it in there though so we could move it to the bsp for
now
<joelagnel> sounds good?
* Hoolxi (~Openfree@124.78.96.197) has joined #oe
<bluelightning> joelagnel: well as a temporary measure but really
duplicating class files is worth avoiding
<bluelightning> just because of the pain of keeping it up-to-date
<joelagnel> sure
<bluelightning> I have to admit I'm unsure of the correct solution in this
case though
<bluelightning> it's worth trying to coax people on the mailing list to come
up with the right answer :)
<joelagnel> bluelightning, sure will do ,thanks :)


Thanks,
Joel

[-- Attachment #2: Type: text/html, Size: 7921 bytes --]