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

[Andreas Färber]

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...".

Andreas