From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by yocto-www.yoctoproject.org (Postfix, from userid 118) id 173A4E00AA5; Mon, 17 Aug 2015 00:10:14 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on yocto-www.yoctoproject.org X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-HAM-Report: * -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low * trust * [207.244.64.178 listed in list.dnswl.org] * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] X-Greylist: delayed 1550 seconds by postgrey-1.32 at yocto-www; Mon, 17 Aug 2015 00:10:08 PDT Received: from mx18-09.smtp.antispamcloud.com (mx18-09.smtp.antispamcloud.com [207.244.64.178]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id D4F22E0049B for ; Mon, 17 Aug 2015 00:10:08 -0700 (PDT) Received: from 100-208.ftth.onsbrabantnet.nl ([88.159.208.100] helo=TOP-EX01.TOPIC.LOCAL) by mx18.antispamcloud.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1ZRE9T-0008Fd-5p; Mon, 17 Aug 2015 08:44:16 +0200 Received: from [192.168.80.121] (192.168.80.121) by TOP-EX01.TOPIC.LOCAL (192.168.10.102) with Microsoft SMTP Server (TLS) id 14.3.224.2; Mon, 17 Aug 2015 08:43:48 +0200 Message-ID: <55D182B7.70700@topic.nl> Date: Mon, 17 Aug 2015 08:44:07 +0200 From: Mike Looijmans Organization: TOPIC User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Khem Raj , John Ernberg References: <558A7025.4050204@actia.se> <7F6CA5E4-057A-4CFB-B4AE-F2F65A565A8D@gmail.com> In-Reply-To: <7F6CA5E4-057A-4CFB-B4AE-F2F65A565A8D@gmail.com> X-Originating-IP: [192.168.80.121] X-EXCLAIMER-MD-CONFIG: 9833cda7-5b21-4d34-9a38-8d025ddc3664 X-EXCLAIMER-MD-BIFURCATION-INSTANCE: 0 X-Filter-ID: s0sct1PQhAABKnZB5plbIbbvfIHzQjPVmPLZeVYSu3xU9luQrU+8/8qthi+0Jd/W6KAUC/fjyuDn NXFr4uarw5xo+yL19ZkIV8F4VBe+tCaqeJUWd0HiubIWOWFjsT3aGDBAA/VTvIOOruDaHoLc8KYS r8HQeMcIMwrPxHk/Al502KbWfB+BvCLafvmmGbn9ThlEsBHk2TqnCEKzpzm/4k1g6JXNZVNZeg5u WtPHJmVaGoaND5S726kVzoIqecXYIo/RvWy4QD6AJSBYDhDIcGbjO41FyBEqIaDudcVplPGgpBI7 ydfmqQwWwdxJC2llIUWkibSg5kNEOneR6RZIg7ukmbhMZr3VFCw5zU0AFjmZ3JKVmi72ocgY5kMQ Sjs7F6PVe4aIcKJEhpPEio8CMZ5oGE2fQ8DC1V7fTjbCA7RK+ZAhhDpFFRBhUuQpQT520z6bhalF EM/pjPCQA+BAll3cqDXLdhIDcTVzECz4l757Zn6OGQcTLcl+10S2CCSFkWJrEe2kO65blt0BWklG DU3T4d9+cTmuxgLJNmuvoGpWBb39uS1TjWG2Inx+Ts2QsKcQXpHx67p5GxisINkPSb7u7J1see3H NyqvEpSPubS9nfjUoepopnPYXbopdVfOUI/fDof9VJyYmVuBI9C3sjjOFyN858K9xWks50oxYVFW gWWsfzmdEBxk/w4+z2XWBFN2Wfesu1/OIRyQoEZNQCXKmgDWyx2rMXlyWF7Fy7muqTdUuVA6eVHt WdVqT7UQoebWqwifARrm2hkmCGZ1aQ== X-Report-Abuse-To: spam@mx99.antispamcloud.com X-Filter-Fingerprint: IFrWXGses7OKB5S5G8/dJUb3OPwsHaH0Fvg5oXltHd/JUWjZ8+qhjyB23tbDuyLOYL8Ff78gYsez 4Rl08xudmXi4esCQ0R1MchVjt7wblGlvhFgW0MjUMRkF5sMCDfftTXNFDzN17hnrWeZYOJvLq0Ic WjZ+XcEjj/7Pkld0zkmvziDInX9WdMov2kn2yXjdwv61T+KDYyYtREgszdyFwv8IxCB3p/oCKvxr eyISh3JGb7OS5oVgiO+kDxZrVPLz3MmEGC2PrUKqLq5WmHK+Nw== X-Originating-IP: 88.159.208.100 X-Spampanel-Domain: topic.nl X-Spampanel-Username: 88.159.208.100 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=88.159.208.100@topic.nl X-Spampanel-Outgoing-Class: ham X-Spampanel-Outgoing-Evidence: Combined (0.07) X-Recommended-Action: accept Cc: "yocto@yoctoproject.org" Subject: Re: Deploying 2 machines, u-boot does not include with both. X-BeenThere: yocto@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Discussion of all things Yocto Project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2015 07:10:14 -0000 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: quoted-printable =EF=BB=BFOn 16-08-15 09:39, Khem Raj wrote: > >>=20 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 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 f= or each of your target machines > and deploy images directory is also per machine so there should be no con= flicts at all, unless you modify > the u-boot recipes such that they are made to be SOC family specific or s= ome 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=20 kernel as well if it is shared between machines. Somewhere in the early tas= ks,=20 the recipe just blatantly removes the last build, and then starts running=20 anew, ignoring that the output of that build was not located in the current= =20 machine's path. I think it will happen to anything that is deployed but is = not=20 specific to one machine. It will even happen to a rootfs if you share that= =20 between machines. The only 'solution' I found for this problem is to copy the resulting binar= ies=20 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=20 instead of MACHINE specific. Some symlinks in the MACHINE path would take c= are=20 of backward compatibility. I had a discussion about this problem on the oe-core list about a year ago= =20 when I bumped into the same problem you describe here.