On 16/01/18 00:54, Philippe Mathieu-Daudé wrote:
CC'ing PCI maintainers.
Hi Mark,
On 01/15/2018 05:58 PM, Mark Cave-Ayland wrote:
This inbuilt device contains a single 4-byte register, of which bit 24 is used
to power down the machine on a real Ultra 5.
The power device exists at offset 0x724000 on a real machine, but due to the
current configuration of the BARs in QEMU it must be located lower in PCI IO
space.
Is is some issue in pci_bar_address()?
Hi Philippe,
It's not an issue with QEMU at all, more the way in which the on-board
devices are mapped. From memory there are 3 different issues with the
current setup:
- OpenBIOS uses PCI IO space accesses for all its drivers
In a real Ultra 5 the on-board devices are behind a memory BAR but
everything in OpenBIOS is hard-coded to use IO accesses. Changing that
will be fairly hard.
- Some OSs use the ebus BAR to access the onboard devices, others use
the direct physical accesses
This means that the ebus BAR has to be located at address zero (even
though its in slot 1) for both accesses to work. The first part of PCI
IO space containing the ebus is then aliased back onto its physical
address to make everything consistent.
- Linux sabre fix-up bug
Potentially this could be fixed by increasing the base physical address
of the simba IO space, however Linux has a fixup routine for this
particular PCI host bridge and this has a bug which means that it
presumes the lower word of the address is 0 (like a real Ultra 5) rather
than reading it from the DT.
Therefore whilst moving the base of PCI IO space within the physical
address space should work, due to this bug the PCI addresses are
converted incorrectly from physical addresses causing a panic.
For the moment we place the power device at offset 0x7240 as a reminder of its
original location and raise the base PCI IO address from 0x4000 to 0x8000.
If we can't fix it, I rather prefer a #define with a comment in the
code, IMHO this is safer and easier to remember than looking in git history.
Well TBH just about all of the current devices for sun4u are either
incorrect or located at the wrong address, and could possibly change
later if required for Solaris compatibility. So while things are still
quite fluid, I'm more inclined to leave them as hard-coded offsets
(similarly in OpenBIOS) until things become more clear.
ATB,
Mark.