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.
I've been AFK for a few days, so just starting to catch up on various bits
and pieces.
OK just wasn't sure if you saw my emails at all as it happened before that
some spam filters disliked my mail server and put messages in the spam
folder.
The only difference I can think of regarding the BAR zeroing is that the
BMDMA BAR is zeroed here. Does the following diff fix things?
This helps, with this the latest driver does not crash but still reads
BAR4 as 0 instead of 0xcc00 so UDMA won't work but at least it boots.
Regards,
BALATON Zoltan
diff --git a/hw/ide/via.c b/hw/ide/via.c
index 47223b1268..2d3124ebd7 100644
--- a/hw/ide/via.c
+++ b/hw/ide/via.c
@@ -164,10 +164,10 @@ static uint32_t via_ide_cfg_read(PCIDevice *pd,
uint32_t addr, int len)
uint8_t mode = pd->config[PCI_CLASS_PROG];
if ((mode & 0xf) == 0xa && ranges_overlap(addr, len,
- PCI_BASE_ADDRESS_0, 24)) {
+ PCI_BASE_ADDRESS_0, 16)) {
/* BARs always read back zero in legacy mode */
for (int i = addr; i < addr + len; i++) {
- if (i >= PCI_BASE_ADDRESS_0 && i < PCI_BASE_ADDRESS_0 + 24) {
+ if (i >= PCI_BASE_ADDRESS_0 && i < PCI_BASE_ADDRESS_0 + 16) {
val &= ~(0xffULL << ((i - addr) << 3));
}
}
- Add comments in pci_ide_update_mode() suggested by Kevin
- Drop the existing R-B and T-B tags: whilst this passes my local tests,
the behaviour
around zero BARs feels different enough here
v2:
- Rebase onto master
- Mask the bottom 4 bits of PCI_CLASS_PROG in pci_ide_update_mode() in
patch 1
- Add patch 2 to remove the default BAR addresses to avoid confusion
- Don't set PCI_INTERRUPT_PIN directly in via_ide_reset() as it is already
set
by pci_ide_update_mode() in patch 3, and reword the commit message
accordingly
- Add Tested-By tags from Zoltan and Bernhard
Mark Cave-Ayland (4):
ide/ioport: move ide_portio_list[] and ide_portio_list2[] definitions
to IDE core
ide/pci: introduce pci_ide_update_mode() function
ide/via: don't attempt to set default BAR addresses
hw/ide/via: implement legacy/native mode switching
hw/ide/core.c | 12 ++++++
hw/ide/ioport.c | 12 ------
hw/ide/pci.c | 84 +++++++++++++++++++++++++++++++++++++++
hw/ide/via.c | 44 ++++++++++++++++----
include/hw/ide/internal.h | 3 ++
include/hw/ide/pci.h | 1 +
6 files changed, 137 insertions(+), 19 deletions(-)
ATB,
Mark.
