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

[Blue Swirl]

On Sun, Dec 27, 2009 at 5: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.

Yes, though some of this may be useful even if the memory space was in
high memory.

> 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?

It may be trivial (just invent the correct way to add the memory base
to BAR address) but in the worst case it may involve changes to all
PCI devices in QEMU and some changes to OpenBIOS PCI code as well.

> Regardless of which approach we choose, I am encouraged that the Milax
> loader gets further :)

We could choose both, apply the patches now and when QEMU is fixed,
revert some of them.