[yocto] The best way to change target architecture

Zhuoqun Cheng czq at bu.edu
Tue Jun 6 16:16:04 PDT 2017


Sorry for the previous message. Accidentally sent it out.

Thanks, Andre! That explains a lot.
I got rid of the entire tmp directory and then rebuilt. And unfortunately
I'm still running into the same problem...
I entered the directory shown in the error and did a 'file' on the
binaries. They are all x86-64 binary. Now I wonder why in the
core2-32-intel-commom-poke-linux folder exists 64 bit binaries?
What configuration could I have messed up?

Thanks,
Tom.


On Tue, Jun 6, 2017 at 7:09 PM, Zhuoqun Cheng <czq at bu.edu> wrote:

> Thanks, Andre! That explains a lot.
> I got rid of the entire tmp directory and then rebuilt. And unfortunately
> I'm still running into the same problem...
> Looking at the error again (see below)
>
>
> On Tue, Jun 6, 2017 at 1:30 PM, Andre McCurdy <armccurdy at gmail.com> wrote:
>
>> On Tue, Jun 6, 2017 at 5:42 AM, Zhuoqun Cheng <czq at bu.edu> wrote:
>> > Hi Yocto Experts,
>> >
>> > I'm fairly new to Yocto and I've already tried my best to search for
>> > answers, but not happy with what I found.
>> >
>> > So here's the situation I've got:
>> >
>> > I'm using yocto to build the intel aero board image, following this
>> link:
>> > https://github.com/intel-aero/meta-intel-aero/wiki/Quickstar
>> t-Guide#yocto-for-intel-aero
>> >
>> > Everything worked fine, until I wanted to change the target architecture
>> > from the default 64-bit x86 to 32-bit x86. What I did is three steps:
>> > 1. do a clean: bitbake -c clean intel-aero-image
>>
>> Note that running the clean task for the final image doesn't have any
>> affect on the packages which go into that image, so this step doesn't
>> actually do very much.
>>
>> > 2. change configuration, from "require conf/machine/intel-corei7-64.conf"
>> to
>> > "require conf/machine/intel-core2-32.conf" in the file
>> > "meta-intel-aero/conf/machine/intel-aero.conf"
>>
>> Here you are changing the target architecture but keeping the machine
>> name the same. In theory it should work, but it probably isn't well
>> tested...
>>
>> > 3. do a build: bitbake intel-aero-image
>> >
>> > Unfortunately, I got loads of errors, like "ERROR:
>> > linux-yocto-4.4.60+gitAUTOINC+2cc78e92f4-r0 do_package_qa: QA Issue:
>> > Architecture did not match (3 to 62) on
>> > work/core2-32-intel-common-poky-linux/linux-yocto/4.4.60+git
>> AUTOINC+2cc78e92f4-r0/packages-split/kernel-module-gspca-
>> kinect/lib/modules/4.4.60-yocto-standard/kernel/drivers/
>> media/usb/gspca/gspca_kinect.ko
>> > [arch]
>> > "
>> >
>> > Then I tried deleting all the files in the packages-split directory and
>> > rebuilding.
>>
>> Manually deleting anything within a recipe's working directory isn't
>> really recommended. Better to run the clean (or cleansstate) task for
>> that recipe instead, e.g. in this case:
>>
>>   bitbake -c cleansstate linux-yocto
>>
>> > It passed building the kernel (even though failed because some
>> > other package's arch mismatch), but those file I deleted never got
>> generated
>> > again! Now I'm a bit worried.
>>
>> It's quite normal that build artefacts will not be generated again if
>> a recipe has been successfully built once before, since build results
>> are stored in sstate cache. To force a particular recipe to be
>> rebuilt, you can use:
>>
>>   bitbake -c cleansstate <recipe>
>>   bitbake <recipe>
>>
>> > So I guess my question is:
>> > What is the correct procedures to follow to reuse a poky folder (already
>> > built once) for a different target architecture? I'm happy to accept any
>> > links and suggested readings.
>>
>> The normal way to recover from the kind of problems you are seeing
>> would be to remove the entire tmp directory (and if that still doesn't
>> work, then manually run the cleansstate task for any individual
>> recipes which still fail to build).
>>
>> > Thanks a lot!
>> > Tom.
>> >
>> >
>> > --
>> > _______________________________________________
>> > yocto mailing list
>> > yocto at yoctoproject.org
>> > https://lists.yoctoproject.org/listinfo/yocto
>> >
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20170606/3eb7263e/attachment.html>


More information about the yocto mailing list