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

DISCUSSION Mike Looijmans 3 participants 8 messages Nov 26, 2014 – Nov 27, 2014

lore

Share & tools

lore

Mike Looijmans

author

2014-11-26 08:19 UTC #0 lore raw

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: [email protected]
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/

Paul Eggleton

2014-11-26 11:31 UTC #1 lore raw

Hi Mike,

Quoted 17 lines · 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

Quoted 8 lines

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

Signature · 2 lines

Paul Eggleton
Intel Open Source Technology Centre

Gary Thomas

2014-11-26 12:14 UTC #7 lore raw

In reply to Mike Looijmans

Quoted 14 lines · 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

Quoted 8 lines

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

Signature · 4 lines

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

Mike Looijmans

author

2014-11-26 13:20 UTC #2 lore raw

In reply to Paul Eggleton

Quoted 27 lines · Paul Eggleton

Hi Mike,
Quoted 24 lines · 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).

Quoted 8 lines

Quoted 1 line
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

Please consider the environment before printing this e-mail

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

Paul Eggleton

2014-11-26 14:58 UTC #3 lore raw

Quoted 44 lines · On Wednesday 26 November 2014 14:20:46 Mike Looijmans wrote:

Quoted 31 lines · Paul Eggleton
Hi Mike,
Quoted 23 lines · 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.
Quoted 4 lines
The machines have the same MACHINE_ARCH, they differ on only minor points (the FPGA).
What is going on here?
Quoted 8 lines
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"

Quoted 6 lines

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.

Quoted 4 lines

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

Signature · 2 lines

Paul Eggleton
Intel Open Source Technology Centre

Mike Looijmans

author

2014-11-26 18:53 UTC #4 lore raw

Quoted 55 lines · Paul Eggleton

Quoted 44 lines · On Wednesday 26 November 2014 14:20:46 Mike Looijmans wrote:
Quoted 31 lines · Paul Eggleton
Hi Mike,
Quoted 23 lines · 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.
Quoted 4 lines
The machines have the same MACHINE_ARCH, they differ on only minor points (the FPGA).
What is going on here?
Quoted 8 lines
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"
Quoted 6 lines
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.

Quoted 6 lines

Quoted 4 lines
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.

Signature · 1 line

Mike Looijmans

Mike Looijmans

author

2014-11-27 07:46 UTC #5 lore raw

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

Quoted 61 lines · Mike Looijmans

Quoted 60 lines · Paul Eggleton
Quoted 44 lines · On Wednesday 26 November 2014 14:20:46 Mike Looijmans wrote:
Quoted 31 lines · Paul Eggleton
Hi Mike,
Quoted 23 lines · 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.
Quoted 4 lines
The machines have the same MACHINE_ARCH, they differ on only minor points (the FPGA).
What is going on here?
Quoted 8 lines
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"
Quoted 6 lines
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.
Quoted 4 lines
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

Quoted 6 lines

Quoted 1 line
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: [email protected]
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/

Mike Looijmans

author

2014-11-27 08:20 UTC #6 lore raw

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

Quoted 72 lines · Mike Looijmans

Quoted 61 lines · Mike Looijmans
Quoted 60 lines · Paul Eggleton
Quoted 44 lines · On Wednesday 26 November 2014 14:20:46 Mike Looijmans wrote:
Quoted 31 lines · Paul Eggleton
Hi Mike,
Quoted 23 lines · 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.
Quoted 4 lines
The machines have the same MACHINE_ARCH, they differ on only minor points (the FPGA).
What is going on here?
Quoted 8 lines
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"
Quoted 6 lines
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.
Quoted 4 lines
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
Quoted 6 lines
Quoted 1 line
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.

Quoted 8 lines

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

Please consider the environment before printing this e-mail

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