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
