On Sun, Dec 13, 2009 at 9:29 PM, Igor Kovalenko igor.v.kovalenko@gmail.com wrote:
On Sun, Dec 13, 2009 at 9:07 PM, Tarl Neustaedter Tarl.Neustaedter@sun.com wrote:
Igor Kovalenko wrote:
[...] We also need to find out how memory mappings are laid out preparing to run client code. It is not clear from of1275 docs.
Generally, OF is placed in high memory, and memory allocations are from low memory.
That is how memory layout looks like now, if we look at 32bits of physical address space. The only difference seems to be with low 16m being used for both pci memory, i/o space and actual memory. It's getting mapped 1:1 into virtual address space used by openbios code.
What is really confusing is how exactly we need to claim and map memory for client program. Some client programs appear to be happy with read-write privileged mapping, some may expect global translation, and docs are basically silent in this regard. Can we do 4M page mappings?
But there are several address spaces, which it sounds like are being overlapped here:
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.
Just thought this needs more words to clarify.
From CPU point of view all three of these address spaces are just distinct
regions in single physical address space accessible with simple load/store instructions. What happens now on qemu side is that we have i/o space and pci memory space addresses assigned near start of actual memory address space. Qemu effectively gives actual memory locations less precedence after i/o and pci bars are mapped by initialization routines, so the issue with ide bmdma registers is obvious.