[OpenBIOS] [PATCH 0/5] v1 alternative implementation of sparc64 boot memory mapping
andreas.faerber at web.de
Sun Dec 27 14:37:35 CET 2009
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:
Allocated 8 Megs of memory at 0x40000000 for kernel
Loaded kernel version 2.6.18
Loading initial ramdisk (3882238 bytes at 0x8C00000 phys, 0x40C00000
Unhandled Exception 0x0000000000000020
PC = 0x00000000005154dc NPC = 0x00000000005154e0
That's just before "Remapping the kernel...".
More information about the OpenBIOS