[OpenBIOS] [PATCH 0/5] v1 alternative implementation of sparc64 boot memory mapping

Mark Cave-Ayland 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 mailing list