[OpenBIOS] [PATCH 0/5] v1 alternative implementation of sparc64 boot memory mapping
mark.cave-ayland at siriusit.co.uk
Sun Dec 27 18:59:38 CET 2009
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 :)
Mark Cave-Ayland - Senior Technical Architect
PostgreSQL - PostGIS
Sirius Corporation plc - control through freedom
t: +44 870 608 0063
Sirius Labs: http://www.siriusit.co.uk/labs
More information about the OpenBIOS