[PATCH 1/6] Fix encoding of PCI and IDE "interrupts" properties

[Benjamin Herrenschmidt]

The main IDE interrupt and the PCI LSIs are level sensitive
which is represented by a "1" in the device-tree.

Signed-off-by: Benjamin Herrenschmidt 
---
 drivers/ide.c | 2 +-
 drivers/pci.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/ide.c b/drivers/ide.c
index 1da60c8..53a0b80 100644
--- a/drivers/ide.c
+++ b/drivers/ide.c
@@ -1630,7 +1630,7 @@ int macio_ide_init(const char *path, uint32_t addr, int nb_channels)
    		props[2] = 0x00000000;
    		break;
    	}
-		props[1] = 0x00000000; /* XXX level triggered on real hw */
+		props[1] = 0x00000001;
    	props[3] = 0x00000000;
    	NEWWORLD(set_property(dnode, "interrupts",
    		     (char *)&props, 4*sizeof(props[0])));
diff --git a/drivers/pci.c b/drivers/pci.c
index 5062f30..2cffa2f 100644
--- a/drivers/pci.c
+++ b/drivers/pci.c
@@ -1510,7 +1510,7 @@ static void ob_pci_host_set_interrupt_map(phandle_t host)
                         props[ncells++] = intno;
                         props[ncells++] = dnode;
                         props[ncells++] = arch->irqs[intno - 1];
-                        props[ncells++] = 3;
+                        props[ncells++] = 1;
 #else
                         /* Keep compiler quiet */
                         dnode = dnode;

[PATCH 2/6] pci: Fix locating Mac driver from PCI rom

[Benjamin Herrenschmidt]

The ROM is not on BAR 1 but BAR 6, I'm not sure what that code ever
did, Qemu uses BAR 6, and I think MOL does too.

Additionally, support using a raw PEF binary without a made up
header.

Eventually we need to support f-code from the ROM but that is not
for today.

Signed-off-by: Benjamin Herrenschmidt 
---
 drivers/pci.c | 54 +++++++++++++++++++++++++++++-------------------------
 1 file changed, 29 insertions(+), 25 deletions(-)

diff --git a/drivers/pci.c b/drivers/pci.c
index 2cffa2f..c748f20 100644
--- a/drivers/pci.c
+++ b/drivers/pci.c
@@ -774,41 +774,45 @@ int macio_keylargo_config_cb (const pci_config_t *config)
 int vga_config_cb (const pci_config_t *config)
 {
         unsigned long rom;
-        uint32_t rom_size, size, mask;
-        int flags, space_code;
+        uint32_t rom_size, size, bar;
         phandle_t ph;

if (config->assigned[0] != 0x00000000) {
             setup_video();

-            pci_decode_pci_addr(config->assigned[1],
-                &flags, &space_code, &mask);
-
-            rom = pci_bus_addr_to_host_addr(space_code,
-                                            config->assigned[1] & ~0x0000000F);
-
-            rom_size = config->sizes[1];
-
-            ph = get_cur_dev();
-
-            if (rom_size >= 8) {
-                const char *p;
-
-                p = (const char *)rom;
-                if (p[0] == 'N' && p[1] == 'D' && p[2] == 'R' && p[3] == 'V') {
-                    size = *(uint32_t*)(p + 4);
-                    set_property(ph, "driver,AAPL,MacOS,PowerPC", p + 8, size);
-                }
+            if (config->assigned[6]) {
+                    rom = pci_bus_addr_to_host_addr(MEMORY_SPACE_32,
+                                                    config->assigned[6] & ~0x0000000F);
+                    rom_size = config->sizes[6];
+
+                    bar = pci_config_read32(config->dev, PCI_ROM_ADDRESS);
+                    bar |= PCI_ROM_ADDRESS_ENABLE;
+                    pci_config_write32(config->dev, PCI_COMMAND, bar);
+                    ph = get_cur_dev();
+
+                    if (rom_size >= 8) {
+                            const char *p;
+
+                            p = (const char *)rom;
+                            if (p[0] == 'N' && p[1] == 'D' && p[2] == 'R' && p[3] == 'V') {
+                                    size = *(uint32_t*)(p + 4);
+                                    set_property(ph, "driver,AAPL,MacOS,PowerPC",
+                                                 p + 8, size);
+                            } else if (p[0] == 'J' && p[1] == 'o' &&
+                                       p[2] == 'y' && p[3] == '!') {
+                                    set_property(ph, "driver,AAPL,MacOS,PowerPC",
+                                                 p, rom_size);
+                            }
+                    }
             }
-
-            /* Currently we don't read FCode from the hardware but execute it directly */
+            /* Currently we don't read FCode from the hardware but execute
+             * it directly */
             feval("['] vga-driver-fcode 2 cells + 1 byte-load");

#ifdef CONFIG_MOL
-	    /* Install special words for Mac On Linux */
-	    molvideo_init();
+            /* Install special words for Mac On Linux */
+            molvideo_init();
 #endif
-
         }

return 0;

[PATCH 2/6] pci: Fix locating Mac driver from PCI rom

[Mark Cave-Ayland]

On 02/08/16 06:35, Benjamin Herrenschmidt wrote:
> The ROM is not on BAR 1 but BAR 6, I'm not sure what that code ever
> did, Qemu uses BAR 6, and I think MOL does too.
>
> Additionally, support using a raw PEF binary without a made up
> header.
>
> Eventually we need to support f-code from the ROM but that is not
> for today.
> Signed-off-by: Benjamin Herrenschmidt
>
> drivers/pci.c | 54 +++++++++++++++++++++++++++++-------------------------
>  1 file changed, 29 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/pci.c b/drivers/pci.c
> index 2cffa2f..c748f20 100644
> --- a/drivers/pci.c
> +++ b/drivers/pci.c
> @@ -774,41 +774,45 @@ int macio_keylargo_config_cb (const pci_config_t *config)
>  int vga_config_cb (const pci_config_t *config)
>  {
>          unsigned long rom;
>    uint32_t rom_size, size, mask;
>    int flags, space_code;
>    uint32_t rom_size, size, bar;
>    phandle_t ph;
>
>    if (config->assigned[0] != 0x00000000) {
>        setup_video();
>
>        pci_decode_pci_addr(config->assigned[1],
>            &flags, &space_code, &mask);
>        rom = pci_bus_addr_to_host_addr(space_code,
>                                        config->assigned[1] & ~0x0000000F);
>        rom_size = config->sizes[1];
>        ph = get_cur_dev();
>        if (rom_size >= 8) {
>            const char *p;
>            p = (const char *)rom;
>            if (p[0] == 'N' && p[1] == 'D' && p[2] == 'R' && p[3] == 'V') {
>                size = *(uint32_t*)(p + 4);
>                set_property(ph, "driver,AAPL,MacOS,PowerPC", p + 8, size);
>            }
>        if (config->assigned[6]) {
>                rom = pci_bus_addr_to_host_addr(MEMORY_SPACE_32,
>                                                config->assigned[6] & ~0x0000000F);
>                rom_size = config->sizes[6];
>                bar = pci_config_read32(config->dev, PCI_ROM_ADDRESS);
>                bar |= PCI_ROM_ADDRESS_ENABLE;
>                pci_config_write32(config->dev, PCI_COMMAND, bar);
>                ph = get_cur_dev();
>                if (rom_size >= 8) {
>                        const char *p;
>                        p = (const char *)rom;
>                        if (p[0] == 'N' && p[1] == 'D' && p[2] == 'R' && p[3] == 'V') {
>                                size = *(uint32_t*)(p + 4);
>                                set_property(ph, "driver,AAPL,MacOS,PowerPC",
>                                             p + 8, size);
>                        } else if (p[0] == 'J' && p[1] == 'o' &&
>                                   p[2] == 'y' && p[3] == '!') {
>                                set_property(ph, "driver,AAPL,MacOS,PowerPC",
>                                             p, rom_size);
>                        }
>                }
>        }
>        /* Currently we don't read FCode from the hardware but execute it directly */
>        /* Currently we don't read FCode from the hardware but execute
>         * it directly */
>        feval("['] vga-driver-fcode 2 cells + 1 byte-load");
>
> #ifdef CONFIG_MOL
>    /* Install special words for Mac On Linux */
>    molvideo_init();
>        /* Install special words for Mac On Linux */
>        molvideo_init();
>
> #endif
>    }
>
> return 0;

Hi Ben,

Just found out during full testing that this breaks SPARC64 VGA
initialisation (it appears that the option ROM isn't mapped so we fault
on accessing the ROM pointer).

I'll temporarily add a patch to wrap this in a #ifdef CONFIG_PPC ....
#endif section for now as I suspect that going forwards most of this
should be reworked as Forth in vga.fs instead.

ATB,

Mark.

[PATCH 2/6] pci: Fix locating Mac driver from PCI rom

[Benjamin Herrenschmidt]

On Fri, 2016-09-09 at 12:38 +0100, Mark Cave-Ayland wrote:
> Just found out during full testing that this breaks SPARC64 VGA
> initialisation (it appears that the option ROM isn't mapped so we
> fault
> on accessing the ROM pointer).
>
> I'll temporarily add a patch to wrap this in a #ifdef CONFIG_PPC ....
> #endif section for now as I suspect that going forwards most of this
> should be reworked as Forth in vga.fs instead.

Absolutely.

Cheers,
Ben.

[PATCH 3/6] escc: Fix legacy addresses

[Benjamin Herrenschmidt]

The legacy addresses were incorrect for both ports, fix them.

Signed-off-by: Benjamin Herrenschmidt 
---
 drivers/escc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/escc.c b/drivers/escc.c
index 1990e79..6515475 100644
--- a/drivers/escc.c
+++ b/drivers/escc.c
@@ -405,9 +405,9 @@ escc_add_channel(const char *path, const char *node, phys_addr_t addr,
             { 0x20, 0x30, 0x50 }
         },{
             /* legacy ch-b */
-            { 0x0, 0x2, 0x8 },
+            { 0x0, 0x4, 0x8 },
             /* legacy ch-a */
-            { 0x4, 0x6, 0xa }
+            { 0x2, 0x6, 0xa }
         }
     };

[PATCH 3/6] escc: Fix legacy addresses

[Mark Cave-Ayland]

On 02/08/16 06:35, Benjamin Herrenschmidt wrote:
> The legacy addresses were incorrect for both ports, fix them.
> Signed-off-by: Benjamin Herrenschmidt
>
> drivers/escc.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/escc.c b/drivers/escc.c
> index 1990e79..6515475 100644
> --- a/drivers/escc.c
> +++ b/drivers/escc.c
> @@ -405,9 +405,9 @@ escc_add_channel(const char *path, const char *node, phys_addr_t addr,
>              { 0x20, 0x30, 0x50 }
>          },{
>              /* legacy ch-b */
>        { 0x0, 0x2, 0x8 },
>        { 0x0, 0x4, 0x8 },
>        /* legacy ch-a */
>        { 0x4, 0x6, 0xa }
>        { 0x2, 0x6, 0xa }
>    }
> };

I remember going through these a while back and thinking that while the
current values didn't match real hardware, they did match what was in
QEMU's hw/misc/macio/macio.c's macio_escc_legacy_setup().
> From memory someone (Alyssa?) picked up on this and posted a patch to

update the mappings in macio_escc_legacy_setup() to match, but I never
got around to digging deeper.

ATB,

Mark.

[PATCH 3/6] escc: Fix legacy addresses

[Alyssa Milburn]

On Tue, Aug 02, 2016 at 09:39:15AM +0100, Mark Cave-Ayland wrote:
> On 02/08/16 06:35, Benjamin Herrenschmidt wrote:
> > The legacy addresses were incorrect for both ports, fix them.
> > Signed-off-by: Benjamin Herrenschmidt
> >
> > drivers/escc.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/escc.c b/drivers/escc.c
> > index 1990e79..6515475 100644
> > --- a/drivers/escc.c
> > +++ b/drivers/escc.c
> > @@ -405,9 +405,9 @@ escc_add_channel(const char *path, const char *node, phys_addr_t addr,
> >              { 0x20, 0x30, 0x50 }
> >          },{
> >              /* legacy ch-b */
> >        { 0x0, 0x2, 0x8 },
> >        { 0x0, 0x4, 0x8 },
> >        /* legacy ch-a */
> >        { 0x4, 0x6, 0xa }
> >        { 0x2, 0x6, 0xa }
> >    }
> > };
>
> I remember going through these a while back and thinking that while the
> current values didn't match real hardware, they did match what was in
> QEMU's hw/misc/macio/macio.c's macio_escc_legacy_setup().
>
> From memory someone (Alyssa?) picked up on this and posted a patch to
> update the mappings in macio_escc_legacy_setup() to match, but I never
> got around to digging deeper.

The attached patch is probably the one you mean. I never posted it to the
qemu list, I think, but in any case it deliberately doesn't change these
values because I think I worked out it wasn't necessary.. it's been too long
for me to remember.
> From memory, the current mappings match *some* hardware, and this new patch

matches other hardware. So they're both "right". I kind of gave up trying to
work out what on earth Apple was thinking (see also the errata mentioned in
the patch).

- Alyssa

[PATCH 3/6] escc: Fix legacy addresses

[Benjamin Herrenschmidt]

On Tue, 2016-08-02 at 08:51 +0000, Alyssa Milburn wrote:
> The attached patch is probably the one you mean. I never posted it to the
> qemu list, I think, but in any case it deliberately doesn't change these
> values because I think I worked out it wasn't necessary.. it's been too long
> > for me to remember.

Nothing uses them anyway at this point. I have done a slightly different
patch that adds comments too, I'll send it to the qemu list later.
> > > om memory, the current mappings match *some* hardware, and this new patch
>
> matches other hardware. So they're both "right". I kind of gave up trying to
> work out what on earth Apple was thinking (see also the errata mentioned in
> the patch).

The register mapping for the base set is fine, and is what everything
uses. The extended registers as described by your patch and my patch
is correct for any MacRISC machine.

I don't know whether more ancient (read: pre-PCI) macs use some
different kind of mapping but I doubt it and in any case it wouldn't
have a macio ASIC so we don't care.

Cheers,
Ben.

[PATCH 3/6] escc: Fix legacy addresses

[Benjamin Herrenschmidt]

On Tue, 2016-08-02 at 09:39 +0100, Mark Cave-Ayland wrote:
> I remember going through these a while back and thinking that while the
> current values didn't match real hardware, they did match what was in
> QEMU's hw/misc/macio/macio.c's macio_escc_legacy_setup().

Nope, though I have this patch below pending (not sent yet) to also fix
other problems in that latter function. But you'll note that the registers
we do care about aren't changed
> > > From memory someone (Alyssa?) picked up on this and posted a patch to
>
> update the mappings in macio_escc_legacy_setup() to match, but I never
> > got around to digging deeper.

Nah so the patch below is based on MacTech.pdf, matches Apple device-
trees and some other Apple documents I can't publish nor talk about :-)

--- a/hw/misc/macio/macio.c
+++ b/hw/misc/macio/macio.c
@@ -89,22 +89,16 @@ static void macio_escc_legacy_setup(MacIOState *macio_state)
     MemoryRegion *bar = &macio_state->bar;
     int i;
     static const int maps[] = {
-        0x00, 0x00,
-        0x02, 0x20,
-        0x04, 0x10,
-        0x06, 0x30,
-        0x08, 0x40,
-        0x0A, 0x50,
-        0x60, 0x60,
-        0x70, 0x70,
-        0x80, 0x70,
-        0x90, 0x80,
-        0xA0, 0x90,
-        0xB0, 0xA0,
-        0xC0, 0xB0,
-        0xD0, 0xC0,
-        0xE0, 0xD0,
-        0xF0, 0xE0,
+        0x00, 0x00, /* Command B */
+        0x02, 0x20, /* Command A */
+        0x04, 0x10, /* Data B */
+        0x06, 0x30, /* Data A */
+        0x08, 0x40, /* Enhancement B */
+        0x0A, 0x50, /* Enhancement A */
+        0x80, 0x80, /* Recovery count */
+        0x90, 0x90, /* Start A */
+        0xa0, 0xa0, /* Start B */
+        0xb0, 0xb0, /* Detect AB */
     };
 
     memory_region_init(escc_legacy, OBJECT(macio_state), "escc-legacy", 256);

[PATCH 4/6] ppc: Fix default serial path

[Benjamin Herrenschmidt]

When CONFIG_SERIAL_PORT is 1 we use port B otherwise port A

Signed-off-by: Benjamin Herrenschmidt 
---
 arch/ppc/qemu/init.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/ppc/qemu/init.c b/arch/ppc/qemu/init.c
index 8f264f4..cc3f21a 100644
--- a/arch/ppc/qemu/init.c
+++ b/arch/ppc/qemu/init.c
@@ -927,11 +927,11 @@ arch_of_init(void)
     if (fw_cfg_read_i16(FW_CFG_NOGRAPHIC)) {
         if (is_apple()) {
             if (CONFIG_SERIAL_PORT) {
-                stdin_path = "scca";
-                stdout_path = "scca";
-            } else {
                 stdin_path = "sccb";
                 stdout_path = "sccb";
+            } else {
+                stdin_path = "scca";
+                stdout_path = "scca";
             }
         } else {
             stdin_path = "ttya";

[PATCH 5/6] escc: Don't set aliases for legacy devices

[Benjamin Herrenschmidt]

We currently overwrite the escc aliases with legacy ones.

This causes us to use a legacy one as a stdout path.

Linux doesn't parse the legacy ones very well causing problems detecting
the default serial console when using a mac model with a serial console.

Signed-off-by: Benjamin Herrenschmidt 
---
 drivers/escc.c | 17 +++++++++--------
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/drivers/escc.c b/drivers/escc.c
index 6515475..4ea8308 100644
--- a/drivers/escc.c
+++ b/drivers/escc.c
@@ -429,14 +429,15 @@ escc_add_channel(const char *path, const char *node, phys_addr_t addr,

/* add aliases */

-    aliases = find_dev("/aliases");
-
-    snprintf(buf, sizeof(buf), "%s/ch-%s", path, node);
-    OLDWORLD(snprintf(tty, sizeof(tty), "tty%s", node));
-    OLDWORLD(set_property(aliases, tty, buf, strlen(buf) + 1));
-    snprintf(tty, sizeof(tty), "scc%s", node);
-    set_property(aliases, tty, buf, strlen(buf) + 1);
-
+    if (!legacy) {
+            aliases = find_dev("/aliases");
+
+            snprintf(buf, sizeof(buf), "%s/ch-%s", path, node);
+            OLDWORLD(snprintf(tty, sizeof(tty), "tty%s", node));
+            OLDWORLD(set_property(aliases, tty, buf, strlen(buf) + 1));
+            snprintf(tty, sizeof(tty), "scc%s", node);
+            set_property(aliases, tty, buf, strlen(buf) + 1);
+    }
     /* add properties */

dnode = find_dev(buf);

[PATCH 6/6] libc: Fix build on recent gcc

[Benjamin Herrenschmidt]

This fixes this warning (which escalates as an error):

roms/openbios/libc/string.c: In function ‘strdup’:
roms/openbios/libc/string.c:353:4: error: nonnull argument ‘str’ compared to NULL [-Werror=nonnull-compare]
  if( !str )
    ^
cc1: all warnings being treated as errors
rules.mak:122: recipe for target 'target/libc		printf("stdout is %s\n", stdout->name);

Signed-off-by: Benjamin Herrenschmidt 
---
 libc/string.c | 5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/libc/string.c b/libc/string.c
index 8f62bd7..bde9a61 100644
--- a/libc/string.c
+++ b/libc/string.c
@@ -349,10 +349,7 @@ int memcmp(const void * cs,const void * ct,size_t count)
 char *
 strdup( const char *str )
 {
-	char *p;
-	if( !str )
-		return NULL;
-	p = malloc( strlen(str) + 1 );
+	char *p = malloc( strlen(str) + 1 );
    strcpy( p, str );
    return p;
 }

[PATCH 6/6] libc: Fix build on recent gcc

[Aurelien Jarno]

On 2016-08-02 15:35, Benjamin Herrenschmidt wrote:
> This fixes this warning (which escalates as an error):
>
> roms/openbios/libc/string.c: In function ‘strdup’:
> roms/openbios/libc/string.c:353:4: error: nonnull argument ‘str’ compared to NULL [-Werror=nonnull-compare]
>   if( !str )
>     ^
> cc1: all warnings being treated as errors
> rules.mak:122: recipe for target 'target/libc		printf("stdout is %s\n", stdout->name);
> Signed-off-by: Benjamin Herrenschmidt
>
> libc/string.c | 5 +----
>  1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/libc/string.c b/libc/string.c
> index 8f62bd7..bde9a61 100644
> --- a/libc/string.c
> +++ b/libc/string.c
> @@ -349,10 +349,7 @@ int memcmp(const void * cs,const void * ct,size_t count)
>  char *
>  strdup( const char *str )
>  {
> char *p;
> if( !str )
> return NULL;
> p = malloc( strlen(str) + 1 );
> char *p = malloc( strlen(str) + 1 );
> strcpy( p, str );
> return p;
>
> }

Sorry to react so late, but wouldn't be better to build openbios with
-ffreestanding instead? That way GCC doesn't try to infer things from
its knowledge of the GNU libc? After all openbios uses its own libc.

Aurelien

[PATCH 6/6] libc: Fix build on recent gcc

[Segher Boessenkool]

On Sun, Nov 06, 2016 at 11:41:40PM +0100, Aurelien Jarno wrote:
> > --- a/libc/string.c
> > +++ b/libc/string.c
> > @@ -349,10 +349,7 @@ int memcmp(const void * cs,const void * ct,size_t count)
> >  char *
> >  strdup( const char *str )
> >  {
> > char *p;
> > if( !str )
> > return NULL;
> > p = malloc( strlen(str) + 1 );
> > char *p = malloc( strlen(str) + 1 );
> > strcpy( p, str );
> > return p;
> >
> > }
>
> Sorry to react so late, but wouldn't be better to build openbios with
> -ffreestanding instead? That way GCC doesn't try to infer things from
> its knowledge of the GNU libc? After all openbios uses its own libc.

This is required not by glibc but by C, for any hosted environment.  Using
-ffreestanding will work, it probably is best to use that (unless openbios
wants to make sure everything else is also implemented correctly, not a
small task).

Segher

[PATCH 6/6] libc: Fix build on recent gcc

[Mark Cave-Ayland]

On 06/11/16 23:18, Segher Boessenkool wrote:
> On Sun, Nov 06, 2016 at 11:41:40PM +0100, Aurelien Jarno wrote:
> > > --- a/libc/string.c
> > > +++ b/libc/string.c
> > > @@ -349,10 +349,7 @@ int memcmp(const void * cs,const void * ct,size_t count)
> > >  char *
> > >  strdup( const char *str )
> > >  {
> > > char *p;
> > > if( !str )
> > > return NULL;
> > > p = malloc( strlen(str) + 1 );
> > > char *p = malloc( strlen(str) + 1 );
> > > strcpy( p, str );
> > > return p;
> > >
> > > }
> >
> > Sorry to react so late, but wouldn't be better to build openbios with
> > -ffreestanding instead? That way GCC doesn't try to infer things from
> > its knowledge of the GNU libc? After all openbios uses its own libc.
>
> This is required not by glibc but by C, for any hosted environment.  Using
> -ffreestanding will work, it probably is best to use that (unless openbios
> wants to make sure everything else is also implemented correctly, not a
> small task).

Oh, interesting. If someone wants to cook up a patch then I'll try it.

ATB,

Mark.

[Howard Spoelstra]

> On 02 Aug 2016, at 07:35, Benjamin Herrenschmidt  wrote:
>
> The main IDE interrupt and the PCI LSIs are level sensitive
> which is represented by a "1" in the device-tree.
> Signed-off-by: Benjamin Herrenschmidt
>
> drivers/ide.c | 2 +-
> drivers/pci.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/ide.c b/drivers/ide.c
> index 1da60c8..53a0b80 100644
> --- a/drivers/ide.c
> +++ b/drivers/ide.c
> @@ -1630,7 +1630,7 @@ int macio_ide_init(const char *path, uint32_t addr, int nb_channels)
>    		props[2] = 0x00000000;
>    		break;
>    	}
> props[1] = 0x00000000; /* XXX level triggered on real hw */
> props[1] = 0x00000001;
> props[3] = 0x00000000;
> NEWWORLD(set_property(dnode, "interrupts",
> 	     (char *)&props, 4*sizeof(props[0])));
>
> diff --git a/drivers/pci.c b/drivers/pci.c
> index 5062f30..2cffa2f 100644
> --- a/drivers/pci.c
> +++ b/drivers/pci.c
> @@ -1510,7 +1510,7 @@ static void ob_pci_host_set_interrupt_map(phandle_t host)
>                         props[ncells++] = intno;
>                         props[ncells++] = dnode;
>                         props[ncells++] = arch->irqs[intno - 1];
>                    props[ncells++] = 3;
>                    props[ncells++] = 1;
>
> #else
>                         /* Keep compiler quiet */
>                         dnode = dnode;
> -- 
> 2.7.4

Wow, these patches allow the USB2 controller to show up when booting a Leopard DVD image and thus provide keyboard/mouse in the installer. During the boot process, only when a disk image is attached, Leopard no longer boots to the installer but hangs on “ still waiting for root device” .

[Mark Cave-Ayland]

On 02/08/16 08:01, Howard Spoelstra wrote:
> > On 02 Aug 2016, at 07:35, Benjamin Herrenschmidt  wrote:
> >
> > The main IDE interrupt and the PCI LSIs are level sensitive
> > which is represented by a "1" in the device-tree.
> > Signed-off-by: Benjamin Herrenschmidt
> >
> > drivers/ide.c | 2 +-
> > drivers/pci.c | 2 +-
> > 2 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/ide.c b/drivers/ide.c
> > index 1da60c8..53a0b80 100644
> > --- a/drivers/ide.c
> > +++ b/drivers/ide.c
> > @@ -1630,7 +1630,7 @@ int macio_ide_init(const char *path, uint32_t addr, int nb_channels)
> >    		props[2] = 0x00000000;
> >    		break;
> >    	}
> > props[1] = 0x00000000; /* XXX level triggered on real hw */
> > props[1] = 0x00000001;
> > props[3] = 0x00000000;
> > NEWWORLD(set_property(dnode, "interrupts",
> > 	     (char *)&props, 4*sizeof(props[0])));
> >
> > diff --git a/drivers/pci.c b/drivers/pci.c
> > index 5062f30..2cffa2f 100644
> > --- a/drivers/pci.c
> > +++ b/drivers/pci.c
> > @@ -1510,7 +1510,7 @@ static void ob_pci_host_set_interrupt_map(phandle_t host)
> >                         props[ncells++] = intno;
> >                         props[ncells++] = dnode;
> >                         props[ncells++] = arch->irqs[intno - 1];
> >                    props[ncells++] = 3;
> >                    props[ncells++] = 1;
> >
> > #else
> >                         /* Keep compiler quiet */
> >                         dnode = dnode;
> > -- 
> > 2.7.4
>
> Wow, these patches allow the USB2 controller to show up when booting a Leopard DVD image and thus provide keyboard/mouse in the installer. During the boot process, only when a disk image is attached, Leopard no longer boots to the installer but hangs on “ still waiting for root device” .

Actually the bottom part of the diff in drivers/pci.c affects all PCI
devices - does it help with the rtl8139 networking in OS 9 at all?

ATB,

Mark.

[Howard Spoelstra]

> On 02 Aug 2016, at 10:50, Mark Cave-Ayland  wrote:
>
> On 02/08/16 08:01, Howard Spoelstra wrote:
> > > On 02 Aug 2016, at 07:35, Benjamin Herrenschmidt  wrote:
> > >
> > > The main IDE interrupt and the PCI LSIs are level sensitive
> > > which is represented by a "1" in the device-tree.
> > > Signed-off-by: Benjamin Herrenschmidt
> > >
> > > drivers/ide.c | 2 +-
> > > drivers/pci.c | 2 +-
> > > 2 files changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/ide.c b/drivers/ide.c
> > > index 1da60c8..53a0b80 100644
> > > --- a/drivers/ide.c
> > > +++ b/drivers/ide.c
> > > @@ -1630,7 +1630,7 @@ int macio_ide_init(const char *path, uint32_t addr, int nb_channels)
> > >    		props[2] = 0x00000000;
> > >    		break;
> > >    	}
> > > props[1] = 0x00000000; /* XXX level triggered on real hw */
> > > props[1] = 0x00000001;
> > > props[3] = 0x00000000;
> > > NEWWORLD(set_property(dnode, "interrupts",
> > > 	     (char *)&props, 4*sizeof(props[0])));
> > >
> > > diff --git a/drivers/pci.c b/drivers/pci.c
> > > index 5062f30..2cffa2f 100644
> > > --- a/drivers/pci.c
> > > +++ b/drivers/pci.c
> > > @@ -1510,7 +1510,7 @@ static void ob_pci_host_set_interrupt_map(phandle_t host)
> > >                        props[ncells++] = intno;
> > >                        props[ncells++] = dnode;
> > >                        props[ncells++] = arch->irqs[intno - 1];
> > >                    props[ncells++] = 3;
> > >                    props[ncells++] = 1;
> > >
> > > #else
> > >                        /* Keep compiler quiet */
> > >                        dnode = dnode;
> > > -- 
> > > 2.7.4
> >
> > Wow, these patches allow the USB2 controller to show up when booting a Leopard DVD image and thus provide keyboard/mouse in the installer. During the boot process, only when a disk image is attached, Leopard no longer boots to the installer but hangs on “ still waiting for root device” .
>
> Actually the bottom part of the diff in drivers/pci.c affects all PCI
> devices - does it help with the rtl8139 networking in OS 9 at all?
>
> ATB,
>
> Mark.

No, still no dice in OS 9.1 Profiler shows Link not available, Speed not available, Duplex not available.
Profiler PCI info says Card type not available and card ROM # not available.
I also see no traffic on my en0 connection.

[Howard Spoelstra]

> On 02 Aug 2016, at 09:01, Howard Spoelstra  wrote:
> > On 02 Aug 2016, at 07:35, Benjamin Herrenschmidt  wrote:
> >
> > The main IDE interrupt and the PCI LSIs are level sensitive
> > which is represented by a "1" in the device-tree.
> > Signed-off-by: Benjamin Herrenschmidt
> >
> > drivers/ide.c | 2 +-
> > drivers/pci.c | 2 +-
> > 2 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/ide.c b/drivers/ide.c
> > index 1da60c8..53a0b80 100644
> > --- a/drivers/ide.c
> > +++ b/drivers/ide.c
> > @@ -1630,7 +1630,7 @@ int macio_ide_init(const char *path, uint32_t addr, int nb_channels)
> >    		props[2] = 0x00000000;
> >    		break;
> >    	}
> > props[1] = 0x00000000; /* XXX level triggered on real hw */
> > props[1] = 0x00000001;
> > props[3] = 0x00000000;
> > NEWWORLD(set_property(dnode, "interrupts",
> > 	     (char *)&props, 4*sizeof(props[0])));
> >
> > diff --git a/drivers/pci.c b/drivers/pci.c
> > index 5062f30..2cffa2f 100644
> > --- a/drivers/pci.c
> > +++ b/drivers/pci.c
> > @@ -1510,7 +1510,7 @@ static void ob_pci_host_set_interrupt_map(phandle_t host)
> >                        props[ncells++] = intno;
> >                        props[ncells++] = dnode;
> >                        props[ncells++] = arch->irqs[intno - 1];
> >                    props[ncells++] = 3;
> >                    props[ncells++] = 1;
> >
> > #else
> >                        /* Keep compiler quiet */
> >                        dnode = dnode;
> > -- 
> > 2.7.4
>
> Wow, these patches allow the USB2 controller to show up when booting a Leopard DVD image and thus provide keyboard/mouse in the installer. During the boot process, only when a disk image is attached, Leopard no longer boots to the installer but hangs on “ still waiting for root device” .

Currently installing Leopard on a “external” usb disk ;-) Lets hope I can attach it later on as a normal disk to boot from. 1 hour to go.

[Howard Spoelstra]

> On 02 Aug 2016, at 10:54, Howard Spoelstra  wrote:
> > On 02 Aug 2016, at 09:01, Howard Spoelstra  wrote:
> > > On 02 Aug 2016, at 07:35, Benjamin Herrenschmidt  wrote:
> > >
> > > The main IDE interrupt and the PCI LSIs are level sensitive
> > > which is represented by a "1" in the device-tree.
> > > Signed-off-by: Benjamin Herrenschmidt
> > >
> > > drivers/ide.c | 2 +-
> > > drivers/pci.c | 2 +-
> > > 2 files changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/ide.c b/drivers/ide.c
> > > index 1da60c8..53a0b80 100644
> > > --- a/drivers/ide.c
> > > +++ b/drivers/ide.c
> > > @@ -1630,7 +1630,7 @@ int macio_ide_init(const char *path, uint32_t addr, int nb_channels)
> > >    		props[2] = 0x00000000;
> > >    		break;
> > >    	}
> > > props[1] = 0x00000000; /* XXX level triggered on real hw */
> > > props[1] = 0x00000001;
> > > props[3] = 0x00000000;
> > > NEWWORLD(set_property(dnode, "interrupts",
> > > 	     (char *)&props, 4*sizeof(props[0])));
> > >
> > > diff --git a/drivers/pci.c b/drivers/pci.c
> > > index 5062f30..2cffa2f 100644
> > > --- a/drivers/pci.c
> > > +++ b/drivers/pci.c
> > > @@ -1510,7 +1510,7 @@ static void ob_pci_host_set_interrupt_map(phandle_t host)
> > >                       props[ncells++] = intno;
> > >                       props[ncells++] = dnode;
> > >                       props[ncells++] = arch->irqs[intno - 1];
> > >                    props[ncells++] = 3;
> > >                    props[ncells++] = 1;
> > >
> > > #else
> > >                       /* Keep compiler quiet */
> > >                       dnode = dnode;
> > > -- 
> > > 2.7.4
> >
> > Wow, these patches allow the USB2 controller to show up when booting a Leopard DVD image and thus provide keyboard/mouse in the installer. During the boot process, only when a disk image is attached, Leopard no longer boots to the installer but hangs on “ still waiting for root device” .
>
> Currently installing Leopard on a “external” usb disk ;-) Lets hope I can attach it later on as a normal disk to boot from. 1 hour to go.

Sadly failed due to OSX reporting not being able to make the disk bootable. I wasn’t able to specify raw as format when adding the disk as usb device.

[Mark Cave-Ayland]

On 02/08/16 06:35, Benjamin Herrenschmidt wrote:
> The main IDE interrupt and the PCI LSIs are level sensitive
> which is represented by a "1" in the device-tree.
> Signed-off-by: Benjamin Herrenschmidt
>
> drivers/ide.c | 2 +-
>  drivers/pci.c | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/ide.c b/drivers/ide.c
> index 1da60c8..53a0b80 100644
> --- a/drivers/ide.c
> +++ b/drivers/ide.c
> @@ -1630,7 +1630,7 @@ int macio_ide_init(const char *path, uint32_t addr, int nb_channels)
>    		props[2] = 0x00000000;
>    		break;
>    	}
> props[1] = 0x00000000; /* XXX level triggered on real hw */
> props[1] = 0x00000001;
> props[3] = 0x00000000;
> NEWWORLD(set_property(dnode, "interrupts",
> 	     (char *)&props, 4*sizeof(props[0])));
>
> diff --git a/drivers/pci.c b/drivers/pci.c
> index 5062f30..2cffa2f 100644
> --- a/drivers/pci.c
> +++ b/drivers/pci.c
> @@ -1510,7 +1510,7 @@ static void ob_pci_host_set_interrupt_map(phandle_t host)
>                          props[ncells++] = intno;
>                          props[ncells++] = dnode;
>                          props[ncells++] = arch->irqs[intno - 1];
>                    props[ncells++] = 3;
>                    props[ncells++] = 1;
>
> #else
>                          /* Keep compiler quiet */
>                          dnode = dnode;

Hi Ben,

I think these all look good except for the reported regression from this
patch - is this something that you can also see?

Since we're close to release, I'll test these tomorrow and queue them in
a separate branch ready for merge once 2.7 is out of the door.

ATB,

Mark.

[Benjamin Herrenschmidt]

On Tue, 2016-08-02 at 23:44 +0100, Mark Cave-Ayland wrote:
> Hi Ben,
>
> I think these all look good except for the reported regression from this
> patch - is this something that you can also see?
>
> Since we're close to release, I'll test these tomorrow and queue them in
> a separate branch ready for merge once 2.7 is out of the door.

I am not sure about the "regression" ... the patches seems to fix
things rather than not and are correct from a HW perspective and
afaik from an emulation perspective.

That said, I wouldn't worry too much about Leopard (OS X 10.5) yet,
the machine we emulate isn't really supported by it to begin with
and there are a number of issues there.

Tiger (OS X 10.4) seems to work well.

I'm working on lifting up the whole Mac model, adding a PMU model,
a SunGEM, bringing MacIO a bit more up to date etc... At that point
I'll make sure 10.5 works well.

Cheers,
Ben.

[BALATON Zoltan]

On Wed, 3 Aug 2016, Benjamin Herrenschmidt wrote:
> That said, I wouldn't worry too much about Leopard (OS X 10.5) yet,
> the machine we emulate isn't really supported by it to begin with
> and there are a number of issues there.
>
> Tiger (OS X 10.4) seems to work well.

The last supported for PowerMac3,1 we emulate now is 10.4.11. 10.5 could 
be installed with a hack (that is, on real hardware, not on qemu). More 
info on this is here in case someone is interested:
http://www.everymac.com/systems/apple/powermac_g4/faq/power-mac-g4-hack-to-r...
> I'm working on lifting up the whole Mac model, adding a PMU model,
> a SunGEM, bringing MacIO a bit more up to date etc... At that point
> I'll make sure 10.5 works well.

This is very exciting. Looking forward to it.

Regards,
BALATON Zoltan

[Howard Spoelstra]

> On 03 Aug 2016, at 14:13, BALATON Zoltan  wrote:
>
> On Wed, 3 Aug 2016, Benjamin Herrenschmidt wrote:
> > That said, I wouldn't worry too much about Leopard (OS X 10.5) yet,
> > the machine we emulate isn't really supported by it to begin with
> > and there are a number of issues there.
> >
> > Tiger (OS X 10.4) seems to work well.
>
> The last supported for PowerMac3,1 we emulate now is 10.4.11. 10.5 could be installed with a hack (that is, on real hardware, not on qemu). More info on this is here in case someone is interested:
> http://www.everymac.com/systems/apple/powermac_g4/faq/power-mac-g4-hack-to-r...
> > I'm working on lifting up the whole Mac model, adding a PMU model,
> > a SunGEM, bringing MacIO a bit more up to date etc... At that point
> > I'll make sure 10.5 works well.
>
> This is very exciting. Looking forward to it.
>
> Regards,
> BALATON Zoltan

I agree with Ben, that regression is not important. I did finally succeed in installing Leopard on an “external” drive connected as USB hard disk. The installer warned that this disk would not be bootable and when it finished reported that it could not make the disk bootable. G5 and earlier seem not able to boot from USB anyway. When I attached the resulting disk as IDE device, it would not boot. The reverse also didnt work. Connecting the dvd image as usb drive didn’t allow boot.

[G 3]

On Aug 3, 2016, at 8:59 AM, Howard Spoelstra wrote:
> > On 03 Aug 2016, at 14:13, BALATON Zoltan  wrote:
> >
> > On Wed, 3 Aug 2016, Benjamin Herrenschmidt wrote:
> > > That said, I wouldn't worry too much about Leopard (OS X 10.5) yet,
> > > the machine we emulate isn't really supported by it to begin with
> > > and there are a number of issues there.
> > >
> > > Tiger (OS X 10.4) seems to work well.
> >
> > The last supported for PowerMac3,1 we emulate now is 10.4.11. 10.5  
> > could be installed with a hack (that is, on real hardware, not on  
> > qemu). More info on this is here in case someone is interested:
> > http://www.everymac.com/systems/apple/powermac_g4/faq/power-mac-g4- 
> > hack-to-run-mac-os-x-105-leopard.html
> > > I'm working on lifting up the whole Mac model, adding a PMU model,
> > > a SunGEM, bringing MacIO a bit more up to date etc... At that point
> > > I'll make sure 10.5 works well.
> >
> > This is very exciting. Looking forward to it.
> >
> > Regards,
> > BALATON Zoltan
>
> I agree with Ben, that regression is not important. I did finally  
> succeed in installing Leopard on an “external” drive connected as  
> USB hard disk. The installer warned that this disk would not be  
> bootable and when it finished reported that it could not make the  
> disk bootable. G5 and earlier seem not able to boot from USB  
> anyway. When I attached the resulting disk as IDE device, it would  
> not boot. The reverse also didnt work. Connecting the dvd image as  
> usb drive didn’t allow boot.

I was able to boot from a USB flash drive on my iMac G5. Holding down  
the option key during startup won't show it. I had to use Open  
Firmware and a command that looked like this ud:,\:tbxi. I not sure  
if this is the exact command. What I booted was a Linux ISO written  
to a USB flash drive.

[BALATON Zoltan]

On Wed, 3 Aug 2016, G 3 wrote:
> On Aug 3, 2016, at 8:59 AM, Howard Spoelstra wrote:
> > finished reported that it could not make the disk bootable. G5 and earlier 
> > seem not able to boot from USB anyway. When I attached the resulting disk 
> > as IDE device, it would not boot. The reverse also didnt work. Connecting 
> > the dvd image as usb drive didn’t allow boot.
>
> I was able to boot from a USB flash drive on my iMac G5. Holding down the 
> option key during startup won't show it. I had to use Open Firmware and a 
> command that looked like this ud:,\:tbxi. I not sure if this is the exact 
> command. What I booted was a Linux ISO written to a USB flash drive.

I don't expect this to work with OpenBIOS on QEMU as I think we don't have 
a USB driver for storage devices. I've only ported a hid driver for 
keyboard on OHCI so unless there was a change in this that is all OpenBIOS 
would see from USB and should not find USB disks.

Also G5 Mac emulation in QEMU is probably not that good as G4 is now so 64 
bit version may have more problems than 32 bit ppc.

Regards,
BALATON Zoltan

[Benjamin Herrenschmidt]

On Wed, 2016-08-03 at 22:59 +0200, BALATON Zoltan wrote:
> Also G5 Mac emulation in QEMU is probably not that good as G4 is now
> so 64 bit version may have more problems than 32 bit ppc.

Well, the processor itself is very well emulated, that isn't the
problem.

The machine however ... our G5 Mac99 model is some kind of franken mac
which tries to pretend to be a U3 based G5 with bits and pieces that
only exist on 32-bit machines and a U3 that doesn't really like like a
real U3 ;-) It's definitely making MacOS X do weird weird things, like
try to instanciate the MacRISC2 PE on top of a 970 CPU.

Based on spare time availability, I want to look into fixing this all
up but only after I've tightened the Mac99 model a bit more to the
point we can run 10.5, have networking, etc...

Cheers,
Ben

[BALATON Zoltan]

On Thu, 4 Aug 2016, Benjamin Herrenschmidt wrote:
> On Wed, 2016-08-03 at 22:59 +0200, BALATON Zoltan wrote:
> > Also G5 Mac emulation in QEMU is probably not that good as G4 is now
> > so 64 bit version may have more problems than 32 bit ppc.
>
> Well, the processor itself is very well emulated, that isn't the
> problem.
>
> The machine however ... our G5 Mac99 model is some kind of franken mac
> which tries to pretend to be a U3 based G5 with bits and pieces that
> only exist on 32-bit machines and a U3 that doesn't really like like a
> real U3 ;-) It's definitely making MacOS X do weird weird things, like

That's what I've meant.
> Based on spare time availability, I want to look into fixing this all
> up but only after I've tightened the Mac99 model a bit more to the
> point we can run 10.5, have networking, etc...

I did not mean to say that fixing G5 Mac emulation would be important or 
high priority as that's much more work than improving the 32 bit one so it 
makes perfect sense to fix the G4 Mac model now which should be enough for 
most apps anyway. The G5 would probably need a rewrite of U3, different 
PMU and more missing pieces so as you've said, maybe sometimes later if 
time permits.

For the G4 Mac I've noticed some missing i2c and gpio emulation when I've 
looked at it a while ago but I did not have the knowledge about how these 
should be implemented.

Regards,
BALATON Zoltan

[Benjamin Herrenschmidt]

On Thu, 2016-08-04 at 03:20 +0200, BALATON Zoltan wrote:
> I did not mean to say that fixing G5 Mac emulation would be important or 
> high priority as that's much more work than improving the 32 bit one so it 
> makes perfect sense to fix the G4 Mac model now which should be enough for 
> most apps anyway. The G5 would probably need a rewrite of U3, different 
> PMU and more missing pieces so as you've said, maybe sometimes later if 
> time permits.

The PMU remains mostly the same, the main work is the hypertransport bits
I think or at least mimmic them enough using PCI, but we'll see.
> > For the G4 Mac I've noticed some missing i2c and gpio emulation when I've
>
> looked at it a while ago but I did not have the knowledge about how these 
> should be implemented.

I'm adding one GPIO for the PMU, the rest is less important. We can
probably get a pretty good model without any i2c. It's used for things
like clocks control, some sound chips, fans, and so .. anyway, we'll
see.

Cheers,
Ben.

[Mark Cave-Ayland]

On 03/08/16 13:59, Howard Spoelstra wrote:
> > On 03 Aug 2016, at 14:13, BALATON Zoltan  wrote:
> >
> > On Wed, 3 Aug 2016, Benjamin Herrenschmidt wrote:
> > > That said, I wouldn't worry too much about Leopard (OS X 10.5) yet,
> > > the machine we emulate isn't really supported by it to begin with
> > > and there are a number of issues there.
> > >
> > > Tiger (OS X 10.4) seems to work well.
> >
> > The last supported for PowerMac3,1 we emulate now is 10.4.11. 10.5 could be installed with a hack (that is, on real hardware, not on qemu). More info on this is here in case someone is interested:
> > http://www.everymac.com/systems/apple/powermac_g4/faq/power-mac-g4-hack-to-r...
> > > I'm working on lifting up the whole Mac model, adding a PMU model,
> > > a SunGEM, bringing MacIO a bit more up to date etc... At that point
> > > I'll make sure 10.5 works well.
> >
> > This is very exciting. Looking forward to it.
> >
> > Regards,
> > BALATON Zoltan
>
> I agree with Ben, that regression is not important. I did finally succeed in installing Leopard on an “external” drive connected as USB hard disk. The installer warned that this disk would not be bootable and when it finished reported that it could not make the disk bootable. G5 and earlier seem not able to boot from USB anyway. When I attached the resulting disk as IDE device, it would not boot. The reverse also didnt work. Connecting the dvd image as usb drive didn’t allow boot.

Okay in that case I consider myself overruled ;)  Will carry on testing
this evening...

ATB,

Mark.

[Benjamin Herrenschmidt]

On Wed, 2016-08-03 at 20:48 +0100, Mark Cave-Ayland wrote:
> Okay in that case I consider myself overruled ;)  Will carry on
> testing this evening...

BTW. The CUDA interrupt has the wrong polarity too afaik.

Cheers,
Ben.

[Mark Cave-Ayland]

On 03/08/16 22:46, Benjamin Herrenschmidt wrote:
> On Wed, 2016-08-03 at 20:48 +0100, Mark Cave-Ayland wrote:
> > Okay in that case I consider myself overruled ;)  Will carry on
> > testing this evening...
>
> BTW. The CUDA interrupt has the wrong polarity too afaik.
>
> Cheers,
> Ben.

Cool. Do you have a diff? If so, I can squash it into the previous
interrupt patch.

I guess we don't care too much about splitting each interrupt change
into a separate patch? I'm musing over whether it's worth doing to
bisecting regressions but perhaps that is overkill right now...

ATB,

Mark.

[Benjamin Herrenschmidt]

On Thu, 2016-08-04 at 20:14 +0100, Mark Cave-Ayland wrote:
> On 03/08/16 22:46, Benjamin Herrenschmidt wrote:
> > On Wed, 2016-08-03 at 20:48 +0100, Mark Cave-Ayland wrote:
> > > Okay in that case I consider myself overruled ;)  Will carry on
> > > testing this evening...
> >
> > BTW. The CUDA interrupt has the wrong polarity too afaik.
> >
> > Cheers,
> > Ben.
>
> Cool. Do you have a diff? If so, I can squash it into the previous
> interrupt patch.
>
> I guess we don't care too much about splitting each interrupt change
> into a separate patch? I'm musing over whether it's worth doing to
> bisecting regressions but perhaps that is overkill right now...

Nah, don't change it. It causes Linux to barf. I suspect a bug in the
emulation in qemu, I'll look into this.

I fixed some VIA bugs in my PMU code in qemu but it's a fork of CUDA at
the moment. I want to eventually move all the VIA stuff into a separate
device common to PMU and CUDA.

Cheers,
Ben.