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

Fri Sep 2 18:12:13 UTC 2011

Hi Koen,

I thought of doing this, I just didn't know if it would be acceptable
and if there was a cleaner way of extending a .bbclass

Thanks,
Joel

On Fri, Sep 2, 2011 at 11:00 AM, Koen Kooi <koen at dominion.thruhere.net> wrote:
> Why not start with
>
> echo "inherit image" >> mynewclass.bbclass
>
> And have the image inherit mynewclass?
>
> Op 2 sep. 2011, om 17:44 heeft Joel A Fernandes het volgende geschreven:
>
>>
>>
>> On Tue, Aug 30, 2011 at 12:47 PM, Koen Kooi <koen at 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 at gmail.com> wrote:
>> >>> On Mon, Aug 29, 2011 at 4:03 PM, Jason Kridner <jkridner at 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 at 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 at 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 at 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 at 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
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core at lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>