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 benh@kernel.crashing.org --- 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;
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 benh@kernel.crashing.org --- 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;
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 benh@kernel.crashing.org
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.
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.
The legacy addresses were incorrect for both ports, fix them.
Signed-off-by: Benjamin Herrenschmidt benh@kernel.crashing.org --- 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 } } };
On 02/08/16 06:35, Benjamin Herrenschmidt wrote:
The legacy addresses were incorrect for both ports, fix them.
Signed-off-by: Benjamin Herrenschmidt benh@kernel.crashing.org
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.
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 benh@kernel.crashing.org
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
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.
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);
When CONFIG_SERIAL_PORT is 1 we use port B otherwise port A
Signed-off-by: Benjamin Herrenschmidt benh@kernel.crashing.org --- 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";
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 benh@kernel.crashing.org --- 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);
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 benh@kernel.crashing.org --- 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; }
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 benh@kernel.crashing.org
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
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
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.
On 02 Aug 2016, at 07:35, Benjamin Herrenschmidt benh@kernel.crashing.org 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 benh@kernel.crashing.org
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;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
-- OpenBIOS http://openbios.org/ Mailinglist: http://lists.openbios.org/mailman/listinfo Free your System - May the Forth be with you
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” .
On 02/08/16 08:01, Howard Spoelstra wrote:
On 02 Aug 2016, at 07:35, Benjamin Herrenschmidt benh@kernel.crashing.org 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 benh@kernel.crashing.org
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;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
-- OpenBIOS http://openbios.org/ Mailinglist: http://lists.openbios.org/mailman/listinfo Free your System - May the Forth be with you
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.
On 02 Aug 2016, at 10:50, Mark Cave-Ayland mark.cave-ayland@ilande.co.uk wrote:
On 02/08/16 08:01, Howard Spoelstra wrote:
On 02 Aug 2016, at 07:35, Benjamin Herrenschmidt benh@kernel.crashing.org 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 benh@kernel.crashing.org
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;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
-- OpenBIOS http://openbios.org/ Mailinglist: http://lists.openbios.org/mailman/listinfo Free your System - May the Forth be with you
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.
-- OpenBIOS http://openbios.org/ Mailinglist: http://lists.openbios.org/mailman/listinfo Free your System - May the Forth be with you
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.
On 02 Aug 2016, at 09:01, Howard Spoelstra hsp.cat7@gmail.com wrote:
On 02 Aug 2016, at 07:35, Benjamin Herrenschmidt benh@kernel.crashing.org 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 benh@kernel.crashing.org
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;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
-- OpenBIOS http://openbios.org/ Mailinglist: http://lists.openbios.org/mailman/listinfo Free your System - May the Forth be with you
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.
On 02 Aug 2016, at 10:54, Howard Spoelstra hsp.cat7@gmail.com wrote:
On 02 Aug 2016, at 09:01, Howard Spoelstra hsp.cat7@gmail.com wrote:
On 02 Aug 2016, at 07:35, Benjamin Herrenschmidt benh@kernel.crashing.org 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 benh@kernel.crashing.org
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;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
-- OpenBIOS http://openbios.org/ Mailinglist: http://lists.openbios.org/mailman/listinfo Free your System - May the Forth be with you
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.
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 benh@kernel.crashing.org
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;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.
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.
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
On 03 Aug 2016, at 14:13, BALATON Zoltan balaton@eik.bme.hu 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
-- OpenBIOS http://openbios.org/ Mailinglist: http://lists.openbios.org/mailman/listinfo Free your System - May the Forth be with you
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.
On Aug 3, 2016, at 8:59 AM, Howard Spoelstra wrote:
On 03 Aug 2016, at 14:13, BALATON Zoltan balaton@eik.bme.hu 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
-- OpenBIOS http://openbios.org/ Mailinglist: http://lists.openbios.org/mailman/listinfo Free your System - May the Forth be with you
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.
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
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
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
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.
On 03/08/16 13:59, Howard Spoelstra wrote:
On 03 Aug 2016, at 14:13, BALATON Zoltan balaton@eik.bme.hu 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
-- OpenBIOS http://openbios.org/ Mailinglist: http://lists.openbios.org/mailman/listinfo Free your System - May the Forth be with you
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.
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.
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.
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.
-
Alyssa Milburn -
Aurelien Jarno -
BALATON Zoltan -
Benjamin Herrenschmidt -
G 3 -
Howard Spoelstra -
Mark Cave-Ayland -
Segher Boessenkool