On 10 Aug 2026, at 06:11, Alex Kiernan via lists.openembedded.org <[email protected]> wrote: > > Add a QEMU machine for exercising an AArch32-only ARMv8-A target > (Cortex-A32) under emulation, defaulting to the cortexa32-crypto tune. > QEMU has no Cortex-A32 model, so it runs on the 'virt' machine with > qemu-system-aarch64 using the Cortex-A32's AArch64-capable sibling, the > Cortex-A35, with 'aarch64=off' so the guest is AArch32-only. This > provides the ARMv8-A AArch32 feature set including the crypto extensions > needed by the crypto tune, and the same binary supports KVM on AArch64 > hosts whose CPUs implement AArch32 at EL1 via '-cpu host,aarch64=off'. > The kernel is built as a zImage and u-boot uses qemu_arm_defconfig, > matching the other 32-bit ARM QEMU machines.
Whilst this is an interesting machine, I’m not sure I see a lot of value in adding it to oe-core. You could easily maintain a tiny BSP layer to do this, for example. If we’re adding this to core then we either need to support it (which means someone needs to confirm that they’ll be maintaining it, we need to build it on the autobuilder which means more resources are used on every build, and build release artefacts for it), or explicitly say that it’s in the same tier as qemuppc etc where someone commits to maintaining the BSP but it’s not tested automatically and may well be broken. Personally, I feel that qemuppc/qemumips are in that second tier for historical reasons, and if they were being added to core now I'd say to put them in a separate layer. Ross
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#243290): https://lists.openembedded.org/g/openembedded-core/message/243290 Mute This Topic: https://lists.openembedded.org/mt/120680639/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
