* Re: [OE-core] linux-yocto: Set CONFIG_ATA_PIIX=y by default [not found] <16AE71B3ADB3BD09.11150@lists.openembedded.org> @ 2021-10-17 8:26 ` Jacob Kroon 2021-10-17 13:32 ` Bruce Ashfield 0 siblings, 1 reply; 6+ messages in thread From: Jacob Kroon @ 2021-10-17 8:26 UTC (permalink / raw) To: openembedded-core, bruce.ashfield; +Cc: Saul.Wold 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [OE-core] linux-yocto: Set CONFIG_ATA_PIIX=y by default 2021-10-17 8:26 ` [OE-core] linux-yocto: Set CONFIG_ATA_PIIX=y by default Jacob Kroon @ 2021-10-17 13:32 ` Bruce Ashfield 2021-10-18 6:39 ` Jacob Kroon 0 siblings, 1 reply; 6+ messages in thread From: Bruce Ashfield @ 2021-10-17 13:32 UTC (permalink / raw) To: Jacob Kroon; +Cc: Patches and discussions about the oe-core layer, Saul Wold 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [OE-core] linux-yocto: Set CONFIG_ATA_PIIX=y by default 2021-10-17 13:32 ` Bruce Ashfield @ 2021-10-18 6:39 ` Jacob Kroon 2021-10-19 2:40 ` Bruce Ashfield 0 siblings, 1 reply; 6+ messages in thread From: Jacob Kroon @ 2021-10-18 6:39 UTC (permalink / raw) To: Bruce Ashfield; +Cc: Patches and discussions about the oe-core layer, Saul Wold 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [OE-core] linux-yocto: Set CONFIG_ATA_PIIX=y by default 2021-10-18 6:39 ` Jacob Kroon @ 2021-10-19 2:40 ` Bruce Ashfield 2021-10-19 5:31 ` Jacob Kroon 0 siblings, 1 reply; 6+ messages in thread From: Bruce Ashfield @ 2021-10-19 2:40 UTC (permalink / raw) To: Jacob Kroon; +Cc: Patches and discussions about the oe-core layer, Saul Wold 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [OE-core] linux-yocto: Set CONFIG_ATA_PIIX=y by default 2021-10-19 2:40 ` Bruce Ashfield @ 2021-10-19 5:31 ` Jacob Kroon 2021-10-19 13:01 ` Bruce Ashfield 0 siblings, 1 reply; 6+ messages in thread From: Jacob Kroon @ 2021-10-19 5:31 UTC (permalink / raw) To: Bruce Ashfield; +Cc: Patches and discussions about the oe-core layer, Saul Wold 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [OE-core] linux-yocto: Set CONFIG_ATA_PIIX=y by default 2021-10-19 5:31 ` Jacob Kroon @ 2021-10-19 13:01 ` Bruce Ashfield 0 siblings, 0 replies; 6+ messages in thread From: Bruce Ashfield @ 2021-10-19 13:01 UTC (permalink / raw) To: Jacob Kroon; +Cc: Patches and discussions about the oe-core layer, Saul Wold 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2021-10-19 13:01 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <16AE71B3ADB3BD09.11150@lists.openembedded.org> 2021-10-17 8:26 ` [OE-core] linux-yocto: Set CONFIG_ATA_PIIX=y by default Jacob Kroon 2021-10-17 13:32 ` Bruce Ashfield 2021-10-18 6:39 ` Jacob Kroon 2021-10-19 2:40 ` Bruce Ashfield 2021-10-19 5:31 ` Jacob Kroon 2021-10-19 13:01 ` Bruce Ashfield
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).