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

[Blue Swirl]

On Sun, Dec 27, 2009 at 6:21 PM, Igor Kovalenko
<igor.v.kovalenko at gmail.com> wrote:
> 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.

I made some progress on that side, now everything works pretty much as
before until kernel gets loaded, at which point there is a crash. But
I think the devices are now mapped at the correct location.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Map-VGA-buffer-only-during-PCI-probe.patch
Type: application/x-patch
Size: 2758 bytes
Desc: not available
URL: <http://lists.openbios.org/pipermail/openbios/attachments/20091227/c558955b/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-PCI-Fix-bus-address-conversion.patch
Type: application/x-patch
Size: 1083 bytes
Desc: not available
URL: <http://lists.openbios.org/pipermail/openbios/attachments/20091227/c558955b/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-Sparc64-move-APB-PCI-memory-base-to-correct-locatio.patch
Type: application/x-patch
Size: 949 bytes
Desc: not available
URL: <http://lists.openbios.org/pipermail/openbios/attachments/20091227/c558955b/attachment-0002.bin>