Re: Why does building an image for machine X delete the bootloader for machine Y?

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

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.


-- 
Mike Looijmans