hw/ide/via.c | 21 +++++---------------- hw/mips/mips_fulong2e.c | 5 ++++- hw/pci/pci.c | 5 ++++- include/hw/ide.h | 1 - 4 files changed, 13 insertions(+), 19 deletions(-)
Following on from the earlier thread "Implement "non 100% native mode"
in via-ide", here is an updated patchset based upon the test cases
sent to me off-list.
The VIA IDE controller is similar to early versions of the PIIX
controller in that the primary and secondary IDE channels are hardwired
to IRQs 14 and 15 respectively. Guest OSs typically handle this by
either switching the controller to legacy mode, or using native mode and
using a combination of PCI device/vendor ID and/or checking various
registers in PCI configuration space to detect this condition and apply
a special fixed IRQ 14/15 routing.
This patchset effectively updates the VIA IDE PCI device to follow the
behaviour in the datasheet in two ways: fixing some PCI configuration
space register defaults and behaviours, and always using legacy IRQ 14/15
routing, and once applied allows all our known test images to boot
correctly.
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
BALATON Zoltan (2):
ide/via: Get rid of via_ide_init()
pci: Honour wmask when resetting PCI_INTERRUPT_LINE
Mark Cave-Ayland (5):
via-ide: move registration of VMStateDescription to DeviceClass
via-ide: ensure that PCI_INTERRUPT_LINE is hard-wired to its default
value
via-ide: initialise IDE controller in legacy mode
via-ide: allow guests to write to PCI_CLASS_PROG
via-ide: always use legacy IRQ 14/15 routing
hw/ide/via.c | 21 +++++----------------
hw/mips/mips_fulong2e.c | 5 ++++-
hw/pci/pci.c | 5 ++++-
include/hw/ide.h | 1 -
4 files changed, 13 insertions(+), 19 deletions(-)
--
2.20.1
> From: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> > This patchset effectively updates the VIA IDE PCI device to follow the > behaviour in the datasheet in two ways: fixing some PCI configuration > space register defaults and behaviours, and always using legacy IRQ 14/15 > routing, and once applied allows all our known test images to boot > correctly. > Hi, Mark, could you just enumerate those test images, download locations, etc. and whatever else is needed to reproduce the boot processes in question - it would be useful not only for this patch set, but for possible future work, wouldn't it? Sorry in advance if that info in possibly in another message, and was missed by me. Many thanks, Aleksandar
Hello, On Fri, 13 Mar 2020, Aleksandar Markovic wrote: > Hi, Mark, could you just enumerate those test images, download > locations, etc. and whatever else is needed to reproduce the boot > processes in question - it would be useful not only for this patch > set, but for possible future work, wouldn't it? > > Sorry in advance if that info in possibly in another message, and > was missed by me. I've sent it to Mark off-list but here it is: On Tue, 10 Mar 2020, BALATON Zoltan wrote: > I was testing fulong2e with this kernel: > > http://distfiles.gentoo.org/experimental/mips/livecd/loongson-2007.1/ > > running it as > > qemu-system-mips64el -M fulong2e -serial stdio -net none -vga none \ > -trace enable="pci*" -kernel gentoo-loongson-2.6.22.6-20070902 \ > -cdrom debian-8.11.0-mipsel-netinst.iso > > adding the cdrom proabably does not really matter and I could not find > corresponding gentoo iso so using a debian one, it's just useful to have > something on the ide bus and also -cdrom adds it to second channel > because if you test with something on first channel only it might work > as that uses IRQ14 anyway. > > On pegasos2 I've used: > > qemu-system-ppc -M pegasos2 -net none -serial stdio \ > -vga none -device ati-vga,romfile=VGABIOS-lgpl-latest.bin \ > -cdrom morphos-3.13.iso > > then enter "boot cd boot.img" at the firmware ok prompt. > > And also the same pegasos2 command with > > -cdrom debian-8.11.0-powerpc-netinst.iso > > and enter "boot cd install/pegasos" then I usually select 3 for rescue > mode which can get to a command prompt. For more info on VGABIOS-lgpl-latest.bin and pegrom.bin needed for pegasos2 see Pegasos2 emulation subproject on my http://qmiga.osdn.io/ page. The fulong2e probably still has some problem correctly emulating pci devices becuase without -net none -vga none the kernel panics, I have no interest trying to debug and fix that, I only using fulong2e to cross-check changes needed for pegasos2. It could also be that the kernel being experimental have some problems, I can't test if it works on real hardware. Regards, BALATON Zoltan
On Fri, 13 Mar 2020, Mark Cave-Ayland wrote: > Following on from the earlier thread "Implement "non 100% native mode" > in via-ide", here is an updated patchset based upon the test cases > sent to me off-list. > > The VIA IDE controller is similar to early versions of the PIIX > controller in that the primary and secondary IDE channels are hardwired > to IRQs 14 and 15 respectively. Guest OSs typically handle this by > either switching the controller to legacy mode, or using native mode and > using a combination of PCI device/vendor ID and/or checking various > registers in PCI configuration space to detect this condition and apply > a special fixed IRQ 14/15 routing. > > This patchset effectively updates the VIA IDE PCI device to follow the > behaviour in the datasheet in two ways: fixing some PCI configuration > space register defaults and behaviours, and always using legacy IRQ 14/15 > routing, and once applied allows all our known test images to boot > correctly. This supersedes my series and also works with the clients that I've also checked so for the series: Tested-by: BALATON Zoltan <balaton@eik.bme.hu> > Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> > > > BALATON Zoltan (2): > ide/via: Get rid of via_ide_init() > pci: Honour wmask when resetting PCI_INTERRUPT_LINE > > Mark Cave-Ayland (5): > via-ide: move registration of VMStateDescription to DeviceClass > via-ide: ensure that PCI_INTERRUPT_LINE is hard-wired to its default > value > via-ide: initialise IDE controller in legacy mode > via-ide: allow guests to write to PCI_CLASS_PROG > via-ide: always use legacy IRQ 14/15 routing > > hw/ide/via.c | 21 +++++---------------- > hw/mips/mips_fulong2e.c | 5 ++++- > hw/pci/pci.c | 5 ++++- > include/hw/ide.h | 1 - > 4 files changed, 13 insertions(+), 19 deletions(-) > >
On 3/13/20 4:24 AM, Mark Cave-Ayland wrote: > Following on from the earlier thread "Implement "non 100% native mode" > in via-ide", here is an updated patchset based upon the test cases > sent to me off-list. > > The VIA IDE controller is similar to early versions of the PIIX > controller in that the primary and secondary IDE channels are hardwired > to IRQs 14 and 15 respectively. Guest OSs typically handle this by > either switching the controller to legacy mode, or using native mode and > using a combination of PCI device/vendor ID and/or checking various > registers in PCI configuration space to detect this condition and apply > a special fixed IRQ 14/15 routing. > > This patchset effectively updates the VIA IDE PCI device to follow the > behaviour in the datasheet in two ways: fixing some PCI configuration > space register defaults and behaviours, and always using legacy IRQ 14/15 > routing, and once applied allows all our known test images to boot > correctly. > > Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> > > > BALATON Zoltan (2): > ide/via: Get rid of via_ide_init() > pci: Honour wmask when resetting PCI_INTERRUPT_LINE > > Mark Cave-Ayland (5): > via-ide: move registration of VMStateDescription to DeviceClass > via-ide: ensure that PCI_INTERRUPT_LINE is hard-wired to its default > value > via-ide: initialise IDE controller in legacy mode > via-ide: allow guests to write to PCI_CLASS_PROG > via-ide: always use legacy IRQ 14/15 routing > > hw/ide/via.c | 21 +++++---------------- > hw/mips/mips_fulong2e.c | 5 ++++- > hw/pci/pci.c | 5 ++++- > include/hw/ide.h | 1 - > 4 files changed, 13 insertions(+), 19 deletions(-) > Does this supersede everything else so far? (Except the two cmd646 related series, four patches total, which are already staged)
On 13/03/2020 17:57, John Snow wrote: > On 3/13/20 4:24 AM, Mark Cave-Ayland wrote: >> Following on from the earlier thread "Implement "non 100% native mode" >> in via-ide", here is an updated patchset based upon the test cases >> sent to me off-list. >> >> The VIA IDE controller is similar to early versions of the PIIX >> controller in that the primary and secondary IDE channels are hardwired >> to IRQs 14 and 15 respectively. Guest OSs typically handle this by >> either switching the controller to legacy mode, or using native mode and >> using a combination of PCI device/vendor ID and/or checking various >> registers in PCI configuration space to detect this condition and apply >> a special fixed IRQ 14/15 routing. >> >> This patchset effectively updates the VIA IDE PCI device to follow the >> behaviour in the datasheet in two ways: fixing some PCI configuration >> space register defaults and behaviours, and always using legacy IRQ 14/15 >> routing, and once applied allows all our known test images to boot >> correctly. >> >> Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> >> >> >> BALATON Zoltan (2): >> ide/via: Get rid of via_ide_init() >> pci: Honour wmask when resetting PCI_INTERRUPT_LINE >> >> Mark Cave-Ayland (5): >> via-ide: move registration of VMStateDescription to DeviceClass >> via-ide: ensure that PCI_INTERRUPT_LINE is hard-wired to its default >> value >> via-ide: initialise IDE controller in legacy mode >> via-ide: allow guests to write to PCI_CLASS_PROG >> via-ide: always use legacy IRQ 14/15 routing >> >> hw/ide/via.c | 21 +++++---------------- >> hw/mips/mips_fulong2e.c | 5 ++++- >> hw/pci/pci.c | 5 ++++- >> include/hw/ide.h | 1 - >> 4 files changed, 13 insertions(+), 19 deletions(-) >> > > Does this supersede everything else so far? (Except the two cmd646 > related series, four patches total, which are already staged) Yes, that's correct. It passes all our tests, and even better allows the fulong2e CD image at the link Zoltan posted to boot. So I believe it's good unless Alexander has any objections? ATB, Mark.
On 3/14/20 5:15 AM, Mark Cave-Ayland wrote: > On 13/03/2020 17:57, John Snow wrote: > >> On 3/13/20 4:24 AM, Mark Cave-Ayland wrote: >>> Following on from the earlier thread "Implement "non 100% native mode" >>> in via-ide", here is an updated patchset based upon the test cases >>> sent to me off-list. >>> >>> The VIA IDE controller is similar to early versions of the PIIX >>> controller in that the primary and secondary IDE channels are hardwired >>> to IRQs 14 and 15 respectively. Guest OSs typically handle this by >>> either switching the controller to legacy mode, or using native mode and >>> using a combination of PCI device/vendor ID and/or checking various >>> registers in PCI configuration space to detect this condition and apply >>> a special fixed IRQ 14/15 routing. >>> >>> This patchset effectively updates the VIA IDE PCI device to follow the >>> behaviour in the datasheet in two ways: fixing some PCI configuration >>> space register defaults and behaviours, and always using legacy IRQ 14/15 >>> routing, and once applied allows all our known test images to boot >>> correctly. >>> >>> Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> >>> >>> >>> BALATON Zoltan (2): >>> ide/via: Get rid of via_ide_init() >>> pci: Honour wmask when resetting PCI_INTERRUPT_LINE >>> >>> Mark Cave-Ayland (5): >>> via-ide: move registration of VMStateDescription to DeviceClass >>> via-ide: ensure that PCI_INTERRUPT_LINE is hard-wired to its default >>> value >>> via-ide: initialise IDE controller in legacy mode >>> via-ide: allow guests to write to PCI_CLASS_PROG >>> via-ide: always use legacy IRQ 14/15 routing >>> >>> hw/ide/via.c | 21 +++++---------------- >>> hw/mips/mips_fulong2e.c | 5 ++++- >>> hw/pci/pci.c | 5 ++++- >>> include/hw/ide.h | 1 - >>> 4 files changed, 13 insertions(+), 19 deletions(-) >>> >> >> Does this supersede everything else so far? (Except the two cmd646 >> related series, four patches total, which are already staged) > > Yes, that's correct. It passes all our tests, and even better allows the fulong2e CD > image at the link Zoltan posted to boot. > > So I believe it's good unless Alexander has any objections? > > > ATB, > > Mark. > Tentatively staged! Please let me know during the RC testing phase if you discover problems. Thanks, applied to my IDE tree: https://github.com/jnsnow/qemu/commits/ide https://github.com/jnsnow/qemu.git --js
On Fri, 13 Mar 2020, John Snow wrote: > On 3/13/20 4:24 AM, Mark Cave-Ayland wrote: >> Following on from the earlier thread "Implement "non 100% native mode" >> in via-ide", here is an updated patchset based upon the test cases >> sent to me off-list. >> >> The VIA IDE controller is similar to early versions of the PIIX >> controller in that the primary and secondary IDE channels are hardwired >> to IRQs 14 and 15 respectively. Guest OSs typically handle this by >> either switching the controller to legacy mode, or using native mode and >> using a combination of PCI device/vendor ID and/or checking various >> registers in PCI configuration space to detect this condition and apply >> a special fixed IRQ 14/15 routing. >> >> This patchset effectively updates the VIA IDE PCI device to follow the >> behaviour in the datasheet in two ways: fixing some PCI configuration >> space register defaults and behaviours, and always using legacy IRQ 14/15 >> routing, and once applied allows all our known test images to boot >> correctly. >> >> Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> >> >> >> BALATON Zoltan (2): >> ide/via: Get rid of via_ide_init() >> pci: Honour wmask when resetting PCI_INTERRUPT_LINE >> >> Mark Cave-Ayland (5): >> via-ide: move registration of VMStateDescription to DeviceClass >> via-ide: ensure that PCI_INTERRUPT_LINE is hard-wired to its default >> value >> via-ide: initialise IDE controller in legacy mode >> via-ide: allow guests to write to PCI_CLASS_PROG >> via-ide: always use legacy IRQ 14/15 routing >> >> hw/ide/via.c | 21 +++++---------------- >> hw/mips/mips_fulong2e.c | 5 ++++- >> hw/pci/pci.c | 5 ++++- >> include/hw/ide.h | 1 - >> 4 files changed, 13 insertions(+), 19 deletions(-) >> > > Does this supersede everything else so far? Yes, this includes all needed changes from my series (two patches directly and other changes split up in smaller commits) so none of my previous series is needed just this series. > (Except the two cmd646 > related series, four patches total, which are already staged) Yes those are not included here and independent changes that should stay. Your tree seemed to have the commits twice though at least on web interface of github. I've also done some more clean ups that I'm polishing now and will submit soon but those are unrelated and a different series on top of this and the cmd646 clean up. Regards, BALATON Zoltan
© 2016 - 2024 Red Hat, Inc.