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