<font class="Apple-style-span" face="verdana, sans-serif"><br><br>On Tue, Aug 30, 2011 at 12:47 PM, Koen Kooi <<a href="mailto:koen@dominion.thruhere.net">koen@dominion.thruhere.net</a>> wrote:<br>><br>> Op 30 aug. 2011, om 18:46 heeft Jason Kridner het volgende geschreven:<br>
><br>>> On Mon, Aug 29, 2011 at 7:08 PM, Joel A Fernandes <<a href="mailto:agnel.joel@gmail.com">agnel.joel@gmail.com</a>> wrote:<br>>>> On Mon, Aug 29, 2011 at 4:03 PM, Jason Kridner <<a href="mailto:jkridner@beagleboard.org">jkridner@beagleboard.org</a>> wrote:<br>
>>>>>>><br>>>>>>>> This script is BSP specific and shouldn't live in the OE-core layer.<br>>>>>>><br>>>>>>> The only issue is this script is used from within the IMAGE_CMD_sdimg<br>
>>>>>> code which lives in OE-core (meta/classes/image_types.<br>>>>>><br>>>>>> classes shouldn't be calling external scripts<br>>>>>><br>>>>><br>
>>>> Is the right approach to add parameters to the IMAGE_CMD_sdimg class<br>>>>> such that it can be used generically to produce SD card images,<br>>>>> instead of trying to move this to meta-ti? Should it perhaps be a bit<br>
>>>> closer to what is being done by the Linaro image tools [1]?<br>>>>><br>>>>> [1] <a href="https://wiki.linaro.org/Source/ImageBuilding">https://wiki.linaro.org/Source/ImageBuilding</a><br>
>>>><br>>>><br>>>> Don't the Linaro scripts need to run on the target?<br>>><br>>> No.<br>>><br>>>> Does it fit well<br>>>> with OE(-core) ?<br>>><br>
>> I don't know, but I hoped that others would comment to help figure it<br>>> out. I think it is a common challenge not just for ARM architectures.<br>>> I'm not sure if the approach is general enough or not, but it does go<br>
>> beyond the BeagleBoard.<br>>><br>>> My primary concerns about leaving it in the BSP are:<br>>> 1) that there is some room for non-BeagleBoard specific optimizations<br>>> to the card layout and<br>
>> 2) there may be improvements to the tools that make it easier to<br>>> create images for systems with different boot requirements.<br>>><br>>> Also, I think we might want to move to an ext3 partition only in the<br>
>> future or other such layout optimizations. I'd like that to be<br>>> something that can be parameterized by the BSP.<br>><br>> I think you're missing the point:<br>><br>> 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.<br>
><br>><br><br>Hi Koen,<br><br>Can you suggest how we proceed with extending the bbclass?<br><br>I have tried both .bbappend and BBCLASSEXTEND and didn't get it to work.<br><br>I could create a new class and inherit the oe-core one from it with tweaks.</font><div>
<font class="Apple-style-span" face="verdana, sans-serif"><br></font></div><div><font class="Apple-style-span" face="verdana, sans-serif">Here is complete IRC discussion between me and bluelightning on the reasoning to extend the image.bbclass:<br>
<br>* cminyard (~<a href="mailto:cminyard@pool-173-57-155-71.dllstx.fios.verizon.net">cminyard@pool-173-57-155-71.dllstx.fios.verizon.net</a>) has joined #oe<br><joelagnel> I'd like to extend a bbclass in oe-core with tweaks in another layer<br>
<joelagnel> What is the right way to do so? .bbappend ? BBCLASSEXTEND?<br><GNUtoo|work> JaMa|Wrk, btw I've also another patch:<br><GNUtoo|work> at eukrea we use ubifs, and had the exact same issue than the freerunner ubifs issue, at least it seems<br>
<GNUtoo|work> we fixed it<br><GNUtoo|work> so if the patch arrived, it should fix it for you too<br><GNUtoo|work> joelagnel, BBCLASSEXTEND seem for recipes<br><joelagnel> I've seen it for classes in meta-oe:<br>
<joelagnel> ../meta-openembedded/meta-oe/classes/gnome.bbclass:BBCLASSEXTEND += "native"<br><joelagnel> GNUtoo|work, but it doesn't do what I want<br><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 ;)<br>
<GNUtoo|work> ok<br><GNUtoo|work> maybe ask in the list<br><joelagnel> everyone here on long weekend holiday? ;)<br>* hollisb (~<a href="mailto:hollisb@c-24-20-193-174.hsd1.or.comcast.net">hollisb@c-24-20-193-174.hsd1.or.comcast.net</a>) has joined #oe<br>
<bluelightning> joelagnel: I don't think bbclassextend is what you want<br><bluelightning> what tweaks do you want to apply?<br><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?<br>
<bluelightning> I don't think you can do it that way no<br><bluelightning> if it's the same name it will just replace it effectively<br><bluelightning> the most likely result in that case is you'll get a circular reference<br>
<joelagnel> BlindMan, there was some talk about moving my changes (IMAGE_CMD_sdimg) to the bsp layer<br><joelagnel> <a href="https://github.com/joelagnel/oe-core/blob/db4c960da57e8e0ae4741eea703a4e163c589efa/meta/classes/image_types.bbclass">https://github.com/joelagnel/oe-core/blob/db4c960da57e8e0ae4741eea703a4e163c589efa/meta/classes/image_types.bbclass</a><br>
<joelagnel> sorry I meant bluelightning ;)<br><joelagnel> need coffee!!! :-D<br><joelagnel> and need .bbclassappend ;)<br>* msm (~<a href="mailto:msm@192.88.168.35">msm@192.88.168.35</a>) has joined #oe<br>
<bluelightning> hmm; this is an interesting one<br><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<br>* phdeswer has quit (Ping timeout: 276 seconds)<br>
<joelagnel> bluelightning, I'm copying in a ubi file into the rootfs which I don't think is generic enough<br><joelagnel> also all sorts of assumptions are made about bootloader file names (U-boot, uEnv, user.txt) etc<br>
<bluelightning> hmm<br><bluelightning> is this only likely to be applicable to one machine then?<br><joelagnel> bluelightning, yeah. specially the bootloader environment files etc make assumptions about the machine (i2c bus names etc)<br>
<joelagnel> bluelightning, also Richard was suggesting that this was attempted before but requires special mounts etc which is true<br><joelagnel> we need it in there though so we could move it to the bsp for now<br>
<joelagnel> sounds good?<br>* Hoolxi (~<a href="mailto:Openfree@124.78.96.197">Openfree@124.78.96.197</a>) has joined #oe<br><bluelightning> joelagnel: well as a temporary measure but really duplicating class files is worth avoiding<br>
<bluelightning> just because of the pain of keeping it up-to-date<br><joelagnel> sure<br><bluelightning> I have to admit I'm unsure of the correct solution in this case though<br><bluelightning> it's worth trying to coax people on the mailing list to come up with the right answer :)<br>
<joelagnel> bluelightning, sure will do ,thanks :)</font><br></div><div><font class="Apple-style-span" face="verdana, sans-serif"><br></font></div><div><font class="Apple-style-span" face="verdana, sans-serif"><br></font></div>
<div><font class="Apple-style-span" face="verdana, sans-serif">Thanks,</font></div><div><font class="Apple-style-span" face="verdana, sans-serif">Joel</font></div>