On Sun, Dec 27, 2009 at 4:37 PM, Andreas Färber andreas.faerber@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).