On Tue, Aug 30, 2011 at 12:47 PM, Koen Kooi <k...@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.j...@gmail.com> wrote: >>> On Mon, Aug 29, 2011 at 4:03 PM, Jason Kridner <jkrid...@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 (~cminy...@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 (~holl...@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
_______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
