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

[Igor Kovalenko]

On Sun, Dec 27, 2009 at 5:35 PM, Andreas Färber <andreas.faerber at web.de> wrote:
>
> Am 27.12.2009 um 14:46 schrieb 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.
>
> Yes.
>
>> Is the image available somewhere so I can take a look?
>
> Try this one:
> http://cdimage.debian.org/cdimage/archive/4.0_r8/sparc/iso-cd/debian-40r8-sparc-businesscard.iso
>
>> I only have debian-40r4a-sparc-businesscard.iso and
>> it keeps failing with inconsistent console (no change here).
>
> I remember getting that message on some host, too.
>
>
> For debian-503-sparc-businesscard.iso with your patches I get:
>
> boot:
> Allocated 8 Megs of memory at 0x40000000 for kernel
> Loaded kernel version 2.6.26
> Loading initial ramdisk (4311252 bytes at 0x8C00000 phys, 0x40C00000
> virt)...
> |
> [    0.000000] PROMLIB: Sun IEEE Boot Prom 'OBP 3.10.24 1999/01/01 01:01'
> [    0.000000] PROMLIB: Root node compatible: sun4u
> [    0.000000] Initializing cgroup subsys cpu
> [    0.000000] Linux version 2.6.26-2-sparc64 (Debian 2.6.26-19)
> (dannf at debian.org) (gcc version 4.1.3 20080704 (prerelease) (Debian
> 4.1.2-25)) #1 Thu Aug 20 15:21:01 UTC 2009
> [    0.000000] console [earlyprom0] enabled
> [    0.000000] ARCH: SUN4U
> [    0.000000] Ethernet address: 52:54:00:12:34:56
> Unhandled Exception 0x0000000000000020
> PC = 0x000000000055049c NPC = 0x00000000005504a0
> Stopping execution
>
> With vanilla r647 I get:
>
> boot:
> Allocated 8 Megs of memory at 0x40000000 for kernel
> Loaded kernel version 2.6.26
> Loading initial ramdisk (4311252 bytes at 0xC00000 phys, 0x40C00000 virt)...
> qemu: unsupported keyboard cmd=0x62
> zqemu: unsupported keyboard cmd=0x27
>

Do you apply the full 5 patches set? It appears that your case
is failing because first remapping patch is not applied. The
'unsupported keyboard cmd' messages are most probably
due to loader writing over keyboard registers.
What is your qemu command line?
I test with 'qemu-system-sparc64 -hda empty.img -cdrom
debian-503-sparc-businesscard.iso -m 256 -boot d'
(mage is empty fwiw.)

Here with debian-503-sparc-businesscard.iso it progresses up to
console handower (and a bit further, but misses timer support to
continue.)

-- 
Kind regards,
Igor V. Kovalenko