Hello,
I'm trying to find out what's missing to use an FCode ROM for the ati-vga device to see how it would set up the card for MacOS. This has been done before for other FCode ROMs e.g. here:
https://mail.coreboot.org/hyperkitty/list/openbios@openbios.org/thread/E7PFX...
I can get some print out of compiling and defining new words by setting fcode-debug? and ?fcode-verbose to true as above but this only gives me what I can also get from detok but does not tell me where exactly it fails during executing these words afterwards. What I get is that after a lot of (compile), new-token and fcode# lines that define a lot of words it just ends in one of these (the second?) when executed:
400514a : [ 0x8bc ] 400514c : [ 0x926 ]
byte-load: exception caught!
But how can I see what's inside this word that caused the exception? There's the forth debugger I think to see or step through execution of words but how can I add an undefined/unnamed word to the debug before the the FCode runs?
Looking at the definition of this word in the detok output does not get me further as it just calls more of these words defined in the FCode:
8512: b(:) 8513: (unnamed-fcode) [0x86a] 8515: (unnamed-fcode) [0x864] 8517: b(") ( len=7 ) " map-out" 8526: (unnamed-fcode) [0x91f] 8528: (unnamed-fcode) [0x86c] 8530: (unnamed-fcode) [0x866] 8532: b(") ( len=7 ) " map-out" 8541: (unnamed-fcode) [0x91f] 8543: 0 8544: b(to) (unnamed-fcode) [0x86c] 8547: 0 8548: b(to) (unnamed-fcode) [0x86a] 8551: b(;) 8552: new-token 0x926
so where can I get more details on execution of these words and the more precise location of the exception?
Regards, BALATON Zoltan
On Sat, 13 Jul 2019, BALATON Zoltan wrote:
(compile), new-token and fcode# lines that define a lot of words it just ends in one of these (the second?) when executed:
400514a : [ 0x8bc ] 400514c : [ 0x926 ]
byte-load: exception caught!
I get the same result with SLOF on qemu-system-ppc64 as per
https://lists.ozlabs.org/pipermail/slof/2018-January/002020.html
914a: [8bc] x8bc 0 0 2 1 1e786d38 914c: [926] x926 Aborted
So maybe it's relying on some pecularity of Apple's Open Firmware implementation? Any idea how to get more info on where it may fail?
Regards, BALATON Zoltan
I eventually did get the Geforce 6600 to work with SLOF in PCI Passthrough.
Sadly my PC wouldn’t POST with a Radeon 9200 PCI in a PCI-E to PCI bridge card, tho it worked fine with a generic firewire card under both OS 9 and OS X in Qemu-system-ppc.
Balaton, are you using PCI Passthrough?
What ATI card are you using, with what FCODE Rom?
On Jul 13, 2019, at 4:46 AM, BALATON Zoltan balaton@eik.bme.hu wrote:
On Sat, 13 Jul 2019, BALATON Zoltan wrote:
(compile), new-token and fcode# lines that define a lot of words it just ends in one of these (the second?) when executed:
400514a : [ 0x8bc ] 400514c : [ 0x926 ]
byte-load: exception caught!
I get the same result with SLOF on qemu-system-ppc64 as per
https://lists.ozlabs.org/pipermail/slof/2018-January/002020.html
914a: [8bc] x8bc 0 0 2 1 1e786d38 914c: [926] x926 Aborted
So maybe it's relying on some pecularity of Apple's Open Firmware implementation? Any idea how to get more info on where it may fail?
Regards, BALATON Zoltan _______________________________________________ OpenBIOS mailing list -- openbios@openbios.org To unsubscribe send an email to openbios-leave@openbios.org
With Openbios and nVidia FCode ROM’s:
OpenBios lacks some of the Config- words and maybe some others that are part of IEEE-1275. Mark made a patch to one of the missing Config words, but others are still unimplemented, likely you are getting abort on unimplemented words.
I don’t think ATI FCode ROM’s use anything Apple specific, other than a work a round to the old Map-In bug present in some Apple Open Firmware implementations.
As a side note: load in Apple’s Open Firmware implementation seems to always do load and go, nessistating striping the PCI Header( everything before the start of the FCode ) from Fcode PCI ROM’s when loading them from a file in Apple’s Open Firmware.
On Jul 13, 2019, at 5:25 AM, Jd Lyons via OpenBIOS openbios@openbios.org wrote:
I eventually did get the Geforce 6600 to work with SLOF in PCI Passthrough.
Sadly my PC wouldn’t POST with a Radeon 9200 PCI in a PCI-E to PCI bridge card, tho it worked fine with a generic firewire card under both OS 9 and OS X in Qemu-system-ppc.
Balaton, are you using PCI Passthrough?
What ATI card are you using, with what FCODE Rom?
On Jul 13, 2019, at 4:46 AM, BALATON Zoltan balaton@eik.bme.hu wrote:
On Sat, 13 Jul 2019, BALATON Zoltan wrote:
(compile), new-token and fcode# lines that define a lot of words it just ends in one of these (the second?) when executed:
400514a : [ 0x8bc ] 400514c : [ 0x926 ]
byte-load: exception caught!
I get the same result with SLOF on qemu-system-ppc64 as per
https://lists.ozlabs.org/pipermail/slof/2018-January/002020.html
914a: [8bc] x8bc 0 0 2 1 1e786d38 914c: [926] x926 Aborted
So maybe it's relying on some pecularity of Apple's Open Firmware implementation? Any idea how to get more info on where it may fail?
Regards, BALATON Zoltan _______________________________________________ OpenBIOS mailing list -- openbios@openbios.org To unsubscribe send an email to openbios-leave@openbios.org
OpenBIOS mailing list -- openbios@openbios.org To unsubscribe send an email to openbios-leave@openbios.org
On Sat, 13 Jul 2019, Jd Lyons wrote:
OpenBios lacks some of the Config- words and maybe some others that are part of IEEE-1275. Mark made a patch to one of the missing Config words, but others are still unimplemented, likely you are getting abort on unimplemented words.
Yes but how to find which ones? The "exception caught" error is not very informative about that.
Regards, BALATON Zoltan
detok the FCode rom and fallow the code from the exception, looking for words that are unimplemented.
I can help if you outline exactly what you are doing and provide the Code rom you are using.
On Jul 13, 2019, at 6:05 AM, BALATON Zoltan balaton@eik.bme.hu wrote:
Yes but how to find which ones? The "exception caught" error is not very informative about that.
On Sat, 13 Jul 2019, Jd Lyons wrote:
I eventually did get the Geforce 6600 to work with SLOF in PCI Passthrough.
Sadly my PC wouldn’t POST with a Radeon 9200 PCI in a PCI-E to PCI bridge card, tho it worked fine with a generic firewire card under both OS 9 and OS X in Qemu-system-ppc.
That's interesting. Do you have it documented somewhere how to do pass through of cards to work on qemu-system-ppc?
Balaton, are you using PCI Passthrough?
What ATI card are you using, with what FCODE Rom?
No passthrough, I don't have a card I could try to pass through. I'm emulating ati-vga in QEMU:
https://git.qemu.org/?p=qemu.git;a=blob;f=hw/display/ati.c;h=a747c4cc98c73d1...
This partially emulates the Rage 128 Pro found in PowerMac3,1 (and eventually may grow to RV100) but it's not there yet. Currently Linux console works in the defaulr 8 bpp and MorphOS can use some 2D acceleration. No 3D or any advanced features of the card emulated yet. More info on this at: https://osdn.net/projects/qmiga/wiki/SubprojectAti
This is in upstream QEMU and can be enabled with -device ati-vga but expect it to not work most of the time so only for developers at the moment.
I'm trying to get an FCode ROM from a real card to talk to the emulation as a way to test what's missing or see what's needed for MacOS. Just putting the NDRV from the ROM in the device-tree makes MacOS poke the card but then does not work so maybe it needs something more that the FCode does. That's why I want to try to run the FCode ROM.
Regards, BALATON Zoltan
On Sat, 13 Jul 2019, BALATON Zoltan wrote:
On Sat, 13 Jul 2019, BALATON Zoltan wrote:
(compile), new-token and fcode# lines that define a lot of words it just ends in one of these (the second?) when executed:
400514a : [ 0x8bc ] 400514c : [ 0x926 ]
How to enable debugging of words defined by FCode such as 0x926 above?
Regards, BALATON Zoltan
That’s a good question, i’m not sure there is a way, I don’t think you can debug words defined as colon definitions either.
Tho others here would know better than me, so let’s see what they have to say about it.
On Jul 17, 2019, at 8:30 AM, BALATON Zoltan balaton@eik.bme.hu wrote:
On Sat, 13 Jul 2019, BALATON Zoltan wrote:
On Sat, 13 Jul 2019, BALATON Zoltan wrote:
(compile), new-token and fcode# lines that define a lot of words it just ends in one of these (the second?) when executed: 400514a : [ 0x8bc ] 400514c : [ 0x926 ]
How to enable debugging of words defined by FCode such as 0x926 above?
Regards, BALATON Zoltan _______________________________________________ OpenBIOS mailing list -- openbios@openbios.org To unsubscribe send an email to openbios-leave@openbios.org
Likely failing config-b@ and or config-b!
On Jul 12, 2019, at 7:38 PM, BALATON Zoltan balaton@eik.bme.hu wrote:
400514a : [ 0x8bc ] 400514c : [ 0x926 ]
If I’m reading this right 0x926 is:
new-token 0x926 b(:) my-address b(lit) 0x1000014 my-space + (unnamed-fcode) [0x867] b(") ( len=6 ) " map-in" (unnamed-fcode) [0x91f] b(to) (unnamed-fcode) [0x86c] b(lit) 0x4 my-space + dup b(") ( len=9 ) " config-b@" (unnamed-fcode) [0x91f] 1 or swap b(") ( len=9 ) " config-b!" (unnamed-fcode) [0x91f] b(;)
On Jul 13, 2019, at 11:33 AM, Jd Lyons via OpenBIOS openbios@openbios.org wrote:
Likely failing config-b@ and or config-b!
On Jul 12, 2019, at 7:38 PM, BALATON Zoltan balaton@eik.bme.hu wrote:
400514a : [ 0x8bc ] 400514c : [ 0x926 ]
OpenBIOS mailing list -- openbios@openbios.org To unsubscribe send an email to openbios-leave@openbios.org
On Sat, 13 Jul 2019, Jd Lyons wrote:
If I’m reading this right 0x926 is:
new-token 0x926 b(:)
I was under the impression that Forth is stack based and defining new word taked stuff from the stack so the new-token for a block might be to one after the b(;) not the one before the b(:) but I'm not sure so this could be as well. Anyway, seeing the execution and getting the exact place of the exception somehow would be better than having to guess.
Regards, BALATON Zoltan
my-address b(lit) 0x1000014 my-space
(unnamed-fcode) [0x867] b(") ( len=6 ) " map-in" (unnamed-fcode) [0x91f] b(to) (unnamed-fcode) [0x86c] b(lit) 0x4 my-space
dup b(") ( len=9 ) " config-b@" (unnamed-fcode) [0x91f] 1 or swap b(") ( len=9 ) " config-b!" (unnamed-fcode) [0x91f] b(;)
On Jul 13, 2019, at 11:33 AM, Jd Lyons via OpenBIOS openbios@openbios.org wrote:
Likely failing config-b@ and or config-b!
On Jul 12, 2019, at 7:38 PM, BALATON Zoltan balaton@eik.bme.hu wrote:
400514a : [ 0x8bc ] 400514c : [ 0x926 ]
OpenBIOS mailing list -- openbios@openbios.org To unsubscribe send an email to openbios-leave@openbios.org
On Sat, 13 Jul 2019, Jd Lyons via OpenBIOS wrote:
Likely failing config-b@ and or config-b!
Is that a wild guess or are you basing it on something concrete? The ROM seems to use these words and it seems to be missing from OpenBIOS so it might be. Any idea how to implement these?
Regards, BALATON Zoltan
On Jul 12, 2019, at 7:38 PM, BALATON Zoltan balaton@eik.bme.hu wrote:
400514a : [ 0x8bc ] 400514c : [ 0x926 ]
OpenBIOS mailing list -- openbios@openbios.org To unsubscribe send an email to openbios-leave@openbios.org
On Jul 13, 2019, at 11:39 AM, BALATON Zoltan balaton@eik.bme.hu wrote:
Is that a wild guess or are you basing it on something concrete? The ROM seems to use these words and it seems to be missing from OpenBIOS so it might be. Any idea how to implement these?
Here is how mark implemented config-l:
diff --git a/drivers/pci.c b/drivers/pci.c index 295be7e..1788c26 100644 --- a/drivers/pci.c +++ b/drivers/pci.c @@ -428,6 +428,15 @@ ob_pci_bus_map_in(int *idx) PUSH(virt); }
+static void +ob_pci_config_readl(int *idx) +{ + ucell addr = POP(); + + uint32_t value = pci_config_read32(0x80000000 | (addr & 0xffffff00), addr & 0xff); + PUSH(value); +} + NODE_METHODS(ob_pci_bus_node) = { { NULL, ob_pci_initialize }, { "open", ob_pci_open }, @@ -435,6 +444,7 @@ NODE_METHODS(ob_pci_bus_node) = { { "decode-unit", ob_pci_decode_unit }, { "encode-unit", ob_pci_encode_unit }, { "pci-map-in", ob_pci_bus_map_in }, + { "config-l@", ob_pci_config_readl }, };
/* ( pci-addr.lo pci-addr.mid pci-addr.hi size -- virt ) */
I’m not 100% sure you are aborting due to the config words, but I’m 100% sure you will if you get that far.
Could you give me you SLOF launch command, I’m having trouble loading the code from the disk?
On Sat, 13 Jul 2019, Jd Lyons wrote:
On Jul 13, 2019, at 11:39 AM, BALATON Zoltan balaton@eik.bme.hu wrote:
Here is how mark implemented config-l:
diff --git a/drivers/pci.c b/drivers/pci.c index 295be7e..1788c26 100644 --- a/drivers/pci.c +++ b/drivers/pci.c @@ -428,6 +428,15 @@ ob_pci_bus_map_in(int *idx) PUSH(virt); }
+static void +ob_pci_config_readl(int *idx) +{
- ucell addr = POP();
- uint32_t value = pci_config_read32(0x80000000 | (addr & 0xffffff00), addr & 0xff);
- PUSH(value);
+}
NODE_METHODS(ob_pci_bus_node) = { { NULL, ob_pci_initialize }, { "open", ob_pci_open }, @@ -435,6 +444,7 @@ NODE_METHODS(ob_pci_bus_node) = { { "decode-unit", ob_pci_decode_unit }, { "encode-unit", ob_pci_encode_unit }, { "pci-map-in", ob_pci_bus_map_in },
- { "config-l@", ob_pci_config_readl },
};
/* ( pci-addr.lo pci-addr.mid pci-addr.hi size -- virt ) */
I’m not 100% sure you are aborting due to the config words, but I’m 100% sure you will if you get that far.
Hope he or someone else can also add config-b fetch and store (@!) words too. Maybe I won't attempt that as I don't understand it well enough. It also seems instead of map-in OpenBIOS has pci-map-in but I don't understand any of that.
Could you give me you SLOF launch command, I’m having trouble loading the code from the disk?
I've used the commands from the end of the message on the SLOF list I've quoted (https://lists.ozlabs.org/pipermail/slof/2018-January/002020.html) and that worked. I think I've either used an image formatted ext2 with the file or an iso created with genisoimage -R then load cdrom:,\ati.rom or similar worked but I've lost the log since, I'll need to redo that.
Regards, BALATON Zoltan
Try this with SLOF:
qemu-system-ppc64 -M pseries -m 512 -device ati-vga -prom-env 'vga-ndrv?=false' -device secondary-vga -cdrom ~/aty.iso
include evaluator.fs dev /pci/@1 load cdrom:,\rage “ /pci/@1” open-dev to my-self 4040 1 byte-load
Wait for it….
Works for me.
On Jul 13, 2019, at 1:58 PM, BALATON Zoltan balaton@eik.bme.hu wrote:
On Sat, 13 Jul 2019, Jd Lyons wrote:
On Jul 13, 2019, at 11:39 AM, BALATON Zoltan balaton@eik.bme.hu wrote:
Here is how mark implemented config-l:
diff --git a/drivers/pci.c b/drivers/pci.c index 295be7e..1788c26 100644 --- a/drivers/pci.c +++ b/drivers/pci.c @@ -428,6 +428,15 @@ ob_pci_bus_map_in(int *idx) PUSH(virt); }
+static void +ob_pci_config_readl(int *idx) +{
- ucell addr = POP();
- uint32_t value = pci_config_read32(0x80000000 | (addr & 0xffffff00), addr & 0xff);
- PUSH(value);
+}
NODE_METHODS(ob_pci_bus_node) = { { NULL, ob_pci_initialize }, { "open", ob_pci_open }, @@ -435,6 +444,7 @@ NODE_METHODS(ob_pci_bus_node) = { { "decode-unit", ob_pci_decode_unit }, { "encode-unit", ob_pci_encode_unit }, { "pci-map-in", ob_pci_bus_map_in },
- { "config-l@", ob_pci_config_readl },
};
/* ( pci-addr.lo pci-addr.mid pci-addr.hi size -- virt ) */
I’m not 100% sure you are aborting due to the config words, but I’m 100% sure you will if you get that far.
Hope he or someone else can also add config-b fetch and store (@!) words too. Maybe I won't attempt that as I don't understand it well enough. It also seems instead of map-in OpenBIOS has pci-map-in but I don't understand any of that.
Could you give me you SLOF launch command, I’m having trouble loading the code from the disk?
I've used the commands from the end of the message on the SLOF list I've quoted (https://lists.ozlabs.org/pipermail/slof/2018-January/002020.html) and that worked. I think I've either used an image formatted ext2 with the file or an iso created with genisoimage -R then load cdrom:,\ati.rom or similar worked but I've lost the log since, I'll need to redo that.
Regards, BALATON Zoltan_______________________________________________ OpenBIOS mailing list -- openbios@openbios.org To unsubscribe send an email to openbios-leave@openbios.org
On Sat, 13 Jul 2019, Jd Lyons wrote:
Try this with SLOF:
qemu-system-ppc64 -M pseries -m 512 -device ati-vga -prom-env 'vga-ndrv?=false' -device secondary-vga -cdrom ~/aty.iso
include evaluator.fs dev /pci/@1 load cdrom:,\rage “ /pci/@1” open-dev to my-self 4040 1 byte-load
Wait for it….
Works for me.
Indeed with these commands it does access the card. (You don't actually need secondary-vga, can use -serial stdio instead and I guess the vga-ndrv?=false also only makes sense for OpenBIOS so these can be omitted.)
With this on SLOF it does what it should I guess:
914a: [8bc] x8bc 0 0 2 1 1e786d20 914c: [926] x926 pci_cfg_read ati-vga 01:0 @0x14 -> 0x101 pci_cfg_read ati-vga 01:0 @0x4 -> 0x7 pci_cfg_write ati-vga 01:0 @0x4 <- 0x7 0 0 2 1 1e786d20 914e: [936] x936 ati_mm_write 4 0x0 MM_INDEX <- 0x50000000 ati_mm_write 4 0x4 MM_DATA <- 0x20005 ati_mm_write 4 0x50000000 unknown <- 0x20005 ati_mm_write 4 0x0 MM_INDEX <- 0x30000000 ati_mm_write 4 0x4 MM_DATA <- 0x40a3b371 ati_mm_write 4 0x30000000 unknown <- 0x40a3b371 ati_mm_write 4 0x0 MM_INDEX <- 0x34000000 ati_mm_write 4 0x4 MM_DATA <- 0x1f000000 ati_mm_write 4 0x34000000 unknown <- 0x1f000000
and so on. It uses indexed access to card registers but the values look wrong. Maybe they are byte swapped so there's an endianness problem somewhere? It does end eventually and adds some properties to device node.
Now the question is why values are the wrong endianness and where are they swapped? PCI devices are little endian by default and that's what the QEMU ati-vga emulates and other drivers normally use (even on ppc, Linux, MorphOS can access the card). The real hardware does have some facilities for big-endian access and an ATI ROM on PowerPC may use that but I don't see how it would enable that. as it only writes one bit before sending data. PCI config reg 0x14 is BAR1 where IO space is that aliases first 256 bytes of mmio regs. (The rest can be accessed via index/data.) This is what it maps in. Then PCI config reg 4 is Command where it turns on bits 0-2 which are enabling io access, mem access and bus master. I don't see what might enable big endian aperture. Can this be that on a Mac this is set by OpenFirmware somehow or SLOF may have some defaults for this?
Regards, BALATON Zoltan
On Sat, 13 Jul 2019, BALATON Zoltan wrote:
Looking at the definition of this word in the detok output does not get me further as it just calls more of these words defined in the FCode:
8512: b(:) 8513: (unnamed-fcode) [0x86a] 8515: (unnamed-fcode) [0x864] 8517: b(") ( len=7 ) " map-out" 8526: (unnamed-fcode) [0x91f] 8528: (unnamed-fcode) [0x86c] 8530: (unnamed-fcode) [0x866] 8532: b(") ( len=7 ) " map-out" 8541: (unnamed-fcode) [0x91f] 8543: 0 8544: b(to) (unnamed-fcode) [0x86c] 8547: 0 8548: b(to) (unnamed-fcode) [0x86a] 8551: b(;) 8552: new-token 0x926
Here is the rest of it:
8555: b(:) 8556: my-address 8558: b(lit) 0x1000014 8563: my-space 8565: + 8566: (unnamed-fcode) [0x867] 8568: b(") ( len=6 ) " map-in" 8576: (unnamed-fcode) [0x91f] 8578: b(to) (unnamed-fcode) [0x86c] 8581: b(lit) 0x4 8586: my-space 8588: + 8589: dup 8590: b(") ( len=9 ) " config-b@" 8601: (unnamed-fcode) [0x91f] 8603: 1 8604: or 8605: swap 8606: b(") ( len=9 ) " config-b!" 8617: (unnamed-fcode) [0x91f] 8619: b(;)
But I'm not sure. The config- words seem to be missing from OpenBIOS but SLOF does have these and it also fails on SLOF so maybe the exception is earlier in map-in? The 0x867 is just some variable and the " map-out" " map-in" is usually followed by $call-parent in other drivers I've seen in OpenBIOS and SLOF so I guess 0x91f should be that. Here's the detok output around there:
8033: new-token 0x91d 8036: b(:) 8037: const_0xb0 8039: (unnamed-fcode) [0x90a] 8041: b(;) 8042: 0 8043: new-token 0x91e 8046: b(value) 8047: new-token 0x91f 8050: b(:) 8051: my-self 8053: 0<> 8054: b?branch 0x000b ( =dec 11 dest = 8066 ) 8057: my-self 8059: b(to) (unnamed-fcode) [0x869] 8062: bbranch 0x0009 ( dest = 8072 ) 8065: b(>resolve) 8066: (unnamed-fcode) [0x869] 8068: b(to) my-self 8071: b(>resolve) 8072: $call-parent 8074: b(;) 8075: new-token 0x920
So if 0x91f should be the one that does $call-parent then new-token comes before the : not after the ; in these listings. (But then what is 0x91e and if it's the value 0 then what about the :; block without new-token before that?)
So is map-in map-out expected to work in OpenBIOS or is it known to be missing? Since these are also used by some OpenBIOS drivers and pci.c does have some code for these maybe it could work. SLOF has these words but some implementation just print a message and do drop2 so does not seem to be really implemented there but maybe it works I just can't read Forth. Maybe we have a problem with $call-parent?
Regards, BALATON Zoltan
On Jul 13, 2019, at 1:01 PM, BALATON Zoltan balaton@eik.bme.hu wrote:
So is map-in map-out expected to work in OpenBIOS or is it known to be missing?
Map-in works, map-out is unimplemented, last I checked.
On Sat, 13 Jul 2019, Jd Lyons wrote:
On Jul 13, 2019, at 1:01 PM, BALATON Zoltan balaton@eik.bme.hu wrote:
So is map-in map-out expected to work in OpenBIOS or is it known to be missing?
Map-in works, map-out is unimplemented, last I checked.
I could not find map-in either so I'm not sure it really works. I've checked in OpenFirmware and found a comment explaining the bug you've mentioned:
https://github.com/openbios/openfirmware/blob/master/dev/video/common/defer....
Not sure if that's useful but just for reference. Probably we don't need to emulate that bug. But we should have map-in map-out words. In OpenFirmware AFAIU these are implemented on the root node:
https://github.com/openbios/openfirmware/blob/master/cpu/ppc/rootnode.fth
and everything else just $call-parent to that. It basically should call claim to get a virtual address for the specified phys address I think.
OpenBIOS does have something similar in drivers/iommu.c but that's only used on sparc32. Should that be generalised and also used on ppc or is that really sparc specific?
Regards, BALATON Zoltan
On Sat, Jul 13, 2019 at 07:01:52PM +0200, BALATON Zoltan wrote:
On Sat, 13 Jul 2019, BALATON Zoltan wrote:
Looking at the definition of this word in the detok output does not get me further as it just calls more of these words defined in the FCode:
8512: b(:) 8513: (unnamed-fcode) [0x86a] 8515: (unnamed-fcode) [0x864] 8517: b(") ( len=7 ) " map-out" 8526: (unnamed-fcode) [0x91f] 8528: (unnamed-fcode) [0x86c] 8530: (unnamed-fcode) [0x866] 8532: b(") ( len=7 ) " map-out" 8541: (unnamed-fcode) [0x91f] 8543: 0 8544: b(to) (unnamed-fcode) [0x86c] 8547: 0 8548: b(to) (unnamed-fcode) [0x86a] 8551: b(;)
: _... _86a _864 " map-out" _91f _86c _866 " map-out" _91f 0 TO _86c 0 TO _86a ;
8552: new-token 0x926
Here is the rest of it:
8555: b(:) 8556: my-address 8558: b(lit) 0x1000014 8563: my-space 8565: + 8566: (unnamed-fcode) [0x867] 8568: b(") ( len=6 ) " map-in" 8576: (unnamed-fcode) [0x91f] 8578: b(to) (unnamed-fcode) [0x86c] 8581: b(lit) 0x4 8586: my-space 8588: + 8589: dup 8590: b(") ( len=9 ) " config-b@" 8601: (unnamed-fcode) [0x91f] 8603: 1 8604: or 8605: swap 8606: b(") ( len=9 ) " config-b!" 8617: (unnamed-fcode) [0x91f] 8619: b(;)
: _926 my-address 01000014 + my-space + _867 " map-in" _91f TO _86c 4 my-space + dup " config-b@" _91f 1 or swap " config-b!" _91f ;
But I'm not sure. The config- words seem to be missing from OpenBIOS but SLOF does have these and it also fails on SLOF so maybe the exception is earlier in map-in?
The standard config-* words are methods of any specific PCI bus node. SLOF also has some in the global dictionaries, as convenience.
The 0x867 is just some variable and the " map-out" " map-in" is usually followed by $call-parent in other drivers I've seen in OpenBIOS and SLOF so I guess 0x91f should be that.
Yup.
Here's the detok output around there:
8033: new-token 0x91d 8036: b(:) 8037: const_0xb0 8039: (unnamed-fcode) [0x90a] 8041: b(;)
: _91d 00b0 _090a ;
8042: 0 8043: new-token 0x91e 8046: b(value)
0 VALUE _91e
8047: new-token 0x91f 8050: b(:) 8051: my-self 8053: 0<> 8054: b?branch 0x000b ( =dec 11 dest = 8066 ) 8057: my-self 8059: b(to) (unnamed-fcode) [0x869] 8062: bbranch 0x0009 ( dest = 8072 ) 8065: b(>resolve) 8066: (unnamed-fcode) [0x869] 8068: b(to) my-self 8071: b(>resolve) 8072: $call-parent 8074: b(;)
: _091f my-self 0<> IF my-self TO _869 ELSE _869 TO my-self THEN $call-parent ;
I.e.: if my-self is non-zero, just call $call-parent ; and if it is zero, set the previously used instance as current instance.
This is pretty curious.
8075: new-token 0x920
So if 0x91f should be the one that does $call-parent then new-token comes before the : not after the ; in these listings.
Yes. new-token makes a word header without a name.
(But then what is 0x91e and if it's the value 0 then what about the :; block without new-token before that?)
I'm not sure which block you mean?
So is map-in map-out expected to work in OpenBIOS or is it known to be missing? Since these are also used by some OpenBIOS drivers and pci.c does have some code for these maybe it could work. SLOF has these words but some implementation just print a message and do drop2 so does not seem to be really implemented there but maybe it works I just can't read Forth.
SLOF runs in real mode, so its memory mapping functions are trivial.
Segher
On Sat, 13 Jul 2019, Segher Boessenkool wrote:
8552: new-token 0x926
Here is the rest of it:
8555: b(:) 8556: my-address 8558: b(lit) 0x1000014 8563: my-space 8565: + 8566: (unnamed-fcode) [0x867] 8568: b(") ( len=6 ) " map-in" 8576: (unnamed-fcode) [0x91f] 8578: b(to) (unnamed-fcode) [0x86c] 8581: b(lit) 0x4 8586: my-space 8588: + 8589: dup 8590: b(") ( len=9 ) " config-b@" 8601: (unnamed-fcode) [0x91f] 8603: 1 8604: or 8605: swap 8606: b(") ( len=9 ) " config-b!" 8617: (unnamed-fcode) [0x91f] 8619: b(;)
: _926 my-address 01000014 + my-space + _867 " map-in" _91f TO _86c 4 my-space + dup " config-b@" _91f 1 or swap " config-b!" _91f ;
Thanks for rewriting it into more idiomatic Forth but I'm afraid I can't read that any better than the above. All I can grasp from it is that it tries to map something (maybe card's PCI config space) somewhere and set a bit in it or something along that line. If it worked I should have seen access to pci config space of the card but it just failed with an exception. According to Jd it may work with SLOF, I'll retry that later.
What's my-space? That's relevant to my other question (unrelated to this but more interesting to me):
https://mail.coreboot.org/hyperkitty/list/openbios@openbios.org/thread/WVQ6R...
Do you have some insight on that maybe? Although I probably need some help from someone with OpenBIOS knowledge if there are anyone here with that.
Here's the detok output around there:
8033: new-token 0x91d 8036: b(:) 8037: const_0xb0 8039: (unnamed-fcode) [0x90a] 8041: b(;)
: _91d 00b0 _090a ;
8042: 0 8043: new-token 0x91e 8046: b(value)
0 VALUE _91e
8047: new-token 0x91f 8050: b(:) 8051: my-self 8053: 0<> 8054: b?branch 0x000b ( =dec 11 dest = 8066 ) 8057: my-self 8059: b(to) (unnamed-fcode) [0x869] 8062: bbranch 0x0009 ( dest = 8072 ) 8065: b(>resolve) 8066: (unnamed-fcode) [0x869] 8068: b(to) my-self 8071: b(>resolve) 8072: $call-parent 8074: b(;)
: _091f my-self 0<> IF my-self TO _869 ELSE _869 TO my-self THEN $call-parent ;
I.e.: if my-self is non-zero, just call $call-parent ; and if it is zero, set the previously used instance as current instance.
This is pretty curious.
8075: new-token 0x920
So if 0x91f should be the one that does $call-parent then new-token comes before the : not after the ; in these listings.
Yes. new-token makes a word header without a name.
OK I don't know how Forth works internally so the debug output did not make much sense.
(But then what is 0x91e and if it's the value 0 then what about the :; block without new-token before that?)
I'm not sure which block you mean?
I was confused by that the new-token comes usually before the defined word but for the 0 value _91e it was between the number and b(value) so not what I expected:
new-token 91e 0 b(value)
as with :; blocks. But the above explains which lines belong to which new-token definition.
So is map-in map-out expected to work in OpenBIOS or is it known to be missing? Since these are also used by some OpenBIOS drivers and pci.c does have some code for these maybe it could work. SLOF has these words but some implementation just print a message and do drop2 so does not seem to be really implemented there but maybe it works I just can't read Forth.
SLOF runs in real mode, so its memory mapping functions are trivial.
I think we can conclude that it gets exception because all the words it tries to use: map-in, config-b@, config-b! are missing in OpenBIOS so it can't really work and likely trips on map-in already.
Thank you, BALATON Zoltan
On Sat, Jul 13, 2019 at 10:34:45PM +0200, BALATON Zoltan wrote:
On Sat, 13 Jul 2019, Segher Boessenkool wrote:
: _926 my-address 01000014 + my-space + _867 " map-in" _91f TO _86c 4 my-space + dup " config-b@" _91f 1 or swap " config-b!" _91f ;
Thanks for rewriting it into more idiomatic Forth but I'm afraid I can't read that any better than the above. All I can grasp from it is that it tries to map something (maybe card's PCI config space) somewhere and set a bit in it or something along that line.
01000014 means the PCI I/O space mapped by BAR 1 (the one at config space address 14). What *exactly* it means I cannot tell either, there is a lot of missing context.
https://www.openfirmware.info/data/docs/bus.pci.pdf
What's my-space? That's relevant to my other question (unrelated to this but more interesting to me):
my-space returns the high 32 bits of an address (PCI addresses are 3 such 32-bit numbers, in open firmware).
https://mail.coreboot.org/hyperkitty/list/openbios@openbios.org/thread/WVQ6R...
I could read that if the https was set up correctly, perhaps.
Yes. new-token makes a word header without a name.
OK I don't know how Forth works internally so the debug output did not make much sense.
https://www.openfirmware.info/data/docs/of1275.pdf
Pay special attention to A.2, the glossary. The entry for : says, for example:
Tokenizer equivalent: new-token|named-token|external-token b(:)
SLOF runs in real mode, so its memory mapping functions are trivial.
I think we can conclude that it gets exception because all the words it tries to use: map-in, config-b@, config-b! are missing in OpenBIOS so it can't really work and likely trips on map-in already.
It should normally fail with an intelligible error message, not try to jump to address zero or similar. But there can be bugs of course, and there is not much you can do about bugs in the FCode program (the card's ROM), etc.
Segher
On 13/07/2019 21:34, BALATON Zoltan wrote:
I think we can conclude that it gets exception because all the words it tries to use: map-in, config-b@, config-b! are missing in OpenBIOS so it can't really work and likely trips on map-in already.
Right. Certainly words like my-parent won't work in FCode for PCI devices until I finish work getting the PCI ihandle instance chain fixed up, and as JD mentioned before, the PCI config words aren't yet implemented but should be fairly trivial.
ATB,
Mark.
On Sun, 14 Jul 2019, Mark Cave-Ayland wrote:
On 13/07/2019 21:34, BALATON Zoltan wrote:
I think we can conclude that it gets exception because all the words it tries to use: map-in, config-b@, config-b! are missing in OpenBIOS so it can't really work and likely trips on map-in already.
Right. Certainly words like my-parent won't work in FCode for PCI devices until I finish work getting the PCI ihandle instance chain fixed up, and as JD mentioned before, the PCI config words aren't yet implemented but should be fairly trivial.
Now this is a separate problem to what's discussed in previous message. That one was about porting SLOF's fdt.fs to use in OpenBIOS, this one is about running an ATI FCode ROM to test QEMU ati-vga emulation with MacOS. Sorry if this was confusing, hope this is now cleared.
I might be able to try to implement config-* words based on the config-l you've added but not sure if these should all call back to C or should we base them on config-l or config-b or some other generic C helper in Forth? For reading bytes one could do config-l@ then extract the needed byte somehow (need to find the forth for that) but for storing we may be better off with a helper otherwise we need to 'config-l@ modify-it config-l!' if we only have config-l! or if we base it on config-b! then we need to do multiple of these for config-l so C helpers or a generic one like do_config_{read,write}(addr, size) might be simpler. I should check how other open firmware implementation do this in forth (although probably I won't understand it). Do you think it's worth trying to do in Forth or should I try to do that in pci.c?
I don't understand map-in map-out enough to try to implement those so I'll need some help with that. I've seen there are pci-map-in and dma-map-in but this is plain map-in which is probably different. I think it should make a phys addr accessible in forth by assigning a virt addr to it. It we have virt == phys then this should be simple do nothing. If so we may try with : map-in 2drop ; or something similar?
In the meantime we've managed to run the FCode ROM in SLOF but data sent to the device turned out byte swapped so not sure if SLOF does something differently or Apple's OpenFirmware.
Regards, BALATON Zoltan
On Sun, 14 Jul 2019, BALATON Zoltan wrote:
I might be able to try to implement config-* words based on the config-l you've added but not sure if these should all call back to C or should we base them on config-l or config-b or some other generic C helper in Forth? For reading bytes one could do config-l@ then extract the needed byte somehow (need to find the forth for that) but for storing we may be better off with a helper otherwise we need to 'config-l@ modify-it config-l!' if we only have config-l! or if we base it on config-b! then we need to do multiple of these for config-l so C helpers or a generic one like do_config_{read,write}(addr, size) might be simpler. I should check how other open firmware implementation do this in forth (although probably I won't understand it). Do you think it's worth trying to do in Forth or should I try to do that in pci.c?
AFAIU looks like most implementations use a C helper for this: most of SmartFirmware is in C, SLOF seem to call back to rtas and maybe only OpenFirmware tries to do this in Forth:
https://github.com/openbios/openfirmware/blob/master/dev/pci/configm1.fth
but even in OF I've seen machine specific implementations that use assembly. So probably doing it in OpenBIOS in a C helper would be simplest or maybe could be done in Forth if the config base address is available somewhere.
Regards, BALATON Zoltan
I suppose the first thing we need it the my-space patch so we can get the correct value before map-in.
On Jul 14, 2019, at 8:24 AM, BALATON Zoltan balaton@eik.bme.hu wrote:
On Sun, 14 Jul 2019, BALATON Zoltan wrote:
I might be able to try to implement config-* words based on the config-l you've added but not sure if these should all call back to C or should we base them on config-l or config-b or some other generic C helper in Forth? For reading bytes one could do config-l@ then extract the needed byte somehow (need to find the forth for that) but for storing we may be better off with a helper otherwise we need to 'config-l@ modify-it config-l!' if we only have config-l! or if we base it on config-b! then we need to do multiple of these for config-l so C helpers or a generic one like do_config_{read,write}(addr, size) might be simpler. I should check how other open firmware implementation do this in forth (although probably I won't understand it). Do you think it's worth trying to do in Forth or should I try to do that in pci.c?
AFAIU looks like most implementations use a C helper for this: most of SmartFirmware is in C, SLOF seem to call back to rtas and maybe only OpenFirmware tries to do this in Forth:
https://github.com/openbios/openfirmware/blob/master/dev/pci/configm1.fth
but even in OF I've seen machine specific implementations that use assembly. So probably doing it in OpenBIOS in a C helper would be simplest or maybe could be done in Forth if the config base address is available somewhere.
Regards, BALATON Zoltan _______________________________________________ OpenBIOS mailing list -- openbios@openbios.org To unsubscribe send an email to openbios-leave@openbios.org
On Sun, 14 Jul 2019, Jd Lyons wrote:
I suppose the first thing we need it the my-space patch so we can get the correct value before map-in. Attachment: openbios-pci-set-args.patch
Why is this patch not in master yet?
Regards, BALATON Zoltan
On 16/07/2019 13:57, BALATON Zoltan wrote:
On Sun, 14 Jul 2019, Jd Lyons wrote:
I suppose the first thing we need it the my-space patch so we can get the correct value before map-in. Attachment: openbios-pci-set-args.patch
Why is this patch not in master yet?
Well sometimes I have been known to have a life outside of QEMU/OpenBIOS... but really quickly there are 2 reasons: 1) it's a bit of a hack (the real solution is to build the DT in order rather than constantly switching around active package/current instance, otherwise your instance variables can be initialised incorrectly) and 2) we're in QEMU freeze at the moment so I'd like to be confident that there will be no OpenBIOS changes required before 4.1 arrives.
As I mentioned in my previous email I am currently working on a patchset to implement 1) properly for PCI devices which I hope to post to the list soon.
ATB,
Mark.
On Fri, 19 Jul 2019, Mark Cave-Ayland wrote:
On 16/07/2019 13:57, BALATON Zoltan wrote:
On Sun, 14 Jul 2019, Jd Lyons wrote:
I suppose the first thing we need it the my-space patch so we can get the correct value before map-in. Attachment: openbios-pci-set-args.patch
Why is this patch not in master yet?
Well sometimes I have been known to have a life outside of QEMU/OpenBIOS... but
Sure, although we only know about this side of your life here :-). I did not mean to complain about you being late with this just asked what's the reason this is a separate patch and not merged yet. It was forwarded to me by Jd and I though this was done when he was trying to run the NVidia ROM a few months ago so I thought it's an older patch that could have been merged unless there's some problem with it that kept it out of master.
really quickly there are 2 reasons: 1) it's a bit of a hack (the real solution is to build the DT in order rather than constantly switching around active package/current instance, otherwise your instance variables can be initialised incorrectly) and 2)
OK, is that something getting the device tree from QEMU as FDT then unflattening it to construct the OF device-tree would help with or is it only about the pci devices part of the tree? Still I think getting a complete tree from QEMU and only adding some properties as SLOF does is better then the current situation where OpenBIOS needs knowledge about every change in QEMU so I think the way to avoid this is to do what SLOF does. This is more work once but then helps to get rid of a lot of hacks and make it less work later because a lot of things can be done in QEMU alone not requiring an OpenBIOS update as well so would make OpenBIOS more stable.
As I mentioned in my previous email I am currently working on a patchset to implement
- properly for PCI devices which I hope to post to the list soon.
Is there more info available on this? If you don't have time to work on it please share the info with the list at least so someone else could have a chance to help (although I get the impression there's no one else who cares about OpenBIOS besides you here).
Regards, BALATON Zoltan
On 19/07/2019 15:57, BALATON Zoltan wrote:
Why is this patch not in master yet?
Well sometimes I have been known to have a life outside of QEMU/OpenBIOS... but
Sure, although we only know about this side of your life here :-). I did not mean to complain about you being late with this just asked what's the reason this is a separate patch and not merged yet. It was forwarded to me by Jd and I though this was done when he was trying to run the NVidia ROM a few months ago so I thought it's an older patch that could have been merged unless there's some problem with it that kept it out of master.
really quickly there are 2 reasons: 1) it's a bit of a hack (the real solution is to build the DT in order rather than constantly switching around active package/current instance, otherwise your instance variables can be initialised incorrectly) and 2)
OK, is that something getting the device tree from QEMU as FDT then unflattening it to construct the OF device-tree would help with or is it only about the pci devices part of the tree? Still I think getting a complete tree from QEMU and only adding some properties as SLOF does is better then the current situation where OpenBIOS needs knowledge about every change in QEMU so I think the way to avoid this is to do what SLOF does. This is more work once but then helps to get rid of a lot of hacks and make it less work later because a lot of things can be done in QEMU alone not requiring an OpenBIOS update as well so would make OpenBIOS more stable.
As I mentioned in my previous email I am currently working on a patchset to implement
- properly for PCI devices which I hope to post to the list soon.
Is there more info available on this? If you don't have time to work on it please share the info with the list at least so someone else could have a chance to help (although I get the impression there's no one else who cares about OpenBIOS besides you here).
The patchset I've just posted is the proper fix for this - please test and let me know how you get on.
ATB,
Mark.
On Sat, 20 Jul 2019, Mark Cave-Ayland wrote:
On 19/07/2019 15:57, BALATON Zoltan wrote:
Why is this patch not in master yet?
Well sometimes I have been known to have a life outside of QEMU/OpenBIOS... but
Sure, although we only know about this side of your life here :-). I did not mean to complain about you being late with this just asked what's the reason this is a separate patch and not merged yet. It was forwarded to me by Jd and I though this was done when he was trying to run the NVidia ROM a few months ago so I thought it's an older patch that could have been merged unless there's some problem with it that kept it out of master.
really quickly there are 2 reasons: 1) it's a bit of a hack (the real solution is to build the DT in order rather than constantly switching around active package/current instance, otherwise your instance variables can be initialised incorrectly) and 2)
OK, is that something getting the device tree from QEMU as FDT then unflattening it to construct the OF device-tree would help with or is it only about the pci devices part of the tree? Still I think getting a complete tree from QEMU and only adding some properties as SLOF does is better then the current situation where OpenBIOS needs knowledge about every change in QEMU so I think the way to avoid this is to do what SLOF does. This is more work once but then helps to get rid of a lot of hacks and make it less work later because a lot of things can be done in QEMU alone not requiring an OpenBIOS update as well so would make OpenBIOS more stable.
As I mentioned in my previous email I am currently working on a patchset to implement
- properly for PCI devices which I hope to post to the list soon.
Is there more info available on this? If you don't have time to work on it please share the info with the list at least so someone else could have a chance to help (although I get the impression there's no one else who cares about OpenBIOS besides you here).
The patchset I've just posted is the proper fix for this - please test and let me know how you get on.
Great work, thanks! I've retried with this patch set instead of the openbios-pci-set-args.patch I was using before but it does not seem to fix that, neither the map-in problem. I've also found that these new patches break vga-ndrv?=false:
Welcome to OpenBIOS v1.1 built on Jul 20 2019 16:18
0 > printenv name "options" boot-args "" boot-device "hd:,\:tbxi hd:,\ppc\bootinfo.txt hd:,%BOOT" use-generic? "false" boot-script "" boot-screen "" vga-ndrv? "false" [...]
0 > cd . .. .. .dev /pci@f2000000/ATY ok 0 > .properties name "ATY" vendor-id 1002 device-id 5046 revision-id 0 class-code 30000 min-grant 0 max-latency 0 devsel-speed 0 subsystem-vendor-id 1af4 subsystem-id 1100 cache-line-size 0 device_type "display" model "ATY Rage128" compatible "VGA" assigned-addresses -- 3c : 42 00 78 10 00 00 00 00 81 00 00 00 00 00 00 00 01 00 00 00 01 00 78 14 00 00 00 00 00 00 10 00 00 00 00 00 00 00 01 00 02 00 78 18 00 00 00 00 82 00 00 00 00 00 00 00 00 00 40 00 reg 00007800 00000000 00000000 00000000 00000000 42007810 00000000 00000000 00000000 01000000 01007814 00000000 00000000 00000000 00000100 02007818 00000000 00000000 00000000 00004000 width 320 height 258 depth 20 linebytes c80 driver,AAPL,MacOS,PowerPC -- 4941 : 4a 6f 79 21 70 65 66 66 70 77 70 63 00
^^^ This driver should not be here.
I've decorated the map_in function with some more debug messages now:
0 > "/pci@f2000000/ATY" open-dev to my-self
ob_pci_bar_map_in idx=1fc5ac54 ob_pci_map: ba=0x82000000 size=16384 ob_pci_map: after decode flags=0x0 space_code=0x2 mask=0xf pci_bus_addr_to_host_addr: space=0x2 ba=0x82000000 ob_pci_map: phys=0x82000000 size=16384 ob_pci_bar_map_in idx=1fc5ac54 ob_pci_map: ba=0x81000000 size=16777216 ob_pci_map: after decode flags=0x0 space_code=0x2 mask=0xf pci_bus_addr_to_host_addr: space=0x2 ba=0x81000000 ob_pci_map: phys=0x81000000 size=16777216
ok 0 > my-unit ok 3 > . 7800 ok 2 > . 0 ok 1 > . 0 ok 0 > my-space . 0 ok
^ this is still wrong, should be 7800
0 > my-address . . 0 0 ok 0 > my-address h# 1000014 h# 7800 + h# 100 ok 4 > .s <4> 0 0 1007814 100 ok 4 > " map-in" $call-parent
ob_pci_bar_map_in idx=1fc5ac54 ob_pci_map: ba=0x00000000 size=256 ob_pci_map: after decode flags=0x0 space_code=0x2 mask=0xf pci_bus_addr_to_host_addr: space=0x2 ba=0x00000000 ob_pci_map: phys=0x00000000 size=256
ok
So the base address already looks wrong in the first line of ob_pci_map. Does the ob_pci_bar_map_in() function decode its parameters correctly?
/* ( pci-addr.lo pci-addr.mid pci-addr.hi size -- virt ) */
static void ob_pci_bus_map_in(int *idx) { uint32_t ba; ucell size; ucell virt;
PCI_DPRINTF("ob_pci_bar_map_in idx=%p\n", idx);
size = POP(); POP(); POP(); ba = POP();
virt = ob_pci_map(ba, size);
PUSH(virt); }
Shouldn't this be
size = POP(); ba = POP(); POP(); POP();
above?
Regards, BALATON Zoltan
On Sat, 20 Jul 2019, BALATON Zoltan wrote:
0 > "/pci@f2000000/ATY" open-dev to my-self
ob_pci_bar_map_in idx=1fc5ac54 ob_pci_map: ba=0x82000000 size=16384 ob_pci_map: after decode flags=0x0 space_code=0x2 mask=0xf pci_bus_addr_to_host_addr: space=0x2 ba=0x82000000 ob_pci_map: phys=0x82000000 size=16384 ob_pci_bar_map_in idx=1fc5ac54 ob_pci_map: ba=0x81000000 size=16777216 ob_pci_map: after decode flags=0x0 space_code=0x2 mask=0xf pci_bus_addr_to_host_addr: space=0x2 ba=0x81000000 ob_pci_map: phys=0x81000000 size=16777216
ok 0 > my-unit ok 3 > . 7800 ok 2 > . 0 ok 1 > . 0 ok 0 > my-space . 0 ok
^ this is still wrong, should be 7800
0 > my-address . . 0 0 ok 0 > my-address h# 1000014 h# 7800 + h# 100 ok 4 > .s <4> 0 0 1007814 100 ok 4 > " map-in" $call-parent
ob_pci_bar_map_in idx=1fc5ac54 ob_pci_map: ba=0x00000000 size=256 ob_pci_map: after decode flags=0x0 space_code=0x2 mask=0xf pci_bus_addr_to_host_addr: space=0x2 ba=0x00000000 ob_pci_map: phys=0x00000000 size=256
ok
So the base address already looks wrong in the first line of ob_pci_map. Does the ob_pci_bar_map_in() function decode its parameters correctly?
/* ( pci-addr.lo pci-addr.mid pci-addr.hi size -- virt ) */
static void ob_pci_bus_map_in(int *idx) { uint32_t ba; ucell size; ucell virt;
PCI_DPRINTF("ob_pci_bar_map_in idx=%p\n", idx); size = POP(); POP(); POP(); ba = POP(); virt = ob_pci_map(ba, size); PUSH(virt);}
Shouldn't this be
size = POP(); ba = POP(); POP(); POP();above?
Or maybe not because it looks correct for BARs as above at the top of this message. So why does this function ignore the pci-addr.hi which is the only non-0 in this call or should it try to map config space of the card for ba=0?
Regards, BALATON Zoltan
On Sat, 20 Jul 2019, BALATON Zoltan wrote:
On Sat, 20 Jul 2019, BALATON Zoltan wrote:
0 > "/pci@f2000000/ATY" open-dev to my-self
ob_pci_bar_map_in idx=1fc5ac54 ob_pci_map: ba=0x82000000 size=16384 ob_pci_map: after decode flags=0x0 space_code=0x2 mask=0xf pci_bus_addr_to_host_addr: space=0x2 ba=0x82000000 ob_pci_map: phys=0x82000000 size=16384 ob_pci_bar_map_in idx=1fc5ac54 ob_pci_map: ba=0x81000000 size=16777216 ob_pci_map: after decode flags=0x0 space_code=0x2 mask=0xf pci_bus_addr_to_host_addr: space=0x2 ba=0x81000000 ob_pci_map: phys=0x81000000 size=16777216
ok 0 > my-unit ok 3 > . 7800 ok 2 > . 0 ok 1 > . 0 ok 0 > my-space . 0 ok
^ this is still wrong, should be 7800
0 > my-address . . 0 0 ok 0 > my-address h# 1000014 h# 7800 + h# 100 ok 4 > .s <4> 0 0 1007814 100 ok 4 > " map-in" $call-parent
ob_pci_bar_map_in idx=1fc5ac54 ob_pci_map: ba=0x00000000 size=256 ob_pci_map: after decode flags=0x0 space_code=0x2 mask=0xf pci_bus_addr_to_host_addr: space=0x2 ba=0x00000000 ob_pci_map: phys=0x00000000 size=256
ok
So the base address already looks wrong in the first line of ob_pci_map. Does the ob_pci_bar_map_in() function decode its parameters correctly?
/* ( pci-addr.lo pci-addr.mid pci-addr.hi size -- virt ) */
static void ob_pci_bus_map_in(int *idx) { uint32_t ba; ucell size; ucell virt;
PCI_DPRINTF("ob_pci_bar_map_in idx=%p\n", idx); size = POP(); POP(); POP(); ba = POP(); virt = ob_pci_map(ba, size); PUSH(virt);}
Shouldn't this be
size = POP(); ba = POP(); POP(); POP();above?
Or maybe not because it looks correct for BARs as above at the top of this message. So why does this function ignore the pci-addr.hi which is the only non-0 in this call or should it try to map config space of the card for ba=0?
This pci_decode_pci_addr() function looks suspicious:
https://github.com/openbios/openbios/blob/master/drivers/pci.c#L156
it's called from ob_pci_map():
https://github.com/openbios/openbios/blob/master/drivers/pci.c#L373
It only expects IO or MMIO space and instead of finding what space is requested from pci-addr.hi it only looks at pci-addr.lo to decide. I think this is probably not how this should work. OK, the comment near ob_pci_map() says it's for mapping PCI MMIO or IO so it was probably not meant to allow access to config space but the map-in word seems to allow that as well. So what's the recommended way here? Which of these functions should be changed to add support for config space or should that be handled in ob_pci_bus_map_in already?
Regards, BALATON Zoltan
On 20/07/2019 18:38, BALATON Zoltan wrote:
Or maybe not because it looks correct for BARs as above at the top of this message. So why does this function ignore the pci-addr.hi which is the only non-0 in this call or should it try to map config space of the card for ba=0?
This pci_decode_pci_addr() function looks suspicious:
https://github.com/openbios/openbios/blob/master/drivers/pci.c#L156
it's called from ob_pci_map():
https://github.com/openbios/openbios/blob/master/drivers/pci.c#L373
It only expects IO or MMIO space and instead of finding what space is requested from pci-addr.hi it only looks at pci-addr.lo to decide. I think this is probably not how this should work. OK, the comment near ob_pci_map() says it's for mapping PCI MMIO or IO so it was probably not meant to allow access to config space but the map-in word seems to allow that as well. So what's the recommended way here? Which of these functions should be changed to add support for config space or should that be handled in ob_pci_bus_map_in already?
Right, moving the detection and handling of the space into map-in rather than relying on the caller to do it seems to be the right thing here. It shouldn't take you too long to make the relevant changes:
- Change pci_bus_addr_to_host_addr() to return arch->cfg_addr if the space code indicates CONFIGURATION_SPACE (a switch statement is probably better here)
- Create pci_decode_phys_addr() as the opposite to pci_encode_phys_addr() that takes an array of 3 u32s and sets flags, space_code, dev and addr
- Switch pci_decode_pci_addr() in ob_pci_map() to use your new pci_decode_phys_addr() function
- ...at which point it probably makes sense to merge ob_pci_map() into ob_pci_bus_map_in(). There are a couple of callers that you'll need to fix up, and possibly vga.fs too.
That should give you a basic working PCI map-in word. Once you get the virtual address for a PCI device configuration space you can easily test by reading a 16-bit LE word and if all is well you'll get the PCI device id back:
0 0 1007814 100 " map-in" $call-parent \ should place virt address on stack le-w@ \ should perform LE read from virt and return 5046 \ on the stack (the device id of your ATI card)
Once the basics work the next step is to look at moving the ob_pci_map() logic into a call-parent chain (particularly the config, IO and MMIO base addresses) to implement the config-* words within the PCI bus node itself.
ATB,
Mark.
On Sun, 21 Jul 2019, Mark Cave-Ayland wrote:
Right, moving the detection and handling of the space into map-in rather than relying on the caller to do it seems to be the right thing here. It shouldn't take you too long to make the relevant changes:
- Change pci_bus_addr_to_host_addr() to return arch->cfg_addr if the space code
indicates CONFIGURATION_SPACE (a switch statement is probably better here)
- Create pci_decode_phys_addr() as the opposite to pci_encode_phys_addr() that takes
an array of 3 u32s and sets flags, space_code, dev and addr
I gave it a try and got to this point without problems.
- Switch pci_decode_pci_addr() in ob_pci_map() to use your new pci_decode_phys_addr()
function
- ...at which point it probably makes sense to merge ob_pci_map() into
ob_pci_bus_map_in(). There are a couple of callers that you'll need to fix up, and possibly vga.fs too.
But I got stuck here, there are too many callers and they have different input than the proposed phys_addr[3] so this I don't see how to adjust them. ob_pci_map currently only takes an address which callers get from config->assigned[1] (the BAR if I got that right) but proposed new function would take phys_addr[3] of which only the low 64 bits are in config->assigned. Where to get the phys[0] part? Should I try to encode that at every caller when it's not really needed? That looks inefficient so unless it's already available somewhere we probably need to leave ob_pci_map as it is.
Then ob_pci_bus_map_in takes forth parameters while ob_pci_map takes C ones so merging the two means that all callers could just use the forth map-in word as they would need to push their parameters to stach to pass to ob_pci_bus_map_in(). Either there's a problem with this design or I need more details on how should this work to go further.
Regards, BALATON Zoltan
OK I came up with the attched patch (on top of your previous series and set-args patch) which is I think about what you've suggested. I kept ob_pci_map for existing callers but renamed it to ob_pci_map_in to keep symmetry between ob_pci_map and ob_pci_unmap with ob_pci_map now only doing mapping as its name suggests (although I think this should still be simpler) and ob_pci_bus_map_in is doing its own address decoding now. The previous ob_pci_map (now called ob_pci_map_in which is a C helper for some of what map-in should do) can be cleaned up as you like. Also cleaned up some white space (tab vs. spaces) but that's excluded from this patch for brevity.
But it does not seem to work yet:
0 > " /pci@f2000000/ATY" open-dev to my-self
ob_pci_bar_map_in idx=1fc5ac54 pci_bus_addr_to_host_addr space=2 ba=0x82000000 ob_pci_map: phys=0x82000000 size=16384 ob_pci_bar_map_in idx=1fc5ac54 pci_bus_addr_to_host_addr space=2 ba=0x81000000 ob_pci_map: phys=0x81000000 size=16777216
ok 0 > my-unit ok 3 > . 7800 ok 2 > . 0 ok 1 > . 0 ok 0 > my-space ok 1 > . 7800 ok 0 > my-address ok 2 > . 0 ok 1 > . 0 ok 0 > my-address h# 1000014 my-space + h# 100 ok 4 > .s <4> 0 0 1007814 100 ok 4 > " map-in" $call-parent
ob_pci_bar_map_in idx=1fc5ac54 pci_bus_addr_to_host_addr space=1 ba=0x0 ob_pci_map: phys=0xf2000000 size=256
ok 1 > .s <1> -e000000 ok 1 > le-l@ ok 1 > . -1 ok 0 >
Any idea?
Regards, BALATON Zoltan
On 21/07/2019 15:16, BALATON Zoltan wrote:
OK I came up with the attched patch (on top of your previous series and set-args patch) which is I think about what you've suggested. I kept ob_pci_map for existing callers but renamed it to ob_pci_map_in to keep symmetry between ob_pci_map and ob_pci_unmap with ob_pci_map now only doing mapping as its name suggests (although I think this should still be simpler) and ob_pci_bus_map_in is doing its own address decoding now. The previous ob_pci_map (now called ob_pci_map_in which is a C helper for some of what map-in should do) can be cleaned up as you like. Also cleaned up some white space (tab vs. spaces) but that's excluded from this patch for brevity.
Now I'm really confused - I had a quick look at your patch and compared it with pci_config_*() words and they show that you can't memory map PCI config space on a Mac. So how did you get to the conclusion earlier in the thread that this was what was required?
But it does not seem to work yet:
0 > " /pci@f2000000/ATY" open-dev to my-self
ob_pci_bar_map_in idx=1fc5ac54 pci_bus_addr_to_host_addr space=2 ba=0x82000000 ob_pci_map: phys=0x82000000 size=16384 ob_pci_bar_map_in idx=1fc5ac54 pci_bus_addr_to_host_addr space=2 ba=0x81000000 ob_pci_map: phys=0x81000000 size=16777216
ok
Here we see 2 MMIO BARs being mapped: one of 16K and another of 16M. And this happens as soon as you open the device? I think you'll have to explain more about your command line and how you are getting OpenBIOS to execute the FCode, since I can't tell if this is OpenBIOS or the FCode.
0 > my-unit ok 3 > . 7800 ok 2 > . 0 ok 1 > . 0 ok 0 > my-space ok 1 > . 7800 ok 0 > my-address ok 2 > . 0 ok 1 > . 0 ok 0 > my-address h# 1000014 my-space + h# 100 ok 4 > .s <4> 0 0 1007814 100 ok 4 > " map-in" $call-parent
ob_pci_bar_map_in idx=1fc5ac54 pci_bus_addr_to_host_addr space=1 ba=0x0 ob_pci_map: phys=0xf2000000 size=256
ok
This is trying to map an IO BAR with 256 bytes, but the phys address isn't going to be correct because OpenBIOS copies arch->io_base into *io_base (and also *mem_base for MMIO) during PCI configuration and advances that copy to hold the start of the next free address.
At a very minimum you're going to have to teach the PCI map-in how to use these values instead of making the assumption that the BAR has already been mapped by ob_pci_configure_bar() and the address can be calculated by adding the BAR address to arch->io_base or arch->mem_base according to the space type. This is how pci_bus_addr_to_host_addr() currently works.
The other issue is that the PCI enumeration code will already have mapped the ATI BARs once so you'll have to come up with a solution so that if you detect an FCode ROM then the existing PCI configuration code is ignored. Otherwise you'll find that you have mapped the 16M MMIO BAR twice which is going to take quite a bit of MMIO memory and lead to more confusion.
Finally one other thing: I'm finding this thread really hard to follow - too much information is spread across too many emails, and the subject line isn't really helping me understand what topic we're following or where I can find related information. May I suggest that it makes sense to break this down into a series of smaller, more concise threads?
ATB,
Mark.
On Sun, Jul 21, 2019 at 07:10:02PM +0100, Mark Cave-Ayland wrote:
On 21/07/2019 15:16, BALATON Zoltan wrote: Now I'm really confused - I had a quick look at your patch and compared it with pci_config_*() words and they show that you can't memory map PCI config space on a Mac.
That depends on the PCI host bridge. Most are direct-mapped on powermac. A few are not.
0 > " /pci@f2000000/ATY" open-dev to my-self
Like this f2000000, that is the physical address that maps directly to PCI config space on that bus.
Segher
On 20/07/2019 17:36, BALATON Zoltan wrote:
On Sat, 20 Jul 2019, Mark Cave-Ayland wrote:
On 19/07/2019 15:57, BALATON Zoltan wrote:
Why is this patch not in master yet?
Well sometimes I have been known to have a life outside of QEMU/OpenBIOS... but
Sure, although we only know about this side of your life here :-). I did not mean to complain about you being late with this just asked what's the reason this is a separate patch and not merged yet. It was forwarded to me by Jd and I though this was done when he was trying to run the NVidia ROM a few months ago so I thought it's an older patch that could have been merged unless there's some problem with it that kept it out of master.
really quickly there are 2 reasons: 1) it's a bit of a hack (the real solution is to build the DT in order rather than constantly switching around active package/current instance, otherwise your instance variables can be initialised incorrectly) and 2)
OK, is that something getting the device tree from QEMU as FDT then unflattening it to construct the OF device-tree would help with or is it only about the pci devices part of the tree? Still I think getting a complete tree from QEMU and only adding some properties as SLOF does is better then the current situation where OpenBIOS needs knowledge about every change in QEMU so I think the way to avoid this is to do what SLOF does. This is more work once but then helps to get rid of a lot of hacks and make it less work later because a lot of things can be done in QEMU alone not requiring an OpenBIOS update as well so would make OpenBIOS more stable.
As I mentioned in my previous email I am currently working on a patchset to implement
- properly for PCI devices which I hope to post to the list soon.
Is there more info available on this? If you don't have time to work on it please share the info with the list at least so someone else could have a chance to help (although I get the impression there's no one else who cares about OpenBIOS besides you here).
The patchset I've just posted is the proper fix for this - please test and let me know how you get on.
Great work, thanks! I've retried with this patch set instead of the openbios-pci-set-args.patch I was using before but it does not seem to fix that, neither the map-in problem. I've also found that these new patches break vga-ndrv?=false:
Welcome to OpenBIOS v1.1 built on Jul 20 2019 16:18
0 > printenv name "options" boot-args "" boot-device "hd:,\:tbxi hd:,\ppc\bootinfo.txt hd:,%BOOT" use-generic? "false" boot-script "" boot-screen "" vga-ndrv? "false" [...]
0 > cd . .. .. .dev /pci@f2000000/ATY ok 0 > .properties name "ATY" vendor-id 1002 device-id 5046 revision-id 0 class-code 30000 min-grant 0 max-latency 0 devsel-speed 0 subsystem-vendor-id 1af4 subsystem-id 1100 cache-line-size 0 device_type "display" model "ATY Rage128" compatible "VGA" assigned-addresses -- 3c : 42 00 78 10 00 00 00 00 81 00 00 00 00 00 00 00 01 00 00 00 01 00 78 14 00 00 00 00 00 00 10 00 00 00 00 00 00 00 01 00 02 00 78 18 00 00 00 00 82 00 00 00 00 00 00 00 00 00 40 00 reg 00007800 00000000 00000000 00000000 00000000 42007810 00000000 00000000 00000000 01000000 01007814 00000000 00000000 00000000 00000100 02007818 00000000 00000000 00000000 00004000 width 320 height 258 depth 20 linebytes c80 driver,AAPL,MacOS,PowerPC -- 4941 : 4a 6f 79 21 70 65 66 66 70 77 70 63 00
^^^ This driver should not be here.
Ah I see. This is because vga_config_cb() gets called not just for a specific device/vendor id but for any PCI display device. It might be worth renaming it to bochs_config_cb() and tying it down to the QEMU device/vendor id so that it doesn't interfere with external FCode ROMs.
I've decorated the map_in function with some more debug messages now:
0 > "/pci@f2000000/ATY" open-dev to my-self
ob_pci_bar_map_in idx=1fc5ac54 ob_pci_map: ba=0x82000000 size=16384 ob_pci_map: after decode flags=0x0 space_code=0x2 mask=0xf pci_bus_addr_to_host_addr: space=0x2 ba=0x82000000 ob_pci_map: phys=0x82000000 size=16384 ob_pci_bar_map_in idx=1fc5ac54 ob_pci_map: ba=0x81000000 size=16777216 ob_pci_map: after decode flags=0x0 space_code=0x2 mask=0xf pci_bus_addr_to_host_addr: space=0x2 ba=0x81000000 ob_pci_map: phys=0x81000000 size=16777216
ok 0 > my-unit ok 3 > . 7800 ok 2 > . 0 ok 1 > . 0 ok 0 > my-space . 0 ok
^ this is still wrong, should be 7800
0 > my-address . . 0 0 ok 0 > my-address h# 1000014 h# 7800 + h# 100 ok 4 > .s <4> 0 0 1007814 100 ok 4 > " map-in" $call-parent
ob_pci_bar_map_in idx=1fc5ac54 ob_pci_map: ba=0x00000000 size=256 ob_pci_map: after decode flags=0x0 space_code=0x2 mask=0xf pci_bus_addr_to_host_addr: space=0x2 ba=0x00000000 ob_pci_map: phys=0x00000000 size=256
ok
I had a fresh read of the relevant parts of the IEEE-1275 specification this morning and the fallback behaviour related to the reg property I was looking at is only related to my-unit, i.e. after the package has been created. So yes, even with the new code we still need an explicit set-args in there since this is the only thing that can set the probe address which is used for my-space and my-address.
Attached is a lightly tested patch to be applied on top of the existing patchset which uses the instance chain to encode the unit number correctly before invoking set-args.
ATB,
Mark.
On Sun, 21 Jul 2019, Mark Cave-Ayland wrote:
On 20/07/2019 17:36, BALATON Zoltan wrote:
driver,AAPL,MacOS,PowerPC -- 4941 : 4a 6f 79 21 70 65 66 66 70 77 70 63 00
^^^ This driver should not be here.
Ah I see. This is because vga_config_cb() gets called not just for a specific device/vendor id but for any PCI display device. It might be worth renaming it to bochs_config_cb() and tying it down to the QEMU device/vendor id so that it doesn't interfere with external FCode ROMs.
But I had vga-ndrv? set to false so this then should not add driver even for QEMU VGA and it didn't add it with this serting before your patches, only does now so there's some problem with handling that option now.
Not running vga.fs and adding driver for ATY but let an FCode ROM do it is next step but we'll need to make FCode ROMs work for that first. (Actually once that works I'd like to also switch QEMU VGA to use proper FCode ROM added in QEMU then the hacks regading vga.fs and NDRV patching could be completely cleaned up from OpenBIOS.)
Regards, BALATON Zoltan
On 21/07/2019 11:00, BALATON Zoltan wrote:
On Sun, 21 Jul 2019, Mark Cave-Ayland wrote:
On 20/07/2019 17:36, BALATON Zoltan wrote:
driver,AAPL,MacOS,PowerPC -- 4941 : 4a 6f 79 21 70 65 66 66 70 77 70 63 00
^^^ This driver should not be here.
Ah I see. This is because vga_config_cb() gets called not just for a specific device/vendor id but for any PCI display device. It might be worth renaming it to bochs_config_cb() and tying it down to the QEMU device/vendor id so that it doesn't interfere with external FCode ROMs.
But I had vga-ndrv? set to false so this then should not add driver even for QEMU VGA and it didn't add it with this serting before your patches, only does now so there's some problem with handling that option now.
Hmmm okay, I thought you meant for your ATI card. I'll do a quick test in a bit and see if I can recreate this.
Not running vga.fs and adding driver for ATY but let an FCode ROM do it is next step but we'll need to make FCode ROMs work for that first. (Actually once that works I'd like to also switch QEMU VGA to use proper FCode ROM added in QEMU then the hacks regading vga.fs and NDRV patching could be completely cleaned up from OpenBIOS.)
I think there is something to be said for splitting out the VGA driver as already is done for the CG3/TCX drivers, but there's not much point doing that until we're happy that the implementation is fairly compliant with the specification. As for the NDRV my current preference is to keep it separate since it makes development/debugging the driver itself considerably easier.
Then again this only affects the QEMU VGA device: if you have a real option ROM then you should be able to pass that in as a parameter to your ATI device and everything should "just work" once OpenBIOS has been tweaked to detect its FCode payload.
ATB,
Mark.
On Sun, 21 Jul 2019, Mark Cave-Ayland wrote:
On 20/07/2019 17:36, BALATON Zoltan wrote:
0 > my-unit? ok 3 > . 7800? ok 2 > . 0? ok 1 > . 0? ok 0 > my-space . 0? ok
^ this is still wrong, should be 7800
0 > my-address . . 0 0? ok 0 > my-address h# 1000014 h# 7800 + h# 100? ok 4 > .s <4> 0 0 1007814 100 ?ok 4 > " map-in" $call-parent
ob_pci_bar_map_in idx=1fc5ac54 ob_pci_map: ba=0x00000000 size=256 ob_pci_map: after decode flags=0x0 space_code=0x2 mask=0xf pci_bus_addr_to_host_addr: space=0x2 ba=0x00000000 ob_pci_map: phys=0x00000000 size=256
?ok
I had a fresh read of the relevant parts of the IEEE-1275 specification this morning and the fallback behaviour related to the reg property I was looking at is only related to my-unit, i.e. after the package has been created. So yes, even with the new code we still need an explicit set-args in there since this is the only thing that can set the probe address which is used for my-space and my-address.
I'm not sure what fallback you mean here but referring to my previous message regarding this:
On Fri, 19 Jul 2019, BALATON Zoltan wrote:
On Mon, 15 Jul 2019, Segher Boessenkool wrote:
my-address is two zeroes for configuration space addresses. But my-space shouldn't be zero, it's 7800 here. my-unit should be exactly identical to my-address my-space , but it isn't for you?
So you say it should be
: my-unit my-address my-space ;
but in OpenBIOS we have (in forth/device/package.fs):
\ \ 5.3.4.3 Get local arguments \
: my-address ( -- phys.lo ... ) ?my-self >in.device-node @
dn.probe-addr
my-#acells tuck /l* + swap 1- 0 ?do /l - dup l@ swap loop drop ;
: my-space ( -- phys.hi ) ?my-self >in.device-node @
dn.probe-addr @
;
: my-unit ( -- phys.lo ... phys.hi ) ?my-self >in.my-unit my-#acells tuck /l* + swap 0 ?do /l - dup l@ swap loop drop ;
my-unit seems to get the info from a different place (>in.my-unit vs.
dn.probe-addr) here. Why is that?
Why isn't my-unit is just my-address my-space and how can these return different values? Should these values be stored on the same place and all of these words get it from that one place? Apparently not there are several places these are stored and the problem is that they get out of sync isnt'it?
Regards, BALATON Zoltan
On 21/07/2019 11:11, BALATON Zoltan wrote:
On Sun, 21 Jul 2019, Mark Cave-Ayland wrote:
On 20/07/2019 17:36, BALATON Zoltan wrote:
0 > my-unit? ok 3 > . 7800? ok 2 > . 0? ok 1 > . 0? ok 0 > my-space . 0? ok
^ this is still wrong, should be 7800
0 > my-address . . 0 0? ok 0 > my-address h# 1000014 h# 7800 + h# 100? ok 4 > .s <4> 0 0 1007814 100 ?ok 4 > " map-in" $call-parent
ob_pci_bar_map_in idx=1fc5ac54 ob_pci_map: ba=0x00000000 size=256 ob_pci_map: after decode flags=0x0 space_code=0x2 mask=0xf pci_bus_addr_to_host_addr: space=0x2 ba=0x00000000 ob_pci_map: phys=0x00000000 size=256
?ok
I had a fresh read of the relevant parts of the IEEE-1275 specification this morning and the fallback behaviour related to the reg property I was looking at is only related to my-unit, i.e. after the package has been created. So yes, even with the new code we still need an explicit set-args in there since this is the only thing that can set the probe address which is used for my-space and my-address.
I'm not sure what fallback you mean here but referring to my previous message regarding this:
On Fri, 19 Jul 2019, BALATON Zoltan wrote:
On Mon, 15 Jul 2019, Segher Boessenkool wrote:
my-address is two zeroes for configuration space addresses. But my-space shouldn't be zero, it's 7800 here. my-unit should be exactly identical to my-address my-space , but it isn't for you?
So you say it should be
: my-unit my-address my-space ;
but in OpenBIOS we have (in forth/device/package.fs):
\ \ 5.3.4.3 Get local arguments \
: my-address ( -- phys.lo ... ) ?my-self >in.device-node @ >dn.probe-addr my-#acells tuck /l* + swap 1- 0 ?do /l - dup l@ swap loop drop ;
: my-space ( -- phys.hi ) ?my-self >in.device-node @ >dn.probe-addr @ ;
: my-unit ( -- phys.lo ... phys.hi ) ?my-self >in.my-unit my-#acells tuck /l* + swap 0 ?do /l - dup l@ swap loop drop ;
my-unit seems to get the info from a different place (>in.my-unit vs. > dn.probe-addr) here. Why is that?
Why isn't my-unit is just my-address my-space and how can these return different values? Should these values be stored on the same place and all of these words get it from that one place? Apparently not there are several places these are stored and the problem is that they get out of sync isnt'it?
I'm not sure what you mean about returning different values? At least with my patchset and this morning's patch applied they both looks the same here:
0 > " /pci/usb" open-dev to my-self ok 0 > my-unit ok 3 > u. 6800 ok 2 > u. 0 ok 1 > u. 0 ok 0 > my-address ok 2 > my-space ok 3 > u. 6800 ok 2 > u. 0 ok 1 > u. 0 ok
Segher's comment about my-unit is an implementation detail rather than a definition from the specification, so I wouldn't worry about this. Given that the above looks correct I'd say it's time to move on to the PCI mapping as per the outline given in my previous email.
ATB,
Mark.
On Sun, 21 Jul 2019, Mark Cave-Ayland wrote:
Why isn't my-unit is just my-address my-space and how can these return different values? Should these values be stored on the same place and all of these words get it from that one place? Apparently not there are several places these are stored and the problem is that they get out of sync isnt'it?
I'm not sure what you mean about returning different values? At least with my patchset and this morning's patch applied they both looks the same here:
I meant before the patch they could refurn different values which means that space address (the one my-space gets it from) can become unsynced from the unit address (the one that my-unit looks at) and this probably should not happen so it suggests there might be a problem here which could be prevented by ensuring space address is only stored at one place and both my-unit and my-space get it from that same place which currently does not seem to be the case.
Segher's comment about my-unit is an implementation detail rather than a definition from the specification, so I wouldn't worry about this. Given that the above looks
I don't care much as long as it works but maybe it would help if I understood the implementation detail why my-space and my-unit are not equivalent in OpenBIOS (for FDT unflattening maybe I'll need to get more understanding of this).
correct I'd say it's time to move on to the PCI mapping as per the outline given in my previous email.
Yes, more on that in next message.
Regards, BALATON Zoltan
Hi Mark,
On Sun, Jul 21, 2019 at 12:08:21PM +0100, Mark Cave-Ayland wrote:
I'm not sure what you mean about returning different values? At least with my patchset and this morning's patch applied they both looks the same here:
0 > " /pci/usb" open-dev to my-self ok 0 > my-unit ok 3 > u. 6800 ok 2 > u. 0 ok 1 > u. 0 ok 0 > my-address ok 2 > my-space ok 3 > u. 6800 ok 2 > u. 0 ok 1 > u. 0 ok
That looks good.
Segher's comment about my-unit is an implementation detail rather than a definition from the specification,
Which comment?
Segher
On Sun, 21 Jul 2019, Segher Boessenkool wrote:
On Sun, Jul 21, 2019 at 12:08:21PM +0100, Mark Cave-Ayland wrote:
I'm not sure what you mean about returning different values? At least with my patchset and this morning's patch applied they both looks the same here:
0 > " /pci/usb" open-dev to my-self ok 0 > my-unit ok 3 > u. 6800 ok 2 > u. 0 ok 1 > u. 0 ok 0 > my-address ok 2 > my-space ok 3 > u. 6800 ok 2 > u. 0 ok 1 > u. 0 ok
That looks good.
Segher's comment about my-unit is an implementation detail rather than a definition from the specification,
Which comment?
That my-unit should be the same as my-address my-space which without Mark's latest patch does not hold in OpenBIOS. But that patch does not change where these values are pulled from just calls set-args which apparently syncs the places space and address come from while my-unit gets space from somewhere else.
Regards, BALATON Zoltan
On Sun, Jul 21, 2019 at 09:19:13PM +0200, BALATON Zoltan wrote:
On Sun, 21 Jul 2019, Segher Boessenkool wrote:
On Sun, Jul 21, 2019 at 12:08:21PM +0100, Mark Cave-Ayland wrote:
Segher's comment about my-unit is an implementation detail rather than a definition from the specification,
Which comment?
That my-unit should be the same as my-address my-space which without Mark's latest patch does not hold in OpenBIOS. But that patch does not change where these values are pulled from just calls set-args which apparently syncs the places space and address come from while my-unit gets space from somewhere else.
set-args sets up what my-address and my-space return. This is standard.
my-space and my-address are used for determining the value in the "reg" property. The standard says this, too, and various bindings make it more explicit.
my-unit gets its value from the "reg" property. This is also standard.
(I'm ignoring wildcard nodes and only partially set up nodes, as usual).
Segher
On Sun, 14 Jul 2019, BALATON Zoltan wrote:
On Sun, 14 Jul 2019, BALATON Zoltan wrote:
I might be able to try to implement config-* words based on the config-l you've added but not sure if these should all call back to C or should we base them on config-l or config-b or some other generic C helper in Forth? For reading bytes one could do config-l@ then extract the needed byte somehow (need to find the forth for that) but for storing we may be better off with a helper otherwise we need to 'config-l@ modify-it config-l!' if we only have config-l! or if we base it on config-b! then we need to do multiple of these for config-l so C helpers or a generic one like do_config_{read,write}(addr, size) might be simpler. I should check how other open firmware implementation do this in forth (although probably I won't understand it). Do you think it's worth trying to do in Forth or should I try to do that in pci.c?
AFAIU looks like most implementations use a C helper for this: most of SmartFirmware is in C, SLOF seem to call back to rtas and maybe only OpenFirmware tries to do this in Forth:
https://github.com/openbios/openfirmware/blob/master/dev/pci/configm1.fth
but even in OF I've seen machine specific implementations that use assembly. So probably doing it in OpenBIOS in a C helper would be simplest or maybe could be done in Forth if the config base address is available somewhere.
Investigating it some more I've found that in OpenBIOS we're missing the register read/write words: r[bwl][!@] besides the pci config-[bwl][!@] words. However we have non-standard io[cwl][!@] words instead (implemented by the io[cwl]{fetch,store} functions in kernel/forth.c) which I think correspond to the missing r[bwl][!@] words so these could be aliased to those. For pci config access we also have non-standard equivalents in
https://github.com/openbios/openbios/blob/master/forth/util/pci.fs
These pci-* words are not much used so maybe we could just rename them to config-* to match OpemFirmware?
Does anyone see a problem with that or do you think this could work?
Regards, BALATON Zoltan
On Sun, 14 Jul 2019, Mark Cave-Ayland wrote:
On 13/07/2019 21:34, BALATON Zoltan wrote:
I think we can conclude that it gets exception because all the words it tries to use: map-in, config-b@, config-b! are missing in OpenBIOS so it can't really work and likely trips on map-in already.
Right. Certainly words like my-parent won't work in FCode for PCI devices until I finish work getting the PCI ihandle instance chain fixed up, and as JD mentioned before, the PCI config words aren't yet implemented but should be fairly trivial.
OK so it's even worse. Not only map-in and config-b[!@] words are missing but also the my-* words don't return what they should that's what you're saying? Looks like that's the case. In OpenBIOS:
0 > " /pci/ATY" select-dev ok 0 > .properties name "ATY" vendor-id 1002 device-id 5046 revision-id 0 class-code 30000 min-grant 0 max-latency 0 devsel-speed 0 subsystem-vendor-id 1af4 subsystem-id 1100 cache-line-size 0 device_type "display" model "ATY Rage128" compatible "VGA" assigned-addresses -- 3c : 42 00 78 10 00 00 00 00 81 00 00 00 00 00 00 00 01 00 00 00 01 00 78 14 00 00 00 00 00 00 10 00 00 00 00 00 00 00 01 00 02 00 78 18 00 00 00 00 82 00 00 00 00 00 00 00 00 00 40 00 reg 00007800 00000000 00000000 00000000 00000000 42007810 00000000 00000000 00000000 01000000 01007814 00000000 00000000 00000000 00000100 02007818 00000000 00000000 00000000 00004000 width 320 height 258 depth 20 linebytes c80 address 81000000 ok 0 > my-self . 1fc5abfc ok 0 > my-space ok 1 > . 0 ok 0 > my-address ok 2 > . 0 ok 1 > . 0 ok 0 > my-unit ok 3 > . 7800 ok 2 > . 0 ok 1 > . 0 ok 0 >
So then even computing the parameter to map-in is probably wrong in the word where it gets exception:
: _926 my-address 01000014 + my-space + _867 " map-in" _91f TO _86c 4 my-space + dup " config-b@" _91f 1 or swap " config-b!" _91f ;
I think these my-* values should have some numbers instead of 0. What's the problem here? Looks like it returns first value from reg but shouldn't it return something from assigned-addresses instead?
Regards, BALATON Zoltan
Hi!
On Mon, Jul 15, 2019 at 02:23:24AM +0200, BALATON Zoltan wrote:
0 > " /pci/ATY" select-dev ok
It's called open-dev since ages, fwiw.
0 > my-self . 1fc5abfc ok 0 > my-space ok 1 > . 0 ok
This one should be 7800
0 > my-address ok 2 > . 0 ok 1 > . 0 ok 0 > my-unit ok 3 > . 7800 ok 2 > . 0 ok 1 > . 0 ok
Those all look fine.
I think these my-* values should have some numbers instead of 0. What's the problem here? Looks like it returns first value from reg but shouldn't it return something from assigned-addresses instead?
my-address is two zeroes for configuration space addresses. But my-space shouldn't be zero, it's 7800 here. my-unit should be exactly identical to my-address my-space , but it isn't for you?
Segher
On Mon, 15 Jul 2019, Segher Boessenkool wrote:
0 > " /pci/ATY" select-dev ok
It's called open-dev since ages, fwiw.
https://github.com/openbios/openbios/blob/master/forth/admin/devices.fs#L49
\ Open selected device node and make it the current instance \ section H.8 errata: pre OpenFirmware, but Sun OBP compatible : select-dev ( -- ) open-dev dup 0= abort" failed opening parent." dup to my-self ihandle>phandle active-package! ;
(actually definition of this word seems wrong, it says ( -- ) but really takes the same values as open-dev ( dev-str dev-len -- )? The following just hangs:
dev /pci/ATY select-dev
But I get same results with open-dev:
0 > " /pci/ATY" open-dev to my-self ok 0 > my-space ok 1 > . 0 ok 0 > my-address ok 2 > . 0 ok 1 > . 0 ok 0 > my-unit ok 3 > . 7800 ok 2 > . 0 ok 1 > . 0 ok 0 >
0 > my-self . 1fc5abfc ok 0 > my-space ok 1 > . 0 ok
This one should be 7800
0 > my-address ok 2 > . 0 ok 1 > . 0 ok 0 > my-unit ok 3 > . 7800 ok 2 > . 0 ok 1 > . 0 ok
Those all look fine.
I think these my-* values should have some numbers instead of 0. What's the problem here? Looks like it returns first value from reg but shouldn't it return something from assigned-addresses instead?
my-address is two zeroes for configuration space addresses. But my-space shouldn't be zero, it's 7800 here. my-unit should be exactly identical to my-address my-space , but it isn't for you?
These words are defined here:
https://github.com/openbios/openbios/blob/master/forth/device/package.fs#L17...
but I don't understand how these work and why they don't return correct values.
Regards, BALATON Zoltan
On Mon, 15 Jul 2019, Segher Boessenkool wrote:
0 > my-self . 1fc5abfc ok 0 > my-space ok 1 > . 0 ok
This one should be 7800
0 > my-address ok 2 > . 0 ok 1 > . 0 ok 0 > my-unit ok 3 > . 7800 ok 2 > . 0 ok 1 > . 0 ok
Those all look fine.
I think these my-* values should have some numbers instead of 0. What's the problem here? Looks like it returns first value from reg but shouldn't it return something from assigned-addresses instead?
my-address is two zeroes for configuration space addresses. But my-space shouldn't be zero, it's 7800 here. my-unit should be exactly identical to my-address my-space , but it isn't for you?
So you say it should be
: my-unit my-address my-space ;
but in OpenBIOS we have (in forth/device/package.fs):
\ \ 5.3.4.3 Get local arguments \
: my-address ( -- phys.lo ... ) ?my-self >in.device-node @
dn.probe-addr
my-#acells tuck /l* + swap 1- 0 ?do /l - dup l@ swap loop drop ;
: my-space ( -- phys.hi ) ?my-self >in.device-node @
dn.probe-addr @
;
: my-unit ( -- phys.lo ... phys.hi ) ?my-self >in.my-unit my-#acells tuck /l* + swap 0 ?do /l - dup l@ swap loop drop ;
my-unit seems to get the info from a different place (>in.my-unit vs.
dn.probe-addr) here. Why is that? Also this brings up further questions:
What are in, dn, ihandle, phandle? (I can probably find what do /l and /l* do.)
Regards, BALATON Zoltan
Might this document help? https://docs.oracle.com/cd/E63648_01/pdf/806-1379.pdf
On Fri, Jul 19, 2019 at 5:17 PM BALATON Zoltan balaton@eik.bme.hu wrote:
On Mon, 15 Jul 2019, Segher Boessenkool wrote:
0 > my-self . 1fc5abfc ok 0 > my-space ok 1 > . 0 ok
This one should be 7800
0 > my-address ok 2 > . 0 ok 1 > . 0 ok 0 > my-unit ok 3 > . 7800 ok 2 > . 0 ok 1 > . 0 ok
Those all look fine.
I think these my-* values should have some numbers instead of 0. What's the problem here? Looks like it returns first value from reg but
shouldn't
it return something from assigned-addresses instead?
my-address is two zeroes for configuration space addresses. But
my-space
shouldn't be zero, it's 7800 here. my-unit should be exactly identical to my-address my-space , but it isn't for you?
So you say it should be
: my-unit my-address my-space ;
but in OpenBIOS we have (in forth/device/package.fs):
\ \ 5.3.4.3 Get local arguments \
: my-address ( -- phys.lo ... ) ?my-self >in.device-node @
dn.probe-addr
my-#acells tuck /l* + swap 1- 0 ?do /l - dup l@ swap loop drop ;
: my-space ( -- phys.hi ) ?my-self >in.device-node @
dn.probe-addr @
;
: my-unit ( -- phys.lo ... phys.hi ) ?my-self >in.my-unit my-#acells tuck /l* + swap 0 ?do /l - dup l@ swap loop drop ;
my-unit seems to get the info from a different place (>in.my-unit vs.
dn.probe-addr) here. Why is that? Also this brings up further questions:
What are in, dn, ihandle, phandle? (I can probably find what do /l and /l* do.)
Regards, BALATON Zoltan _______________________________________________ OpenBIOS mailing list -- openbios@openbios.org To unsubscribe send an email to openbios-leave@openbios.org
On Fri, 19 Jul 2019, Howard Spoelstra wrote:
Might this document help? https://docs.oracle.com/cd/E63648_01/pdf/806-1379.pdf
I'm sure it would help I just rather have someone else read it and then answer my questions because I aleady have enough to read (such as ati-vga docs, Pegasos2 chipset docs, PPC docs) so I'd not add OpenFirmware standards and docs to this list because I don't have time for all of these.
Regards, BALATON Zoltan
On Fri, Jul 19, 2019 at 10:36:36PM +0200, BALATON Zoltan wrote:
On Fri, 19 Jul 2019, Howard Spoelstra wrote:
Might this document help? https://docs.oracle.com/cd/E63648_01/pdf/806-1379.pdf
I'm sure it would help I just rather have someone else read it and then answer my questions because I aleady have enough to read (such as ati-vga docs, Pegasos2 chipset docs, PPC docs) so I'd not add OpenFirmware standards and docs to this list because I don't have time for all of these.
If you do not know open firmware basics, and you refuse to learn them, then why (and how!) do you expect us to help you with your misunderstandings of it?
Segher
On Fri, 19 Jul 2019, Segher Boessenkool wrote:
On Fri, Jul 19, 2019 at 10:36:36PM +0200, BALATON Zoltan wrote:
On Fri, 19 Jul 2019, Howard Spoelstra wrote:
Might this document help? https://docs.oracle.com/cd/E63648_01/pdf/806-1379.pdf
I'm sure it would help I just rather have someone else read it and then answer my questions because I aleady have enough to read (such as ati-vga docs, Pegasos2 chipset docs, PPC docs) so I'd not add OpenFirmware standards and docs to this list because I don't have time for all of these.
If you do not know open firmware basics, and you refuse to learn them, then why (and how!) do you expect us to help you with your misunderstandings of it?
By explaining it and answering specific questions so I can learn the small part I need without reading through hundreds of pages? For someone who already read the docs or know these it's probably easy to see why I'm wrong and correct me or point me to the pages I should read to clear my misunderstanding while for me who knows nothing about it I don't even know where to look for an answer. I ask questions here because I hope to get it done quicker that way than learning everything myself to the point that I can do it alone. I'm not refusing to learn but I don't have time to make myself an Open Firmware expert first to be able to make some changes. I hope those who are already experts could help me here this way. That's what a development mailing list is for isn't it? As for why, I do this because no one else does and I need a firmware for the machines I'm trying to emulate in QEMU.
Regards, BALATON Zoltan
Okay, let's try to start at the start then...
You need to know the #address-cells of the bus your device sits on (its parent node), and the reg of your device.
"cells" means 32-bit integers in this context. For PCI buses, it is 3. Addresses on a PCI bus consist of three 32-bit integers, in open firmware.
The address used to identify your device is the first address in reg . It is the PCI configuration space address. This address has the last two cells zero always. The first cell is busdevfn. See page 4 and 5 of https://www.openfirmware.info/data/docs/bus.pci.pdf .
my-space give you that first cell. my-address gives you the rest, so two zeroes here. my-unit gives you all three.
my-unit is more complicated for "wildcard nodes", but you can ignore that stuff. And things are of course a bit different while the device tree is being constructed.
Segher
On Fri, 19 Jul 2019, Segher Boessenkool wrote:
The address used to identify your device is the first address in reg . It is the PCI configuration space address. This address has the last two cells zero always. The first cell is busdevfn. See page 4 and 5 of https://www.openfirmware.info/data/docs/bus.pci.pdf .
my-space give you that first cell. my-address gives you the rest, so two zeroes here. my-unit gives you all three.
OK thanks it makes more sense now (I haven't yet checked the doc but probably will look at it later). At least for the problem of running ATI FCode ROM, based on the above I think the pci-map-in implemented in OpenBIOS's pci driver approximately does what map-in we're missing should do:
https://github.com/openbios/openbios/blob/master/drivers/pci.c#L413
I've also found before that the other missing words seem to have similar but differently named implementations in OpenBIOS as well:
On Mon, 15 Jul 2019, BALATON Zoltan wrote:
Investigating it some more I've found that in OpenBIOS we're missing the register read/write words: r[bwl][!@] besides the pci config-[bwl][!@] words. However we have non-standard io[cwl][!@] words instead (implemented by the io[cwl]{fetch,store} functions in kernel/forth.c) which I think correspond to the missing r[bwl][!@] words so these could be aliased to those. For pci config access we also have non-standard equivalents in
https://github.com/openbios/openbios/blob/master/forth/util/pci.fs
These pci-* words are not much used so maybe we could just rename them to config-* to match OpemFirmware?
Does anyone see a problem with that or do you think this could work?
So I could try to connect the dots and make a patch to test this but is there a way to try from OpenBIOS command line first without patching? I can define words for r* and config-* words like:
: rb! ioc! ; : rb@ ioc@ ; : config-b! pci-c! ; : config-b@ pci-c@ ;
and so on for w and l but how do I define map-in? This should be a method of the parent of the device so it should be added to /pci@f2000000 somehow where it now has pci-map-in. Is there a way to define a new method that's alias of an existing one?
Or maybe it's easier to just rename pci-map-in in source as it only seems to be used by the vga driver FCode part in drivers/vga.fs (where it is used to map PCI BARs of the card, the same as the ATI ROM is trying to do). So is there a reason this is not yet called map-in but pci-map in?
I'll try this when I'll have time but if anyone else wants to test this and come up with a patch I won't mind. (One can tell if it works if the ATI FCode pokes the ati-vga card regs which can be seen with -trace enable='ati*' on QEMU command line.)
Regards, BALATON Zoltan
On Sat, 20 Jul 2019, BALATON Zoltan wrote:
based on the above I think the pci-map-in implemented in OpenBIOS's pci driver approximately does what map-in we're missing should do:
https://github.com/openbios/openbios/blob/master/drivers/pci.c#L413
[...]
Or maybe it's easier to just rename pci-map-in in source as it only seems to be used by the vga driver FCode part in drivers/vga.fs (where it is used to map PCI BARs of the card, the same as the ATI ROM is trying to do). So is there a reason this is not yet called map-in but pci-map in?
I've tried renaming pci-map-in to map-in but it does not seem to work for what the ATI FCode is trying to do. I've also enabled PCI debugging options in OpenBIOS and QEMU, here are some logs I got (this is with the pci-set-args patch we talked about earlier plus renaming pci-map-in to map-in in drivers/pci.c):
[Cut some logs of init-ing other PCI cards, similar as below for ati-vga] 3233@1563634437.470612:pci_cfg_read ati-vga 15:0 @0x0 -> 0x1002 3233@1563634437.470616:pci_cfg_read ati-vga 15:0 @0x2 -> 0x5046 3233@1563634437.470619:pci_cfg_read ati-vga 15:0 @0xa -> 0x300 3233@1563634437.470622:pci_cfg_read ati-vga 15:0 @0x9 -> 0x0
0:f.0 - 1002:5046 -
3233@1563634437.470675:pci_cfg_read ati-vga 15:0 @0xe -> 0x0 /pci@f2000000/ATY - 3233@1563634437.471882:pci_cfg_read ati-vga 15:0 @0x3d -> 0x0 3233@1563634437.471886:pci_cfg_read ati-vga 15:0 @0x10 -> 0x8 3233@1563634437.471889:pci_cfg_write ati-vga 15:0 @0x10 <- 0xffffffff 3233@1563634437.471892:pci_cfg_read ati-vga 15:0 @0x10 -> 0xff000008 changing mem_base from 0x80400000 to 0x82000000
Configuring BARs for /pci@f2000000/ATY: reloc 0x81000000 omask 0x8
io_base 0x1000 mem_base 0x82000000 size 0x1000000 3233@1563634437.472242:pci_cfg_write ati-vga 15:0 @0x10 <- 0x81000008 3233@1563634437.472254:pci_cfg_read ati-vga 15:0 @0x14 -> 0x1 3233@1563634437.472257:pci_cfg_write ati-vga 15:0 @0x14 <- 0xffffffff 3233@1563634437.472260:pci_cfg_read ati-vga 15:0 @0x14 -> 0xffffff01
changing io_base from 0x1000 to 0x1100 Configuring BARs for /pci@f2000000/ATY: reloc 0x1000 omask 0x1 io_base
0x1100 mem_base 0x82000000 size 0x100 3233@1563634437.472556:pci_cfg_write ati-vga 15:0 @0x14 <- 0x1001 3233@1563634437.472566:pci_cfg_read ati-vga 15:0 @0x18 -> 0x0 3233@1563634437.472569:pci_cfg_write ati-vga 15:0 @0x18 <- 0xffffffff 3233@1563634437.472571:pci_cfg_read ati-vga 15:0 @0x18 -> 0xffffc000
changing mem_base from 0x82000000 to 0x82010000 Configuring BARs for /pci@f2000000/ATY: reloc 0x82000000 omask 0x0
io_base 0x1100 mem_base 0x82010000 size 0x10000 3233@1563634437.472878:pci_cfg_write ati-vga 15:0 @0x18 <- 0x82000000 3233@1563634437.472881:pci_cfg_read ati-vga 15:0 @0x1c -> 0x0 3233@1563634437.472884:pci_cfg_write ati-vga 15:0 @0x1c <- 0xffffffff 3233@1563634437.472886:pci_cfg_read ati-vga 15:0 @0x1c -> 0x0 3233@1563634437.472889:pci_cfg_read ati-vga 15:0 @0x20 -> 0x0 3233@1563634437.472891:pci_cfg_write ati-vga 15:0 @0x20 <- 0xffffffff 3233@1563634437.472893:pci_cfg_read ati-vga 15:0 @0x20 -> 0x0 3233@1563634437.472896:pci_cfg_read ati-vga 15:0 @0x24 -> 0x0 3233@1563634437.472898:pci_cfg_write ati-vga 15:0 @0x24 <- 0xffffffff 3233@1563634437.472901:pci_cfg_read ati-vga 15:0 @0x24 -> 0x0 3233@1563634437.472903:pci_cfg_read ati-vga 15:0 @0x30 -> 0x0 3233@1563634437.472906:pci_cfg_write ati-vga 15:0 @0x30 <- 0xffffffff 3233@1563634437.472908:pci_cfg_read ati-vga 15:0 @0x30 -> 0xffff0001
changing mem_base from 0x82010000 to 0x82020000 Configuring BARs for /pci@f2000000/ATY: reloc 0x82010000 omask 0x1
io_base 0x1100 mem_base 0x82020000 size 0x10000 3233@1563634437.473236:pci_cfg_write ati-vga 15:0 @0x30 <- 0x82010001 3233@1563634437.473240:pci_cfg_read ati-vga 15:0 @0x4 -> 0x0 3233@1563634437.473242:pci_cfg_write ati-vga 15:0 @0x4 <- 0x3 3233@1563634437.473244:pci_update_mappings_add d=0x55ef8ac6e280 00:0f.0 0,0x81000000+0x1000000 pci_update_mappings: adding bar 0 to unin-pci-mmio @ 0x81000000 3233@1563634437.473322:pci_update_mappings_add d=0x55ef8ac6e280 00:0f.0 1,0x1000+0x100 pci_update_mappings: adding bar 1 to unin-pci-isa-mmio @ 0x1000 3233@1563634437.473409:pci_update_mappings_add d=0x55ef8ac6e280 00:0f.0 2,0x82000000+0x4000 pci_update_mappings: adding bar 2 to unin-pci-mmio @ 0x82000000 3233@1563634437.473531:pci_update_mappings_add d=0x55ef8ac6e280 00:0f.0 6,0x82010000+0x10000 pci_update_mappings: adding bar 6 to unin-pci-mmio @ 0x82010000 3233@1563634437.473639:pci_cfg_read ati-vga 15:0 @0x0 -> 0x1002 3233@1563634437.473643:pci_cfg_read ati-vga 15:0 @0x2 -> 0x5046 3233@1563634437.473645:pci_cfg_read ati-vga 15:0 @0x8 -> 0x0 3233@1563634437.473647:pci_cfg_read ati-vga 15:0 @0x9 -> 0x0 3233@1563634437.473649:pci_cfg_read ati-vga 15:0 @0xa -> 0x300 3233@1563634437.473914:pci_cfg_read ati-vga 15:0 @0x3e -> 0x0 3233@1563634437.474012:pci_cfg_read ati-vga 15:0 @0x3f -> 0x0 3233@1563634437.474146:pci_cfg_read ati-vga 15:0 @0x6 -> 0x0 3233@1563634437.474261:pci_cfg_read ati-vga 15:0 @0x2c -> 0x1af4 3233@1563634437.474380:pci_cfg_read ati-vga 15:0 @0x2e -> 0x1100 3233@1563634437.474515:pci_cfg_read ati-vga 15:0 @0xc -> 0x0
ob_pci_encode_unit space=0 dev=15 fn=0 buf=f
=== CHANGED === package path old=/pci@f2000000/ATY
new=/pci@f2000000/ATY@f
pci_set_reg reg 00007800 00000000 00000000 00000000 00000000 42007810
00000000 00000000 00000000 01000000 01007814 00000000 00000000 00000000 00000100 02007818 00000000 00000000 00000000 00004000 3233@1563634437.593836:pci_cfg_read uni-north-pci 11:0 @0x30 -> 0x0 3233@1563634437.593845:pci_cfg_write uni-north-pci 11:0 @0x0 <- 0x1
ob_pci_decode_unit idx=1fc5a984 ob_pci_decode_unit idx=1fc5a984 addr=00000000 00000000 00007800 ob_pci_bar_map_in idx=1fc5a984 ob_pci_map: phys=0x82000000 size=16384 ob_pci_bar_map_in idx=1fc5a984 ob_pci_map: phys=0x81000000 size=16777216 ob_pci_decode_unit idx=1fc5a984 ob_pci_decode_unit idx=1fc5a984 addr=00000000 00000000 00007800
3233@1563634437.781563:pci_cfg_write uni-north-pci 11:0 @0x1a <- 0x0
bridge /pci@f2000000 PCI bus primary=0 secondary=0 subordinate=0
3233@1563634437.781711:pci_cfg_write uni-north-pci 11:0 @0x22 <- 0x8200 3233@1563634437.781718:pci_cfg_write uni-north-pci 11:0 @0x32 <- 0x0 3233@1563634437.781724:pci_cfg_write uni-north-pci 11:0 @0x1d <- 0x10 3233@1563634437.781729:pci_cfg_read uni-north-pci 11:0 @0x4 -> 0x3
setting bus range for /pci@f2000000 PCI device, package handle fff5b0a8
bus primary=0 secondary=0 subordinate=0
setting up interrupt map for host fff5b0a8 set_property: NULL phandle
============================================================= OpenBIOS 1.1 [Jul 20 2019 14:01] Configuration device id QEMU version 1 machine id 1 CPUs: 1 Memory: 512M UUID: 00000000-0000-0000-0000-000000000000 CPU type PowerPC,G4
milliseconds isn't unique.
ob_pci_decode_unit idx=fff5b130 ob_pci_decode_unit idx=fff5b130 addr=00000000 00000000 00006000 ob_pci_decode_unit idx=1fc5ab54 ob_pci_decode_unit idx=1fc5ab54 addr=00000000 00000000 00006000 ob_pci_encode_unit space=0 dev=13 fn=0 buf=d ob_pci_decode_unit idx=fff5b130 ob_pci_decode_unit idx=fff5b130 addr=00000000 00000000 00006000 ob_pci_decode_unit idx=fff5b130 ob_pci_decode_unit idx=fff5b130 addr=00000000 00000000 00006000 ob_pci_decode_unit idx=1fc5acc0 ob_pci_decode_unit idx=1fc5acc0 addr=00000000 00000000 00006000 ob_pci_decode_unit idx=fff5b130 ob_pci_decode_unit idx=fff5b130 addr=00000000 00000000 00006000 ob_pci_decode_unit idx=1fc5adc8 ob_pci_decode_unit idx=1fc5adc8 addr=00000000 00000000 00006000
Welcome to OpenBIOS v1.1 built on Jul 20 2019 14:01
0 > dev /pci@f2000000/ATY ok 0 > .properties name "ATY" vendor-id 1002 device-id 5046 revision-id 0 class-code 30000 min-grant 0 max-latency 0 devsel-speed 0 subsystem-vendor-id 1af4 subsystem-id 1100 cache-line-size 0 device_type "display" model "ATY Rage128" compatible "VGA" assigned-addresses -- 3c : 42 00 78 10 00 00 00 00 81 00 00 00 00 00 00 00 01 00 00 00 01 00 78 14 00 00 00 00 00 00 10 00 00 00 00 00 00 00 01 00 02 00 78 18 00 00 00 00 82 00 00 00 00 00 00 00 00 00 40 00 reg 00007800 00000000 00000000 00000000 00000000 42007810 00000000 00000000 00000000 01000000 01007814 00000000 00000000 00000000 00000100 02007818 00000000 00000000 00000000 00004000 width 320 height 258 depth 20 linebytes c80 address 81000000 ok 0 > " /pci@f2000000/ATY" open-dev to my-self ok 0 > my-unit ok 3 > . 7800 ok 2 > . 0 ok 1 > . 0 ok 0 > my-address ok 2 > . 0 ok 1 > . 0 ok 0 > my-space . 7800 ok 0 > my-address h# 1000014 my-space + h# 100 ok 4 > .s <4> 0 0 1007814 100 ok 4 > " map-in" $call-parent >> ob_pci_bar_map_in idx=1fc5aef4
ob_pci_map: phys=0x00000000 size=256
ok 1 > . -1 ok 0 >
So the ob_pci_bus_map_in() in drivers/pci.c is called but it does not find the correct phys address to map. This is done in ob_pci_map() where I've added a debug message before of_mem_claim_phys() is called. Before that it has these calls:
pci_decode_pci_addr(ba, &flags, &space_code, &mask);
phys = pci_bus_addr_to_host_addr(space_code, ba & ~mask);
So one of these does not work correctly and cannot find the requested space of the card. Maybe this only works for BARs but we need config space here which is not yet supported? Does the above make sense to anyone or do I have to trace it back myself?
Regards, BALATON Zoltan
On 20/07/2019 16:19, BALATON Zoltan wrote:
On Sat, 20 Jul 2019, BALATON Zoltan wrote:
based on the above I think the pci-map-in implemented in OpenBIOS's pci driver approximately does what map-in we're missing should do:
https://github.com/openbios/openbios/blob/master/drivers/pci.c#L413
[...]
Or maybe it's easier to just rename pci-map-in in source as it only seems to be used by the vga driver FCode part in drivers/vga.fs (where it is used to map PCI BARs of the card, the same as the ATI ROM is trying to do). So is there a reason this is not yet called map-in but pci-map in?
I've tried renaming pci-map-in to map-in but it does not seem to work for what the ATI FCode is trying to do. I've also enabled PCI debugging options in OpenBIOS and QEMU, here are some logs I got (this is with the pci-set-args patch we talked about earlier plus renaming pci-map-in to map-in in drivers/pci.c):
[Cut some logs of init-ing other PCI cards, similar as below for ati-vga] 3233@1563634437.470612:pci_cfg_read ati-vga 15:0 @0x0 -> 0x1002 3233@1563634437.470616:pci_cfg_read ati-vga 15:0 @0x2 -> 0x5046 3233@1563634437.470619:pci_cfg_read ati-vga 15:0 @0xa -> 0x300 3233@1563634437.470622:pci_cfg_read ati-vga 15:0 @0x9 -> 0x0
0:f.0 - 1002:5046 -
3233@1563634437.470675:pci_cfg_read ati-vga 15:0 @0xe -> 0x0 /pci@f2000000/ATY - 3233@1563634437.471882:pci_cfg_read ati-vga 15:0 @0x3d -> 0x0 3233@1563634437.471886:pci_cfg_read ati-vga 15:0 @0x10 -> 0x8 3233@1563634437.471889:pci_cfg_write ati-vga 15:0 @0x10 <- 0xffffffff 3233@1563634437.471892:pci_cfg_read ati-vga 15:0 @0x10 -> 0xff000008 changing mem_base from 0x80400000 to 0x82000000
Configuring BARs for /pci@f2000000/ATY: reloc 0x81000000 omask 0x8
io_base 0x1000 mem_base 0x82000000 size 0x1000000 3233@1563634437.472242:pci_cfg_write ati-vga 15:0 @0x10 <- 0x81000008 3233@1563634437.472254:pci_cfg_read ati-vga 15:0 @0x14 -> 0x1 3233@1563634437.472257:pci_cfg_write ati-vga 15:0 @0x14 <- 0xffffffff 3233@1563634437.472260:pci_cfg_read ati-vga 15:0 @0x14 -> 0xffffff01
changing io_base from 0x1000 to 0x1100 Configuring BARs for /pci@f2000000/ATY: reloc 0x1000 omask 0x1 io_base
0x1100 mem_base 0x82000000 size 0x100 3233@1563634437.472556:pci_cfg_write ati-vga 15:0 @0x14 <- 0x1001 3233@1563634437.472566:pci_cfg_read ati-vga 15:0 @0x18 -> 0x0 3233@1563634437.472569:pci_cfg_write ati-vga 15:0 @0x18 <- 0xffffffff 3233@1563634437.472571:pci_cfg_read ati-vga 15:0 @0x18 -> 0xffffc000
changing mem_base from 0x82000000 to 0x82010000 Configuring BARs for /pci@f2000000/ATY: reloc 0x82000000 omask 0x0
io_base 0x1100 mem_base 0x82010000 size 0x10000 3233@1563634437.472878:pci_cfg_write ati-vga 15:0 @0x18 <- 0x82000000 3233@1563634437.472881:pci_cfg_read ati-vga 15:0 @0x1c -> 0x0 3233@1563634437.472884:pci_cfg_write ati-vga 15:0 @0x1c <- 0xffffffff 3233@1563634437.472886:pci_cfg_read ati-vga 15:0 @0x1c -> 0x0 3233@1563634437.472889:pci_cfg_read ati-vga 15:0 @0x20 -> 0x0 3233@1563634437.472891:pci_cfg_write ati-vga 15:0 @0x20 <- 0xffffffff 3233@1563634437.472893:pci_cfg_read ati-vga 15:0 @0x20 -> 0x0 3233@1563634437.472896:pci_cfg_read ati-vga 15:0 @0x24 -> 0x0 3233@1563634437.472898:pci_cfg_write ati-vga 15:0 @0x24 <- 0xffffffff 3233@1563634437.472901:pci_cfg_read ati-vga 15:0 @0x24 -> 0x0 3233@1563634437.472903:pci_cfg_read ati-vga 15:0 @0x30 -> 0x0 3233@1563634437.472906:pci_cfg_write ati-vga 15:0 @0x30 <- 0xffffffff 3233@1563634437.472908:pci_cfg_read ati-vga 15:0 @0x30 -> 0xffff0001
changing mem_base from 0x82010000 to 0x82020000 Configuring BARs for /pci@f2000000/ATY: reloc 0x82010000 omask 0x1
io_base 0x1100 mem_base 0x82020000 size 0x10000 3233@1563634437.473236:pci_cfg_write ati-vga 15:0 @0x30 <- 0x82010001 3233@1563634437.473240:pci_cfg_read ati-vga 15:0 @0x4 -> 0x0 3233@1563634437.473242:pci_cfg_write ati-vga 15:0 @0x4 <- 0x3 3233@1563634437.473244:pci_update_mappings_add d=0x55ef8ac6e280 00:0f.0 0,0x81000000+0x1000000 pci_update_mappings: adding bar 0 to unin-pci-mmio @ 0x81000000 3233@1563634437.473322:pci_update_mappings_add d=0x55ef8ac6e280 00:0f.0 1,0x1000+0x100 pci_update_mappings: adding bar 1 to unin-pci-isa-mmio @ 0x1000 3233@1563634437.473409:pci_update_mappings_add d=0x55ef8ac6e280 00:0f.0 2,0x82000000+0x4000 pci_update_mappings: adding bar 2 to unin-pci-mmio @ 0x82000000 3233@1563634437.473531:pci_update_mappings_add d=0x55ef8ac6e280 00:0f.0 6,0x82010000+0x10000 pci_update_mappings: adding bar 6 to unin-pci-mmio @ 0x82010000 3233@1563634437.473639:pci_cfg_read ati-vga 15:0 @0x0 -> 0x1002 3233@1563634437.473643:pci_cfg_read ati-vga 15:0 @0x2 -> 0x5046 3233@1563634437.473645:pci_cfg_read ati-vga 15:0 @0x8 -> 0x0 3233@1563634437.473647:pci_cfg_read ati-vga 15:0 @0x9 -> 0x0 3233@1563634437.473649:pci_cfg_read ati-vga 15:0 @0xa -> 0x300 3233@1563634437.473914:pci_cfg_read ati-vga 15:0 @0x3e -> 0x0 3233@1563634437.474012:pci_cfg_read ati-vga 15:0 @0x3f -> 0x0 3233@1563634437.474146:pci_cfg_read ati-vga 15:0 @0x6 -> 0x0 3233@1563634437.474261:pci_cfg_read ati-vga 15:0 @0x2c -> 0x1af4 3233@1563634437.474380:pci_cfg_read ati-vga 15:0 @0x2e -> 0x1100 3233@1563634437.474515:pci_cfg_read ati-vga 15:0 @0xc -> 0x0
ob_pci_encode_unit space=0 dev=15 fn=0 buf=f
=== CHANGED === package path old=/pci@f2000000/ATY
new=/pci@f2000000/ATY@f
pci_set_reg reg 00007800 00000000 00000000 00000000 00000000 42007810
00000000 00000000 00000000 01000000 01007814 00000000 00000000 00000000 00000100 02007818 00000000 00000000 00000000 00004000 3233@1563634437.593836:pci_cfg_read uni-north-pci 11:0 @0x30 -> 0x0 3233@1563634437.593845:pci_cfg_write uni-north-pci 11:0 @0x0 <- 0x1
ob_pci_decode_unit idx=1fc5a984 ob_pci_decode_unit idx=1fc5a984 addr=00000000 00000000 00007800 ob_pci_bar_map_in idx=1fc5a984 ob_pci_map: phys=0x82000000 size=16384 ob_pci_bar_map_in idx=1fc5a984 ob_pci_map: phys=0x81000000 size=16777216 ob_pci_decode_unit idx=1fc5a984 ob_pci_decode_unit idx=1fc5a984 addr=00000000 00000000 00007800
3233@1563634437.781563:pci_cfg_write uni-north-pci 11:0 @0x1a <- 0x0
bridge /pci@f2000000 PCI bus primary=0 secondary=0 subordinate=0
3233@1563634437.781711:pci_cfg_write uni-north-pci 11:0 @0x22 <- 0x8200 3233@1563634437.781718:pci_cfg_write uni-north-pci 11:0 @0x32 <- 0x0 3233@1563634437.781724:pci_cfg_write uni-north-pci 11:0 @0x1d <- 0x10 3233@1563634437.781729:pci_cfg_read uni-north-pci 11:0 @0x4 -> 0x3
setting bus range for /pci@f2000000 PCI device, package handle fff5b0a8
bus primary=0 secondary=0 subordinate=0
setting up interrupt map for host fff5b0a8 set_property: NULL phandle
============================================================= OpenBIOS 1.1 [Jul 20 2019 14:01] Configuration device id QEMU version 1 machine id 1 CPUs: 1 Memory: 512M UUID: 00000000-0000-0000-0000-000000000000 CPU type PowerPC,G4
milliseconds isn't unique.
ob_pci_decode_unit idx=fff5b130 ob_pci_decode_unit idx=fff5b130 addr=00000000 00000000 00006000 ob_pci_decode_unit idx=1fc5ab54 ob_pci_decode_unit idx=1fc5ab54 addr=00000000 00000000 00006000 ob_pci_encode_unit space=0 dev=13 fn=0 buf=d ob_pci_decode_unit idx=fff5b130 ob_pci_decode_unit idx=fff5b130 addr=00000000 00000000 00006000 ob_pci_decode_unit idx=fff5b130 ob_pci_decode_unit idx=fff5b130 addr=00000000 00000000 00006000 ob_pci_decode_unit idx=1fc5acc0 ob_pci_decode_unit idx=1fc5acc0 addr=00000000 00000000 00006000 ob_pci_decode_unit idx=fff5b130 ob_pci_decode_unit idx=fff5b130 addr=00000000 00000000 00006000 ob_pci_decode_unit idx=1fc5adc8 ob_pci_decode_unit idx=1fc5adc8 addr=00000000 00000000 00006000
Welcome to OpenBIOS v1.1 built on Jul 20 2019 14:01
0 > dev /pci@f2000000/ATY ok 0 > .properties name "ATY" vendor-id 1002 device-id 5046 revision-id 0 class-code 30000 min-grant 0 max-latency 0 devsel-speed 0 subsystem-vendor-id 1af4 subsystem-id 1100 cache-line-size 0 device_type "display" model "ATY Rage128" compatible "VGA" assigned-addresses -- 3c : 42 00 78 10 00 00 00 00 81 00 00 00 00 00 00 00 01 00 00 00 01 00 78 14 00 00 00 00 00 00 10 00 00 00 00 00 00 00 01 00 02 00 78 18 00 00 00 00 82 00 00 00 00 00 00 00 00 00 40 00 reg 00007800 00000000 00000000 00000000 00000000 42007810 00000000 00000000 00000000 01000000 01007814 00000000 00000000 00000000 00000100 02007818 00000000 00000000 00000000 00004000 width 320 height 258 depth 20 linebytes c80 address 81000000 ok 0 > " /pci@f2000000/ATY" open-dev to my-self ok 0 > my-unit ok 3 > . 7800 ok 2 > . 0 ok 1 > . 0 ok 0 > my-address ok 2 > . 0 ok 1 > . 0 ok 0 > my-space . 7800 ok 0 > my-address h# 1000014 my-space + h# 100 ok 4 > .s <4> 0 0 1007814 100 ok 4 > " map-in" $call-parent >> ob_pci_bar_map_in idx=1fc5aef4
ob_pci_map: phys=0x00000000 size=256
ok 1 > . -1 ok 0 >
So the ob_pci_bus_map_in() in drivers/pci.c is called but it does not find the correct phys address to map. This is done in ob_pci_map() where I've added a debug message before of_mem_claim_phys() is called. Before that it has these calls:
pci_decode_pci_addr(ba, &flags, &space_code, &mask);
phys = pci_bus_addr_to_host_addr(space_code, ba & ~mask);
So one of these does not work correctly and cannot find the requested space of the card. Maybe this only works for BARs but we need config space here which is not yet supported? Does the above make sense to anyone or do I have to trace it back myself?
I'm fairly sure the reason I named the function pci-map-in rather than just map-in is because it doesn't quite follow the spec, but it's enough to allow us to map various devices within memory such as the in-built VGA driver in vga.fs (see there for an example usage).
Probably the correct solution is to create a call-parent chain much like the dma-* words which should also enable you to get rid of the hack that is pci_bus_addr_to_host_addr(). Also looking at your Forth above where you are about to call map-in for a PCI device the parameters look correct, so it's really the PCI mapping function that needs to be tweaked here.
ATB,
Mark.
On Sat, Jul 20, 2019 at 04:39:08PM +0100, Mark Cave-Ayland wrote:
I'm fairly sure the reason I named the function pci-map-in rather than just map-in is because it doesn't quite follow the spec, but it's enough to allow us to map various devices within memory such as the in-built VGA driver in vga.fs (see there for an example usage).
There is no standard map-in word, only map-in device methods, which can be different for each (bus) node. It is convenient to have some global words that work for many buses on a system, like your pci-map-in probably is; it is also helpful to have separate names for them then, to ease debugging.
Segher
On Sat, 20 Jul 2019, Mark Cave-Ayland wrote:
Probably the correct solution is to create a call-parent chain much like the dma-* words which should also enable you to get rid of the hack that is pci_bus_addr_to_host_addr().
Maybe we don't need a chain up to the root for this. SLOF seems to translate adresses by looking at the parent's ranges property. See translate-address in this file:
https://github.com/aik/SLOF/blob/master/slof/fs/translate.fs
This is used to implement map-in as well:
https://github.com/aik/SLOF/blob/master/slof/fs/pci-config-bridge.fs
Maybe we should do the same (either in Forth or in C).
Regards, BALATON Zoltan
Hello,
OK back to this thread now that map-in and other missing words are implemented enough to test this (improvements to the pci-map-in patch will be in the implementing map-in thread, this is about running the FCode ROM now to keep it organised).
With my last pci-map-in patch on top of Mark's device tree creation and set-args fixes to OpenBIOS the FCode ROM now runs but we don't get correct picture yet with MacOS (and maybe the NDRV does not fully init yet).
You'll also need these two QEMU patches at the moment before they are merged in QEMU:
http://patchwork.ozlabs.org/patch/1127919/ http://patchwork.ozlabs.org/patch/1136568/
The GPIO_MONID patch fixes EDID access (at least for the Rage128Ps-110 FCode ROM), the other one tries to add registers the NDRV seems to access but not sure if those are correct.
The FCode ROM switches mode but does that before reading EDID and with parameters that I can't handle from the emulation so the question is why it selects this mode and if this is correct. What mode does it set on real hardware? Before setting the mode it tries to access another set of registers similar to what is used to get the EDID. These are called AMCGPIO in the doc but not explained what that is. AMC may be ATI Multimedia Channel which is an ATI specific feature connector but I'm not sure. Does it try to access some info over that? Does the card have multiple connectors and it expects the primary display somewhere else than what we emulate? The NDRV also only seems to try the AMCGPIO regs and stop after that without trying the switch mode. Does anyone have any info on this or knows about some source of info?
Regards, BALATON Zoltan
On Thu, 25 Jul 2019, BALATON Zoltan wrote:
With my last pci-map-in patch on top of Mark's device tree creation and set-args fixes to OpenBIOS the FCode ROM now runs but we don't get correct picture yet with MacOS (and maybe the NDRV does not fully init yet).
You'll also need these two QEMU patches at the moment before they are merged in QEMU:
http://patchwork.ozlabs.org/patch/1127919/ http://patchwork.ozlabs.org/patch/1136568/
The GPIO_MONID patch fixes EDID access (at least for the Rage128Ps-110 FCode ROM), the other one tries to add registers the NDRV seems to access but not sure if those are correct.
The FCode ROM switches mode but does that before reading EDID and with parameters that I can't handle from the emulation so the question is why it
Here's another QEMU patch that hopefully fixes handling the offset that is set by the FCode ROM:
http://patchwork.ozlabs.org/patch/1136954/
Picture is still broken but maybe now because of a mismatch between the VGA driver of OpenBIOS and the FCode ROM programming the card and setting up its own words but I'm not sure OpenBIOS uses those and maybe blindly continues to use its own driver instead which no longer works after FCode ROM has set up the card. Maybe the gfx card initialisation should now be fixed in OpenBIOS to allow proper FCode ROMs to init the card and turn the OpenBIOS vga driver into FCode as well so it works more like it should on real hardware. This looks like a welcome clean up but I'm not volunteering to do that because I don't know enough about how this should work just so I'm bringing up the topic here for comments.
selects this mode and if this is correct. What mode does it set on real hardware? Before setting the mode it tries to access another set of registers similar to what is used to get the EDID. These are called AMCGPIO in the doc but not explained what that is. AMC may be ATI Multimedia Channel which is an ATI specific feature connector but I'm not sure. Does it try to access some info over that? Does the card have multiple connectors and it expects the primary display somewhere else than what we emulate? The NDRV also only seems to try the AMCGPIO regs and stop after that without trying the switch mode. Does anyone have any info on this or knows about some source of info?
This is still the same. I wonder if MacOS uses the firmware routines to draw before the NDRV is inited and picture is now broken because OpenBIOS does not know about what the FCode has done and uses the wrong routines to drive the card? Then next question is why NDRV stops but I can't answer that because it gives no error and just stops accessing card regs after attempting to read something (EDID?) from AMCGPIO regs and getting BAR addresses. So someone may need to debug the NDRV to find out.
Regards, BALATON Zoltan
On Thu, 25 Jul 2019, BALATON Zoltan wrote:
On Thu, 25 Jul 2019, BALATON Zoltan wrote:
With my last pci-map-in patch on top of Mark's device tree creation and set-args fixes to OpenBIOS the FCode ROM now runs but we don't get correct picture yet with MacOS (and maybe the NDRV does not fully init yet).
You'll also need these two QEMU patches at the moment before they are merged in QEMU:
http://patchwork.ozlabs.org/patch/1127919/ http://patchwork.ozlabs.org/patch/1136568/
The GPIO_MONID patch fixes EDID access (at least for the Rage128Ps-110 FCode ROM), the other one tries to add registers the NDRV seems to access but not sure if those are correct.
The FCode ROM switches mode but does that before reading EDID and with parameters that I can't handle from the emulation so the question is why it
I've found that the card has two ports but we only emulate the VGA one not the DVI. The ROM tries to get EDID from flat panel (DVI?) first, if it finds that it won't init the CRTC part so we get no picture. Therefore I think this is now OK and what happens is FCode tries reading EDID from DVI and when that fails switches to VGA port and sets default mode before reading EDID which it then puts in the device tree. I'm not sure how it selects default mode though, probably not from EDID.
Here's another QEMU patch that hopefully fixes handling the offset that is set by the FCode ROM:
http://patchwork.ozlabs.org/patch/1136954/
Picture is still broken but maybe now because of a mismatch between the VGA driver of OpenBIOS and the FCode ROM programming the card and setting up its own words but I'm not sure OpenBIOS uses those and maybe blindly continues to use its own driver instead which no longer works after FCode ROM has set up the card. Maybe the gfx card initialisation should now be fixed in OpenBIOS to allow proper FCode ROMs to init the card and turn the OpenBIOS vga driver into FCode as well so it works more like it should on real hardware. This looks like a welcome clean up but I'm not volunteering to do that because I don't know enough about how this should work just so I'm bringing up the topic here for comments.
We've tried to find why the NDRV that the FCode installs fails during booting MacOS but we could not find out yet. It also tries getting DFP EDID but it does not matter if it finds that or not. Then queries BAR addresses and after trying to switch to mmio it stops working. I've compared device tree properties after FCode run to those on real hardware and found these differences:
1. address is missing the 8000 offset that also appears in the screen mode it switches to but I don't know why. Manually changing it by
81008000 encode-int " address" property
before boot does not fix display and NDRV still hangs so while this is likely wrong not what causing the NDRV to exit.
2. reg property matches but assigned-addresses has several differences (probably need my patch from openbios list to see it). In OpenBIOS we have io BAR mapped but ROM BAR not mapped and the vram BAR size is 1000000 instead of 4000000 (i.e. only 4M vram is mapped instead of the full vram). Not sure if any of these causes problem with NDRV.
OpenBIOS: assigned-addresses 42007810 00000000 81000000 00000000 01000000 01007814 00000000 00001000 00000000 00000100 02007818 00000000 82000000 00000000 00004000 reg 00007800 00000000 00000000 00000000 00000000 02007830 00000000 00000000 00000000 00020000 42007810 00000000 00000000 00000000 04000000 02007818 00000000 00000000 00000000 00004000
real machine: assigned-addresses c2008010 00000000 94000000 00000000 04000000 82008030 00000000 90020000 00000000 00020000 82008018 00000000 90000000 00000000 00004000 reg 00008000 00000000 00000000 00000000 00000000 02008030 00000000 00000000 00000000 00020000 42008010 00000000 00000000 00000000 04000000 02008018 00000000 00000000 00000000 00004000
3. We don't have AGP_Master and ATYN property. The AGP one is likely not needed but not sure about what ATYN is.
hardware? Before setting the mode it tries to access another set of registers similar to what is used to get the EDID. These are called AMCGPIO in the doc but not explained what that is. AMC may be ATI Multimedia Channel which is an ATI specific feature connector but I'm not sure. Does it try to access some info over that? Does the card have multiple connectors and it expects the primary display somewhere else than what we emulate? The NDRV also only seems to try the AMCGPIO regs and stop after that without trying the switch mode. Does anyone have any info on this or knows about some source of info?
Answering myself: this is where the EDID form the DFP is read so I think it's maybe connected to DVI port or it's unused on the card and useful in laptops. In any case we don't emulate DFP controller only CRT so this is not needed and likely not where NDRV fails as it does run a bit further after this.
This is still the same. I wonder if MacOS uses the firmware routines to draw before the NDRV is inited and picture is now broken because OpenBIOS does not know about what the FCode has done and uses the wrong routines to drive the card? Then next question is why NDRV stops but I can't answer that because it gives no error and just stops accessing card regs after attempting to read something (EDID?) from AMCGPIO regs and getting BAR addresses. So someone may need to debug the NDRV to find out.
Still don't know what happens with NDRV, it's not the missing EDID from AMCGPIO regs and not the wrong address property. The last thing the NDRV appears to do is getting mmio and ROM BARs then trying to set up mmio but after that no register writes or reads reach the card but I'm not sure why.
I think that's enough for me of this, I'll let others who are interested in making this work experiment with it and find out.
Regards, BALATON Zoltan
Executing the FCode ROM completely screws up all the address and device properties in PCIPeek under OS 9.
The card is in an unusable state, it doesn’t even have unit address, vendor or device ID’s.
On Jul 27, 2019, at 7:00 PM, BALATON Zoltan balaton@eik.bme.hu wrote:
On Thu, 25 Jul 2019, BALATON Zoltan wrote:
On Thu, 25 Jul 2019, BALATON Zoltan wrote:
With my last pci-map-in patch on top of Mark's device tree creation and set-args fixes to OpenBIOS the FCode ROM now runs but we don't get correct picture yet with MacOS (and maybe the NDRV does not fully init yet). You'll also need these two QEMU patches at the moment before they are merged in QEMU: http://patchwork.ozlabs.org/patch/1127919/ http://patchwork.ozlabs.org/patch/1136568/ The GPIO_MONID patch fixes EDID access (at least for the Rage128Ps-110 FCode ROM), the other one tries to add registers the NDRV seems to access but not sure if those are correct. The FCode ROM switches mode but does that before reading EDID and with parameters that I can't handle from the emulation so the question is why it
I've found that the card has two ports but we only emulate the VGA one not the DVI. The ROM tries to get EDID from flat panel (DVI?) first, if it finds that it won't init the CRTC part so we get no picture. Therefore I think this is now OK and what happens is FCode tries reading EDID from DVI and when that fails switches to VGA port and sets default mode before reading EDID which it then puts in the device tree. I'm not sure how it selects default mode though, probably not from EDID.
Here's another QEMU patch that hopefully fixes handling the offset that is set by the FCode ROM:
http://patchwork.ozlabs.org/patch/1136954/
Picture is still broken but maybe now because of a mismatch between the VGA driver of OpenBIOS and the FCode ROM programming the card and setting up its own words but I'm not sure OpenBIOS uses those and maybe blindly continues to use its own driver instead which no longer works after FCode ROM has set up the card. Maybe the gfx card initialisation should now be fixed in OpenBIOS to allow proper FCode ROMs to init the card and turn the OpenBIOS vga driver into FCode as well so it works more like it should on real hardware. This looks like a welcome clean up but I'm not volunteering to do that because I don't know enough about how this should work just so I'm bringing up the topic here for comments.
We've tried to find why the NDRV that the FCode installs fails during booting MacOS but we could not find out yet. It also tries getting DFP EDID but it does not matter if it finds that or not. Then queries BAR addresses and after trying to switch to mmio it stops working. I've compared device tree properties after FCode run to those on real hardware and found these differences:
- address is missing the 8000 offset that also appears in the screen mode it switches to but I don't know why. Manually changing it by
81008000 encode-int " address" property
before boot does not fix display and NDRV still hangs so while this is likely wrong not what causing the NDRV to exit.
- reg property matches but assigned-addresses has several differences (probably need my patch from openbios list to see it). In OpenBIOS we have io BAR mapped but ROM BAR not mapped and the vram BAR size is 1000000 instead of 4000000 (i.e. only 4M vram is mapped instead of the full vram). Not sure if any of these causes problem with NDRV.
OpenBIOS: assigned-addresses 42007810 00000000 81000000 00000000 01000000 01007814 00000000 00001000 00000000 00000100 02007818 00000000 82000000 00000000 00004000 reg 00007800 00000000 00000000 00000000 00000000 02007830 00000000 00000000 00000000 00020000 42007810 00000000 00000000 00000000 04000000 02007818 00000000 00000000 00000000 00004000
real machine: assigned-addresses c2008010 00000000 94000000 00000000 04000000 82008030 00000000 90020000 00000000 00020000 82008018 00000000 90000000 00000000 00004000 reg 00008000 00000000 00000000 00000000 00000000 02008030 00000000 00000000 00000000 00020000 42008010 00000000 00000000 00000000 04000000 02008018 00000000 00000000 00000000 00004000
- We don't have AGP_Master and ATYN property. The AGP one is likely not needed but not sure about what ATYN is.
hardware? Before setting the mode it tries to access another set of registers similar to what is used to get the EDID. These are called AMCGPIO in the doc but not explained what that is. AMC may be ATI Multimedia Channel which is an ATI specific feature connector but I'm not sure. Does it try to access some info over that? Does the card have multiple connectors and it expects the primary display somewhere else than what we emulate? The NDRV also only seems to try the AMCGPIO regs and stop after that without trying the switch mode. Does anyone have any info on this or knows about some source of info?
Answering myself: this is where the EDID form the DFP is read so I think it's maybe connected to DVI port or it's unused on the card and useful in laptops. In any case we don't emulate DFP controller only CRT so this is not needed and likely not where NDRV fails as it does run a bit further after this.
This is still the same. I wonder if MacOS uses the firmware routines to draw before the NDRV is inited and picture is now broken because OpenBIOS does not know about what the FCode has done and uses the wrong routines to drive the card? Then next question is why NDRV stops but I can't answer that because it gives no error and just stops accessing card regs after attempting to read something (EDID?) from AMCGPIO regs and getting BAR addresses. So someone may need to debug the NDRV to find out.
Still don't know what happens with NDRV, it's not the missing EDID from AMCGPIO regs and not the wrong address property. The last thing the NDRV appears to do is getting mmio and ROM BARs then trying to set up mmio but after that no register writes or reads reach the card but I'm not sure why.
I think that's enough for me of this, I'll let others who are interested in making this work experiment with it and find out.
Regards, BALATON Zoltan _______________________________________________ OpenBIOS mailing list -- openbios@openbios.org To unsubscribe send an email to openbios-leave@openbios.org
Hello,
On Fri, 2 Aug 2019, Jd Lyons wrote:
Executing the FCode ROM completely screws up all the address and device properties in PCIPeek under OS 9.
The card is in an unusable state, it doesn’t even have unit address, vendor or device ID’s.
You should elaboreate a bit more because I'm not sure what you did. What FCode ROM did you run with which OpenBIOS and which card and how did it screw up device state and properties?
Regards, BALATON Zoltan
I think the only properties that matter are the “ name” property and the “ EDID” property.
I think if we just inject them correctly into the device tree for the card we will have more success……….
On Aug 2, 2019, at 6:08 AM, Jd Lyons lyons_dj@yahoo.com wrote:
Executing the FCode ROM completely screws up all the address and device properties in PCIPeek under OS 9.
The card is in an unusable state, it doesn’t even have unit address, vendor or device ID’s.
On Jul 27, 2019, at 7:00 PM, BALATON Zoltan balaton@eik.bme.hu wrote:
On Thu, 25 Jul 2019, BALATON Zoltan wrote:
On Thu, 25 Jul 2019, BALATON Zoltan wrote:
With my last pci-map-in patch on top of Mark's device tree creation and set-args fixes to OpenBIOS the FCode ROM now runs but we don't get correct picture yet with MacOS (and maybe the NDRV does not fully init yet). You'll also need these two QEMU patches at the moment before they are merged in QEMU: http://patchwork.ozlabs.org/patch/1127919/ http://patchwork.ozlabs.org/patch/1136568/ The GPIO_MONID patch fixes EDID access (at least for the Rage128Ps-110 FCode ROM), the other one tries to add registers the NDRV seems to access but not sure if those are correct. The FCode ROM switches mode but does that before reading EDID and with parameters that I can't handle from the emulation so the question is why it
I've found that the card has two ports but we only emulate the VGA one not the DVI. The ROM tries to get EDID from flat panel (DVI?) first, if it finds that it won't init the CRTC part so we get no picture. Therefore I think this is now OK and what happens is FCode tries reading EDID from DVI and when that fails switches to VGA port and sets default mode before reading EDID which it then puts in the device tree. I'm not sure how it selects default mode though, probably not from EDID.
Here's another QEMU patch that hopefully fixes handling the offset that is set by the FCode ROM:
http://patchwork.ozlabs.org/patch/1136954/
Picture is still broken but maybe now because of a mismatch between the VGA driver of OpenBIOS and the FCode ROM programming the card and setting up its own words but I'm not sure OpenBIOS uses those and maybe blindly continues to use its own driver instead which no longer works after FCode ROM has set up the card. Maybe the gfx card initialisation should now be fixed in OpenBIOS to allow proper FCode ROMs to init the card and turn the OpenBIOS vga driver into FCode as well so it works more like it should on real hardware. This looks like a welcome clean up but I'm not volunteering to do that because I don't know enough about how this should work just so I'm bringing up the topic here for comments.
We've tried to find why the NDRV that the FCode installs fails during booting MacOS but we could not find out yet. It also tries getting DFP EDID but it does not matter if it finds that or not. Then queries BAR addresses and after trying to switch to mmio it stops working. I've compared device tree properties after FCode run to those on real hardware and found these differences:
- address is missing the 8000 offset that also appears in the screen mode it switches to but I don't know why. Manually changing it by
81008000 encode-int " address" property
before boot does not fix display and NDRV still hangs so while this is likely wrong not what causing the NDRV to exit.
- reg property matches but assigned-addresses has several differences (probably need my patch from openbios list to see it). In OpenBIOS we have io BAR mapped but ROM BAR not mapped and the vram BAR size is 1000000 instead of 4000000 (i.e. only 4M vram is mapped instead of the full vram). Not sure if any of these causes problem with NDRV.
OpenBIOS: assigned-addresses 42007810 00000000 81000000 00000000 01000000 01007814 00000000 00001000 00000000 00000100 02007818 00000000 82000000 00000000 00004000 reg 00007800 00000000 00000000 00000000 00000000 02007830 00000000 00000000 00000000 00020000 42007810 00000000 00000000 00000000 04000000 02007818 00000000 00000000 00000000 00004000
real machine: assigned-addresses c2008010 00000000 94000000 00000000 04000000 82008030 00000000 90020000 00000000 00020000 82008018 00000000 90000000 00000000 00004000 reg 00008000 00000000 00000000 00000000 00000000 02008030 00000000 00000000 00000000 00020000 42008010 00000000 00000000 00000000 04000000 02008018 00000000 00000000 00000000 00004000
- We don't have AGP_Master and ATYN property. The AGP one is likely not needed but not sure about what ATYN is.
hardware? Before setting the mode it tries to access another set of registers similar to what is used to get the EDID. These are called AMCGPIO in the doc but not explained what that is. AMC may be ATI Multimedia Channel which is an ATI specific feature connector but I'm not sure. Does it try to access some info over that? Does the card have multiple connectors and it expects the primary display somewhere else than what we emulate? The NDRV also only seems to try the AMCGPIO regs and stop after that without trying the switch mode. Does anyone have any info on this or knows about some source of info?
Answering myself: this is where the EDID form the DFP is read so I think it's maybe connected to DVI port or it's unused on the card and useful in laptops. In any case we don't emulate DFP controller only CRT so this is not needed and likely not where NDRV fails as it does run a bit further after this.
This is still the same. I wonder if MacOS uses the firmware routines to draw before the NDRV is inited and picture is now broken because OpenBIOS does not know about what the FCode has done and uses the wrong routines to drive the card? Then next question is why NDRV stops but I can't answer that because it gives no error and just stops accessing card regs after attempting to read something (EDID?) from AMCGPIO regs and getting BAR addresses. So someone may need to debug the NDRV to find out.
Still don't know what happens with NDRV, it's not the missing EDID from AMCGPIO regs and not the wrong address property. The last thing the NDRV appears to do is getting mmio and ROM BARs then trying to set up mmio but after that no register writes or reads reach the card but I'm not sure why.
I think that's enough for me of this, I'll let others who are interested in making this work experiment with it and find out.
Regards, BALATON Zoltan _______________________________________________ OpenBIOS mailing list -- openbios@openbios.org To unsubscribe send an email to openbios-leave@openbios.org
On Fri, 2 Aug 2019, Jd Lyons wrote:
I think the only properties that matter are the “ name” property and the “ EDID” property.
I think if we just inject them correctly into the device tree for the card we will have more success……….
I don't think that's enough at least it did not work the last time I've tried but could be I made some mistake somewhere. Maybe you'd also need "address" at least which seems to point to the frame buffer address and not sure EDID is needed as the NDRV seems to read it itself as well but without checking what the NDRV does this is all just guessing and we can't be sure. Shortest way to success would be to find out what NDRV does so we can understand why it fails and then fix that instead of trying to find out by trial and error.
Maybe this tool could help: https://web.archive.org/web/20110603204602/http://developer.apple.com/tools/... found as reference on https://en.wikipedia.org/wiki/Preferred_Executable_Format
Or you could also test if adding attributes is enough by either adding these by hand from command line or loading and executing a forth script to do it or temporarily change drivers/vga.fs which is run also for ati-vga so you could add forth code there to add arbitrary properties for testing.
Regards, BALATON Zoltan
I made a custom Mac OS ROM that injects the EDID and ATY,Rage128Ps via a script, however that didn’t solve any issues:-(
Zoltan, did you notice that the node on the PCI bus changes after execution of the FCode ROM, it moves from /pci/@f to /pci/@0.
I think this is why PCIPeek returns garbage and maybe why our NDRV is aborting.
On Aug 2, 2019, at 6:54 AM, Jd Lyons lyons_dj@yahoo.com wrote:
I think the only properties that matter are the “ name” property and the “ EDID” property.
I think if we just inject them correctly into the device tree for the card we will have more success……….
On Aug 2, 2019, at 6:08 AM, Jd Lyons lyons_dj@yahoo.com wrote:
Executing the FCode ROM completely screws up all the address and device properties in PCIPeek under OS 9.
The card is in an unusable state, it doesn’t even have unit address, vendor or device ID’s.
On Jul 27, 2019, at 7:00 PM, BALATON Zoltan balaton@eik.bme.hu wrote:
On Thu, 25 Jul 2019, BALATON Zoltan wrote:
On Thu, 25 Jul 2019, BALATON Zoltan wrote:
With my last pci-map-in patch on top of Mark's device tree creation and set-args fixes to OpenBIOS the FCode ROM now runs but we don't get correct picture yet with MacOS (and maybe the NDRV does not fully init yet). You'll also need these two QEMU patches at the moment before they are merged in QEMU: http://patchwork.ozlabs.org/patch/1127919/ http://patchwork.ozlabs.org/patch/1136568/ The GPIO_MONID patch fixes EDID access (at least for the Rage128Ps-110 FCode ROM), the other one tries to add registers the NDRV seems to access but not sure if those are correct. The FCode ROM switches mode but does that before reading EDID and with parameters that I can't handle from the emulation so the question is why it
I've found that the card has two ports but we only emulate the VGA one not the DVI. The ROM tries to get EDID from flat panel (DVI?) first, if it finds that it won't init the CRTC part so we get no picture. Therefore I think this is now OK and what happens is FCode tries reading EDID from DVI and when that fails switches to VGA port and sets default mode before reading EDID which it then puts in the device tree. I'm not sure how it selects default mode though, probably not from EDID.
Here's another QEMU patch that hopefully fixes handling the offset that is set by the FCode ROM:
http://patchwork.ozlabs.org/patch/1136954/
Picture is still broken but maybe now because of a mismatch between the VGA driver of OpenBIOS and the FCode ROM programming the card and setting up its own words but I'm not sure OpenBIOS uses those and maybe blindly continues to use its own driver instead which no longer works after FCode ROM has set up the card. Maybe the gfx card initialisation should now be fixed in OpenBIOS to allow proper FCode ROMs to init the card and turn the OpenBIOS vga driver into FCode as well so it works more like it should on real hardware. This looks like a welcome clean up but I'm not volunteering to do that because I don't know enough about how this should work just so I'm bringing up the topic here for comments.
We've tried to find why the NDRV that the FCode installs fails during booting MacOS but we could not find out yet. It also tries getting DFP EDID but it does not matter if it finds that or not. Then queries BAR addresses and after trying to switch to mmio it stops working. I've compared device tree properties after FCode run to those on real hardware and found these differences:
- address is missing the 8000 offset that also appears in the screen mode it switches to but I don't know why. Manually changing it by
81008000 encode-int " address" property
before boot does not fix display and NDRV still hangs so while this is likely wrong not what causing the NDRV to exit.
- reg property matches but assigned-addresses has several differences (probably need my patch from openbios list to see it). In OpenBIOS we have io BAR mapped but ROM BAR not mapped and the vram BAR size is 1000000 instead of 4000000 (i.e. only 4M vram is mapped instead of the full vram). Not sure if any of these causes problem with NDRV.
OpenBIOS: assigned-addresses 42007810 00000000 81000000 00000000 01000000 01007814 00000000 00001000 00000000 00000100 02007818 00000000 82000000 00000000 00004000 reg 00007800 00000000 00000000 00000000 00000000 02007830 00000000 00000000 00000000 00020000 42007810 00000000 00000000 00000000 04000000 02007818 00000000 00000000 00000000 00004000
real machine: assigned-addresses c2008010 00000000 94000000 00000000 04000000 82008030 00000000 90020000 00000000 00020000 82008018 00000000 90000000 00000000 00004000 reg 00008000 00000000 00000000 00000000 00000000 02008030 00000000 00000000 00000000 00020000 42008010 00000000 00000000 00000000 04000000 02008018 00000000 00000000 00000000 00004000
- We don't have AGP_Master and ATYN property. The AGP one is likely not needed but not sure about what ATYN is.
hardware? Before setting the mode it tries to access another set of registers similar to what is used to get the EDID. These are called AMCGPIO in the doc but not explained what that is. AMC may be ATI Multimedia Channel which is an ATI specific feature connector but I'm not sure. Does it try to access some info over that? Does the card have multiple connectors and it expects the primary display somewhere else than what we emulate? The NDRV also only seems to try the AMCGPIO regs and stop after that without trying the switch mode. Does anyone have any info on this or knows about some source of info?
Answering myself: this is where the EDID form the DFP is read so I think it's maybe connected to DVI port or it's unused on the card and useful in laptops. In any case we don't emulate DFP controller only CRT so this is not needed and likely not where NDRV fails as it does run a bit further after this.
This is still the same. I wonder if MacOS uses the firmware routines to draw before the NDRV is inited and picture is now broken because OpenBIOS does not know about what the FCode has done and uses the wrong routines to drive the card? Then next question is why NDRV stops but I can't answer that because it gives no error and just stops accessing card regs after attempting to read something (EDID?) from AMCGPIO regs and getting BAR addresses. So someone may need to debug the NDRV to find out.
Still don't know what happens with NDRV, it's not the missing EDID from AMCGPIO regs and not the wrong address property. The last thing the NDRV appears to do is getting mmio and ROM BARs then trying to set up mmio but after that no register writes or reads reach the card but I'm not sure why.
I think that's enough for me of this, I'll let others who are interested in making this work experiment with it and find out.
Regards, BALATON Zoltan _______________________________________________ OpenBIOS mailing list -- openbios@openbios.org To unsubscribe send an email to openbios-leave@openbios.org
On Sat, 3 Aug 2019, Jd Lyons wrote:
Zoltan, did you notice that the node on the PCI bus changes after execution of the FCode ROM, it moves from /pci/@f to /pci/@0.
No I haven't noticed that nor do I know what that means and if it could cause any problems. I think the driver should look at properties and not the node name so I don't think it matters but I don't know. I've only noticed the wrong address, difference in assigned-addresses property and some differences in other properties as I've listed in my original message that you keep quoting below your reply.
I think this is why PCIPeek returns garbage and maybe why our NDRV is aborting.
Not sure about that. It still looks like you're just blindly guessing instead of trying to find out what the NDRV does. I've found there supposed to be pef support in GNU binutils so I've tried compiling it with target powerpc-darwin that adds pef format but it did not recognise the NDRV (maybe it supports a different pef version or has some bugs or I have too old version). So the best tool to look at the NDRV may be the one from MPW but I don'thave experience with that, nor a machine to try it on, nor free time to spend on that.
Regards, BALATON Zoltan
-
BALATON Zoltan -
Howard Spoelstra -
Jd Lyons -
Mark Cave-Ayland -
Segher Boessenkool