[PATCH] ppc: fix ESCC reg properties

[Hervé Poussineau]

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 
---
 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;

[Programmingkid]

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
>
> 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;

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?

[Hervé Poussineau]

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
> >
> > 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;
>
> 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é

[Programmingkid]

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
> > >
> > > 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;
> >
> > 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.

[Alyssa Milburn]

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

[Programmingkid]

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.

[Mark Cave-Ayland]

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.

[Segher Boessenkool]

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

[Programmingkid]

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?

[Segher Boessenkool]

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

[Programmingkid]

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?

[Alyssa Milburn]

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

[Segher Boessenkool]

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

[Mark Cave-Ayland]

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
>
> 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;

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.

[Alyssa Milburn]

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

[Mark Cave-Ayland]

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.

[Alyssa Milburn]

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

[Programmingkid]

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.

[Alyssa Milburn]

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

[Programmingkid]

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...

[Segher Boessenkool]

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

[Programmingkid]

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?