On 6/10/20 12:58 PM, Rocky Hotas wrote:
On giu 10 12:54, Rocky Hotas wrote:the address 0x10110000 belongs to a `user process virtual space, mapped and cached', both when the processor uses 32 and 64 bit addresses.
The address reported by pcictl is a physical address. It looks correct in my opinion.
NetBSD is mapping PCI devices on cobalt starting at address 0x10000000. This is defined in src/sys/arch/cobalt/include/cpu.h.
gxemul does not really emulate cobalt firmware, so the whole setup of PCI bus is done via PCI_NETBSD_CONFIGURE mechanism. Considering that device was mapped to a sane looking address, I can guess this part has worked successfully.
If you want to double check this, I suggest editing src/sys/dev/pci/pciconf.c and setting pci_conf_debug to 1. This should give you detailed output of configuration process.
The real question boils down to why pci_mapreg_map() fails and I am afraid, this requires inserting a few printfs into this function, as suggested by other people on the mailing list.
I suspect there are two options: either something has bit-rotted in Cobalt-specific PCI code, or the ancient gxemul from 2012 does not work correctly anymore.
Nevertheless, this requires further debugging. Best regards, Radoslaw