All of lore.kernel.org
 help / color / mirror / Atom feed
* Deploying 2 machines, u-boot does not include with both.
@ 2015-06-24  8:53 John Ernberg
  2015-08-16  7:39 ` Khem Raj
  0 siblings, 1 reply; 3+ messages in thread
From: John Ernberg @ 2015-06-24  8:53 UTC (permalink / raw)
  To: yocto@yoctoproject.org

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 directory.

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.

We're using the Daisy branch of Yocto.

Thank you in advance.

Best regards // John Ernberg

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Deploying 2 machines, u-boot does not include with both.
  2015-06-24  8:53 Deploying 2 machines, u-boot does not include with both John Ernberg
@ 2015-08-16  7:39 ` Khem Raj
  2015-08-17  6:44   ` Mike Looijmans
  0 siblings, 1 reply; 3+ messages in thread
From: Khem Raj @ 2015-08-16  7:39 UTC (permalink / raw)
  To: John Ernberg; +Cc: yocto@yoctoproject.org

[-- Attachment #1: Type: text/plain, Size: 2311 bytes --]


> On Jun 24, 2015, at 1:53 AM, John Ernberg <john.ernberg@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 directory.
> 
> 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.

> We're using the Daisy branch of Yocto.
> 
> Thank you in advance.
> 
> Best regards // John Ernberg
> --
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 211 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Deploying 2 machines, u-boot does not include with both.
  2015-08-16  7:39 ` Khem Raj
@ 2015-08-17  6:44   ` Mike Looijmans
  0 siblings, 0 replies; 3+ messages in thread
From: Mike Looijmans @ 2015-08-17  6:44 UTC (permalink / raw)
  To: Khem Raj, John Ernberg; +Cc: yocto@yoctoproject.org

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.looijmans@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.ernberg@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.


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2015-08-17  7:10 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-06-24  8:53 Deploying 2 machines, u-boot does not include with both John Ernberg
2015-08-16  7:39 ` Khem Raj
2015-08-17  6:44   ` Mike Looijmans

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.