Re: Deploying 2 machines, u-boot does not include with both.

[Mike Looijmans <mike.looijmans@topic.nl>]

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.