Yes that works for me much of the time, however I still often need to delete everything to start from scratch. I won't be in this mode of development forever, but for now it's been very painful. Thanks
On Mon, Jan 23, 2023 at 8:28 AM Philip Balister <[email protected]> wrote: > Removing the tmp directory and keeping the shared state directory might > help recover from build issues without requiring a complete rebuild of > qemu and other packages. > > Philip > > On 1/23/23 10:54, David Babich wrote: > > I had a similar reply from Ulf. Here is my response: > > > > "Yes, I'm in a heavy development flow where I am designing the build > > system to support 4 images and 3 machines (2 dev-kits and custom > > hardware). There are a lot of common features shared between all of the > > configurations, but there are also numerous differences. As I'm > > developing it often the state of my build system gets messed up to the > > point where I need to completely clean and build from scratch. I also > > often have to build from scratch to test that changes I made work from > > start to finish on the various configurations. The qemu components > > extend the build time significantly, and I have no need for them. So it > > would help me greatly in meeting the design schedule if I can remove > > them from the build." > > > > So I basically don't want qemu /now/ because it is severely slowing down > > my development cycles. We should have replied to the whole list, Ulf > > has provided me the following information which I will try today: > > > > "Here is a discussion on how to do this in Gentoo: > > > > https://wiki.gentoo.org/wiki/Yocto <https://wiki.gentoo.org/wiki/Yocto> > > > > They use the native qemu installation provied by Gentoo, so they don't > > even use the Yocto build. > > > > They simply add > > > > ASSUME_PROVIDED += "qemu-native libsdl-native" > > > > to local.conf and are done. > > > > According to this Wiki, qemu-native is used when generating the rootfs, > > so *removing* qemu-native is not possible. > > > > ========================= > > On my Ubuntu-18.04 system, I have /usr/bin/qemu-* files, so it might be > > possible in my system as well. > > > > ========================= > > > > If You want to use the Yocto builts stuff: > > > > After you bitbaked qemu-native you will have a > > > > TOPDIR/build/tmp/work/x86_64-linux/qemu-native/6.2.0-r0/image/ directory. > > > > Step down in this until you reach recipe-sysroot-native/ > > > > In this directory, you find what Yocto will run. > > > > . > > └── usr > > ├── bin > > │ ├── qemu-aarch64 > > │ ├── qemu-arm > > │ ├── qemu-i386 > > │ ├── qemu-mips > > │ ├── qemu-mips64 > > │ ├── qemu-mips64el > > │ ├── qemu-mipsel > > │ ├── qemu-mips.real > > │ ├── qemu-ppc > > │ ├── qemu-ppc64 > > │ ├── qemu-ppc64le > > │ ├── qemu-riscv32 > > │ ├── qemu-riscv64 > > │ ├── qemu-sh4 > > │ └── qemu-x86_64 > > ├── include > > │ └── qemu-plugin.h > > └── share > > └── qemu > > ├── keymaps > > │ ├── ar > > │ ├── bepo > > │ ├── cz > > │ ├── da > > │ ├── de > > │ ├── de-ch > > │ ├── en-gb > > │ ├── en-us > > │ ├── es > > │ ├── et > > │ ├── fi > > │ ├── fo > > │ ├── fr > > │ ├── fr-be > > │ ├── fr-ca > > │ ├── fr-ch > > │ ├── hr > > │ ├── hu > > │ ├── is > > │ ├── it > > │ ├── ja > > │ ├── lt > > │ ├── lv > > │ ├── mk > > │ ├── nl > > │ ├── no > > │ ├── pl > > │ ├── pt > > │ ├── pt-br > > │ ├── ru > > │ ├── sl > > │ ├── sv > > │ ├── th > > │ └── tr > > └── trace-events-all > > > > One way would be to copy it all to your host. > > Be careful, since if I check my own Ubuntu 18.04 I have: > > > > ls -1 /usr/bin/qemu* > > /usr/bin/qemu-aarch64-static > > /usr/bin/qemu-alpha-static > > /usr/bin/qemu-armeb-static > > /usr/bin/qemu-arm-static > > /usr/bin/qemu-cris-static > > /usr/bin/qemu-hppa-static > > /usr/bin/qemu-i386-static > > /usr/bin/qemu-img > > /usr/bin/qemu-io > > /usr/bin/qemu-m68k-static > > /usr/bin/qemu-microblazeel-static > > /usr/bin/qemu-microblaze-static > > /usr/bin/qemu-mips64el-static > > /usr/bin/qemu-mips64-static > > /usr/bin/qemu-mipsel-static > > /usr/bin/qemu-mipsn32el-static > > /usr/bin/qemu-mipsn32-static > > /usr/bin/qemu-mips-static > > /usr/bin/qemu-nbd > > /usr/bin/qemu-nios2-static > > /usr/bin/qemu-or1k-static > > /usr/bin/qemu-ppc64abi32-static > > /usr/bin/qemu-ppc64le-static > > /usr/bin/qemu-ppc64-static > > /usr/bin/qemu-ppc-static > > /usr/bin/qemu-s390x-static > > /usr/bin/qemu-sh4eb-static > > /usr/bin/qemu-sh4-static > > /usr/bin/qemu-sparc32plus-static > > /usr/bin/qemu-sparc64-static > > /usr/bin/qemu-sparc-static > > /usr/bin/qemu-system-i386 > > /usr/bin/qemu-system-x86_64 > > /usr/bin/qemu-system-x86_64-spice > > /usr/bin/qemu-tilegx-static > > /usr/bin/qemu-x86_64-static > > > > I do not have a name collision, but that is not necessary the case for > > all systems. > > You might overwrite something. > > > > You might also consider manually symlinking the QEMU applications if a > > simple ASSUME_PROVIDED does not work. > > > > I.E: > > > > cd /usr/bin ; sudo ln -sf qemu-aarch64-static qemu-aarch64 > > > > > > I have not tested this, but it seems worth a try. > > > > > > Best Regards > > > > Ulf Samuelsson" > > > > I'll post status on my success or failure. Thanks > > -David > > > > On Sun, Jan 22, 2023 at 10:08 AM Mark Hatle > > <[email protected] <mailto:[email protected]>> > > > wrote: > > > > What are you trying to accomplish, why are you trying to get rid of > > qemu and > > which version of the Yocto Project are you using? > > > > You need some qemu support for parts of the system to function > > properly. They > > expect on arm/aarch64 hardware to be able to run test scripts and/or > > post-install scripts as the target architecture during the root > > filesystem > > generation. > > > > The dependencies for qemu based items are ingrained into the base > > system > > configuration. > > > > For instance, if the filesystem type of 'qemu-sd' is enabled (and it > > is in most > > configurations), then a dependency on qemu-xilinx-system-native will > > be introduced. > > > > On 1/19/23 2:56 PM, David Babich wrote: > > > I've been trying in vain to remove all qemu support from my > > custom build. I've > > > add the following to my distro.conf file: > > > > > > PNBLACKLIST[qemu]="blacklist" > > > PNBLACKLIST[qemu-native]="blacklist" > > > PNBLACKLIST[qemu-helper-native]="blacklist" > > > PNBLACKLIST[qemu-helper-native-dev]="blacklist" > > > PNBLACKLIST[qemu-system-native]="blacklist" > > > #PNBLACKLIST[qemu-xilinx]="blacklist" > > > #PNBLACKLIST[qemu-xilinx-native]="blacklist" > > > #PNBLACKLIST[qemu-xilinx-system-native]="blacklist" > > > PNBLACKLIST[nativesdk-qemu]="blacklist" > > > PNBLACKLIST[nativesdk-qemu-helper]="blacklist" > > > PNBLACKLIST[nativesdk-packagegroup-sdk-host]="blacklist" > > > MACHINE_FEATURES_BACKFILL_CONSIDERED = " \ > > > qemu-usermode \ > > > " > > > > > > However when I uncomment the qemu-xilinx, qemu-xilinx-native and > > > qemu-xilinx-system-native I get errors indicating unbuildable > > dependencies for > > > those missing packages. I've also tried adding them to > > PACKAGE_EXCLUDE, > > > IMAGE_FEATURES:remove, DISTRO_FEATURES:remove, and > > IMAGE_INSTALL:remove with no > > > luck. There must be some way to completely disable this without > > forking the > > > meta-xilinx layers and manually removing them. > > > > If I could understand your use-case and reason to disable them, I > > might be able > > to suggest something. But generally, no you can't just completely > > disable qemu > > without significantly changing aspects of the system as a whole. > > > > At a minimum you will want to remove (and resolve dangling > > references to): > > > > meta-xilinx-core/conf/machine/include/machine-xilinx-qemu.inc > > meta-xilinx-core/classes/image-types-xilinx-qemu.bbclass > > > > PNBLACKLIST or SKIP_RECIPE > > > > If you are simply trying to ensure that qemu never goes to the > > target image, > > then you only need to skip qemu/qemu-xilinx. > > > > The qemu-*native and nativesdk-qemu* packages are helpers during > > compilation > > time and do not get deployed into the target image. > > > > --Mark > > > > > Thanks in advance for any help. > > > -David > > > > > > > > > > > > > > > > > > > > > > > -- > > *David Babich* > > Principal Embedded Software Engineer/Founder > > Bootseeds Engineering LLC. > > 303-913-4863 > > [email protected] <mailto:[email protected]> > > www.bootseeds.com <http://www.bootseeds.com> > > > > > > > > > -- *David Babich* Principal Embedded Software Engineer/Founder Bootseeds Engineering LLC. 303-913-4863 [email protected] www.bootseeds.com
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#5134): https://lists.yoctoproject.org/g/meta-xilinx/message/5134 Mute This Topic: https://lists.yoctoproject.org/mt/96386630/21656 Group Owner: [email protected] Unsubscribe: https://lists.yoctoproject.org/g/meta-xilinx/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
