<div dir="ltr"><div dir="ltr">Hey guys,</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Dec 2, 2019 at 3:24 PM Mark Hatle <<a href="mailto:mark.hatle@kernel.crashing.org">mark.hatle@kernel.crashing.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
On 12/2/19 4:09 PM, Richard Purdie wrote:<br>
> On Mon, 2019-12-02 at 21:58 +0000, Richard Purdie wrote:<br>
>> On Mon, 2019-12-02 at 15:37 -0600, Mark Hatle wrote:<br>
>>> In all of the above examples, the user has manually configured the<br>
>>> multiconfig within their project. There is a simple way to move<br>
>>> that<br>
>>> configuration to a layer, simply place it in a conf/multiconfig<br>
>>> directory within that layer.<br>
>>><br>
>>> This ability suggests to be that there should be a standard way to<br>
>>> specify a layer above that of machine, which defines the overall<br>
>>> characteristics of the system.<br>
>>><br>
>>> I'm proposing calling this new layer type as a system layer and<br>
>>> it's<br>
>>> configuration variable "SYSTEM". It will be used instead of<br>
>>> MACHINE<br>
>>> when there is no single machine to quantify the contents of the<br>
>>> produced system image. When implementing a system, we do not want<br>
>>> to<br>
>>> make major changes to any other components. Due to the existing<br>
>>> implementation requiring MACHINE and certain TUNE parameters, this<br>
>>> will require us to provide a special MACHINE value that can be used<br>
>>> for a heterogeneous system. I suggest we create a new 'nomachine'<br>
>>> system that only defines/uses an equivalent noarch style<br>
>>> tune. This<br>
>>> will instruct the system that this configuration can be used to<br>
>>> noarch software and create images (including with wic), but it is<br>
>>> not<br>
>>> able to compile specific applications. Each of these applications<br>
>>> or<br>
>>> images must come from a defined MACHINE.<br>
>><br>
>> I'm not sure I 'buy' this explanation and I think a "nomachine"<br>
>> target will be horrible in practice. In your example below, why can't<br>
>> mysystem.conf just set MACHINE = "zcu_cortex-a72" and the other bits<br>
>> of linux.conf and BBMULTICONFIG = "bootloader fpga" ? <br>
> <br>
> In fact, if you create a conf/machine/system-zcu_cortex-a72.conf and<br>
> have it set something like:<br>
> <br>
> BBMULTICONFIG = "bootloader fpga"<br>
> MACHINE = "zcu_cortex-a72"<br>
> require conf/machine/${MACHINE}.conf<br>
> <br>
> I think what I/you describe may even work today without a new variable<br>
> and simply a new convention of a special set of new machine name<br>
> targets in layers...<br></blockquote><div><br></div><div><div>So I have tried something similar to this, and while it does work, due to some parsing issue (I still have not figured out exactly what)</div><div>the multiconfig dependencies between multiconfigs are not being taken into account, which defeats the whole purpose.</div><div><br></div><div>While I understand that introducing a new variable might create some confusion, at the same time I do believe that it would be</div><div>better if we do it that way, and in some way separate workflows when we are building a "full" heterogeneous system vs a single</div><div>architecture system, the difference lies in the fact that we dont set what the "master" or core MACHINE is, they are all equal.</div><div><br></div><div>I have been working on the implementation of this proposal and here is what I currently have for which of course I am open to change.</div><div><br></div><div>Like I said, I had issues with defining a placeholder machine for the multiconfig dependencies, so I did go with defining</div><div><br></div><div>SYSTEM = "dummy-system"</div><div><br></div><div>on local.conf (also not a huge fan of the name since to me its a bit too generic,but as RP said, the name is probably the least of our problems)</div><div><br></div><div>then</div><div>include conf/system/${SYSTEM}.conf<br></div><div><br></div><div>and I have the following set up on a layer:</div><div><br></div><div>meta-heterogeneous</div><div> conf/layer.conf</div><div> conf/system/dummy-system.conf</div><div> conf/multiconfig/dummy-arm64.conf</div><div> conf/multiconfig/dummy-x86-64.conf</div><div> recipes-heterogeneous/<a href="http://heterogeneous-example_1.0.bb">heterogeneous-example_1.0.bb</a></div><div><br></div><div>Explanation:</div><div>layer.conf - normal layer.conf, nothing out of the ordinary</div><div><div>dummy-system.conf - Defines BBMULTICONFIG as dummy-arm64 and dummy-x86-64, AND defines the multiconfig dependencies between them</div><div>dummy-*64.conf - Define each of the multiconfigs, in them there are only 3 variables, DISTRO, MACHINE (qemuarm64 and qemux86-64 respectively), and TMPDIR which is simpy defined as tmp-${MACHINE}</div><div><a href="http://heterogeneous-example_1.0.bb">heterogeneous-example_1.0.bb</a> : This was a placeholder recipe, since to my knowledge bitbake required a target, and it simply contained a line that set up a multiconfig dependency that would allow:</div><div><br></div><div>$ bitbake heterogeneous-example</div><div><br></div><div>to start a buld for core-image-minimal (for example) for all archs in the SYSTEM.</div><div><br></div><div>Now that I read RP's email about BBTARGETS I believe this can be improved and at the very least delete the example recipe, let me know what yo guys think</div><div></div></div><div><br></div><div>Cheers,</div><div><br></div><div>Alejandro</div><div></div></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Yes, SYSTEM could be implemented as something like:<br>
<br>
MACHINE ??= ${@'system-${SYSTEM}' if d.getVar('SYSTEM')}<br>
<br>
(I'm not really sure if that will work on not...)<br>
<br>
The key though, I want a way to specify a system that by itself can't build<br>
binaries -- but can only include binaries from other architectures. (It -CAN-<br>
however build noarch/all [text file] components to be included in the image.)<br>
<br>
So you end up with:<br>
<br>
system-zcu.conf<br>
zcu-cortex-a72.conf<br>
zcu-r5.conf<br>
zcu-microblaze.conf<br>
<br>
In the end the users should be able to build each of the components<br>
independently WITHOUT ever using system, if they choose the 'old' way of<br>
combining parts and pieces post build outside of the build system.<br>
<br>
If they want a pre-defined multiconfig build, then they could use the system-zcu<br>
to select all of the defaults for them.<br>
<br>
--Mark<br>
<br>
> Cheers,<br>
> <br>
> Richard<br>
> <br>
_______________________________________________<br>
Openembedded-architecture mailing list<br>
<a href="mailto:Openembedded-architecture@lists.openembedded.org" target="_blank">Openembedded-architecture@lists.openembedded.org</a><br>
<a href="http://lists.openembedded.org/mailman/listinfo/openembedded-architecture" rel="noreferrer" target="_blank">http://lists.openembedded.org/mailman/listinfo/openembedded-architecture</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><b style="font-size:12.8px">M.S. Alejandro Enedino Herna</b><b style="font-size:12.8px">ndez Samaniego</b></div></div></div></div></div></div></div></div></div></div>