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

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

[Mike Looijmans]

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?


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/

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

[Paul Eggleton]

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.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

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

[Gary Thomas]

On 2014-11-26 01:19, 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?
>

What machines are you building for?  I've built for two different
i.MX6 platforms in the same build tree and I don't see this behaviour.
n.b. this was using the latest master Poky/Yocto

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

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

[Mike Looijmans]

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?)

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




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/

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

[Paul Eggleton]

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?

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

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

[Mike Looijmans]

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

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

[Mike Looijmans]

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/

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