[Openembedded-architecture] Heterogeneous System Proposal

Mark Hatle mark.hatle at kernel.crashing.org
Mon Dec 2 23:23:49 UTC 2019



On 12/2/19 4:09 PM, Richard Purdie wrote:
> On Mon, 2019-12-02 at 21:58 +0000, Richard Purdie wrote:
>> On Mon, 2019-12-02 at 15:37 -0600, Mark Hatle wrote:
>>> In all of the above examples, the user has manually configured the
>>> multiconfig within their project.  There is a simple way to move
>>> that
>>> configuration to a layer, simply place it in a conf/multiconfig
>>> directory within that layer.
>>>
>>> This ability suggests to be that there should be a standard way to
>>> specify a layer above that of machine, which defines the overall
>>> characteristics of the system.
>>>
>>> I'm proposing calling this new layer type as a system layer and
>>> it's
>>> configuration variable "SYSTEM".  It will be used instead of
>>> MACHINE
>>> when there is no single machine to quantify the contents of the
>>> produced system image.  When implementing a system, we do not want
>>> to
>>> make major changes to any other components.  Due to the existing
>>> implementation requiring MACHINE and certain TUNE parameters, this
>>> will require us to provide a special MACHINE value that can be used
>>> for a heterogeneous system.  I suggest we create a new 'nomachine'
>>> system that only defines/uses an equivalent noarch style
>>> tune.  This
>>> will instruct the system that this configuration can be used to
>>> noarch software and create images (including with wic), but it is
>>> not
>>> able to compile specific applications.  Each of these applications
>>> or
>>> images must come from a defined MACHINE.
>>
>> I'm not sure I 'buy' this explanation and I think a "nomachine"
>> target will be horrible in practice. In your example below, why can't
>> mysystem.conf just set MACHINE = "zcu_cortex-a72" and the other bits
>> of linux.conf and BBMULTICONFIG = "bootloader fpga" ? 
> 
> In fact, if you create a conf/machine/system-zcu_cortex-a72.conf and
> have it set something like:
> 
> BBMULTICONFIG = "bootloader fpga"
> MACHINE = "zcu_cortex-a72"
> require conf/machine/${MACHINE}.conf
> 
> I think what I/you describe may even work today without a new variable
> and simply a new convention of a special set of new machine name
> targets in layers...

Yes, SYSTEM could be implemented as something like:

MACHINE ??= ${@'system-${SYSTEM}' if d.getVar('SYSTEM')}

(I'm not really sure if that will work on not...)

The key though, I want a way to specify a system that by itself can't build
binaries -- but can only include binaries from other architectures.  (It -CAN-
however build noarch/all [text file] components to be included in the image.)

So you end up with:

system-zcu.conf
zcu-cortex-a72.conf
zcu-r5.conf
zcu-microblaze.conf

In the end the users should be able to build each of the components
independently WITHOUT ever using system, if they choose the 'old' way of
combining parts and pieces post build outside of the build system.

If they want a pre-defined multiconfig build, then they could use the system-zcu
to select all of the defaults for them.

--Mark

> Cheers,
> 
> Richard
> 


More information about the Openembedded-architecture mailing list