I/O offsets were wrong in legacy mode and some were missing in non-legacy mode. This fixes serial port detection in NetBSD, which was ignoring it. This also partly fixes MacOS 9.2, which relies on them to initialize OpenTransport.
Signed-off-by: Hervé Poussineau hpoussin@reactos.org --- drivers/escc.c | 22 ++++++++++++---------- 1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/escc.c b/drivers/escc.c index afb97fa..8f122d8 100644 --- a/drivers/escc.c +++ b/drivers/escc.c @@ -384,6 +384,8 @@ escc_add_channel(const char *path, const char *node, phys_addr_t addr, { char buf[64], tty[32]; phandle_t dnode, aliases; + int legacy_offsets[][3] = { { 0x4, 0x6, 0xa }, { 0x0, 0x2, 0x8 } }; + int offsets[][3] = { { 0x20, 0x30, 0x50 }, { 0x00, 0x10, 0x40 } };
cell props[10]; int offset; @@ -425,18 +427,18 @@ escc_add_channel(const char *path, const char *node, phys_addr_t addr, set_property(dnode, "compatible", buf, 9);
if (legacy) { - props[0] = IO_ESCC_LEGACY_OFFSET + offset * 0x4; - props[1] = 0x00000001; - props[2] = IO_ESCC_LEGACY_OFFSET + offset * 0x4 + 2; - props[3] = 0x00000001; - props[4] = IO_ESCC_LEGACY_OFFSET + offset * 0x4 + 6; - props[5] = 0x00000001; - set_property(dnode, "reg", (char *)&props, 6 * sizeof(cell)); + props[0] = IO_ESCC_LEGACY_OFFSET + legacy_offsets[offset][0]; + props[2] = IO_ESCC_LEGACY_OFFSET + legacy_offsets[offset][1]; + props[4] = IO_ESCC_LEGACY_OFFSET + legacy_offsets[offset][2]; } else { - props[0] = IO_ESCC_OFFSET + offset * 0x20; - props[1] = 0x00000020; - set_property(dnode, "reg", (char *)&props, 2 * sizeof(cell)); + props[0] = IO_ESCC_LEGACY_OFFSET + offsets[offset][0]; + props[2] = IO_ESCC_LEGACY_OFFSET + offsets[offset][1]; + props[4] = IO_ESCC_LEGACY_OFFSET + offsets[offset][2]; } + props[1] = 0x00000001; + props[3] = 0x00000001; + props[5] = 0x00000001; + set_property(dnode, "reg", (char *)&props, 6 * sizeof(cell));
if (legacy) { props[0] = addr + IO_ESCC_LEGACY_OFFSET + offset * 0x4;
On Feb 3, 2016, at 1:29 AM, Hervé Poussineau wrote:
I/O offsets were wrong in legacy mode and some were missing in non-legacy mode. This fixes serial port detection in NetBSD, which was ignoring it. This also partly fixes MacOS 9.2, which relies on them to initialize OpenTransport.
Signed-off-by: Hervé Poussineau hpoussin@reactos.org
drivers/escc.c | 22 ++++++++++++---------- 1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/escc.c b/drivers/escc.c index afb97fa..8f122d8 100644 --- a/drivers/escc.c +++ b/drivers/escc.c @@ -384,6 +384,8 @@ escc_add_channel(const char *path, const char *node, phys_addr_t addr, { char buf[64], tty[32]; phandle_t dnode, aliases;
int legacy_offsets[][3] = { { 0x4, 0x6, 0xa }, { 0x0, 0x2, 0x8 } };
int offsets[][3] = { { 0x20, 0x30, 0x50 }, { 0x00, 0x10, 0x40 } };
cell props[10]; int offset;
@@ -425,18 +427,18 @@ escc_add_channel(const char *path, const char *node, phys_addr_t addr, set_property(dnode, "compatible", buf, 9);
if (legacy) {
props[0] = IO_ESCC_LEGACY_OFFSET + offset * 0x4;
props[1] = 0x00000001;
props[2] = IO_ESCC_LEGACY_OFFSET + offset * 0x4 + 2;
props[3] = 0x00000001;
props[4] = IO_ESCC_LEGACY_OFFSET + offset * 0x4 + 6;
props[5] = 0x00000001;
set_property(dnode, "reg", (char *)&props, 6 * sizeof(cell));
props[0] = IO_ESCC_LEGACY_OFFSET + legacy_offsets[offset][0];
props[2] = IO_ESCC_LEGACY_OFFSET + legacy_offsets[offset][1];
} else {props[4] = IO_ESCC_LEGACY_OFFSET + legacy_offsets[offset][2];
props[0] = IO_ESCC_OFFSET + offset * 0x20;
props[1] = 0x00000020;
set_property(dnode, "reg", (char *)&props, 2 * sizeof(cell));
props[0] = IO_ESCC_LEGACY_OFFSET + offsets[offset][0];
props[2] = IO_ESCC_LEGACY_OFFSET + offsets[offset][1];
props[4] = IO_ESCC_LEGACY_OFFSET + offsets[offset][2];
}
props[1] = 0x00000001;
props[3] = 0x00000001;
props[5] = 0x00000001;
set_property(dnode, "reg", (char *)&props, 6 * sizeof(cell));
if (legacy) { props[0] = addr + IO_ESCC_LEGACY_OFFSET + offset * 0x4;
-- 2.1.4
I didn't notice anything different when I tried booting Mac OS 9.2 with and without your patch. Mac OS 9.2 always crashes on startup for me. What changes did you notice while using Mac OS 9 with your patch?
On Feb 3, 2016, at 2:12 PM, Hervé Poussineau wrote:
Le 03/02/2016 18:00, Programmingkid a écrit :
On Feb 3, 2016, at 1:29 AM, Hervé Poussineau wrote:
I/O offsets were wrong in legacy mode and some were missing in non-legacy mode. This fixes serial port detection in NetBSD, which was ignoring it. This also partly fixes MacOS 9.2, which relies on them to initialize OpenTransport.
Signed-off-by: Hervé Poussineau hpoussin@reactos.org
drivers/escc.c | 22 ++++++++++++---------- 1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/escc.c b/drivers/escc.c index afb97fa..8f122d8 100644 --- a/drivers/escc.c +++ b/drivers/escc.c @@ -384,6 +384,8 @@ escc_add_channel(const char *path, const char *node, phys_addr_t addr, { char buf[64], tty[32]; phandle_t dnode, aliases;
int legacy_offsets[][3] = { { 0x4, 0x6, 0xa }, { 0x0, 0x2, 0x8 } };
int offsets[][3] = { { 0x20, 0x30, 0x50 }, { 0x00, 0x10, 0x40 } };
cell props[10]; int offset;
@@ -425,18 +427,18 @@ escc_add_channel(const char *path, const char *node, phys_addr_t addr, set_property(dnode, "compatible", buf, 9);
if (legacy) {
props[0] = IO_ESCC_LEGACY_OFFSET + offset * 0x4;
props[1] = 0x00000001;
props[2] = IO_ESCC_LEGACY_OFFSET + offset * 0x4 + 2;
props[3] = 0x00000001;
props[4] = IO_ESCC_LEGACY_OFFSET + offset * 0x4 + 6;
props[5] = 0x00000001;
set_property(dnode, "reg", (char *)&props, 6 * sizeof(cell));
props[0] = IO_ESCC_LEGACY_OFFSET + legacy_offsets[offset][0];
props[2] = IO_ESCC_LEGACY_OFFSET + legacy_offsets[offset][1];
} else {props[4] = IO_ESCC_LEGACY_OFFSET + legacy_offsets[offset][2];
props[0] = IO_ESCC_OFFSET + offset * 0x20;
props[1] = 0x00000020;
set_property(dnode, "reg", (char *)&props, 2 * sizeof(cell));
props[0] = IO_ESCC_LEGACY_OFFSET + offsets[offset][0];
props[2] = IO_ESCC_LEGACY_OFFSET + offsets[offset][1];
props[4] = IO_ESCC_LEGACY_OFFSET + offsets[offset][2];
}
props[1] = 0x00000001;
props[3] = 0x00000001;
props[5] = 0x00000001;
set_property(dnode, "reg", (char *)&props, 6 * sizeof(cell));
if (legacy) { props[0] = addr + IO_ESCC_LEGACY_OFFSET + offset * 0x4;
-- 2.1.4
I didn't notice anything different when I tried booting Mac OS 9.2 with and without your patch. Mac OS 9.2 always crashes on startup for me. What changes did you notice while using Mac OS 9 with your patch?
Using QEMU master (87574621b18f86eab295a2c207e0b42c77b5dfa0), with unmodified Mac OS 9.2 ISO.
- With OpenBIOS r1377 + CR/LF patch
MacOS 9.2 load screen is shown, then you have the rotating icon on the top left of the screen, and then QEMU crashes Console contains Trying to write invalid spr 0 (0x000) at 00f113c0 Trying to read invalid spr 0 (0x000) at 00f113c8 invalid/unsupported opcode: 1f - 07 - 02 (7c00488e) 00f113dc 0 invalid/unsupported opcode: 1f - 07 - 06 (7c00498e) 00f113e4 0 Trying to write privileged spr 955 (0x3bb) at 00f168c8 Trying to write invalid spr 959 (0x3bf) at 00f16930 Trying to read invalid spr 959 (0x3bf) at 00f16938 Trying to write invalid spr 944 (0x3b0) at 00f1694c Trying to read invalid spr 944 (0x3b0) at 00f16954 Trying to write invalid spr 951 (0x3b7) at 00f16960 Trying to read invalid spr 951 (0x3b7) at 00f16968 Trying to write privileged spr 955 (0x3bb) at 00f168c8 Trying to write invalid spr 959 (0x3bf) at 00f16930 Trying to read invalid spr 959 (0x3bf) at 00f16938 Trying to write invalid spr 944 (0x3b0) at 00f1694c Trying to read invalid spr 944 (0x3b0) at 00f16954 Trying to write invalid spr 951 (0x3b7) at 00f16960 Trying to read invalid spr 951 (0x3b7) at 00f16968 invalid/unsupported opcode: 13 - 0a - 05 (4f434154) 009e1d10 1 invalid/unsupported opcode: 00 - 00 - 00 (00c10000) 00000000 1 invalid/unsupported opcode: 00 - 00 - 00 (00c10000) 00000000 1 invalid/unsupported opcode: 00 - 00 - 00 (00000000) 008c0f14 1 invalid/unsupported opcode: 00 - 00 - 00 (00000000) 0421b81c 1 qemu: fatal: Trying to execute code outside RAM or ROM at 0xfdfdfdfc
NIP fdfdfdfc LR fdfdfdfd CTR ffcf0dcc XER 20000100 CPU#0 MSR 0000f032 HID0 00810000 HF 00006000 idx 0 TB 00000000 1615152802 DECR 00059059 GPR00 00000000fdfdfdfd 00000000ffe55000 000000000004d280 00000000ffffffff GPR04 00000000ffffffff 00000000ffffffff 00000000f2ffc048 00000000f4ffc048 GPR08 0000000000ffc048 00000000f0ffc048 00000000ffffffff 00000000f6ffc048 GPR12 00000000fcffc048 0000000068fff400 0000000000004e94 000000000bb957ea GPR16 000000003f3f3f3f 0000000000000001 0000000053680000 0000000000000000 GPR20 0000000000000001 0000000000000005 000000000bb8d12c 0000000000006807 GPR24 000000000004ccf0 000000000bb8d130 0000000000084d38 00000000009d0eb8 GPR28 0000000000084d38 00000000ffffffff 00000000fdfdfdfd 000000000000fdfd CR 82220482 [ L E E E - G L E ] RES ffffffff FPR00 0000000082004000 41d2cac6a8000000 0000000000000000 41d2cac6a8000000 FPR04 41d2cac6a8000000 bfd549b141dea8e2 bf880033ba736cfd 3fefffd039962f40 FPR08 3faaf497f23bd4ec 4230000000000000 0000000082004000 4330000017d6dc13 FPR12 3f847b718aeb3db1 ffffffffff3f8c5c 0000000000000000 0000000000000000 FPR16 0000000000000000 0000000000000000 0000000000000000 0000000000000000 FPR20 0000000000000000 0000000000000000 0000000000000000 0000000000000000 FPR24 0000000000000000 0000000000000000 0000000000000000 0000000000000000 FPR28 0000000000000000 0000000000000000 0000000000000000 0000000000000000 FPSCR 82004000 SRR0 fdfdfdfc SRR1 4000f032 PVR 00080301 VRSAVE 00000000 SPRG0 0fbfe000 SPRG1 ffe55000 SPRG2 fdfdfdfd SPRG3 0fbfe420 SPRG4 00000000 SPRG5 00000000 SPRG6 00000000 SPRG7 00000000 SDR1 0fc0001f DAR ffe54fd8 DSISR 0a000000 Aborted
- With OpenBIOS r1377 + CR/LF patch + my patch
MacOS 9.2 load screen is shown, OpenTransport icon is displayed at the bottom left on the screen, and there is an message box with "illegal instruction". Console contains Trying to write invalid spr 0 (0x000) at 00f113c0 Trying to read invalid spr 0 (0x000) at 00f113c8 invalid/unsupported opcode: 1f - 07 - 02 (7c00488e) 00f113dc 0 invalid/unsupported opcode: 1f - 07 - 06 (7c00498e) 00f113e4 0 Trying to write privileged spr 955 (0x3bb) at 00f168c8 Trying to write invalid spr 959 (0x3bf) at 00f16930 Trying to read invalid spr 959 (0x3bf) at 00f16938 Trying to write invalid spr 944 (0x3b0) at 00f1694c Trying to read invalid spr 944 (0x3b0) at 00f16954 Trying to write invalid spr 951 (0x3b7) at 00f16960 Trying to read invalid spr 951 (0x3b7) at 00f16968 Trying to write privileged spr 955 (0x3bb) at 00f168c8 Trying to write invalid spr 959 (0x3bf) at 00f16930 Trying to read invalid spr 959 (0x3bf) at 00f16938 Trying to write invalid spr 944 (0x3b0) at 00f1694c Trying to read invalid spr 944 (0x3b0) at 00f16954 Trying to write invalid spr 951 (0x3b7) at 00f16960 Trying to read invalid spr 951 (0x3b7) at 00f16968 invalid/unsupported opcode: 00 - 00 - 00 (00c10000) 00000000 1
Is it possible the invalid/unsupported opcode errors are PowerPC instructions that are not implemented? Or do you think the processor is executing memory it should not be executing? The message "qemu: fatal: Trying to execute code outside RAM or ROM at 0xfdfdfdfc", was it shown when you used your patch? If it was then there is some kind of address calculation error possibly taking place.
On Wed, Feb 03, 2016 at 03:36:52PM -0500, Programmingkid wrote:
Is it possible the invalid/unsupported opcode errors are PowerPC instructions that are not implemented? Or do you think the processor is executing memory it should not be executing? The message "qemu: fatal: Trying to execute code outside RAM or ROM at 0xfdfdfdfc", was it shown when you used your patch? If it was then there is some kind of address calculation error possibly taking place.
There's some kind of weird memory corruption going on during the Mac OS 9 boot for me, and making small changes (even changing the available RAM) makes things behave differently. A jump to some arbitrary address (often NULL) is a pretty common result, and annoyingly at that point no amount of hunting around with MacsBug seems to let me work out what's going on. Maybe the crash here is/was another instance of this?
Usually I manage to get through the whole boot process and then it crashes after the menu bar has appeared inside something like the Control Strip code. Sometimes it even boots. It makes it pretty frustrating to debug though, since you can't just randomly remove resources (e.g. patches) and check whether that fixed it or not. Maybe I'm doing something really stupid though, so I'll post this in this thread and see if anyone has suggestions..!
- Alyssa
On Feb 3, 2016, at 3:58 PM, Alyssa Milburn wrote:
On Wed, Feb 03, 2016 at 03:36:52PM -0500, Programmingkid wrote:
Is it possible the invalid/unsupported opcode errors are PowerPC instructions that are not implemented? Or do you think the processor is executing memory it should not be executing? The message "qemu: fatal: Trying to execute code outside RAM or ROM at 0xfdfdfdfc", was it shown when you used your patch? If it was then there is some kind of address calculation error possibly taking place.
There's some kind of weird memory corruption going on during the Mac OS 9 boot for me, and making small changes (even changing the available RAM) makes things behave differently. A jump to some arbitrary address (often NULL) is a pretty common result, and annoyingly at that point no amount of hunting around with MacsBug seems to let me work out what's going on. Maybe the crash here is/was another instance of this?
Usually I manage to get through the whole boot process and then it crashes after the menu bar has appeared inside something like the Control Strip code. Sometimes it even boots. It makes it pretty frustrating to debug though, since you can't just randomly remove resources (e.g. patches) and check whether that fixed it or not. Maybe I'm doing something really stupid though, so I'll post this in this thread and see if anyone has suggestions..!
There has to be an easier way. Things would be a lot easier if Apple released the source code to Mac OS 9. What I have been doing is improving how Mac OS X behaves in QEMU and hoping my patches also help Mac OS 9. It looks like a lot of programs rely on The OTUtilityLib to operate. When it is gone a lot of good programs go with it. So I currently can't test out if the RTL8139 NIC actually works in Mac OS 9 yet.
On 03/02/16 06:29, Hervé Poussineau wrote:
I/O offsets were wrong in legacy mode and some were missing in non-legacy mode. This fixes serial port detection in NetBSD, which was ignoring it. This also partly fixes MacOS 9.2, which relies on them to initialize OpenTransport.
Signed-off-by: Hervé Poussineau hpoussin@reactos.org
drivers/escc.c | 22 ++++++++++++---------- 1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/escc.c b/drivers/escc.c index afb97fa..8f122d8 100644 --- a/drivers/escc.c +++ b/drivers/escc.c @@ -384,6 +384,8 @@ escc_add_channel(const char *path, const char *node, phys_addr_t addr, { char buf[64], tty[32]; phandle_t dnode, aliases;
int legacy_offsets[][3] = { { 0x4, 0x6, 0xa }, { 0x0, 0x2, 0x8 } };
int offsets[][3] = { { 0x20, 0x30, 0x50 }, { 0x00, 0x10, 0x40 } };
cell props[10]; int offset;
@@ -425,18 +427,18 @@ escc_add_channel(const char *path, const char *node, phys_addr_t addr, set_property(dnode, "compatible", buf, 9);
if (legacy) {
props[0] = IO_ESCC_LEGACY_OFFSET + offset * 0x4;
props[1] = 0x00000001;
props[2] = IO_ESCC_LEGACY_OFFSET + offset * 0x4 + 2;
props[3] = 0x00000001;
props[4] = IO_ESCC_LEGACY_OFFSET + offset * 0x4 + 6;
props[5] = 0x00000001;
set_property(dnode, "reg", (char *)&props, 6 * sizeof(cell));
props[0] = IO_ESCC_LEGACY_OFFSET + legacy_offsets[offset][0];
props[2] = IO_ESCC_LEGACY_OFFSET + legacy_offsets[offset][1];
} else {props[4] = IO_ESCC_LEGACY_OFFSET + legacy_offsets[offset][2];
props[0] = IO_ESCC_OFFSET + offset * 0x20;
props[1] = 0x00000020;
set_property(dnode, "reg", (char *)&props, 2 * sizeof(cell));
props[0] = IO_ESCC_LEGACY_OFFSET + offsets[offset][0];
props[2] = IO_ESCC_LEGACY_OFFSET + offsets[offset][1];
props[4] = IO_ESCC_LEGACY_OFFSET + offsets[offset][2];
}
props[1] = 0x00000001;
props[3] = 0x00000001;
props[5] = 0x00000001;
set_property(dnode, "reg", (char *)&props, 6 * sizeof(cell));
if (legacy) { props[0] = addr + IO_ESCC_LEGACY_OFFSET + offset * 0x4;
Good catch! I've just compared this with an G4 AGP device tree and it does look right - not quite sure how I missed this first time around.
My two comments would be if possible can we just use a single array with another subscript, and also can we move the odd numbered properties back inline so we have something like this:
int offsets[2][2][3] = { { /* legacy ch-b, legacy ch-a */ { 0x4, 0x6, 0xa }, { 0x0, 0x2, 0x8 } }, { /* ch-b, ch-a */ { 0x20, 0x30, 0x50 }, { 0x00, 0x10, 0x40 } } };
and then the loop just becomes:
props[0] = IO_ESCC_LEGACY_OFFSET + offsets[legacy][offset][0]; props[1] = 0x00000001; props[2] = IO_ESCC_LEGACY_OFFSET + offsets[legacy][offset][1]; props[3] = 0x00000001; props[4] = IO_ESCC_LEGACY_OFFSET + offsets[legacy][offset][2]; props[5] = 0x00000001;
Also perhaps it is also worth renaming offset to idx or similar for clarity?
I've just done a quick test on OS 9 and on the plus side I don't get a crash into MacsBug, but I get a long hang followed by the mouse cursor turning into a bomb - but at least that's progress :) If you can resubmit a new version, I'll give it a quick spin around a few other OSs to make sure there are no regressions.
Note that currently we don't add the DBDMA properties at the end of the reg property because QEMU doesn't yet support serial DBDMA, but perhaps it is time to start turning on DBDMA logging to see if this is what's is causing OT to get stuck.
In fact, do we know if OT ever worked on MOL at all or did it provide its own drivers?
ATB,
Mark.
On 03/02/16 20:58, Alyssa Milburn wrote:
On Wed, Feb 03, 2016 at 03:36:52PM -0500, Programmingkid wrote:
Is it possible the invalid/unsupported opcode errors are PowerPC instructions that are not implemented? Or do you think the processor is executing memory it should not be executing? The message "qemu: fatal: Trying to execute code outside RAM or ROM at 0xfdfdfdfc", was it shown when you used your patch? If it was then there is some kind of address calculation error possibly taking place.
There's some kind of weird memory corruption going on during the Mac OS 9 boot for me, and making small changes (even changing the available RAM) makes things behave differently. A jump to some arbitrary address (often NULL) is a pretty common result, and annoyingly at that point no amount of hunting around with MacsBug seems to let me work out what's going on. Maybe the crash here is/was another instance of this?
Usually I manage to get through the whole boot process and then it crashes after the menu bar has appeared inside something like the Control Strip code. Sometimes it even boots. It makes it pretty frustrating to debug though, since you can't just randomly remove resources (e.g. patches) and check whether that fixed it or not. Maybe I'm doing something really stupid though, so I'll post this in this thread and see if anyone has suggestions..!
It seems that there are about 3 or 4 extensions on a vanilla 9.2.2 ISO that will crash QEMU. Currently I've taken the hfsplus ISO, mounted it, and removed all extensions except for OT and OT ASLM modules to ensure that any crashes I get are only caused by OT and not one of the other extensions that tends to break QEMU, e.g. MultiProcessing.
But yes, as you point out this is necessary because extensions tend to load in an asynchronous and non-deterministic manner in OS 9 under QEMU...
ATB,
Mark.
On Wed, Feb 03, 2016 at 03:36:52PM -0500, Programmingkid wrote:
Trying to write invalid spr 0 (0x000) at 00f113c0 Trying to read invalid spr 0 (0x000) at 00f113c8
This is normal (it's a 601 SPR, Mac OS always writes that, and it catches the CPU exception).
invalid/unsupported opcode: 1f - 07 - 02 (7c00488e) 00f113dc 0 invalid/unsupported opcode: 1f - 07 - 06 (7c00498e) 00f113e4 0
lvewx and stvewx, VMX insns, same thing.
Trying to write privileged spr 955 (0x3bb) at 00f168c8
SIAR
Trying to write invalid spr 959 (0x3bf) at 00f16930 Trying to read invalid spr 959 (0x3bf) at 00f16938
SDAR
Trying to write invalid spr 944 (0x3b0) at 00f1694c Trying to read invalid spr 944 (0x3b0) at 00f16954
MMCR2
etc. Don't worry about it.
invalid/unsupported opcode: 13 - 0a - 05 (4f434154) 009e1d10 1
'OCAT', now that is broken.
invalid/unsupported opcode: 00 - 00 - 00 (00c10000) 00000000 1 invalid/unsupported opcode: 00 - 00 - 00 (00c10000) 00000000 1 invalid/unsupported opcode: 00 - 00 - 00 (00000000) 008c0f14 1 invalid/unsupported opcode: 00 - 00 - 00 (00000000) 0421b81c 1
Primary opcode 0 is always invalid.
qemu: fatal: Trying to execute code outside RAM or ROM at 0xfdfdfdfc
NIP fdfdfdfc LR fdfdfdfd CTR ffcf0dcc XER 20000100 CPU#0
LR fdfdfdfd is not likely valid ;-) (the low two bits are masked when trying to actually jump there, as it did, so you get fdfdfdfc).
MSR 0000f032 HID0 00810000 HF 00006000 idx 0 TB 00000000 1615152802 DECR 00059059 GPR00 00000000fdfdfdfd 00000000ffe55000 000000000004d280 00000000ffffffff
It got it from r0, so probably from the usual epilogue sequence; looks like a corrupted stack.
GPR04 00000000ffffffff 00000000ffffffff 00000000f2ffc048 00000000f4ffc048 GPR08 0000000000ffc048 00000000f0ffc048 00000000ffffffff 00000000f6ffc048 GPR12 00000000fcffc048 0000000068fff400 0000000000004e94 000000000bb957ea GPR16 000000003f3f3f3f 0000000000000001 0000000053680000 0000000000000000 GPR20 0000000000000001 0000000000000005 000000000bb8d12c 0000000000006807 GPR24 000000000004ccf0 000000000bb8d130 0000000000084d38 00000000009d0eb8 GPR28 0000000000084d38 00000000ffffffff 00000000fdfdfdfd 000000000000fdfd
It is also in r30.
SRR0 fdfdfdfc SRR1 4000f032 PVR 00080301 VRSAVE 00000000 SPRG0 0fbfe000 SPRG1 ffe55000 SPRG2 fdfdfdfd SPRG3 0fbfe420
And in sprg2.
Is it possible the invalid/unsupported opcode errors are PowerPC instructions that are not implemented? Or do you think the processor is executing memory it should not be executing? The message "qemu: fatal: Trying to execute code outside RAM or ROM at 0xfdfdfdfc", was it shown when you used your patch? If it was then there is some kind of address calculation error possibly taking place.
Segher
On Wed, Feb 03, 2016 at 08:01:36PM -0500, Programmingkid wrote:
On Feb 3, 2016, at 7:40 PM, Segher Boessenkool wrote:
invalid/unsupported opcode: 13 - 0a - 05 (4f434154) 009e1d10 1
'OCAT', now that is broken.
What is OCAT?
4f434154 is. Character constant 'OCAT', maybe a fourcc, or a part of a string.
Segher
On Feb 4, 2016, at 6:11 AM, Segher Boessenkool wrote:
On Wed, Feb 03, 2016 at 08:01:36PM -0500, Programmingkid wrote:
On Feb 3, 2016, at 7:40 PM, Segher Boessenkool wrote:
invalid/unsupported opcode: 13 - 0a - 05 (4f434154) 009e1d10 1
'OCAT', now that is broken.
What is OCAT?
4f434154 is. Character constant 'OCAT', maybe a fourcc, or a part of a string.
Would you have a link to any documentation about this OCAT? If OCAT is just a string, then it shouldn't be executing as an opcode, right?
On Thu, Feb 04, 2016 at 08:26:40AM -0500, Programmingkid wrote:
If OCAT is just a string, then it shouldn't be executing as an opcode, right?
Exactly, i.e. this is probably some kind of memory corruption (or the stack pointer pointing into the ROM or whatever).
- Alyssa
On Thu, Feb 04, 2016 at 08:26:40AM -0500, Programmingkid wrote:
invalid/unsupported opcode: 13 - 0a - 05 (4f434154) 009e1d10 1
'OCAT', now that is broken.
What is OCAT?
4f434154 is. Character constant 'OCAT', maybe a fourcc, or a part of a string.
Would you have a link to any documentation about this OCAT? If OCAT is just a string, then it shouldn't be executing as an opcode, right?
As I said, it is either a fourcc or a piece of a string, overwritten over something else. If I had to guess, "OCAT" is a part of "lOCATion".
Segher
On Wed, Feb 03, 2016 at 09:58:50PM +0000, Mark Cave-Ayland wrote:
Note that currently we don't add the DBDMA properties at the end of the reg property because QEMU doesn't yet support serial DBDMA, but perhaps it is time to start turning on DBDMA logging to see if this is what's is causing OT to get stuck.
In fact, do we know if OT ever worked on MOL at all or did it provide its own drivers?
In any case, MOL has a comment /* this hack keeps MacOS 9 happy */ just above the point where it enables serial DBDMA on ch-b, so that sounds like a rather big hint for us. I might go try this now..
- Alyssa
On 04/02/16 21:55, Alyssa Milburn wrote:
On Wed, Feb 03, 2016 at 09:58:50PM +0000, Mark Cave-Ayland wrote:
Note that currently we don't add the DBDMA properties at the end of the reg property because QEMU doesn't yet support serial DBDMA, but perhaps it is time to start turning on DBDMA logging to see if this is what's is causing OT to get stuck.
In fact, do we know if OT ever worked on MOL at all or did it provide its own drivers?
In any case, MOL has a comment /* this hack keeps MacOS 9 happy */ just above the point where it enables serial DBDMA on ch-b, so that sounds like a rather big hint for us. I might go try this now..
Interesting. Does MOL implement full emulation or does it manage to persuade OS 9 to not crash by fudging some properties? And thinking about it, does MOL use OT for its networking emulation or does it use its own drivers?
ATB,
Mark.
On Fri, Feb 05, 2016 at 01:10:39PM +0000, Mark Cave-Ayland wrote:
In any case, MOL has a comment /* this hack keeps MacOS 9 happy */ just above the point where it enables serial DBDMA on ch-b, so that sounds like a rather big hint for us. I might go try this now..
Interesting. Does MOL implement full emulation or does it manage to persuade OS 9 to not crash by fudging some properties? And thinking about it, does MOL use OT for its networking emulation or does it use its own drivers?
They ship custom drivers for everything, I think. mac-drivers/enet_driver does use OpenTransport though.
- Alyssa
On Feb 4, 2016, at 4:55 PM, Alyssa Milburn wrote:
On Wed, Feb 03, 2016 at 09:58:50PM +0000, Mark Cave-Ayland wrote:
Note that currently we don't add the DBDMA properties at the end of the reg property because QEMU doesn't yet support serial DBDMA, but perhaps it is time to start turning on DBDMA logging to see if this is what's is causing OT to get stuck.
In fact, do we know if OT ever worked on MOL at all or did it provide its own drivers?
In any case, MOL has a comment /* this hack keeps MacOS 9 happy */ just above the point where it enables serial DBDMA on ch-b, so that sounds like a rather big hint for us. I might go try this now..
I did a little research and found out that some of the properties of the escc-legacy's ch-a and ch-b nodes are wrong.
ftp://ftp.software.ibm.com/rs6000/technology/spec/chrp/inwork/CHRP_IORef_1.0.pdf According to this CHRP specifications, page 246, the escc-legacy node is suppose to have a "ranges" property. This is missing. It is also missing the #size-cells properties. The escc-legacy/ch-a node also looks like it's device_type property should be "legacy" rather than serial.
On Sat, Feb 06, 2016 at 12:12:38AM -0500, Programmingkid wrote:
I did a little research and found out that some of the properties of the escc-legacy's ch-a and ch-b nodes are wrong.
ftp://ftp.software.ibm.com/rs6000/technology/spec/chrp/inwork/CHRP_IORef_1.0.pdf According to this CHRP specifications, page 246, the escc-legacy node is suppose to have a "ranges" property. This is missing. It is also missing the #size-cells properties. The escc-legacy/ch-a node also looks like it's device_type property should be "legacy" rather than serial.
The spec is quite seriously flawed for ESCC (there's an errata which fixes some of it, but even then it doesn't seem to match a lot of Apple's hw), so I wouldn't trust anything it says, unfortunately. :(
If you google e.g. "interrupt-controller" "escc" "boot-rom" then you'll find a lot of OF dumps from different hardware which seem to use "serial" for the device-type.
The Mac OS 9 bootloader seems to only look for 'ranges' for CardBus, but I see that it is there on real hardware (as an empty property?), might be worth trying..
Maybe it might be a good idea to document these things (and how they differ between iteratons of Apple's OF properties, and what is/isn't required by OS 9), but I'm not sure where/how to do so. Any suggestions?
- Alyssa
On Feb 6, 2016, at 4:27 AM, Alyssa Milburn wrote:
On Sat, Feb 06, 2016 at 12:12:38AM -0500, Programmingkid wrote:
I did a little research and found out that some of the properties of the escc-legacy's ch-a and ch-b nodes are wrong.
ftp://ftp.software.ibm.com/rs6000/technology/spec/chrp/inwork/CHRP_IORef_1.0.pdf According to this CHRP specifications, page 246, the escc-legacy node is suppose to have a "ranges" property. This is missing. It is also missing the #size-cells properties. The escc-legacy/ch-a node also looks like it's device_type property should be "legacy" rather than serial.
The spec is quite seriously flawed for ESCC (there's an errata which fixes some of it, but even then it doesn't seem to match a lot of Apple's hw), so I wouldn't trust anything it says, unfortunately. :(
I believe that! Apple themselves made the CHRP specifications and never really used it. Was Steve Jobs afraid the Mac OS might run on IBM hardware? I know he definitely didn't like IBM and this specification was made just before he came back to Apple.
If you google e.g. "interrupt-controller" "escc" "boot-rom" then you'll find a lot of OF dumps from different hardware which seem to use "serial" for the device-type.
The Mac OS 9 bootloader seems to only look for 'ranges' for CardBus, but I see that it is there on real hardware (as an empty property?), might be worth trying..
Maybe it might be a good idea to document these things (and how they differ between iteratons of Apple's OF properties, and what is/isn't required by OS 9), but I'm not sure where/how to do so. Any suggestions?
Everyone who has a Mac could post their escc-legacy and escc node properties to the list.
Maybe we need to go over the facts so far. Please correct me if I'm wrong. We know that OpenTransport causes Mac OS 9.2 to crash. We think the problem could be related to the escc or escc-legacy nodes. From what I heard there might be missing registers, dbdma, or incorrect properties that are keeping us from using OpenTransport. OpenTransport is closed-source so finding out what it is doing would probably require someone who knows PowerPC assembly to figure out what is going on. I think OpenBIOS and/or QEMU could be set so that we see what hardware Mac OS 9.2 is trying to access. Also the only way to see what crashes Mac OS 9.2 is to use Macsbug. So my conclusion is if one of us or all of us knew PowerPC assembly language and all of Macsbug's commands, we might be able to figure out how to solve this problem. Simple enough...
On Sat, Feb 06, 2016 at 09:27:25AM +0000, Alyssa Milburn wrote:
The Mac OS 9 bootloader seems to only look for 'ranges' for CardBus, but I see that it is there on real hardware (as an empty property?), might be worth trying..
An empty "ranges" property means 1-1 translation. No "ranges" property means nothing is mapped below this.
Maybe it might be a good idea to document these things (and how they differ between iteratons of Apple's OF properties, and what is/isn't required by OS 9), but I'm not sure where/how to do so. Any suggestions?
The Linux kernel is the primary for a lot of other bindings, it may be the best place to collect this info (it also has drivers for these devices).
Segher
On Feb 6, 2016, at 4:27 AM, Alyssa Milburn wrote:
On Sat, Feb 06, 2016 at 12:12:38AM -0500, Programmingkid wrote:
I did a little research and found out that some of the properties of the escc-legacy's ch-a and ch-b nodes are wrong.
ftp://ftp.software.ibm.com/rs6000/technology/spec/chrp/inwork/CHRP_IORef_1.0.pdf According to this CHRP specifications, page 246, the escc-legacy node is suppose to have a "ranges" property. This is missing. It is also missing the #size-cells properties. The escc-legacy/ch-a node also looks like it's device_type property should be "legacy" rather than serial.
The spec is quite seriously flawed for ESCC (there's an errata which fixes some of it, but even then it doesn't seem to match a lot of Apple's hw), so I wouldn't trust anything it says, unfortunately. :(
If you google e.g. "interrupt-controller" "escc" "boot-rom" then you'll find a lot of OF dumps from different hardware which seem to use "serial" for the device-type.
The Mac OS 9 bootloader seems to only look for 'ranges' for CardBus, but I see that it is there on real hardware (as an empty property?), might be worth trying..
Maybe it might be a good idea to document these things (and how they differ between iteratons of Apple's OF properties, and what is/isn't required by OS 9), but I'm not sure where/how to do so. Any suggestions?
Your beige g3 has a serial port. The serial port is connected to the escc. If you have Mac OS X or Linux installed on it, what is the output of this command: ls /dev/tty.*
The output of the command on Mac OS X running in QEMU with both the mac99 and g3beige targets is "ls: no match". I think this means Mac OS X could not find the serial port.
If the serial port is working perfectly, then in theory we should be able to write to the serial console in QEMU from the terminal using something like this: echo "Hello world" > /dev/tty.serialport.
Anyone know what the device file is that is assigned to the serial port on a Macintosh?
Le 03/02/2016 18:00, Programmingkid a écrit :
On Feb 3, 2016, at 1:29 AM, Hervé Poussineau wrote:
I/O offsets were wrong in legacy mode and some were missing in non-legacy mode. This fixes serial port detection in NetBSD, which was ignoring it. This also partly fixes MacOS 9.2, which relies on them to initialize OpenTransport.
Signed-off-by: Hervé Poussineau hpoussin@reactos.org
drivers/escc.c | 22 ++++++++++++---------- 1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/escc.c b/drivers/escc.c index afb97fa..8f122d8 100644 --- a/drivers/escc.c +++ b/drivers/escc.c @@ -384,6 +384,8 @@ escc_add_channel(const char *path, const char *node, phys_addr_t addr, { char buf[64], tty[32]; phandle_t dnode, aliases;
int legacy_offsets[][3] = { { 0x4, 0x6, 0xa }, { 0x0, 0x2, 0x8 } };
int offsets[][3] = { { 0x20, 0x30, 0x50 }, { 0x00, 0x10, 0x40 } };
cell props[10]; int offset;
@@ -425,18 +427,18 @@ escc_add_channel(const char *path, const char *node, phys_addr_t addr, set_property(dnode, "compatible", buf, 9);
if (legacy) {
props[0] = IO_ESCC_LEGACY_OFFSET + offset * 0x4;
props[1] = 0x00000001;
props[2] = IO_ESCC_LEGACY_OFFSET + offset * 0x4 + 2;
props[3] = 0x00000001;
props[4] = IO_ESCC_LEGACY_OFFSET + offset * 0x4 + 6;
props[5] = 0x00000001;
set_property(dnode, "reg", (char *)&props, 6 * sizeof(cell));
props[0] = IO_ESCC_LEGACY_OFFSET + legacy_offsets[offset][0];
props[2] = IO_ESCC_LEGACY_OFFSET + legacy_offsets[offset][1];
} else {props[4] = IO_ESCC_LEGACY_OFFSET + legacy_offsets[offset][2];
props[0] = IO_ESCC_OFFSET + offset * 0x20;
props[1] = 0x00000020;
set_property(dnode, "reg", (char *)&props, 2 * sizeof(cell));
props[0] = IO_ESCC_LEGACY_OFFSET + offsets[offset][0];
props[2] = IO_ESCC_LEGACY_OFFSET + offsets[offset][1];
props[4] = IO_ESCC_LEGACY_OFFSET + offsets[offset][2];
}
props[1] = 0x00000001;
props[3] = 0x00000001;
props[5] = 0x00000001;
set_property(dnode, "reg", (char *)&props, 6 * sizeof(cell));
if (legacy) { props[0] = addr + IO_ESCC_LEGACY_OFFSET + offset * 0x4;
-- 2.1.4
I didn't notice anything different when I tried booting Mac OS 9.2 with and without your patch. Mac OS 9.2 always crashes on startup for me. What changes did you notice while using Mac OS 9 with your patch?
Using QEMU master (87574621b18f86eab295a2c207e0b42c77b5dfa0), with unmodified Mac OS 9.2 ISO. * With OpenBIOS r1377 + CR/LF patch MacOS 9.2 load screen is shown, then you have the rotating icon on the top left of the screen, and then QEMU crashes Console contains Trying to write invalid spr 0 (0x000) at 00f113c0 Trying to read invalid spr 0 (0x000) at 00f113c8 invalid/unsupported opcode: 1f - 07 - 02 (7c00488e) 00f113dc 0 invalid/unsupported opcode: 1f - 07 - 06 (7c00498e) 00f113e4 0 Trying to write privileged spr 955 (0x3bb) at 00f168c8 Trying to write invalid spr 959 (0x3bf) at 00f16930 Trying to read invalid spr 959 (0x3bf) at 00f16938 Trying to write invalid spr 944 (0x3b0) at 00f1694c Trying to read invalid spr 944 (0x3b0) at 00f16954 Trying to write invalid spr 951 (0x3b7) at 00f16960 Trying to read invalid spr 951 (0x3b7) at 00f16968 Trying to write privileged spr 955 (0x3bb) at 00f168c8 Trying to write invalid spr 959 (0x3bf) at 00f16930 Trying to read invalid spr 959 (0x3bf) at 00f16938 Trying to write invalid spr 944 (0x3b0) at 00f1694c Trying to read invalid spr 944 (0x3b0) at 00f16954 Trying to write invalid spr 951 (0x3b7) at 00f16960 Trying to read invalid spr 951 (0x3b7) at 00f16968 invalid/unsupported opcode: 13 - 0a - 05 (4f434154) 009e1d10 1 invalid/unsupported opcode: 00 - 00 - 00 (00c10000) 00000000 1 invalid/unsupported opcode: 00 - 00 - 00 (00c10000) 00000000 1 invalid/unsupported opcode: 00 - 00 - 00 (00000000) 008c0f14 1 invalid/unsupported opcode: 00 - 00 - 00 (00000000) 0421b81c 1 qemu: fatal: Trying to execute code outside RAM or ROM at 0xfdfdfdfc
NIP fdfdfdfc LR fdfdfdfd CTR ffcf0dcc XER 20000100 CPU#0 MSR 0000f032 HID0 00810000 HF 00006000 idx 0 TB 00000000 1615152802 DECR 00059059 GPR00 00000000fdfdfdfd 00000000ffe55000 000000000004d280 00000000ffffffff GPR04 00000000ffffffff 00000000ffffffff 00000000f2ffc048 00000000f4ffc048 GPR08 0000000000ffc048 00000000f0ffc048 00000000ffffffff 00000000f6ffc048 GPR12 00000000fcffc048 0000000068fff400 0000000000004e94 000000000bb957ea GPR16 000000003f3f3f3f 0000000000000001 0000000053680000 0000000000000000 GPR20 0000000000000001 0000000000000005 000000000bb8d12c 0000000000006807 GPR24 000000000004ccf0 000000000bb8d130 0000000000084d38 00000000009d0eb8 GPR28 0000000000084d38 00000000ffffffff 00000000fdfdfdfd 000000000000fdfd CR 82220482 [ L E E E - G L E ] RES ffffffff FPR00 0000000082004000 41d2cac6a8000000 0000000000000000 41d2cac6a8000000 FPR04 41d2cac6a8000000 bfd549b141dea8e2 bf880033ba736cfd 3fefffd039962f40 FPR08 3faaf497f23bd4ec 4230000000000000 0000000082004000 4330000017d6dc13 FPR12 3f847b718aeb3db1 ffffffffff3f8c5c 0000000000000000 0000000000000000 FPR16 0000000000000000 0000000000000000 0000000000000000 0000000000000000 FPR20 0000000000000000 0000000000000000 0000000000000000 0000000000000000 FPR24 0000000000000000 0000000000000000 0000000000000000 0000000000000000 FPR28 0000000000000000 0000000000000000 0000000000000000 0000000000000000 FPSCR 82004000 SRR0 fdfdfdfc SRR1 4000f032 PVR 00080301 VRSAVE 00000000 SPRG0 0fbfe000 SPRG1 ffe55000 SPRG2 fdfdfdfd SPRG3 0fbfe420 SPRG4 00000000 SPRG5 00000000 SPRG6 00000000 SPRG7 00000000 SDR1 0fc0001f DAR ffe54fd8 DSISR 0a000000 Aborted
* With OpenBIOS r1377 + CR/LF patch + my patch MacOS 9.2 load screen is shown, OpenTransport icon is displayed at the bottom left on the screen, and there is an message box with "illegal instruction". Console contains Trying to write invalid spr 0 (0x000) at 00f113c0 Trying to read invalid spr 0 (0x000) at 00f113c8 invalid/unsupported opcode: 1f - 07 - 02 (7c00488e) 00f113dc 0 invalid/unsupported opcode: 1f - 07 - 06 (7c00498e) 00f113e4 0 Trying to write privileged spr 955 (0x3bb) at 00f168c8 Trying to write invalid spr 959 (0x3bf) at 00f16930 Trying to read invalid spr 959 (0x3bf) at 00f16938 Trying to write invalid spr 944 (0x3b0) at 00f1694c Trying to read invalid spr 944 (0x3b0) at 00f16954 Trying to write invalid spr 951 (0x3b7) at 00f16960 Trying to read invalid spr 951 (0x3b7) at 00f16968 Trying to write privileged spr 955 (0x3bb) at 00f168c8 Trying to write invalid spr 959 (0x3bf) at 00f16930 Trying to read invalid spr 959 (0x3bf) at 00f16938 Trying to write invalid spr 944 (0x3b0) at 00f1694c Trying to read invalid spr 944 (0x3b0) at 00f16954 Trying to write invalid spr 951 (0x3b7) at 00f16960 Trying to read invalid spr 951 (0x3b7) at 00f16968 invalid/unsupported opcode: 00 - 00 - 00 (00c10000) 00000000 1
Regards,
Hervé