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