All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Looijmans <mike.looijmans@topic.nl>
To: Paul Eggleton <paul.eggleton@linux.intel.com>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: Why does building an image for machine X delete the bootloader for machine Y?
Date: Wed, 26 Nov 2014 14:20:46 +0100	[thread overview]
Message-ID: <5475D3AE.1040803@topic.nl> (raw)
In-Reply-To: <12654718.RPpo1aQ4TE@peggleto-mobl5.ger.corp.intel.com>

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/



  reply	other threads:[~2014-11-26 13:20 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-26  8:19 Why does building an image for machine X delete the bootloader for machine Y? Mike Looijmans
2014-11-26 11:31 ` Paul Eggleton
2014-11-26 13:20   ` Mike Looijmans [this message]
2014-11-26 14:57     ` Paul Eggleton
2014-11-26 18:44       ` Mike Looijmans
2014-11-27  7:46         ` Why does building an image for machine X delete the bootloader (and kernel) " Mike Looijmans
2014-11-27  8:20           ` Mike Looijmans
2014-11-26 12:14 ` Why does building an image for machine X delete the bootloader " Gary Thomas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5475D3AE.1040803@topic.nl \
    --to=mike.looijmans@topic.nl \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=paul.eggleton@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.