On Mon, 20 Nov 2023, Mark Cave-Ayland wrote:
On 20/11/2023 13:30, BALATON Zoltan wrote:
On Mon, 20 Nov 2023, BALATON Zoltan wrote:
On Mon, 20 Nov 2023, Mark Cave-Ayland wrote:
On 19/11/2023 21:43, BALATON Zoltan wrote:
On Thu, 16 Nov 2023, Mark Cave-Ayland wrote:
This series adds a simple implementation of legacy/native mode
switching for PCI
IDE controllers and updates the via-ide device to use it.
The approach I take here is to add a new pci_ide_update_mode() function
which handles
management of the PCI BARs and legacy IDE ioports for each mode to
avoid exposing
details of the internal logic to individual PCI IDE controllers.
As noted in [1] this is extracted from a local WIP branch I have which
contains
further work in this area. However for the moment I've kept it simple
(and
restricted it to the via-ide device) which is good enough for Zoltan's
PPC
images whilst paving the way for future improvements after 8.2.
Signed-off-by: Mark Cave-Ayland <mark.cave-ayl...@ilande.co.uk>
[1] https://lists.gnu.org/archive/html/qemu-devel/2023-10/msg05403.html
v3:
- Rebase onto master
- Move ide_portio_list[] and ide_portio_list2[] to IDE core to prevent
duplication in
hw/ide/pci.c
- Don't zero BARs when switching from native mode to legacy mode,
instead always force
them to read zero as suggested in the PCI IDE specification (note:
this also appears
to fix the fuloong2e machine booting from IDE)
Not sure you're getting this, see also:
https://lists.nongnu.org/archive/html/qemu-devel/2023-11/msg04167.html
but this seems to break latest version of the AmigaOS driver for some
reason. I assume this is the BAR zeroing that causes this as it works
with v2 series and nothing else changed in v3 that could cause this.
Testing was done by Rene Engel, cc'd so maybe he can add more info. It
seems to work with my patch that sets BARs to legacy values and with v2
that sets them to 0 but not with v3 which should also read 0 but maybe
something is off here.
Is this document here accurate as to how it works on real hardware?
https://intuitionbase.com/hints.php.
That should be about right. On QEMU the U-boot env vars won't work because
NVRAM is not emulated yet so they can't be saved but you can call idetool
from startup-sequence boot script instead for same effect (UDMA is enabled
a bit later with that but after that it's the same).
I can't understand why the base OS is attempting any access to BAR 4 if
BMDMA isn't enabled by default on real hardware due to hardware bugs.
Real hardware had problems with DMA (the VIA chip was also infamous for it
on PC hardware and later also the ArticiaS was found to have its own
problems) so the default is to use IDE in PIO mode and UDMA has to be
enabled manually. But if it works (and it should on QEMU) it's much faster
so we want to enable it.
Are we sure that the idetool hacks given in the link above to enable
BMDMA haven't already been run on the AmigaOS install when testing an
earlier version of the patches?
It was tested with my original series and works with that as my patch sets
the default vaules for BARs and the driver reads it correctly. Then we
tested your series too and I've noted for v2 already that it misses the
degault value for BAR4. Other BARs don't matter as it will apparently use
ISA IDE ports when it gets 0 or it knows that in legacy mode these shoud
be the port values but seems to read BAR4 for UDMA and only works if the
right default value is there, otherwise it lists DMA BAR 0 on start.
This probably wasn't clear so what I mean is:
a1ide.device 53.22 (28.6.2017)
[a1ide/dev_init] Found chip #0
[a1ide/init_port] ---> Port 0
[a1ide/init_port] IOBase 000001F0, AltBase 000003F6
[a1ide/init_port] bmcr_base 0000CC00
[a1ide/init_port] MMIOBase 00000000
This is with my patch:
https://patchew.org/QEMU/cover.1697661160.git.bala...@eik.bme.hu/4095e01f4596e77a478759161ae736f0c398600a.1697661160.git.bala...@eik.bme.hu/
With yours bmcr_base is 0 and then when enabling UDMA with idetool it hangs
as it needs this value from BAR4.
Right, so what you're saying is that AmigaOS will run fine with the v3 series
out-of-the-box, but only fails when you try and enable UDMA with idetool
(which is explicitly changing the configuration from the AmigaOS default)?
No, what I said is it boots with v2 but fails when enabling UDMA but does
not even boot with v3 as it crashes even before printing the above debug
logs with v3. The changes you've and Kevin proposed fix v3 to boot and
allow UDMA too which I've tested and sent another reply about.
Regards,
BALATON Zoltan
