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

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

[Jacob Kroon]

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 ?

Regards Jacob

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

[Bruce Ashfield]

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.

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.

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 ?

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.

Cheers,

Bruce

>
> 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

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

[Jacob Kroon]

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).

> 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.

> 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 have the following bbappended in my yocto kernel recipe:
KMACHINE:cm-itc ?= "common-pc"
COMPATIBLE_MACHINE:cm-itc = "cm-itc"

together with some custom kernel configuration.

Regards Jacob

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

[Bruce Ashfield]

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.

Cheers,

Bruce

> I have the following bbappended in my yocto kernel recipe:
> KMACHINE:cm-itc ?= "common-pc"
> COMPATIBLE_MACHINE:cm-itc = "cm-itc"
>
> together with some custom kernel configuration.
>
> 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

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

[Jacob Kroon]

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.

I can carry the kernel config option locally for now.

Regards
Jacob

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

[Bruce Ashfield]

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