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

[Igor Kovalenko]

On Sun, Dec 27, 2009 at 4:37 PM, Andreas Färber <andreas.faerber at web.de> wrote:
> Hello,
>
> Am 27.12.2009 um 12:43 schrieb Igor V. Kovalenko:
>
>> 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!
>
> I can confirm this behavior of milax032sparc.iso (with -m 256).
>
> debian-40r3-sparc-CD-1.iso however fails as follows, even with -m 1024:
>
> boot:
> Allocated 8 Megs of memory at 0x40000000 for kernel
> Loaded kernel version 2.6.18
> Loading initial ramdisk (3882238 bytes at 0x8C00000 phys, 0x40C00000
> virt)...
> -
> Unhandled Exception 0x0000000000000020
> PC = 0x00000000005154dc NPC = 0x00000000005154e0
> Stopping execution
>
> That's just before "Remapping the kernel...".

I wonder if it worked before the proposed change.

Is the image available somewhere so I can take a look?
I only have debian-40r4a-sparc-businesscard.iso and
it keeps failing with inconsistent console (no change here).

-- 
Kind regards,
Igor V. Kovalenko