Balaton when you realigned the memory hole on Qemu from Size: 0x70000000 (1792 MB, 0x80000000–0xF0000000). To 256MB was there a specific issue that you can recall? The reason I ask is I’m trying to use PCI Passthrough of a PCI-E Radeon X1950XT with 265MB of VRAM and I assume, tho I’ve not checked yet, it uses 64bit BARs. Qemu skips BARs marked as 64Bit. if ((*p_omask & 0x0000000f) == 0x4) { /* 64 bits memory mapping */ PCI_DPRINTF("Skipping 64 bit BARs for %s\n", config->path); return; } So when the FCode ROM tries to setup the BAR 0x10 and 0x18 we are failing there: 400369f : (compile) 2 [ 0xa7 ] 40036a0 : (compile) or [ 0x24 ] 40036a2 : (compile) [ 0x9e6 ] 40036a4 : (compile) [ 0xb40 ] 40036a5 : (compile) b(;) [ 0xc2 ] 40036a6 : b(lit) [ 0x10 ] 40036ac : my-space [ 0x103 ] 40036ad : + [ 0x1e ] 40036ae : b(") [ 0x12 ] (const) config-l@ 40036ba : $call-parent [ 0x209 ] byte-load: exception caught! ok I was just going to bypass the 64bit BAR check in Openbios as 265MB is still within the 4GB address space of 32bit but I’m going to need more space in the hole for the other BARs, no?
On Mon, 19 May 2025, Jd Lyons wrote:
Balaton when you realigned the memory hole on Qemu from Size: 0x70000000 (1792 MB, 0x80000000–0xF0000000). To 256MB was there a specific issue that you can recall?
As the commit message says this is what's on the real machine as seen in the device tree which was also what OpenBIOS put in the device tree so whatever reads the device tree probably won't expect larger window and it may overlap some other region that should be there too. QEMU should follow what is on the real machine but I don't remember the details as this was more than 10 years ago.
The reason I ask is I’m trying to use PCI Passthrough of a PCI-E Radeon X1950XT with 265MB of VRAM and I assume, tho I’ve not checked yet, it uses 64bit BARs. Qemu skips BARs marked as 64Bit.
It's not QEMU but OpenBIOS. The code below does not appear in QEMU.
if ((*p_omask & 0x0000000f) == 0x4) { /* 64 bits memory mapping */ PCI_DPRINTF("Skipping 64 bit BARs for %s\n", config->path); return; }
So when the FCode ROM tries to setup the BAR 0x10 and 0x18 we are failing there:
400369f : (compile) 2 [ 0xa7 ] 40036a0 : (compile) or [ 0x24 ] 40036a2 : (compile) [ 0x9e6 ] 40036a4 : (compile) [ 0xb40 ] 40036a5 : (compile) b(;) [ 0xc2 ] 40036a6 : b(lit) [ 0x10 ] 40036ac : my-space [ 0x103 ] 40036ad : + [ 0x1e ] 40036ae : b(") [ 0x12 ] (const) config-l@ 40036ba : $call-parent [ 0x209 ]
byte-load: exception caught! ok
I was just going to bypass the 64bit BAR check in Openbios as 265MB is
I'm not sure that will work without more changes, maybe the check is there for a reason.
still within the 4GB address space of 32bit but I’m going to need more space in the hole for the other BARs, no?
On real machine graphics cards probably appear on different PCI bus that has a different window but we don't quite model that in QEMU and OpenBIOS cannot handle it so you may need to hack something to allow the card to be added but I don't know what and how. Also if your host firmware setup has an option to disable resizable BARs that may help but I'm not sure. Regards, BALATON Zoltan
Thanks, did you ever post you patches for Openbios and the Rage128? I’m going to need to recompile Openbios but I need your patch set if you still have it?
On May 19, 2025, at 9:35 PM, BALATON Zoltan <balaton@eik.bme.hu> wrote:
On Mon, 19 May 2025, Jd Lyons wrote:
Balaton when you realigned the memory hole on Qemu from Size: 0x70000000 (1792 MB, 0x80000000–0xF0000000). To 256MB was there a specific issue that you can recall?
As the commit message says this is what's on the real machine as seen in the device tree which was also what OpenBIOS put in the device tree so whatever reads the device tree probably won't expect larger window and it may overlap some other region that should be there too. QEMU should follow what is on the real machine but I don't remember the details as this was more than 10 years ago.
The reason I ask is I’m trying to use PCI Passthrough of a PCI-E Radeon X1950XT with 265MB of VRAM and I assume, tho I’ve not checked yet, it uses 64bit BARs. Qemu skips BARs marked as 64Bit.
It's not QEMU but OpenBIOS. The code below does not appear in QEMU.
if ((*p_omask & 0x0000000f) == 0x4) { /* 64 bits memory mapping */ PCI_DPRINTF("Skipping 64 bit BARs for %s\n", config->path); return; }
So when the FCode ROM tries to setup the BAR 0x10 and 0x18 we are failing there:
400369f : (compile) 2 [ 0xa7 ] 40036a0 : (compile) or [ 0x24 ] 40036a2 : (compile) [ 0x9e6 ] 40036a4 : (compile) [ 0xb40 ] 40036a5 : (compile) b(;) [ 0xc2 ] 40036a6 : b(lit) [ 0x10 ] 40036ac : my-space [ 0x103 ] 40036ad : + [ 0x1e ] 40036ae : b(") [ 0x12 ] (const) config-l@ 40036ba : $call-parent [ 0x209 ]
byte-load: exception caught! ok
I was just going to bypass the 64bit BAR check in Openbios as 265MB is
I'm not sure that will work without more changes, maybe the check is there for a reason.
still within the 4GB address space of 32bit but I’m going to need more space in the hole for the other BARs, no?
On real machine graphics cards probably appear on different PCI bus that has a different window but we don't quite model that in QEMU and OpenBIOS cannot handle it so you may need to hack something to allow the card to be added but I don't know what and how. Also if your host firmware setup has an option to disable resizable BARs that may help but I'm not sure.
Regards, BALATON Zoltan
On Thu, 22 May 2025, Jd Lyons wrote:
Thanks, did you ever post you patches for Openbios and the Rage128?
I’m going to need to recompile Openbios but I need your patch set if you still have it?
Yes, I've sent all my patches to the openbios list they just tend to get lost and forgotten. You may be able to dig them out from the list archive but that's also not very friendly for searching. It may help if you remember the date when we made that (I don't remember) then you could look up the archive by date. It would help if you could pick up the necessary patches and upstream them. Regards, BALATON Zoltan
I found the patch here; https://mail.coreboot.org/hyperkitty/list/openbios@openbios.org/message/JQ6V2BDIPUTDI2N4GA3OH2FEU6QEZ5H4/ But can’t seem to get the formatting correct to get it to apply?
On May 22, 2025, at 6:00 PM, BALATON Zoltan <balaton@eik.bme.hu> wrote:
On Thu, 22 May 2025, Jd Lyons wrote:
Thanks, did you ever post you patches for Openbios and the Rage128?
I’m going to need to recompile Openbios but I need your patch set if you still have it?
Yes, I've sent all my patches to the openbios list they just tend to get lost and forgotten. You may be able to dig them out from the list archive but that's also not very friendly for searching. It may help if you remember the date when we made that (I don't remember) then you could look up the archive by date. It would help if you could pick up the necessary patches and upstream them.
Regards, BALATON Zoltan
On Fri, May 23, 2025 at 4:56 PM Jd Lyons via OpenBIOS <openbios@openbios.org> wrote:
I found the patch here;
[OpenBIOS] Re: [PATCH v2] Implement missing words for the ATI FCode ROM ati-vga emulation - OpenBIOS - mail.coreboot.org <https://mail.coreboot.org/hyperkitty/list/openbios@openbios.org/message/JQ6V...> mail.coreboot.org <https://mail.coreboot.org/hyperkitty/list/openbios@openbios.org/message/JQ6V...> [image: favicon.ico] <https://mail.coreboot.org/hyperkitty/list/openbios@openbios.org/message/JQ6V...> <https://mail.coreboot.org/hyperkitty/list/openbios@openbios.org/message/JQ6V...>
But can’t seem to get the formatting correct to get it to apply?
On May 22, 2025, at 6:00 PM, BALATON Zoltan <balaton@eik.bme.hu> wrote:
On Thu, 22 May 2025, Jd Lyons wrote:
Thanks, did you ever post you patches for Openbios and the Rage128?
I’m going to need to recompile Openbios but I need your patch set if you still have it?
Yes, I've sent all my patches to the openbios list they just tend to get lost and forgotten. You may be able to dig them out from the list archive but that's also not very friendly for searching. It may help if you remember the date when we made that (I don't remember) then you could look up the archive by date. It would help if you could pick up the necessary patches and upstream them.
Regards, BALATON Zoltan
Do you have more luck with this rendering? [PATCH v2] Implement missing words for the ATI FCode ROM ati-vga emulation - OpenBIOS - mail.coreboot.org <https://mail.coreboot.org/hyperkitty/list/openbios@openbios.org/thread/HA4U6...>
I think I formatted the patch correct, but things have changed in Openbios and it will not longer apply. My attempts to fix it just resulted in an Openbios that builds but won’t POST. It’s frustrating that Balaton made these patches and we tested them at the time yet they were never upstreamed and Openbios files changed so instead of working on new code someone will have to reinvent the wheel just to get back where we were 6 years ago. diff --git a/drivers/pci.c b/drivers/pci.c index f30e427..787fa93 100644 --- a/drivers/pci.c +++ b/drivers/pci.c @@ -408,20 +408,68 @@ static void ob_pci_unmap(ucell virt, ucell size) { static void ob_pci_bus_map_in(int *idx) { - uint32_t ba; - ucell size; - ucell virt; + fword("pci-map-in"); +} - PCI_DPRINTF("ob_pci_bar_map_in idx=%p\n", idx); +static void +ob_pci_bus_map_out(int *idx) +{ + /* Should call pci-map-out but nothing to do in it yet */ + fword("2drop"); +} - size = POP(); - POP(); - POP(); - ba = POP(); +static void +ob_pci_config_read8(int *idx) +{ + cell hi = POP(); + pci_addr addr = PCI_ADDR(PCI_BUS(hi), PCI_DEV(hi), PCI_FN(hi)); + uint8_t val = pci_config_read8(addr, hi & 0xff); + PUSH(val); +} - virt = ob_pci_map(ba, size); +static void +ob_pci_config_write8(int *idx) +{ + cell hi = POP(); + pci_addr addr = PCI_ADDR(PCI_BUS(hi), PCI_DEV(hi), PCI_FN(hi)); + cell val = POP(); + pci_config_write8(addr, hi & 0xff, val); +} - PUSH(virt); +static void +ob_pci_config_read16(int *idx) +{ + cell hi = POP(); + pci_addr addr = PCI_ADDR(PCI_BUS(hi), PCI_DEV(hi), PCI_FN(hi)); + uint16_t val = pci_config_read16(addr, hi & 0xff); + PUSH(val); +} + +static void +ob_pci_config_write16(int *idx) +{ + cell hi = POP(); + pci_addr addr = PCI_ADDR(PCI_BUS(hi), PCI_DEV(hi), PCI_FN(hi)); + cell val = POP(); + pci_config_write16(addr, hi & 0xff, val); +} + +static void +ob_pci_config_read32(int *idx) +{ + cell hi = POP(); + pci_addr addr = PCI_ADDR(PCI_BUS(hi), PCI_DEV(hi), PCI_FN(hi)); + uint32_t val = pci_config_read32(addr, hi & 0xff); + PUSH(val); +} + +static void +ob_pci_config_write32(int *idx) +{ + cell hi = POP(); + pci_addr addr = PCI_ADDR(PCI_BUS(hi), PCI_DEV(hi), PCI_FN(hi)); + cell val = POP(); + pci_config_write32(addr, hi & 0xff, val); } static void @@ -459,7 +507,14 @@ NODE_METHODS(ob_pci_bus_node) = { { "close", ob_pci_close }, { "decode-unit", ob_pci_decode_unit }, { "encode-unit", ob_pci_encode_unit }, - { "pci-map-in", ob_pci_bus_map_in }, + { "map-in", ob_pci_bus_map_in }, + { "map-out", ob_pci_bus_map_out }, + { "config-b@", ob_pci_config_read8 }, + { "config-b!", ob_pci_config_write8 }, + { "config-w@", ob_pci_config_read16 }, + { "config-w!", ob_pci_config_write16 }, + { "config-l@", ob_pci_config_read32 }, + { "config-l!", ob_pci_config_write32 }, { "dma-alloc", ob_pci_dma_alloc }, { "dma-free", ob_pci_dma_free }, { "dma-map-in", ob_pci_dma_map_in }, @@ -473,7 +528,14 @@ static void ob_pci_bridge_map_in(int *idx) { /* As per the IEEE-1275 PCI specification, chain up to the parent */ - call_parent_method("pci-map-in"); + call_parent_method("map-in"); +} + +static void +ob_pci_bridge_map_out(int *idx) +{ + /* As per the IEEE-1275 PCI specification, chain up to the parent */ + call_parent_method("map-out"); } NODE_METHODS(ob_pci_bridge_node) = { @@ -481,7 +543,8 @@ NODE_METHODS(ob_pci_bridge_node) = { { "close", ob_pci_close }, { "decode-unit", ob_pci_decode_unit }, { "encode-unit", ob_pci_encode_unit }, - { "pci-map-in", ob_pci_bridge_map_in }, + { "map-in", ob_pci_bridge_map_in }, + { "map-out", ob_pci_bridge_map_out }, { "dma-alloc", ob_pci_dma_alloc }, { "dma-free", ob_pci_dma_free }, { "dma-map-in", ob_pci_dma_map_in }, diff --git a/drivers/pci.fs b/drivers/pci.fs index a7b56e1..327c9c9 100644 --- a/drivers/pci.fs +++ b/drivers/pci.fs @@ -37,4 +37,45 @@ then ; +: pci-map-in ( addr.lo addr.mid addr.hi size -- virt ) + \ Ignore everything but addr.hi and find assigned addr for BAR + drop nip nip + \ Save my-self and set it to same as active package because otherwise + \ decode-phys below seems to be confused. Maybe this should not be needed + my-self swap active-package ihandle>phandle to my-self + " assigned-addresses" active-package get-package-property 0= if + begin + decode-phys ( bar prop prop-len phys.lo phys.mid phys.hi ) + dup 0fffffff and 6 pick 0fffffff and = if + 2drop -rot + decode-int drop decode-int drop 2drop + ( bar addr.lo ) + \ Now translate addr.lo, This may be wrong + \ maybe we should look at parent's ranges instead? + over 18 rshift 3 and 1 = if + " reg" active-package parent get-package-property 0= if + ( bar addr.lo prop prop-len reg.addr reg.size ) + decode-int -rot decode-int 3drop + + + then + then + nip swap to my-self + exit + else + 3drop \ no match, try next + then + \ Drop the size as we don't need it + decode-int drop decode-int drop + dup 0= + until + 3drop + to my-self + -1 \ not found + else + drop + to my-self + -1 \ could not find assigned-addresses + then + ; + [THEN] diff --git a/drivers/vga.fs b/drivers/vga.fs index 53dcff0..f3ffda7 100644 --- a/drivers/vga.fs +++ b/drivers/vga.fs @@ -146,14 +146,14 @@ defer vbe-iow! : map-fb ( -- ) cfg-bar0 pci-bar>pci-addr if \ ( pci-addr.lo pci-addr.mid pci-addr.hi size ) - " pci-map-in" $call-parent + " map-in" $call-parent to fb-addr then ; : map-mmio ( -- ) cfg-bar2 pci-bar>pci-addr if \ ( pci-addr.lo pci-addr.mid pci-addr.hi size ) - " pci-map-in" $call-parent + " map-in" $call-parent to mmio-addr then ; diff --git a/forth/device/other.fs b/forth/device/other.fs index 1bed9b8..0ff34b6 100644 --- a/forth/device/other.fs +++ b/forth/device/other.fs @@ -58,21 +58,27 @@ defer (poke) \ 5.3.7.2 Device-register access : rb@ ( addr -- byte ) + ioc@ ; : rw@ ( waddr -- w ) + iow@ ; : rl@ ( qaddr -- quad ) + iol@ ; : rb! ( byte addr -- ) + ioc! ; : rw! ( w waddr -- ) + iow! ; : rl! ( quad qaddr -- ) + iol! ; : rx@ ( oaddr - o ) -- 2.30.4
On May 23, 2025, at 3:45 PM, Howard Spoelstra <hsp.cat7@gmail.com> wrote:
On Fri, May 23, 2025 at 4:56 PM Jd Lyons via OpenBIOS <openbios@openbios.org <mailto:openbios@openbios.org>> wrote:
I found the patch here;
[OpenBIOS] Re: [PATCH v2] Implement missing words for the ATI FCode ROM ati-vga emulation - OpenBIOS - mail.coreboot.org mail.coreboot.org
<https://mail.coreboot.org/hyperkitty/list/openbios@openbios.org/message/JQ6V2BDIPUTDI2N4GA3OH2FEU6QEZ5H4/>[OpenBIOS] Re: [PATCH v2] Implement missing words for the ATI FCode ROM ati-vga emulation - OpenBIOS - mail.coreboot.org <https://mail.coreboot.org/hyperkitty/list/openbios@openbios.org/message/JQ6V...> mail.coreboot.org <https://mail.coreboot.org/hyperkitty/list/openbios@openbios.org/message/JQ6V...> <https://mail.coreboot.org/hyperkitty/list/openbios@openbios.org/message/JQ6V2BDIPUTDI2N4GA3OH2FEU6QEZ5H4/>
But can’t seem to get the formatting correct to get it to apply?
On May 22, 2025, at 6:00 PM, BALATON Zoltan <balaton@eik.bme.hu <mailto:balaton@eik.bme.hu>> wrote:
On Thu, 22 May 2025, Jd Lyons wrote:
Thanks, did you ever post you patches for Openbios and the Rage128?
I’m going to need to recompile Openbios but I need your patch set if you still have it?
Yes, I've sent all my patches to the openbios list they just tend to get lost and forgotten. You may be able to dig them out from the list archive but that's also not very friendly for searching. It may help if you remember the date when we made that (I don't remember) then you could look up the archive by date. It would help if you could pick up the necessary patches and upstream them.
Regards, BALATON Zoltan
Do you have more luck with this rendering? [PATCH v2] Implement missing words for the ATI FCode ROM ati-vga emulation - OpenBIOS - mail.coreboot.org <https://mail.coreboot.org/hyperkitty/list/openbios@openbios.org/thread/HA4U6...>
I don’t know errors on a clean master with this diff but I’m not sure what exactly is going wrong as the code hasn’t changed the much: diff --git a/drivers/pci.c b/drivers/pci.c index f30e427..1836034 100644 --- a/drivers/pci.c +++ b/drivers/pci.c @@ -408,20 +408,76 @@ static void ob_pci_unmap(ucell virt, ucell size) { static void ob_pci_bus_map_in(int *idx) { - uint32_t ba; - ucell size; - ucell virt; + cell size = POP(); + (void)POP(); /* Discard hi */ + (void)POP(); /* Discard mid */ + cell lo = POP(); + uint32_t ba = lo; /* Use low part of address for mapping */ + ucell virt = ob_pci_map(ba, size); + PUSH(virt); + } + + static void + ob_pci_bus_map_out(int *idx) + { + cell size = POP(); + cell virt = POP(); + ob_pci_unmap(virt, size); + } + + +static void +ob_pci_config_read8(int *idx) +{ + cell hi = POP(); + pci_addr addr = PCI_ADDR(PCI_BUS(hi), PCI_DEV(hi), PCI_FN(hi)); + uint8_t val = pci_config_read8(addr, hi & 0xff); + PUSH(val); +} + +static void +ob_pci_config_write8(int *idx) +{ + cell hi = POP(); + pci_addr addr = PCI_ADDR(PCI_BUS(hi), PCI_DEV(hi), PCI_FN(hi)); + cell val = POP(); + pci_config_write8(addr, hi & 0xff, val); +} - PCI_DPRINTF("ob_pci_bar_map_in idx=%p\n", idx); +static void +ob_pci_config_read16(int *idx) +{ + cell hi = POP(); + pci_addr addr = PCI_ADDR(PCI_BUS(hi), PCI_DEV(hi), PCI_FN(hi)); + uint16_t val = pci_config_read16(addr, hi & 0xff); + PUSH(val); +} - size = POP(); - POP(); - POP(); - ba = POP(); +static void +ob_pci_config_write16(int *idx) +{ + cell hi = POP(); + pci_addr addr = PCI_ADDR(PCI_BUS(hi), PCI_DEV(hi), PCI_FN(hi)); + cell val = POP(); + pci_config_write16(addr, hi & 0xff, val); +} - virt = ob_pci_map(ba, size); +static void +ob_pci_config_read32(int *idx) +{ + cell hi = POP(); + pci_addr addr = PCI_ADDR(PCI_BUS(hi), PCI_DEV(hi), PCI_FN(hi)); + uint32_t val = pci_config_read32(addr, hi & 0xff); + PUSH(val); +} - PUSH(virt); +static void +ob_pci_config_write32(int *idx) +{ + cell hi = POP(); + pci_addr addr = PCI_ADDR(PCI_BUS(hi), PCI_DEV(hi), PCI_FN(hi)); + cell val = POP(); + pci_config_write32(addr, hi & 0xff, val); } static void @@ -459,7 +515,14 @@ NODE_METHODS(ob_pci_bus_node) = { { "close", ob_pci_close }, { "decode-unit", ob_pci_decode_unit }, { "encode-unit", ob_pci_encode_unit }, - { "pci-map-in", ob_pci_bus_map_in }, + { "map-in", ob_pci_bus_map_in }, + { "map-out", ob_pci_bus_map_out }, + { "config-b@", ob_pci_config_read8 }, + { "config-b!", ob_pci_config_write8 }, + { "config-w@", ob_pci_config_read16 }, + { "config-w!", ob_pci_config_write16 }, + { "config-l@", ob_pci_config_read32 }, + { "config-l!", ob_pci_config_write32 }, { "dma-alloc", ob_pci_dma_alloc }, { "dma-free", ob_pci_dma_free }, { "dma-map-in", ob_pci_dma_map_in }, @@ -473,7 +536,14 @@ static void ob_pci_bridge_map_in(int *idx) { /* As per the IEEE-1275 PCI specification, chain up to the parent */ - call_parent_method("pci-map-in"); + call_parent_method("map-in"); + } + + static void + ob_pci_bridge_map_out(int *idx) + { + /* As per the IEEE-1275 PCI specification, chain up to the parent */ + call_parent_method("map-out"); } NODE_METHODS(ob_pci_bridge_node) = { @@ -481,7 +551,8 @@ NODE_METHODS(ob_pci_bridge_node) = { { "close", ob_pci_close }, { "decode-unit", ob_pci_decode_unit }, { "encode-unit", ob_pci_encode_unit }, - { "pci-map-in", ob_pci_bridge_map_in }, + { "map-in", ob_pci_bridge_map_in }, + { "map-out", ob_pci_bridge_map_out }, { "dma-alloc", ob_pci_dma_alloc }, { "dma-free", ob_pci_dma_free }, { "dma-map-in", ob_pci_dma_map_in }, diff --git a/drivers/pci.fs b/drivers/pci.fs index a7b56e1..6924b71 100644 --- a/drivers/pci.fs +++ b/drivers/pci.fs @@ -37,4 +37,44 @@ then ; + drop nip nip + \ Save my-self and set it to same as active package because otherwise + \ decode-phys below seems to be confused. Maybe this should not be needed + my-self swap active-package ihandle>phandle to my-self + " assigned-addresses" active-package get-package-property 0= if + begin + decode-phys ( bar prop prop-len phys.lo phys.mid phys.hi ) + dup 0fffffff and 6 pick 0fffffff and = if + 2drop -rot + decode-int drop decode-int drop 2drop + ( bar addr.lo ) + \ Now translate addr.lo, This may be wrong + \ maybe we should look at parent's ranges instead? + over 18 rshift 3 and 1 = if + " reg" active-package parent get-package-property 0= if + ( bar addr.lo prop prop-len reg.addr reg.size ) + decode-int -rot decode-int 3drop + + + then + then + nip swap to my-self + exit + else + 3drop \ no match, try next + then + \ Drop the size as we don't need it + decode-int drop decode-int drop + dup 0= + until + 3drop + to my-self + -1 \ not found + else + drop +to my-self + -1 \ could not find assigned-addresses + then + ; + + [THEN] diff --git a/drivers/vga.fs b/drivers/vga.fs index 53dcff0..f3ffda7 100644 --- a/drivers/vga.fs +++ b/drivers/vga.fs @@ -146,14 +146,14 @@ defer vbe-iow! : map-fb ( -- ) cfg-bar0 pci-bar>pci-addr if \ ( pci-addr.lo pci-addr.mid pci-addr.hi size ) - " pci-map-in" $call-parent + " map-in" $call-parent to fb-addr then ; : map-mmio ( -- ) cfg-bar2 pci-bar>pci-addr if \ ( pci-addr.lo pci-addr.mid pci-addr.hi size ) - " pci-map-in" $call-parent + " map-in" $call-parent to mmio-addr then ; diff --git a/forth/device/other.fs b/forth/device/other.fs index 1bed9b8..11a5b8d 100644 --- a/forth/device/other.fs +++ b/forth/device/other.fs @@ -37,7 +37,8 @@ defer (peek) ['] l@ (peek) ; -defer (poke) + + :noname execute true ; to (poke) @@ -58,22 +59,28 @@ defer (poke) \ 5.3.7.2 Device-register access : rb@ ( addr -- byte ) - ; + ioc@ + ; : rw@ ( waddr -- w ) - ; + iow@ + ; : rl@ ( qaddr -- quad ) - ; + iol@ + ; : rb! ( byte addr -- ) - ; + ioc! + ; : rw! ( w waddr -- ) - ; + iow! + ; : rl! ( quad qaddr -- ) - ; + iol! + ; : rx@ ( oaddr - o ) state @ if make clean Cleaning up... make[1]: Entering directory '/data/ati2/openbios/obj-ppc' Cleaning up for ppc... ok make[1]: Leaving directory '/data/ati2/openbios/obj-ppc' root@beb8f7168fce:/data/ati2/openbios# make -j8 Building OpenBIOS for ppc Building... /usr/bin/xsltproc error: AR libpackages.a powerpc-linux-gnu-ar: `u' modifier ignored since `D' is the default (see `U') AR libdrivers.a AR libfs.a AR liblibc.a powerpc-linux-gnu-ar: `u' modifier ignored since `D' is the default (see `U')powerpc-linux-gnu-ar: `u' modifier ignored since `D' is the default (see `U') powerpc-linux-gnu-ar: `u' modifier ignored since `D' is the default (see `U') AR libgcc.a powerpc-linux-gnu-ar: `u' modifier ignored since `D' is the default (see `U') GEN bootstrap.dict GEN openbios.dict forth/device/other.fs:45: undefined word. make[1]: *** [rules.mak:72: openbios.dict] Error 1 make[1]: Leaving directory '/data/ati2/openbios/obj-ppc' make: *** [Makefile:19: build] Error 1
On May 23, 2025, at 3:45 PM, Howard Spoelstra <hsp.cat7@gmail.com> wrote:
On Fri, May 23, 2025 at 4:56 PM Jd Lyons via OpenBIOS <openbios@openbios.org <mailto:openbios@openbios.org>> wrote:
I found the patch here;
[OpenBIOS] Re: [PATCH v2] Implement missing words for the ATI FCode ROM ati-vga emulation - OpenBIOS - mail.coreboot.org mail.coreboot.org <favicon.ico> <https://mail.coreboot.org/hyperkitty/list/openbios@openbios.org/message/JQ6V2BDIPUTDI2N4GA3OH2FEU6QEZ5H4/>[OpenBIOS] Re: [PATCH v2] Implement missing words for the ATI FCode ROM ati-vga emulation - OpenBIOS - mail.coreboot.org <https://mail.coreboot.org/hyperkitty/list/openbios@openbios.org/message/JQ6V...> mail.coreboot.org <https://mail.coreboot.org/hyperkitty/list/openbios@openbios.org/message/JQ6V...> <favicon.ico> <https://mail.coreboot.org/hyperkitty/list/openbios@openbios.org/message/JQ6V...>
But can’t seem to get the formatting correct to get it to apply?
On May 22, 2025, at 6:00 PM, BALATON Zoltan <balaton@eik.bme.hu <mailto:balaton@eik.bme.hu>> wrote:
On Thu, 22 May 2025, Jd Lyons wrote:
Thanks, did you ever post you patches for Openbios and the Rage128?
I’m going to need to recompile Openbios but I need your patch set if you still have it?
Yes, I've sent all my patches to the openbios list they just tend to get lost and forgotten. You may be able to dig them out from the list archive but that's also not very friendly for searching. It may help if you remember the date when we made that (I don't remember) then you could look up the archive by date. It would help if you could pick up the necessary patches and upstream them.
Regards, BALATON Zoltan
Do you have more luck with this rendering? [PATCH v2] Implement missing words for the ATI FCode ROM ati-vga emulation - OpenBIOS - mail.coreboot.org <https://mail.coreboot.org/hyperkitty/list/openbios@openbios.org/thread/HA4U6...>
This words are not defined as forth words? I keep getting compile errors on these words as undefined, the patch is incomplete.
On May 24, 2025, at 1:33 PM, Jd Lyons <lyons_dj@yahoo.com> wrote:
: rb@ ( addr -- byte ) - ; + ioc@ + ;
: rw@ ( waddr -- w ) - ; + iow@ + ;
: rl@ ( qaddr -- quad ) - ; + iol@ + ;
: rb! ( byte addr -- ) - ; + ioc! + ;
: rw! ( w waddr -- ) - ; + iow! + ;
: rl! ( quad qaddr -- ) - ; + iol! + ;
On Tue, May 27, 2025 at 4:03 PM Jd Lyons <lyons_dj@yahoo.com> wrote:
This words are not defined as forth words?
I keep getting compile errors on these words as undefined, the patch is incomplete.
On May 24, 2025, at 1:33 PM, Jd Lyons <lyons_dj@yahoo.com> wrote:
: rb@ ( addr -- byte ) - ; + ioc@ + ;
: rw@ ( waddr -- w ) - ; + iow@ + ;
: rl@ ( qaddr -- quad ) - ; + iol@ + ;
: rb! ( byte addr -- ) - ; + ioc! + ;
: rw! ( w waddr -- ) - ; + iow! + ;
: rl! ( quad qaddr -- ) - ; + iol! + ;
I remember running into that as well. I patched these few instances by hand. Best, Howard
Do you remember how you patched them tho? For the life of me I can’t figure it.
On May 28, 2025, at 12:03 PM, Howard Spoelstra <hsp.cat7@gmail.com> wrote:
On Tue, May 27, 2025 at 4:03 PM Jd Lyons <lyons_dj@yahoo.com <mailto:lyons_dj@yahoo.com>> wrote:
This words are not defined as forth words?
I keep getting compile errors on these words as undefined, the patch is incomplete.
On May 24, 2025, at 1:33 PM, Jd Lyons <lyons_dj@yahoo.com <mailto:lyons_dj@yahoo.com>> wrote:
: rb@ ( addr -- byte ) - ; + ioc@ + ;
: rw@ ( waddr -- w ) - ; + iow@ + ;
: rl@ ( qaddr -- quad ) - ; + iol@ + ;
: rb! ( byte addr -- ) - ; + ioc! + ;
: rw! ( w waddr -- ) - ; + iow! + ;
: rl! ( quad qaddr -- ) - ; + iol! + ;
I remember running into that as well. I patched these few instances by hand. Best, Howard
On Thu, 29 May 2025, Jd Lyons via OpenBIOS wrote:
Do you remember how you patched them tho?
I don't remember much about these but in this thread: https://mail.coreboot.org/archives/list/openbios@openbios.org/thread/72WONUF... I concluded these aren't correct anyway so would need to be implemented in some other way. Regards, BALATON Zoltan
On Thu, May 29, 2025 at 04:39:52PM +0200, BALATON Zoltan wrote:
On Thu, 29 May 2025, Jd Lyons via OpenBIOS wrote:
Do you remember how you patched them tho?
I don't remember much about these but in this thread: https://mail.coreboot.org/archives/list/openbios@openbios.org/thread/72WONUF... I concluded these aren't correct anyway so would need to be implemented in some other way.
No matter how you do it it needs some indirection, each bus can implement things a totally different way, and that applies to all its children. Segher
I mean it was good enough that I was able to use a PCI Rage128 in PCI Passthough and it worked fine under OS X Tiger. 2D and 3D acceleration worked fine in my tests. The perfect is the enemy of the good enough. I still have the GF6600 and X1950 XT but they bomb out trying to run the fcode in Openbios. The 6600 works in some ways with SLOF, but the X1950 crashes the host executing the FCode ROM. I have set some debug code to try and figure what Openbios is catching the default catch in the x1950 ROM, it’s around the code for the VRAM BAR and I’m just not sure is my-space is returning the correct value, I tried to add some debug code for that but must have the syntax wrong because I never see the output? : colon_definition_function_be1 \ (be1) [0b5 0b7] " DBG: Enter be1" type \ Debug: Entering be1 1010101 \ [010] " DBG: Pushed 1010101" type \ Debug: After pushing constant const_9de_7af0 \ (9de 7af0) [9de] " DBG: const_9de_7af0" type \ Debug: After pushing const_9de_7af0 colon_definition_function_b40 \ (b40) [b40] " DBG: After b40_1" type \ Debug: After first b40 call 0 \ [0a5] const_9e3_7b04 \ (9e3 7b04) [9e3] " DBG: const_9e3_7b04" type \ Debug: After pushing const_9e3_7b04 colon_definition_function_b40 \ (b40) [b40] " DBG: After b40_2" type \ Debug: After second b40 call const_9c2_7a80 \ (9c2 7a80) [9c2] colon_definition_function_b3d \ (b3d) [b3d] " DBG: After b3d_1" type \ Debug: After first b3d call 1 \ [0a6] invert \ [026] " DBG: After invert_1" type \ Debug: After first invert and \ [023] " DBG: After and_1" type \ Debug: After first and const_9c2_7a80 \ (9c2 7a80) [9c2] colon_definition_function_b40 \ (b40) [b40] " DBG: After b40_3" type \ Debug: After third b40 call const_9e6_7b10 \ (9e6 7b10) [9e6] colon_definition_function_b3d \ (b3d) [b3d] " DBG: After b3d_2" type \ Debug: After second b3d call 1 \ [0a6] invert \ [026] " DBG: After invert_2" type \ Debug: After second invert and \ [023] " DBG: After and_2" type \ Debug: After second and 2 \ [0a7] or \ [024] " DBG: After or" type \ Debug: After or const_9e6_7b10 \ (9e6 7b10) [9e6] colon_definition_function_b40 \ (b40) [b40] " DBG: After b40_4" type \ Debug: After fourth b40 call ; \ [0c2] " DBG: Exit be1" type \ Debug: Exiting be1 10 \ [010] my-space \ [103] + \ [01e] " DBG: Before config-l@_1" type \ Debug: Before first config-l@ " config-l@" \ [012] $call-parent \ [209] " DBG: After config-l@_1" type \ Debug: After first config-l@ -1 \ [010] 10 \ [010] my-space \ [103] + \ [01e] " DBG: Before config-l!_1" type \ Debug: Before first config-l! " config-l!" \ [012] $call-parent \ [209] " DBG: After config-l!_1" type \ Debug: After first config-l! 10 \ [010] my-space \ [103] + \ [01e] " DBG: Before config-l@_2" type \ Debug: Before second config-l@ " config-l@" \ [012] $call-parent \ [209] " DBG: After config-l@_2" type \ Debug: After second config-l@ 0f \ [010] invert \ [026] and \ [023] " DBG: After and_3" type \ Debug: After third and invert \ [026] 1+ \ [0a6 01e] " DBG: After 1+_1" type \ Debug: After first 1+ to value_9f9_10000000 \ (9f9 10000000) [0c3 9f9] " DBG: After to value_9f9" type \ Debug: After storing to value_9f9 10 \ [010] my-space \ [103] + \ [01e] " DBG: Before config-l!_2" type \ Debug: Before second config-l! " config-l!" \ [012] $call-parent \ [209] " DBG: After config-l!_2" type \ Debug: After second config-l! 18 \ [010] my-space \ [103] + \ [01e] " DBG: Before config-l@_3" type \ Debug: Before third config-l@ " config-l@" \ [012] $call-parent \ [209] " DBG: After config-l@_3" type \ Debug: After third config-l@ -1 \ [010] 18 \ [010] my-space \ [103] + \ [01e] " DBG: Before config-l!_3" type \ Debug: Before third config-l! " config-l!" \ [012] $call-parent \ [209] " DBG: After config-l!_3" type \ Debug: After third config-l! 18 \ [010] my-space \ [103] + \ [01e] " DBG: Before config-l@_4" type \ Debug: Before fourth config-l@ " config-l@" \ [012] $call-parent \ [209] " DBG: After config-l@_4" type \ Debug: After fourth config-l@ 0f \ [010] invert \ [026] and \ [023] " DBG: After and_4" type \ Debug: After fourth and invert \ [026] 1+ \ [0a6 01e] " DBG: After 1+_2" type \ Debug: After second 1+ to value_9fb_10000 \ (9fb 10000) [0c3 9fb] " DBG: After to value_9fb" type \ Debug: After storing to value_9fb 18 \ [010] my-space \ [103] + \ [01e] " DBG: Before config-l!_4" type \ Debug: Before fourth config-l! " config-l!" \ [012] $call-parent \ [209] " DBG: After config-l!_4" type \ Debug: After fourth config-l! : new-token [ 0xb5 ] (fcode#) be1 40035d6 : b(:) [ 0xb7 ] 40035d7 : (compile) b(") [ 0x12 ] (const) DBG: Enter be1 40035e7 : (compile) type [ 0x90 ] 40035e8 : (compile) b(lit) [ 0x10 ] 40035ed : (compile) b(") [ 0x12 ] (const) DBG: Pushed 1010101 4003602 : (compile) type [ 0x90 ] 4003604 : (compile) [ 0x9de ] 4003605 : (compile) b(") [ 0x12 ] (const) DBG: const_9de_7af0 400361a : (compile) type [ 0x90 ] 400361c : (compile) [ 0xb40 ] 400361d : (compile) b(") [ 0x12 ] (const) DBG: After b40_1 400362f : (compile) type [ 0x90 ] 4003630 : (compile) 0 [ 0xa5 ] 4003632 : (compile) [ 0x9e3 ] 4003633 : (compile) b(") [ 0x12 ] (const) DBG: const_9e3_7b04 4003648 : (compile) type [ 0x90 ] 400364a : (compile) [ 0xb40 ] 400364b : (compile) b(") [ 0x12 ] (const) DBG: After b40_2 400365d : (compile) type [ 0x90 ] 400365f : (compile) [ 0x9c2 ] 4003661 : (compile) [ 0xb3d ] 4003662 : (compile) b(") [ 0x12 ] (const) DBG: After b3d_1 4003674 : (compile) type [ 0x90 ] 4003675 : (compile) 1 [ 0xa6 ] 4003676 : (compile) invert [ 0x26 ] 4003677 : (compile) b(") [ 0x12 ] (const) DBG: After invert_1 400368c : (compile) type [ 0x90 ] 400368d : (compile) and [ 0x23 ] 400368e : (compile) b(") [ 0x12 ] (const) DBG: After and_1 40036a0 : (compile) type [ 0x90 ] 40036a2 : (compile) [ 0x9c2 ] 40036a4 : (compile) [ 0xb40 ] 40036a5 : (compile) b(") [ 0x12 ] (const) DBG: After b40_3 40036b7 : (compile) type [ 0x90 ] 40036b9 : (compile) [ 0x9e6 ] 40036bb : (compile) [ 0xb3d ] 40036bc : (compile) b(") [ 0x12 ] (const) DBG: After b3d_2 40036ce : (compile) type [ 0x90 ] 40036cf : (compile) 1 [ 0xa6 ] 40036d0 : (compile) invert [ 0x26 ] 40036d1 : (compile) b(") [ 0x12 ] (const) DBG: After invert_2 40036e6 : (compile) type [ 0x90 ] 40036e7 : (compile) and [ 0x23 ] 40036e8 : (compile) b(") [ 0x12 ] (const) DBG: After and_2 40036fa : (compile) type [ 0x90 ] 40036fb : (compile) 2 [ 0xa7 ] 40036fc : (compile) or [ 0x24 ] 40036fd : (compile) b(") [ 0x12 ] (const) DBG: After or 400370c : (compile) type [ 0x90 ] 400370e : (compile) [ 0x9e6 ] 4003710 : (compile) [ 0xb40 ] 4003711 : (compile) b(") [ 0x12 ] (const) DBG: After b40_4 4003723 : (compile) type [ 0x90 ] 4003724 : (compile) b(;) [ 0xc2 ] 4003725 : b(") [ 0x12 ] (const) DBG: Exit be1 4003734 : type [ 0x90 ] DBG: Exit be14003735 : b(lit) [ 0x10 ] 400373b : my-space [ 0x103 ] 400373c : + [ 0x1e ] 400373d : b(") [ 0x12 ] (const) DBG: Before config-l@_1 4003756 : type [ 0x90 ] DBG: Before config-l@_14003757 : b(") [ 0x12 ] (const) config-l@ 4003763 : $call-parent [ 0x209 ] byte-load: exception caught! ok
On May 29, 2025, at 10:39 AM, BALATON Zoltan <balaton@eik.bme.hu> wrote:
On Thu, 29 May 2025, Jd Lyons via OpenBIOS wrote:
Do you remember how you patched them tho?
I don't remember much about these but in this thread: https://mail.coreboot.org/archives/list/openbios@openbios.org/thread/72WONUF... I concluded these aren't correct anyway so would need to be implemented in some other way.
Regards, BALATON Zoltan
On Fri, 30 May 2025, Jd Lyons wrote:
I mean it was good enough that I was able to use a PCI Rage128 in PCI Passthough and it worked fine under OS X Tiger. 2D and 3D acceleration worked fine in my tests.
The perfect is the enemy of the good enough.
Completely wrong may not be good enough though. Maybe the Rage128 ROM did not use these or wasn't critical but for other cards may need better implementation that actually does what it should.
I still have the GF6600 and X1950 XT but they bomb out trying to run the fcode in Openbios. The 6600 works in some ways with SLOF, but the X1950 crashes the host executing the FCode ROM.
Do you by chance have Intel iGPU? That is not compatible with GPU passthrough so you may need two graphics cards or a kernel patch to avoid the hang. Or did this hang happened on second run of QEMU? I saw this when GPU was not fully init by the guest, then second try freezes host. You need to reboot after every QEMU run or try another kernel patch. I have some info on this here: http://qmiga.codeberg.page/qemu_vfio.html Regards, BALATON Zoltan
I have a Core 7 Ultra 265k and I do use the on-chip graphics to display the host linux desktop, but it’s not an issue with qemu-system-x86 With passthrough of a GF6600 or X1950. I can normally boot/shutdown/boot the x86 virtual machine as may times as I like without a reboot of the host. This was not the case a few years back when I was booting the macOS and passing through a R580X, each boot required a reboot. Doesn’t seem to be an issue with this setup. The config-l@ and config-l! Words are not working and I’m not even sure they exist in the prebuilt binary Howard has posted at emaculation, the Rage128 doesn’t use them only config words in the Fcode rom v136 are config-b@ and config-b!. So I don’t know if they were included in the patched binary I have, or they are global words not on the /pci node and I just don’t know how to dump openbios’s full dictionary?
On May 31, 2025, at 7:28 AM, BALATON Zoltan <balaton@eik.bme.hu> wrote:
On Fri, 30 May 2025, Jd Lyons wrote:
I mean it was good enough that I was able to use a PCI Rage128 in PCI Passthough and it worked fine under OS X Tiger. 2D and 3D acceleration worked fine in my tests.
The perfect is the enemy of the good enough.
Completely wrong may not be good enough though. Maybe the Rage128 ROM did not use these or wasn't critical but for other cards may need better implementation that actually does what it should.
I still have the GF6600 and X1950 XT but they bomb out trying to run the fcode in Openbios. The 6600 works in some ways with SLOF, but the X1950 crashes the host executing the FCode ROM.
Do you by chance have Intel iGPU? That is not compatible with GPU passthrough so you may need two graphics cards or a kernel patch to avoid the hang. Or did this hang happened on second run of QEMU? I saw this when GPU was not fully init by the guest, then second try freezes host. You need to reboot after every QEMU run or try another kernel patch. I have some info on this here: http://qmiga.codeberg.page/qemu_vfio.html
Regards, BALATON Zoltan
On Sun, 1 Jun 2025, Jd Lyons wrote:
I have a Core 7 Ultra 265k and I do use the on-chip graphics to display the host linux desktop, but it’s not an issue with qemu-system-x86 With passthrough of a GF6600 or X1950.
With x86_64 you can avoid the problem if using OVMF/UEFI and the card has a UEFI ROM, then x-vga=on is not needed and won't clash with Intel iGPU. I don't know if the Mac ROM needs VGA, maybe it doesn't but the BIOS ROM needs it on most older cards. If you see corrupted graphics on host when starting QEMU with passed through card then likely VGA writes go to the iGPU instead of the passed through card which is the sign of this issue. You can avoid that by not using x-vga=on but then the passed through card won't be init correctly. It may still work with better drivers that can init the card without BIOS but MacOS likely depends on the ROM to set up the card and the device tree.
I can normally boot/shutdown/boot the x86 virtual machine as may times as I like without a reboot of the host. This was not the case a few years back when I was booting the macOS and passing through a R580X, each boot required a reboot.
The reboot problem may only affect ATI/AMD cards or when the card was not correctly init so it's left in some half inited state, then the next attempt to use it can freeze the host. I have links on the page I have quoted before about these and how to fix them. I have the same problem with an ATI card that works with Linux guest even multiple times but the AmigaOS driver hangs with no picture. Then if I stop QEMU and try to run it again the host will freeze but can reboot before starting QEMU again then it can be used again. The reboot problem may be a bit different as that was seen with cards that worked but but after shutting down the guest it could not be used again until host reboot. There's an off-tree kernel module to fix that for some cards (again, link on my page).
Doesn’t seem to be an issue with this setup.
The config-l@ and config-l! Words are not working and I’m not even sure they exist in the prebuilt binary Howard has posted at emaculation, the
Howard should really include the source with GPL binaries otherwise they cannot be legally distributed.
Rage128 doesn’t use them only config words in the Fcode rom v136 are config-b@ and config-b!.
So I don’t know if they were included in the patched binary I have, or they are global words not on the /pci node and I just don’t know how to dump openbios’s full dictionary?
They should be per node so you could list them with cd /pci and then "words". Regards, BALATON Zoltan
I got Balaton’s V2 patch to work and the FCode for the X1950XT now completes to end, but I haven’t gotten video from a connected display and the display node does not include an EDID. So there is still some work to do there, it would be helpful if I could use qemu-vga or ati-vga to get to the OS X desktop and poke the card with it’s driver. All the tools I use require GUI. The issue is OpenBIOS does not seem to be able to manage more than one VGA card, even if the other VGA card is not using a FCode ROM: You don’t even need to Passthrough a VGA card, just append -vga std and -device ati-vga and qemu can’t initialize the display, but you can boot with —no graphic and both VGA cards are setup on the /pci bus. Can anyone point me to the code where we may be able to resolve OpenBIOS’s issue with two VGA cards?
On Jun 1, 2025, at 11:38 AM, Jd Lyons <lyons_dj@yahoo.com> wrote:
I have a Core 7 Ultra 265k and I do use the on-chip graphics to display the host linux desktop, but it’s not an issue with qemu-system-x86 With passthrough of a GF6600 or X1950.
I can normally boot/shutdown/boot the x86 virtual machine as may times as I like without a reboot of the host. This was not the case a few years back when I was booting the macOS and passing through a R580X, each boot required a reboot.
Doesn’t seem to be an issue with this setup.
The config-l@ and config-l! Words are not working and I’m not even sure they exist in the prebuilt binary Howard has posted at emaculation, the Rage128 doesn’t use them only config words in the Fcode rom v136 are config-b@ and config-b!.
So I don’t know if they were included in the patched binary I have, or they are global words not on the /pci node and I just don’t know how to dump openbios’s full dictionary?
On May 31, 2025, at 7:28 AM, BALATON Zoltan <balaton@eik.bme.hu> wrote:
On Fri, 30 May 2025, Jd Lyons wrote:
I mean it was good enough that I was able to use a PCI Rage128 in PCI Passthough and it worked fine under OS X Tiger. 2D and 3D acceleration worked fine in my tests.
The perfect is the enemy of the good enough.
Completely wrong may not be good enough though. Maybe the Rage128 ROM did not use these or wasn't critical but for other cards may need better implementation that actually does what it should.
I still have the GF6600 and X1950 XT but they bomb out trying to run the fcode in Openbios. The 6600 works in some ways with SLOF, but the X1950 crashes the host executing the FCode ROM.
Do you by chance have Intel iGPU? That is not compatible with GPU passthrough so you may need two graphics cards or a kernel patch to avoid the hang. Or did this hang happened on second run of QEMU? I saw this when GPU was not fully init by the guest, then second try freezes host. You need to reboot after every QEMU run or try another kernel patch. I have some info on this here: http://qmiga.codeberg.page/qemu_vfio.html
Regards, BALATON Zoltan
On Mon, 2 Jun 2025, Jd Lyons wrote:
I got Balaton’s V2 patch to work and the FCode for the X1950XT now completes to end, but I haven’t gotten video from a connected display and the display node does not include an EDID.
So there is still some work to do there, it would be helpful if I could use qemu-vga or ati-vga to get to the OS X desktop and poke the card with it’s driver. All the tools I use require GUI.
The ati-vga did work with MacOS but only in frame buffer mode with the extensions disabled as no advanced features of the card are emulated. Howard had a guide on this somewhere or there were messages on the list. (These chips evolved from a simple VGA controller to a full 3D accelerator with adding a 2D acceleration inbetween and all layers were kept for compatibility so it has a lot of features and some of them are undocumented. Therefore it's quote a complex device with a lot of things to emulate and most of that is still missing. But for simple frame buffer with some simple 2D acceleration it should work.)
The issue is OpenBIOS does not seem to be able to manage more than one VGA card, even if the other VGA card is not using a FCode ROM:
Are you by chance being bitten by this: https://patchew.org/QEMU/cover.1672868854.git.balaton@eik.bme.hu/e8d6aa41eeb... I've tried to fix that 2 years ago but could not get it accepted so you always need to disable the silly behaviour of OpenBIOS to install an NDRV for cards that does not work with them.
You don’t even need to Passthrough a VGA card, just append -vga std and -device ati-vga and qemu can’t initialize the display, but you can boot with —no graphic and both VGA cards are setup on the /pci bus.
This may be a separate issue but maybe it has nothing to do with OpenBIOS. Both of these cards may claim legacy VGA ports which does not work. You need to use instead of -vga std either -device secondary-vga or -device bochs-display which can be added as second display as they don't have legacy VGA ports. Regards, BALATON Zoltan
Pretty sure openbios doesn’t give an ’ndrv’ to every vga device anymore. -device bochs-display does work with VGA std so I’m not sure why I can’t use -vga std with PCI Passthrough of a VGA card?
On Jun 2, 2025, at 8:13 AM, BALATON Zoltan <balaton@eik.bme.hu> wrote:
On Mon, 2 Jun 2025, Jd Lyons wrote:
I got Balaton’s V2 patch to work and the FCode for the X1950XT now completes to end, but I haven’t gotten video from a connected display and the display node does not include an EDID.
So there is still some work to do there, it would be helpful if I could use qemu-vga or ati-vga to get to the OS X desktop and poke the card with it’s driver. All the tools I use require GUI.
The ati-vga did work with MacOS but only in frame buffer mode with the extensions disabled as no advanced features of the card are emulated. Howard had a guide on this somewhere or there were messages on the list. (These chips evolved from a simple VGA controller to a full 3D accelerator with adding a 2D acceleration inbetween and all layers were kept for compatibility so it has a lot of features and some of them are undocumented. Therefore it's quote a complex device with a lot of things to emulate and most of that is still missing. But for simple frame buffer with some simple 2D acceleration it should work.)
The issue is OpenBIOS does not seem to be able to manage more than one VGA card, even if the other VGA card is not using a FCode ROM:
Are you by chance being bitten by this: https://patchew.org/QEMU/cover.1672868854.git.balaton@eik.bme.hu/e8d6aa41eeb... I've tried to fix that 2 years ago but could not get it accepted so you always need to disable the silly behaviour of OpenBIOS to install an NDRV for cards that does not work with them.
You don’t even need to Passthrough a VGA card, just append -vga std and -device ati-vga and qemu can’t initialize the display, but you can boot with —no graphic and both VGA cards are setup on the /pci bus.
This may be a separate issue but maybe it has nothing to do with OpenBIOS. Both of these cards may claim legacy VGA ports which does not work. You need to use instead of -vga std either -device secondary-vga or -device bochs-display which can be added as second display as they don't have legacy VGA ports.
Regards, BALATON Zoltan
On Mon, 2 Jun 2025, Jd Lyons wrote:
Pretty sure openbios doesn’t give an ’ndrv’ to every vga device anymore.
Have you cheched? $ ./qemu-system-ppc -device ati-vga -nographic [...]
OpenBIOS 1.1 [Sep 24 2024 19:56] [...] 0 > cd /pci ok 0 > ls fff62120 NE2000@1 fff624d4 ATY@2 fff67b18 mac-io@10 0 > cd ATY ok 0 > .properties [...] driver,AAPL,MacOS,PowerPC -- 4941 : 4a 6f 79 21 70 65 66 66 70 77 70 63 00 00 00
This should not be there otherwise the ROM will not add its own correct driver and this one likely does not work with an ATI card. The QEMU patch I posted fixed this without any changes needed in OpenBIOS but as usual I was told to fix OpenBIOS instead which I don't want to do especially if the suggested way would make it more complex instead of simpler that my patch would have allowed.
-device bochs-display does work with VGA std so I’m not sure why I can’t use -vga std with PCI Passthrough of a VGA card?
Because both of them have legacy VGA ports and only one card can have it in the system. With a passed thorugh card that should be the real card with x-vga=on otherwise if the ROM accessses those ports it won't go to the card but to an emulated device so part of the init of the card will be missing. But x-vga=on does not work if you have Intel iGPU unless you patch i915 Linux driver because it does not release VGA ports so it will corrupt host display instead and ROM can still not access real card. But it may be an Apple FCode ROM does not need legacy VGA ports so only the OpenBIOS NDRV bug is biting you which you can disabled with a command line option then it may work but I always forget about that and spend days to debug it until I remember it again. That's what motivated the patch but I wasn't successful in helping others avoiding the same issue again and again. Regards, BALATON Zoltan
I remember us going over this with my PCI Pasthrough of the GF6600, there are issues with ‘ms’ seems the code defaults it to zero either using out-ticks or the dummy path, we talked about it but it doesn’t seem to be fixed? I’m having an issue with the X1950 FCode not getting the EDID of a connected display and it seems to be a timing issue over DDC which seems very sensitive to timings or that’s what my thinking is right now. The full FCode completes to end without errors but the EDID of the connected display never gets detected. The FCode calls ms several times in it’s EDID/DDC2 code, so I don’t think the way we do ms/msecs/obpt-ticks is going to work for this. Likely deserves it’s own thread, but maybe we already had one about ms? I can’t seem to find it if we did.
On Jun 2, 2025, at 10:01 AM, BALATON Zoltan <balaton@eik.bme.hu> wrote:
On Mon, 2 Jun 2025, Jd Lyons wrote:
Pretty sure openbios doesn’t give an ’ndrv’ to every vga device anymore.
Have you cheched?
$ ./qemu-system-ppc -device ati-vga -nographic [...]
OpenBIOS 1.1 [Sep 24 2024 19:56] [...] 0 > cd /pci ok 0 > ls fff62120 NE2000@1 fff624d4 ATY@2 fff67b18 mac-io@10 0 > cd ATY ok 0 > .properties [...] driver,AAPL,MacOS,PowerPC -- 4941 : 4a 6f 79 21 70 65 66 66 70 77 70 63 00 00 00
This should not be there otherwise the ROM will not add its own correct driver and this one likely does not work with an ATI card. The QEMU patch I posted fixed this without any changes needed in OpenBIOS but as usual I was told to fix OpenBIOS instead which I don't want to do especially if the suggested way would make it more complex instead of simpler that my patch would have allowed.
-device bochs-display does work with VGA std so I’m not sure why I can’t use -vga std with PCI Passthrough of a VGA card?
Because both of them have legacy VGA ports and only one card can have it in the system. With a passed thorugh card that should be the real card with x-vga=on otherwise if the ROM accessses those ports it won't go to the card but to an emulated device so part of the init of the card will be missing. But x-vga=on does not work if you have Intel iGPU unless you patch i915 Linux driver because it does not release VGA ports so it will corrupt host display instead and ROM can still not access real card.
But it may be an Apple FCode ROM does not need legacy VGA ports so only the OpenBIOS NDRV bug is biting you which you can disabled with a command line option then it may work but I always forget about that and spend days to debug it until I remember it again. That's what motivated the patch but I wasn't successful in helping others avoiding the same issue again and again.
Regards, BALATON Zoltan
On May 24, 2025, at 1:33 PM, Jd Lyons <lyons_dj@yahoo.com> wrote ioc@ iow@ iol@ ioc! iow!
participants (4)
-
BALATON Zoltan -
Howard Spoelstra -
Jd Lyons -
Segher Boessenkool