On Sun, Dec 27, 2009 at 8:59 PM, Mark Cave-Ayland mark.cave-ayland@siriusit.co.uk wrote:
Igor V. Kovalenko wrote:
The following series implements alternative approach to solve issue where qemu provides i/o and pci memory spaces within physical RAM address space, which makes low memory addresses unusable.
Instead of changing qemu to move i/o and pci spaces out of RAM space we can remap 64M of i/o and pci spaces to above 32bit accessible by client program. Then we map physical RAM at 64M offset to start of virtual memory.
A few extra changes are required. At very least we need to find where framebuffer virtual address is placed by startup code, helper change is provided.
NOTE: this approach may hide up to 128M from client allocations, therefore default qemu memory size is not sufficient. Please use at least '-m 256' on qemu command line to test with these changes.
In my test these series are as efficient as qemu change to remap i/o and pci spaces in allowing milax032sparc.iso to not step over cmd646 registers. Currently milax loader gets a bit further and fails with
Can't open /ramdisk-root byte-load: exception caught!
AIUI this is an alternative approach to the one suggested by Blue; instead of moving the PCI memory space into high memory, we simply mark the appropriate regions as being in use. I'm currently unsure as to how much work is required for Blue's patches to add the required functionality to Qemu; so should we temporarily apply this patch set to allow further development work or continue to work from the Qemu side instead?
Regardless of which approach we choose, I am encouraged that the Milax loader gets further :)
That's the intention here, to progress on forth loader while qemu part is on it's way.