Igor Kovalenko wrote:
Right, that's the issue we have at the moment; both qemu and openbios are to be changed.
- Actual memory
- PCI memory space
- PCI IO space
They are each independent address spaces. Zero in any one of them is independent from zero in all the others.
Well, sparc64 is a bit unique.
From what I have seen almost any other openbios platform is either 32bit or has no pci devices, also every other platform has pci configuration mechanism 1 in place.
- sparc64 has no configuration mechanism 1 (which has basically a single port
to implement configuration protocol) but directly maps configuration space. So for sparc64 pci is also quite different from the rest, and a few clients know about that mapped configuration space.
- PCI support is there and useful, but a few places has bar address
mapping hardcoded;
- getting ucells right on 64bit sparc was *real* fun :) It turns out that linux
kernel started to rely more on prom tree data so that required ofmem supporting allocations and range properties; no other openbios platform seem to require implementing ofmem to such extent
Right, so is what you're saying is that at a minimum we'd need to implement 2) with a PCI configuration mechanism in place for this to stand any chance of working? Would the configuration mechanism simply be a set of MMIO addresses?
I've never looked at PCI devices in much detail before, however if there is any C coding I can do to help out, please let me know.
Welcome! But to my mind we need to get qemu part right first, in that we need to remap pci address spaces out of low addresses. If you could invent another workaround it would be a good start, we need get these 3 address spaces right one way or another.
Does that mean you've already started working on the Qemu side of this? If so, again let me know if I can help at all. Incidentally if you already have ideas for this, it's probably worth floating any proposals to the qemu-devel list first before doing any coding, just to make sure that they would be happy to accept patches implementing this new functionality.
ATB,
Mark.