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.looijm...@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/
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
