[OE-core] Why does building an image for machine X delete the bootloader (and kernel) for machine Y?

[Mike Looijmans]

On 11/27/2014 08:46 AM, Mike Looijmans wrote:
> On 11/26/2014 07:44 PM, Mike Looijmans wrote:
>> On 11/26/2014 03:57 PM, Paul Eggleton wrote:
>>> On Wednesday 26 November 2014 14:20:46 Mike Looijmans wrote:
>>>> On 11/26/2014 12:31 PM, Paul Eggleton wrote:
>>>>> Hi Mike,
>>>>>
>>>>> On Wednesday 26 November 2014 09:19:13 Mike Looijmans wrote:
>>>>>> I do a:
>>>>>>
>>>>>> MACHINE=X bitbake my-image
>>>>>>
>>>>>> This DEPENDS on a virtual bootloader, which will produce a BOOT.BIN file
>>>>>> in
>>>>>> the deploy directory, which is tmp-glibc/deploy.images/X/
>>>>>>
>>>>>> If I then do a:
>>>>>>
>>>>>> MACHINE=Y bitbake my-image
>>>>>>
>>>>>> the BOOT.BIN in tmp-glibc/deploy.images/X/ is suddenly gone!
>>>>>>
>>>>>> If i do a
>>>>>>
>>>>>> MACHINE=X bitbake my-image
>>>>>>
>>>>>> then the the BOOT.BIN in tmp-glibc/deploy.images/Y/ is suddenly gone, and
>>>>>> the one for the X machine appears again. The bootloader recipe is not
>>>>>> being
>>>>>> rebuilt at all.
>>>>>>
>>>>>> The machines have the same MACHINE_ARCH, they differ on only minor points
>>>>>> (the FPGA).
>>>>>>
>>>>>> What is going on here?
>>>>>
>>>>> I can't be sure, but my guess is the recipe is not marked as being
>>>>> machine-
>>>>> specific (i.e. PACKAGE_ARCH is not set to "${MACHINE_ARCH}" - is that the
>>>>> case?) but there is still some variable dependency on a variable that has
>>>>> a machine-specific value. If it's not obvious from the recipe, check if
>>>>> there are two sets of tasks for the bootloader recipe in the sstate
>>>>> cache, and then use bitbake-diffsigs to compare the sigdata/siginfo
>>>>> files.
>>>>
>>>> MACHINE is actually "topic-miami-florida-med-xc7z015" or
>>>> "topic-miami-florida-med-xc7z030"
>>>>
>>>> Both machines have MACHINE_ARCH = "topic_miami_florida_med" since they only
>>>> differ in the FPGA subsystem, but share all the rest (kernel, bootloader,
>>>> etc).
>>>>
>>>> Is it forbidden to share $MACHINE_ARCH between $MACHINEs? (And if so, why
>>>> does MACHINE_ARCH even exist?)
>>>
>>> I don't know for sure, but I don't think that is forbidden. I'm not sure
>>> that's the issue here though.
>>>
>>>> The BSP layer for the topic-miami machines is here (yes, you can build OE or
>>>> Yocto images with it, but I have yet some more work to do to make it a
>>>> proper BSP...):
>>>> https://github.com/topic-embedded-products/meta-topic
>>>
>>> Is it u-boot that's the actual bootloader we are talking about here?
>>
>> Yep.
>>
>> u-boot-spl to be exact. The BOOT.bin is just one of the files that disappears,
>> it's the firststage loader built by u-boot.
>
> It happens anytime I switch between machines. Building for one will delete the
> files for the other. It will delete all bootloader and kernel files.
>
> Running
> MACHINE=topic-miami-florida-med-xc7z030 bitbake virtual/kernel -c deploy
> deletes the kernel for the xc7z015, and places it in the xz7z030 deploy dir, and
> MACHINE=topic-miami-florida-med-xc7z015 bitbake virtual/kernel -c deploy
> does the opposite.
>
> Probably some unforeseen effect of deploy when machines share the same arch?
>

It's not limited to kernel and bootloader either, it happens for ANY task that 
has a "deploy". The deploy task will remove files for another MACHINE, and 
then replace them with its own. It does not take the MACHINE into 
consideration, even though the deployment directory is specific to a machine 
(and not just MACHINE_ARCH).

Something similar happens if you create a package that is generic for all 
machines (PACKAGE_ARCH="all" or so), but needs to be deployed. Building for 
another machine will remove that package from the previous machine's 
deployment directory.

Seems to be a bug in OE. I'll create an example recipe to demonstrate it for 
any target.




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/