Re: [OE-core] linux-yocto: Set CONFIG_ATA_PIIX=y by default

[Bruce Ashfield <bruce.ashfield@gmail.com>]

On Tue, Oct 19, 2021 at 1:31 AM Jacob Kroon <jacob.kroon@gmail.com> wrote:
>
> On 10/19/21 04:40, Bruce Ashfield wrote:
> > On Mon, Oct 18, 2021 at 2:39 AM Jacob Kroon <jacob.kroon@gmail.com> wrote:
> >>
> >> On 10/17/21 15:32, Bruce Ashfield wrote:
> >>> On Sun, Oct 17, 2021 at 4:26 AM Jacob Kroon <jacob.kroon@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.

Don't let my long winded description make it appear that I'm reluctant,
I was sold when I realized (and you pointed out) the old IDE config had
PIIX enabled and that we were autoloading the PIIX module on boot
due to hardware detection.

I just wanted to make sure I documented the process :D

I'm just doing some tests with the tweaked config today and it will
be in my next pull request.

Bruce

>
> I can carry the kernel config option locally for now.
>
> Regards
> Jacob



-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II