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
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]>
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]
www.bootseeds.com
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5132):
https://lists.yoctoproject.org/g/meta-xilinx/message/5132
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]]
-=-=-=-=-=-=-=-=-=-=-=-
