Re: Why does building an image for machine X delete the bootloader (and kernel) for machine Y?

[Mike Looijmans <mike.looijmans@topic.nl>]

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?


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@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/