[OE-core] Deployment for machine X will remove its results from machine Y's deploy dir

[Mike Looijmans]

On 11/27/2014 05:21 PM, Richard Purdie wrote:
> On Thu, 2014-11-27 at 16:17 +0100, Mike Looijmans wrote:
>> If I understand correctly, having two "MACHINE" share the same
>> MACHINE_ARCH (which is the case for several intel boards too), is not
>> actually allowed?
>>
>> Because you get the same kernel/bootloader for different machines then.
>> That's what I wanted, and that triggered me finding this issue.
>
> Its a very good question. As things stand today, there is a one to one
> mapping between MACHINE_ARCH and MACHINE, the difference being the
> removal of invalid characters for the package namespace. That implies
> that no, its not allowed.

Okay... So I have to revert that, even through it worked remarkably well so 
far (until I found this issue - compared to the situation before that, this is 
still a vast improvement).

> The intel boards you mention do something a little different, they
> inject a new "arch" into the hierarchy and then several machines share
> that common "arch".

Yeah. I did basically the opposite, I expanded the MACHINE with an extra 
suffix and then stripped the suffix away when composing the MACHINE_ARCH.

> I suspect the intel boards you mention do suffer from the issue you
> mention in a related way and the fix may be to s/MACHINE/PACKAGE_ARCH/
> in DEPLOY_DIR_IMAGE as previously mentioned. The difference is I suspect
> they deploy for the first machine built and then not for any other.
> Nitin/Darren may be interested in checking into that.

Yes.

But if I set DEPOY_DIR_IMAGE to use MACHINE_ARCH, I get the opposite problem 
of two MACHINEs overwriting eachothers root filesystem. Though the $MACHINE in 
most of the filenames (which is typically removed for the links) might help 
separate those.

>> Please realize that the example is just an example. The actual problem
>> I'm experiencing is with the kernel and bootloader!
>
> Right, the allarch behaviour is an illustration but not the underlying
> problem you need to resolve (although its related).

Well, I thought I had it all sorted out, but I'm back to square one now.

What I'm really trying to do here is to create another "dimension".

The board contains a combined ARM + FPGA. The ARM part is just like any other 
machine, and it's the same on all boards.

The FPGA part also needs things built in the OE environment, and it has its 
own OS and "applications" in the form of a static bitstream to configure the 
whole device, and partial bitstreams that are swapped in and out at runtime to 
use it for various different functions. The build structure works much like a 
normal CPU toolchain, in that it creates the full bitstream which provides the 
"library" (Xilinx calls this a checkpoint) for the partials.
The FPGA can be of different types (currently we have xc7z015 and xc7z030 
boards, but there are plans to create SOMs for various other types too), and 
the bistreams are unique for each type, unlike CPU code, you cannot exchange 
them. The FPGA recipes leave these checkpoints into the sysroot where other 
FPGA recipes can pick them up and expand on them. Hence, I can't just make 
separate recipes for different FPGA types, because they need the sysroot to be 
specific to them.

So what I did was define the MACHINE as a combination of SOM+carrier+FPGA. The 
SOM+carrier part went into SOM_FAMILY and MACHINE_ARCH, and the FPGA part into 
the "FPGA_FAMILY" (and an FPGA_FAMILY_ARCH). The FPGA recipes use PACKAGE_ARCH 
= "${FPGA_FAMILY_ARCH}".

This config file sets that up:
https://github.com/topic-embedded-products/meta-topic/blob/master/conf/machine/include/topic-miami.inc

This has so far accomplished what I wanted to do, It makes all the ARM part 
things (like kernel and bootloader) generic, because they don't depend on the 
type of FPGA at all. And it makes the FPGA parts independent of the ARM side 
too, drastically reducing build times (FPGA bitstreams typically take 1 to 4 
hours to build, and that's for the smaller devices..) and heavily leaning on 
shares sstate-cache so we can re-use a buildserver's nightly output all over 
the place.

Another approach would be to introduce a global variable (FPGA_FAMILY?) that 
has the same level as MACHINE does, and require it to be set in local.conf or 
environment.
By explicitly using FPGA_FAMILY in intermediate and output paths, I think I 
can make it so that the sysroot can still hold the intermediate files for 
various targets. And simply including FPGA_FAMILY in the rootfs image name 
should solve the deployment issue.

I think more machines will emerge that need this kind of setup. The kernel has 
already gotten quite good at supporting hardware that can just grow itself a 
network card or i2c controller when it needs one...


Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Systems
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: (+31) (0) 499 33 69 79
Telefax:  (+31) (0) 499 33 69 70
E-mail: mike.looijmans at topic.nl
Website: www.topic.nl

Please consider the environment before printing this e-mail

Topic zoekt gedreven (embedded) software specialisten!
http://topic.nl/vacatures/topic-zoekt-software-engineers/