On 10/19/21 04:40, Bruce Ashfield wrote:
On Mon, Oct 18, 2021 at 2:39 AM Jacob Kroon <jacob.kr...@gmail.com> wrote:
On 10/17/21 15:32, Bruce Ashfield wrote:
On Sun, Oct 17, 2021 at 4:26 AM Jacob Kroon <jacob.kr...@gmail.com> wrote:
Hi Bruce and Saul,
On 10/16/21 09:18, Jacob Kroon via lists.openembedded.org wrote:
Hi Bruce,
My Yocto images (which uses the linux-yocto kernel) stopped booting in
QEMU some time ago, and after some debugging it turns out this was
because the upstream Linux kernel removed the legacy IDE driver. Instead
one should use the libata driver. However, I don't think the linux-yocto
kernel has builtin support for the HW that is emulated by QEMU by
default (PIIX), instead it is built as a module, CONFIG_ATA_PIIX=m. If I
set CONFIG_ATA_PIIX=y, my images boot again.
I did a "make ARCH=i386 defconfig" in Torvalds master linux tree, and
the .config has CONFIG_ATA_PIIX=y.
Do you think it would make sense to have the support builtin in
linux-yocto aswell ?
I'm using KMACHINE = "common-pc". CC:ing Saul Wold, since I see that
commit 0d4f5ed5dca41a48423ce738131e52f7863d8ca6 in yocto-kernel-cache did:
diff --git a/bsp/common-pc/common-pc-drivers.cfg
b/bsp/common-pc/common-pc-drivers.cfg
index 71608433..0b821903 100644
--- a/bsp/common-pc/common-pc-drivers.cfg
+++ b/bsp/common-pc/common-pc-drivers.cfg
@@ -5,7 +5,8 @@ CONFIG_PCI_MSI=y
CONFIG_ATA=y
CONFIG_ATA_ACPI=y
CONFIG_ATA_SFF=y
-CONFIG_ATA_PIIX=y
+CONFIG_ATA_BMDMA=y
+CONFIG_ATA_PIIX=m
CONFIG_INPUT=y
CONFIG_INPUT_MOUSEDEV=y
which changed ATA_PIIX from a builtin to a module. Maybe this wasn't
intentional ?
It was definitely intentional.
> We try and keep the configuration space of the targets as small as
possible. In particular, this is exactly why qemux86* was created, so
we wouldn't have to enable options in either the h/w targets or the
emulated targets that are specific to a use case on one (and vice
versa). That being said, they still actually do share the same machine
definitions in the kernel-cache, since nothing significant has forced
me to use that namespace split.
qemux86 doesn't need PIIX out of the box to boot, and the Kconfig
indicates "set it to N unless ...", and we do know the built-ins we
want, so it is set to 'm' as a middle ground.
When I start qemu-system-x86_64/qemu-system-i386 and type "info qtree"
in the QEMU monitor (both version 5.2.0 and 6.1.0) I see "piix3-ide" for
the IDE controller. Given that for older Yocto kernels the legacy IDE
driver was builtin (CONFIG_BLK_DEV_PIIX=y), but is now removed in the
kernel present on master, I'd figure ATA_PIIX=y would be required
nowadays in order to get the kernels to boot in QEMU (since libata is
replacing the old legacy IDE driver nowadays).
It all depends on how the boot media is wired into the qemu run.
The runqemu boots are using vda and virtio-blk to start up, with
an explicit kernel and image passed to qemu.
ATA_PIIX is loaded as a module after that, and is active (but not
used) .. and of course it is loaded since the piix is detected and
triggers the load.
Obviously we've been booting qemux86* all throughout the
development cycle :D Even after I cleaned up all the old
obsolete IDE options.
That being said, it isn't out of the question to enable it (slippery
slope to giant defconfig like beasts with everything and the kitchen
sink enabled notwithstanding .. not that this is much of a step down
that slope!) .. just let me ask a few more things first.
Yeah, the only reason I'm asking is because I think I'm using default
QEMU emulated hardware, and I'm sure we want a Yocto kernel to boot in
default QEMU hardware.
It's less about the h/w and more about what we want to enable
as boot media, and the boot process. If we were going through
an initramfs, etc, we could load the modules from rootfs and
have everything available as potential boot options.
You say you are using KMACHINE='common-pc', that's good. But what else
is at play ? What OE MACHINE are you building ? What image FStypes,
etc ?
It is a custom machine for
https://www.compulab.com/products/computer-on-modules/cm-itc/
machine/cm-itc.conf:
---
IMAGE_FSTYPES ?= "ext4"
require conf/machine/include/x86/tune-i686.inc
require conf/machine/include/x86/x86-base.inc
PREFERRED_PROVIDER_virtual/bootloader = "grub-efi"
---
I won't be able to do some build testing until Monday, but do you
happen to have the qemu command lines (via runqemu) and machine
definitions for qemux88 and your machine? I'd like to look at them
and confirm exactly what image, and boot parameters are in play, since
one boots and the other doesn't.
I don't use the "runqemu"-script, I boot the images using Fedora 34 QEMU
installation (QEMU version 5.2.0). Commandline is:
qemu-system-x86_64 -m 1G -enable-kvm -nic user,hostfwd=tcp::10022-:22 -cpu n270 -bios
/usr/share/edk2/ovmf-ia32/OVMF_CODE.fd -drive format=raw,file=<path-to-image>
I obviously wasn't able to boot exactly like this, but it tells me enough
about what you are doing.
As I was saying before, enabling PIIX isn't much added size, doesn't
take us far down the slope of enabling too much 'just in case' .. and is
roughly equivalent to the old IDE PIIX.
I can turn it on for common-pc* in master, and it could be proposed
for backport to the impending release in a dot release.
Thanks Bruce. I'd say if more people request it then maybe its worth
enabling it, but if I am the only one then maybe not.
I can carry the kernel config option locally for now.
Regards
Jacob
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#157105):
https://lists.openembedded.org/g/openembedded-core/message/157105
Mute This Topic: https://lists.openembedded.org/mt/86367293/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
