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

[Igor Kovalenko]

On Sun, Dec 27, 2009 at 8:59 PM, Mark Cave-Ayland
<mark.cave-ayland at 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.

-- 
Kind regards,
Igor V. Kovalenko