Am 27. Juni 2023 07:11:33 UTC schrieb Paolo Bonzini <pbonz...@redhat.com>:
>On 6/26/23 23:19, Olaf Hering wrote:
>> I need advice on how to debug this.
>>
>> One thing that stands out is uhci_irq().
>> It reads a u16 from the USBSTS register.
>>
>> On the qemu side, this read is served from bmdma_read. Since the read
>> size is 2, the result is ~0, and uhci_irq() turns the controller off.
>> In other words, memory_region_ops_read from addr=0xc102 is served from
>> "piix-bmdma"
>>
>> If the pci_set_word calls in piix_ide_reset are skipped, the read is
>> served from uhci_port_write. This is the expected behavior.
>> In other words, memory_region_ops_read from addr=0xc102 is served from
>> "uhci".
>
>I think what's happening is that
>
> pci_set_byte(pci_conf + 0x20, 0x01); /* BMIBA: 20-23h */
>
>is setting the BAR to 0xC100, therefore overlapping the UHCI device's region.
>In principle this line shouldn't be necessary at all though; it's enough to
>clear the COMMAND register.
Interesting. The BAR is a 32 bit register whose default value is 0x00000001. I
think what's supposed to happen here is a pci_set_long() rather than a
pci_set_byte().
Bits 4..15 represent the BAR address, and pci_set_byte() only clears bits 4..7,
leaving bits 8..15 unchanged. Perhaps this causes the BAR to be moved into the
UHCI region? Does changing the call to pci_set_long() fix the problem?
Best regards,
Bernhard
>
>Can you check the value of the COMMAND register (pci_conf + 0x04, 16 bits,
>little endian)? Something might be causing the register to be set back to a
>nonzero value, therefore re-enabling the I/O at the address that overlaps the
>UHCI device.
>
>Paolo
>
>
