Hi folks,
I've been trying to use OpenBIOS with QEMU, and I've had trouble
getting it to boot any PowerPC-based OS discs (Linux, Mac OS X, etc).
OpenBIOS just doesn't seem to find anything bootable. If I try booting
QEMU with -nographic, I get this output (I get the same with a
self-built openbios-qemu.elf from the OpenBIOS SVN as well):
---- snip ----
>> =============================================================
>> OpenBIOS 1.0 [Apr 12 2009 00:55]
>> Configuration device id QEMU version 1 machine id 1
>> CPUs: 1
>> Memory: 128M
>> UUID: 00000000-0000-0000-0000-000000000000
>> CPU type PowerPC,970FX
Welcome to OpenBIOS v1.0 built on Apr 12 2009 00:55
>> ELF - yaboot_startup: Entering boot, no path
>> ELF - try_bootinfo: Trying hd:0,ppc\bootinfo.txt
>> ELF - try_bootinfo: Can't open hd:0,ppc\bootinfo.txt
>> ELF - try_path: Trying hd:2,\ofclient
>> ELF - try_path: Can't open hd:2,\ofclient
>> ELF - try_path: Trying hd:2,\yaboot conf=hd:2,\yaboot.conf
>> ELF - try_path: Can't open hd:2,\yaboot
>> *** Boot failure! No secondary bootloader specified ***
---- snip ----
Laurent Vivier suggested in this conversation in February
(http://lists.openbios.org/pipermail/openbios/2009-February/003476.html)
that there could be a bug in partition map decoding. Has such a bug
been confirmed? I was trying to find the bug myself (I am an
experienced C/C++ programmer), but the bug seems to be subtle, and my
lack of familiarity with the code base doesn't help much.
I've been trying to figure this out for 7 hours straight now... Any
advice or other help would be much appreciated!
- Steven
Using this patch stacked on Steven Noonan's I was able to make BootX from
Mac OS X 10.4 load XNU successfully in qemu-system-ppc.
Unfortunately, most of this patch is nothing but a mere hack to find out
what we really need to get this working.
Also I didn't manage to get anything but 10.4 running. Other versions broke
in the partition table interpretation.
I would not feel good taking the patch as is, because it would be better to
implement the correct Forth magic to make the real callbacks work. Here is
what I found to be broken:
- unselect-dev is missing
- local variables don't work ({ ... })
- I ran into an endless loop, getting isi and dsi faults on the same 2
addresses all the time
Also, Qemu's only usable Desktop PPC target is a G3 Beige which is only
supported up to 10.2.8 IIRC. So even getting the bootloader running for
10.4 didn't exactly buy me much.
Don't apply the patch as is!
It'd be great to see someone build on this!
---
arch/ppc/qemu/ofmem.c | 4 ++--
modules/client.c | 40 ++++++++++++++++++++++++++++++++++++++++
2 files changed, 42 insertions(+), 2 deletions(-)
diff --git a/arch/ppc/qemu/ofmem.c b/arch/ppc/qemu/ofmem.c
index a1a8fb1..32642e2 100644
--- a/arch/ppc/qemu/ofmem.c
+++ b/arch/ppc/qemu/ofmem.c
@@ -716,8 +716,8 @@ hash_page_32( ulong ea, ulong phys, int mode )
/* out of slots, just evict one */
if( !found ) {
- i = next_grab_slot + 1;
- next_grab_slot = (next_grab_slot + 1) % 8;
+ i = next_grab_slot + 3;
+ next_grab_slot = (next_grab_slot + 3) % 8;
}
i--;
upte[i*2] = cmp;
diff --git a/modules/client.c b/modules/client.c
index a2e8405..a8c89ff 100644
--- a/modules/client.c
+++ b/modules/client.c
@@ -49,6 +49,46 @@ handle_calls( prom_args_t *pb )
pb->nargs, pb->nret);
#endif
+#if 1
+ if (!strcmp(pb->service, "interpret"))
+ {
+ char *ns;
+
+ ns = strstr((char*)pb->args[0], "{ ; dpth }");
+ if (ns) return 0;
+
+ ns = strstr((char*)pb->args[0], "dev /chosen ");
+ if (ns) memcpy(ns, " \" /chosen\"", 11);
+ }
+ else if (!strcmp(pb->service, "call-method"))
+ {
+ if (!strncmp((char*)pb->args[0], "slw_init_keymap", 15)) {
+
+ char *a = (char*)malloc(20);
+ memset(a, 0x00, 20);
+ pb->args[4] = (uint32_t)a;
+ pb->args[3] = 0;
+
+ return 0;
+ }
+ if (!strncmp((char*)pb->args[0], "slw_emit", strlen("slw_emit"))) {
+ PUSH( (char)pb->args[2] );
+ fword("emit");
+
+ return 0;
+ }
+ if (!strncmp((char*)pb->args[0], "slw_cr", strlen("slw_cr"))) {
+ PUSH( '\n' );
+ fword("emit");
+ return 0;
+ }
+ if (!strncmp((char*)pb->args[0], "slw_update_keymap", strlen("slw_update_keymap"))) return 0;
+ if (!strncmp((char*)pb->args[0], "slw_set_output_level", strlen("slw_set_output_level"))) return 0;
+ if (!strncmp((char*)pb->args[0], "slw_spin_init", strlen("slw_spin_init"))) return 0;
+ if (!strncmp((char*)pb->args[0], "slw_spin", strlen("slw_spin"))) return 0;
+ }
+#endif
+
for( i=pb->nargs-1; i>=0; i-- )
PUSH( pb->args[i] );
--
1.6.0.2
Hi!
This patch series implement OF memory manager.
I used arch/ppc/qemu/ofmem.c as a starting point,
future plans in ofmem area would be to migrate common
parts from working implementations (ppc and sparc64)
into shared module.
Since ofmem declarations are to be used by different
architectures it appears that using ucell type in
ofmem.h is appropriate. This required changes to
ppc/qemu code. Unfortunately mol, briq and pearpc
configurations does not build in my setup so I did not
touched those parts, and this change may be incomplete.
It seems useful to introduce CONFIG_OFMEM_OPTION to
conditionally trace ofmem operations, so this is
implemented as well. Also I introduce FMT_cell and other
macros to help formatting log messages easily.
Client interface handler now uses ofmem implementation
instead of walking hardware translation tables. Since setup
code in entry.S does install it's own translations ofmem
initialization routine simply copies entries from hardware.
Properties "available" and "translations" are then populated
as needed.
This implementation passes boot test with no visible changes
on screen for HelenOS-0.4.0-sparc64.iso
Linux boot does not improve with this patch due to conflicts
with memory mappings in low memory region. Also there is
an issue with lazy conditional codes evaluation by qemu.
If disrupting trap is taken before conditional branch is
executed then upon return from trap conditional codes are not
evaluated correctly. Visible effect is that with this patch
series silo is no longer gets into second stage, stopping at
SIL output. Patch for this issue is already posted
to qemu-devel mailing list.
Signed-off-by: igor.v.kovalenko(a)gmail.com
--
Kind regards,
Igor V. Kovalenko
Hi!
This patch series implements OF memory manager.
I used arch/ppc/qemu/ofmem.c as a starting point,
future plans in ofmem area would be to migrate common
parts from working implementations (ppc and sparc64)
into shared ofmem module.
I decided to switch ofmem.h declarations to use ucell
type while passing arguments so ofmem declarations
can be used by all architectures.
Client interface handler now uses ofmem implementation
instead of walking hardware translation tables. Since setup
code in entry.S does install it's own translations ofmem
initialization routine simply copies entries from hardware.
Properties "available" and "translations" are then populated
as needed.
This implementation passes boot test with no visible changes
on screen for HelenOS-0.4.0-sparc64.iso
Linux boot does not really improve this time due to
conflicts with memory mappings in low memory region.
Also there is a problem in qemu with evaluation of conditional
codes in case disrupting trap is taken before conditional
branch is executed. This precludes silo second-stage code from
working. Patch fixing that is posted to qemu-devel list.
Signed-off-by: igor.v.kovalenko(a)gmail.com
--
Kind regards,
Igor V. Kovalenko
Hi all,
Over the past few weeks, I've been experimenting with different
approaches to allow me to break and single-step through certain code
sections to help me debug issues with Sparc64. Sadly, after a reasonable
amount of experimentation, I haven't managed to come up with anything
that works 100% per specification and so thought I'd ask the list to see
if there are any better ideas.
My aim has been to implement a subset of the OF spec 7.5.3.4 "Forth
source-level debugger" commands to enable me to step through various
code sections.
The main problem I have at the moment is that there doesn't seem to be
an easy way to determine which word is currently being executed in order
to decide whether to execute the word normally or single step through it.
The nearest I have managed so far is to append a debug marker to the
return stack indicating whether words executed in the current stack
frame should executed normally or single-stepped. This works for the
majority of words, except for those which push/pop items from the return
stack during execution - as soon as the return stack is popped, the
marker is lost and so debug disappears part way through a word :(
Can anyone else come up with a better idea of implementing this so that
it can work with words that modify the return stack?
ATB,
Mark.
--
Mark Cave-Ayland - Senior Technical Architect
PostgreSQL - PostGIS
Sirius Corporation plc - control through freedom
http://www.siriusit.co.uk
t: +44 870 608 0063
