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!
v0 -> v1: split ofmem_find_virtual changes into separate patches
---
Igor V. Kovalenko (5): sparc64: remap first 64M physical address space sparc64: claim memory mapped by startup code ofmem: helper to find first virtual address map entry ofmem: use helper to access command line parameters from qemu ofmem: use helper to find framebuffer virtual address on sparc64
arch/sparc64/entry.S | 68 +++++++++++++++++++----------------------- arch/sparc64/ofmem_sparc64.c | 2 + arch/sparc64/openbios.c | 19 ++++++++---- include/ofmem.h | 1 + modules/ofmem_common.c | 25 +++++++++++++++ modules/video.c | 9 +++++- 6 files changed, 80 insertions(+), 44 deletions(-)
From: Igor V. Kovalenko igor.v.kovalenko@gmail.com
At the moment qemu maps i/o and pci memory spaces into low physical addresses, making first megabytes of RAM space unavalable.
Instead of changing qemu we map first 64M of physical address space at 0x1ff.00000000 and map low virtual addresses after that hole. i/o space is accessed via bypass ASI therefore no changes to drivers using i/o are required.
Issue with framebuffer mapping is solved by separate patch to find where framebuffer got mapped by startup code.
- map low 64M of physical address space at 0x1ff00000000 by startup code
- map low 64M of virtual address space after 64M of physical address space by startup code
Signed-off-by: Igor V. Kovalenko igor.v.kovalenko@gmail.com --- arch/sparc64/entry.S | 68 +++++++++++++++++++++++--------------------------- 1 files changed, 31 insertions(+), 37 deletions(-)
diff --git a/arch/sparc64/entry.S b/arch/sparc64/entry.S index d3075d8..c865a5d 100644 --- a/arch/sparc64/entry.S +++ b/arch/sparc64/entry.S @@ -18,6 +18,11 @@ #define PROM_ADDR 0x1fff0000000 #define CFG_ADDR 0x1fe02000510
+! where do we remap low 64M as a workaround +#define REMAP_VADDR 0x1ff00000000 +! where usable RAM starts after 64M hole +#define REMAP_PADDR 0x4000000 + .globl entry, _entry
.section ".text", "ax" @@ -180,39 +185,47 @@ entry: bne 1b add %l2, %g5, %l2
- ! setup VGA buffer - setx 0x1ff004a0000, %g7, %g4 - mov 2, %g6 + ! remap low 64m including VGA buffer to high memory + setx 0, %l1, %l3 ! physical address + setx REMAP_VADDR, %l1, %l4 ! virtual address + + ! 16x4M mapped + mov 16, %g6 set 48, %g7 - set 0x10000, %g5 -1: stxa %g4, [%g7] ASI_DMMU ! vaddr = 0x1ff004a0000, ctx=0 - set 0xa0000000, %g3 + set 0x400000, %g5 +1: mov %l4, %g4 + stxa %g4, [%g7] ASI_DMMU ! vaddr = 0x1ff00000000, ctx=0 + set 0xe0000000, %g3 sllx %g3, 32, %g3 - or %g3, 0x76, %g3 + or %g3, 0x76, %g3 ! valid, 4M, locked, cacheable(I/E/C), priv, writable + mov %l3, %g4 or %g4, %g3, %g3 - ! valid, 64k, locked, cacheable(I/E/C), priv, writable - ! paddr = 0x1ff004a0000 stxa %g3, [%g0] ASI_DTLB_DATA_IN - add %g4, %g5, %g4 + add %l3, %g5, %l3 + add %l4, %g5, %l4 deccc %g6 bne 1b nop
#if 1 - ! setup 0-16M - mov %g0, %g4 - mov 4, %g6 + ! setup 0-64M of virtual space after 64M of physical space + setx REMAP_PADDR, %l1, %l3 ! physical address + setx 0, %l1, %l4 ! virtual address + + ! 16x4M mapped + mov 16, %g6 set 48, %g7 set 0x400000, %g5 -1: stxa %g4, [%g7] ASI_DMMU ! vaddr = 0, ctx=0 +1: mov %l4, %g4 + stxa %g4, [%g7] ASI_DMMU ! vaddr = 0x1ff00000000, ctx=0 set 0xe0000000, %g3 sllx %g3, 32, %g3 - or %g3, 0x36, %g3 + or %g3, 0x36, %g3 ! valid, 4M, cacheable(I/E/C), priv, writable + mov %l3, %g4 or %g4, %g3, %g3 - ! valid, 4M, cacheable(I/E/C), priv, writable - ! paddr = 0 stxa %g3, [%g0] ASI_DTLB_DATA_IN - add %g4, %g5, %g4 + add %l3, %g5, %l3 + add %l4, %g5, %l4 deccc %g6 bne 1b nop @@ -242,25 +255,6 @@ entry: bne 1b add %l2, %g5, %l2
-#if 1 - ! setup 0-16M - mov %g0, %g4 - mov 4, %g6 - set 0x400000, %g5 -1: stxa %g4, [%g7] ASI_IMMU ! vaddr = 0, ctx=0 - set 0xe0000000, %g3 - sllx %g3, 32, %g3 - or %g3, 0x34, %g3 - or %g4, %g3, %g3 - ! valid, 4M, cacheable(I/E/C), priv - ! paddr = 0 - stxa %g3, [%g0] ASI_ITLB_DATA_IN - add %g4, %g5, %g4 - deccc %g6 - bne 1b - nop -#endif - flush %g4
mov %g1, %g3
From: Igor V. Kovalenko igor.v.kovalenko@gmail.com
- claim both physical and virtual address ranges while walking boot memory mappings
Signed-off-by: Igor V. Kovalenko igor.v.kovalenko@gmail.com --- arch/sparc64/ofmem_sparc64.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/sparc64/ofmem_sparc64.c b/arch/sparc64/ofmem_sparc64.c index e69f36b..e96060c 100644 --- a/arch/sparc64/ofmem_sparc64.c +++ b/arch/sparc64/ofmem_sparc64.c @@ -83,6 +83,8 @@ extern uint64_t qemu_mem_size;
static int remap_page_range( ucell phys, ucell virt, ucell size, ucell mode ) { + ofmem_claim_phys(phys, size, 0); + ofmem_claim_virt(virt, size, 0); ofmem_map_page_range(phys, virt, size, mode); if (!(mode & SPITFIRE_TTE_LOCKED)) { OFMEM_TRACE("remap_page_range clearing translation " FMT_ucellx
From: Igor V. Kovalenko igor.v.kovalenko@gmail.com
A few places in sparc64 code may need to know where specific physical address range is mapped to access memory locations. Create helper to find first suitable mapping and return virtual address.
- ofmem_find_virtual: new method; use it to find where physical memory address is mapped
Signed-off-by: Igor V. Kovalenko igor.v.kovalenko@gmail.com --- include/ofmem.h | 1 + modules/ofmem_common.c | 25 +++++++++++++++++++++++++ 2 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/include/ofmem.h b/include/ofmem.h index 37f9e3b..eaa5082 100644 --- a/include/ofmem.h +++ b/include/ofmem.h @@ -92,6 +92,7 @@ extern int ofmem_unmap( ucell virt, ucell size ); extern void ofmem_release_phys( ucell phys, ucell size ); extern void ofmem_release_virt( ucell virt, ucell size ); extern ucell ofmem_translate( ucell virt, ucell *ret_mode ); +extern ucell ofmem_find_virtual( ucell phys );
#ifdef CONFIG_PPC #define PAGE_SHIFT 12 diff --git a/modules/ofmem_common.c b/modules/ofmem_common.c index 760823d..fedcaa1 100644 --- a/modules/ofmem_common.c +++ b/modules/ofmem_common.c @@ -694,6 +694,31 @@ ucell ofmem_translate( ucell virt, ucell *mode ) return -1; }
+/* physical -> virtual. + return first found translation + */ +ucell ofmem_find_virtual( ucell phys ) +{ + ofmem_t *ofmem = ofmem_arch_get_private(); + translation_t *t; + + OFMEM_TRACE("ofmem_find_virtual: searching virtual address of " + FMT_ucellx "\n", phys); + + for( t=ofmem->trans; t ; t=t->next ) { + ucell offs; + if( t->phys <= phys && t->phys + t->size - 1 >= phys ) { + offs = phys - t->phys; + return t->virt + offs; + } + } + + OFMEM_TRACE("ofmem_find_virtual: no translation defined (" FMT_ucellx ")\n", + phys); + + return -1; +} + /* release memory allocated by ofmem_claim_phys */ void ofmem_release_phys( ucell phys, ucell size ) {
From: Igor V. Kovalenko igor.v.kovalenko@gmail.com
- arch_nvram_get: call ofmem_find_virtual to access kernel command line parameters from qemu
Signed-off-by: Igor V. Kovalenko igor.v.kovalenko@gmail.com --- arch/sparc64/openbios.c | 19 +++++++++++++------ 1 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/arch/sparc64/openbios.c b/arch/sparc64/openbios.c index 03993b5..dd6151f 100644 --- a/arch/sparc64/openbios.c +++ b/arch/sparc64/openbios.c @@ -281,6 +281,7 @@ void arch_nvram_get(char *data) uint16_t machine_id; const char *stdin_path, *stdout_path; const char *kernel_cmdline; + ucell kernel_cmdline_addr;
fw_cfg_init();
@@ -302,12 +303,18 @@ void arch_nvram_get(char *data) kernel_size = fw_cfg_read_i32(FW_CFG_KERNEL_SIZE); if (kernel_size) kernel_image = fw_cfg_read_i64(FW_CFG_KERNEL_ADDR); - kernel_cmdline = (const char *) fw_cfg_read_i64(FW_CFG_KERNEL_CMDLINE); - if (kernel_cmdline) { - size = strlen(kernel_cmdline); - if (size > OBIO_CMDLINE_MAX - 1) - size = OBIO_CMDLINE_MAX - 1; - memcpy(&obio_cmdline, kernel_cmdline, size); + /* first read physical address of command line parameters */ + kernel_cmdline_addr = fw_cfg_read_i64(FW_CFG_KERNEL_CMDLINE); + if (kernel_cmdline_addr) { + /* find virtual address, expect it to be mapped by entry.S */ + kernel_cmdline_addr = ofmem_find_virtual(kernel_cmdline_addr); + if (kernel_cmdline_addr != (ucell)-1) { + kernel_cmdline = (const char*) kernel_cmdline_addr; + size = strlen(kernel_cmdline); + if (size > OBIO_CMDLINE_MAX - 1) + size = OBIO_CMDLINE_MAX - 1; + memcpy(&obio_cmdline, kernel_cmdline, size); + } } obio_cmdline[size] = '\0'; qemu_cmdline = (uint64_t)obio_cmdline;
From: Igor V. Kovalenko igor.v.kovalenko@gmail.com
- init_video: call ofmem_find_virtual to access framebuffer on sparc64
Signed-off-by: Igor V. Kovalenko igor.v.kovalenko@gmail.com --- modules/video.c | 9 ++++++++- 1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/modules/video.c b/modules/video.c index fe8f1a2..83a39b4 100644 --- a/modules/video.c +++ b/modules/video.c @@ -309,7 +309,6 @@ init_video( unsigned long fb, int width, int height, int depth, int rb ) int i, s, size; phandle_t ph=0;
- video.fb.mphys = fb; video.fb.w = width; video.fb.h = height; video.fb.depth = depth; @@ -333,6 +332,14 @@ init_video( unsigned long fb, int width, int height, int depth, int rb ) ofmem_claim_virt( video.fb.mphys, size, 0 ); ofmem_map( video.fb.mphys, video.fb.mphys, size, -1 ); #endif +#if defined(CONFIG_SPARC64) + // TODO: use full 64bit physical address of framebuffer + // The issue here is that fb is passed value of bar address + // which is an offset from pci memory space + fb = ofmem_find_virtual(fb); +#endif + + video.fb.mphys = fb;
for( i=0; i<256; i++ ) set_color( i, i * 0x010101 );
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
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).
Am 27.12.2009 um 14:46 schrieb Igor Kovalenko:
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.
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-sp...
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@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
Andreas
On Sun, Dec 27, 2009 at 5:35 PM, Andreas Färber andreas.faerber@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@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-sp...
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@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.)
Am 27.12.2009 um 17:33 schrieb Igor Kovalenko:
On Sun, Dec 27, 2009 at 5:35 PM, Andreas Färber <andreas.faerber@web.de
wrote:
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@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.
'vanilla r647' = none of your patches 'with your patches' = 5 of 5 patches, yes
Host is OSX/ppc64.
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.)
qemu-system-sparc64 -m 1024 -boot d -cdrom debian-503-sparc- businesscard.iso -nographic
Here with debian-503-sparc-businesscard.iso it progresses up to console handower (and a bit further, but misses timer support to continue.)
On OpenSolaris/amd64 host I do get to "console handover: boot [earlyprom0] -> real [tty0]"...
Andreas
On Sun, Dec 27, 2009 at 8:17 PM, Andreas Färber andreas.faerber@web.de wrote:
Am 27.12.2009 um 17:33 schrieb Igor Kovalenko:
On Sun, Dec 27, 2009 at 5:35 PM, Andreas Färber andreas.faerber@web.de wrote:
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@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.
'vanilla r647' = none of your patches 'with your patches' = 5 of 5 patches, yes
Host is OSX/ppc64.
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.)
qemu-system-sparc64 -m 1024 -boot d -cdrom debian-503-sparc-businesscard.iso -nographic
Here with debian-503-sparc-businesscard.iso it progresses up to console handower (and a bit further, but misses timer support to continue.)
On OpenSolaris/amd64 host I do get to "console handover: boot [earlyprom0] -> real [tty0]"...
Is it the same with r647? I'd assume we have some qemu issue then, my host is x86_64.
Am 27.12.2009 um 18:47 schrieb Igor Kovalenko:
On Sun, Dec 27, 2009 at 8:17 PM, Andreas Färber <andreas.faerber@web.de
wrote:
Am 27.12.2009 um 17:33 schrieb Igor Kovalenko:
On Sun, Dec 27, 2009 at 5:35 PM, Andreas Färber <andreas.faerber@web.de
wrote:
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
'vanilla r647' = none of your patches
Host is OSX/ppc64.
Here with debian-503-sparc-businesscard.iso it progresses up to console handower (and a bit further, but misses timer support to continue.)
On OpenSolaris/amd64 host I do get to "console handover: boot [earlyprom0] -> real [tty0]"...
Is it the same with r647?
No, r647 has the same keyboard issues on both OSX/ppc64 and OpenSolaris/amd64.
Andreas
Igor V. Kovalenko wrote:
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!
AIUI this is an alternative approach to the one suggested by Blue; instead of moving the PCI memory space into high memory, we simply mark the appropriate regions as being in use.
I'm currently unsure as to how much work is required for Blue's patches to add the required functionality to Qemu; so should we temporarily apply this patch set to allow further development work or continue to work from the Qemu side instead?
Regardless of which approach we choose, I am encouraged that the Milax loader gets further :)
ATB,
Mark.
On Sun, Dec 27, 2009 at 5:59 PM, Mark Cave-Ayland mark.cave-ayland@siriusit.co.uk wrote:
Igor V. Kovalenko wrote:
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!
AIUI this is an alternative approach to the one suggested by Blue; instead of moving the PCI memory space into high memory, we simply mark the appropriate regions as being in use.
Yes, though some of this may be useful even if the memory space was in high memory.
I'm currently unsure as to how much work is required for Blue's patches to add the required functionality to Qemu; so should we temporarily apply this patch set to allow further development work or continue to work from the Qemu side instead?
It may be trivial (just invent the correct way to add the memory base to BAR address) but in the worst case it may involve changes to all PCI devices in QEMU and some changes to OpenBIOS PCI code as well.
Regardless of which approach we choose, I am encouraged that the Milax loader gets further :)
We could choose both, apply the patches now and when QEMU is fixed, revert some of them.
On Sun, Dec 27, 2009 at 8:59 PM, Mark Cave-Ayland mark.cave-ayland@siriusit.co.uk wrote:
Igor V. Kovalenko wrote:
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!
AIUI this is an alternative approach to the one suggested by Blue; instead of moving the PCI memory space into high memory, we simply mark the appropriate regions as being in use. I'm currently unsure as to how much work is required for Blue's patches to add the required functionality to Qemu; so should we temporarily apply this patch set to allow further development work or continue to work from the Qemu side instead?
Regardless of which approach we choose, I am encouraged that the Milax loader gets further :)
That's the intention here, to progress on forth loader while qemu part is on it's way.
On Sun, Dec 27, 2009 at 6:21 PM, Igor Kovalenko igor.v.kovalenko@gmail.com wrote:
On Sun, Dec 27, 2009 at 8:59 PM, Mark Cave-Ayland mark.cave-ayland@siriusit.co.uk wrote:
Igor V. Kovalenko wrote:
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!
AIUI this is an alternative approach to the one suggested by Blue; instead of moving the PCI memory space into high memory, we simply mark the appropriate regions as being in use. I'm currently unsure as to how much work is required for Blue's patches to add the required functionality to Qemu; so should we temporarily apply this patch set to allow further development work or continue to work from the Qemu side instead?
Regardless of which approach we choose, I am encouraged that the Milax loader gets further :)
That's the intention here, to progress on forth loader while qemu part is on it's way.
I made some progress on that side, now everything works pretty much as before until kernel gets loaded, at which point there is a crash. But I think the devices are now mapped at the correct location.
Igor V. Kovalenko wrote:
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!
Igor/Blue,
Well done on the progress you've both made on this. I've just updated to latest git/SVN and I now get the same error above when trying to boot Milax.
Some initial prodding shows that the ramdisk has an Fcode payload that gets executed to create a new /ramdisk-root node in the device tree. However for reasons currently unknown, the methods contained within the ramdisk Fcode aren't being created under the /ramdisk-root node which is why boot fails.
Since this section of code is surrounded by a push-package/pop-package pair, I'm beginning to wonder if I've missed some subtlety related to wordlists in my implementation which causes the new words to be defined in the wrong place...
ATB,
Mark.
-
Andreas Färber -
Blue Swirl -
Igor Kovalenko -
Igor V. Kovalenko
-
Mark Cave-Ayland