On 16-08-15 09:39, Khem Raj wrote:
Kind regards,
Mike Looijmans
System Expert
TOPIC Embedded Products
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.looijm...@topicproducts.com
Website: www.topicproducts.com
Please consider the environment before printing this e-mail
On Jun 24, 2015, at 1:53 AM, John Ernberg <john.ernb...@actia.se> wrote:
Hi
This is a weird one that I have been researching for a while trying to
figure out how this can happen.
We recently had to extend our targets with another machine, they have
the same core CPU architecture, but we provide different configurations
of the kernel for them. Along with some IMAGE_INSTALL changes.
Since very little needs to be rebuilt, and the only thing needed to
change target machine is to edit the MACHINE variable, we chose to build
the images using the same build directory.
This means we set the MACHINE variable to machine_A. run bitbake
[machine_A_image], change the MACHINE variable to machine_B, and then
run bitbake [machine_B_image].
Here is when the weird happens. After machine_A has built, we can find
everything we expect to find in the machine_A image deploy directory.
When we change the MACHINE variable and build machine_B, we find that
the u-boot image from the machine_A directory has disappeared.
Depending on build machine it has moved into the machine_B directory, in
addition to u-boot image for machine_B being present in this directory,
OR it has just been removed.
Changing back to building machine_A, the u-boot(s) are removed from the
machine_B directory, and the machine_A u-boot will show up in the
machine_A directo
What could be at play here to cause such a strange behaviour? How can I
debug such a behaviour? I could not find anything on Google regarding
this, nor anything in the logs generated by bitbake.
u-boot is machine specific package so in theory, it should have rebuilt for
each of your target machines
and deploy images directory is also per machine so there should be no conflicts
at all, unless you modify
the u-boot recipes such that they are made to be SOC family specific or some
other voodoo, share your configurations
and recipes to get clear picture and may be something can come out.
This happens to any recipe that is built for multiple machines, e.g. the
kernel as well if it is shared between machines. Somewhere in the early tasks,
the recipe just blatantly removes the last build, and then starts running
anew, ignoring that the output of that build was not located in the current
machine's path. I think it will happen to anything that is deployed but is not
specific to one machine. It will even happen to a rootfs if you share that
between machines.
The only 'solution' I found for this problem is to copy the resulting binaries
to yet another location after building them. Then bitbake can't reach them.
The proper thing to do here would be to have ARCH specific deploy paths
instead of MACHINE specific. Some symlinks in the MACHINE path would take care
of backward compatibility.
I had a discussion about this problem on the oe-core list about a year ago
when I bumped into the same problem you describe here.
--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
