Debugging FCode ROM

[BALATON Zoltan]

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/[e-mail]/thread/E7PF…

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

[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

[Jd Lyons]

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(a)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(a)openbios.org
 To unsubscribe send an email to openbios-leave(a)openbios.org

[Jd Lyons]

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(a)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(a)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(a)openbios.org
 To unsubscribe send an email to openbios-leave(a)openbios.org
_______________________________________________
 OpenBIOS mailing list -- openbios(a)openbios.org
 To unsubscribe send an email to openbios-leave(a)openbios.org

[BALATON Zoltan]

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

[Jd Lyons]

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(a)eik.bme.hu> wrote:
 
 
 Yes but how to find which ones? The "exception caught" error is not very
informative about that.

[BALATON Zoltan]

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=a747c4cc98c73d…

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

[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

[Jd Lyons]

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(a)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(a)openbios.org
 To unsubscribe send an email to openbios-leave(a)openbios.org

[Jd Lyons]

Likely failing config-b@ and or config-b!

  On Jul 12, 2019, at 7:38 PM, BALATON Zoltan
<balaton(a)eik.bme.hu> wrote:
 
 400514a :  [ 0x8bc ]
 400514c :  [ 0x926 ]

[Jd Lyons]

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(a)openbios.org> wrote:
 
 Likely failing config-b@ and or config-b!
 
  On Jul 12, 2019, at 7:38 PM, BALATON Zoltan
<balaton(a)eik.bme.hu> wrote:
 
 400514a :  [ 0x8bc ]
 400514c :  [ 0x926 ]
 _______________________________________________
 OpenBIOS mailing list -- openbios(a)openbios.org
 To unsubscribe send an email to openbios-leave(a)openbios.org

[BALATON Zoltan]

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(a)openbios.org> wrote:

 Likely failing config-b@ and or config-b!

  On Jul 12, 2019, at 7:38 PM, BALATON Zoltan
<balaton(a)eik.bme.hu> wrote:

 400514a :  [ 0x8bc ]
 400514c :  [ 0x926 ]
 _______________________________________________
 OpenBIOS mailing list -- openbios(a)openbios.org
 To unsubscribe send an email to openbios-leave(a)openbios.org

[BALATON Zoltan]

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(a)eik.bme.hu> wrote:
>>
>> 400514a :  [ 0x8bc ]
>> 400514c :  [ 0x926 ]
> _______________________________________________
> OpenBIOS mailing list -- openbios(a)openbios.org
> To unsubscribe send an email to openbios-leave(a)openbios.org
>
>

[Jd Lyons]

  On Jul 13, 2019, at 11:39 AM, BALATON Zoltan
<balaton(a)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?

[BALATON Zoltan]

On Sat, 13 Jul 2019, Jd Lyons wrote:
  On Jul 13,
2019, at 11:39 AM, BALATON Zoltan <balaton(a)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

[Jd Lyons]

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(a)eik.bme.hu> wrote:
 
 On Sat, 13 Jul 2019, Jd Lyons wrote:
  On Jul
13, 2019, at 11:39 AM, BALATON Zoltan <balaton(a)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(a)openbios.org
 To unsubscribe send an email to openbios-leave(a)openbios.org

[BALATON Zoltan]

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

[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

[Jd Lyons]

  On Jul 13, 2019, at 1:01 PM, BALATON Zoltan
<balaton(a)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.

[BALATON Zoltan]

On Sat, 13 Jul 2019, Jd Lyons wrote:
  On Jul 13,
2019, at 1:01 PM, BALATON Zoltan <balaton(a)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

[Segher Boessenkool]

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

[BALATON Zoltan]

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/[e-mail]/thread/WVQ6…

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

[Segher Boessenkool]

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/[e-mail]/thread/WVQ6…
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

[Mark Cave-Ayland]

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.

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

[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

[Jd Lyons]

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(a)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(a)openbios.org
 To unsubscribe send an email to openbios-leave(a)openbios.org

[BALATON Zoltan]

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

[Mark Cave-Ayland]

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.

[BALATON Zoltan]

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
 1) 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

[Mark Cave-Ayland]

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

[BALATON Zoltan]

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
 1) 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

[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

[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

[Mark Cave-Ayland]

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.

[BALATON Zoltan]

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

[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

[Mark Cave-Ayland]

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.

[Segher Boessenkool]

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

[Mark Cave-Ayland]

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

[BALATON Zoltan]

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

[Mark Cave-Ayland]

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.

[BALATON Zoltan]

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

[Mark Cave-Ayland]

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.

[BALATON Zoltan]

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

[Segher Boessenkool]

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

[BALATON Zoltan]

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

[Segher Boessenkool]

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

[BALATON Zoltan]

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

[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

[Segher Boessenkool]

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

[BALATON Zoltan]

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#L1…

but I don't understand how these work and why they don't return correct 
values.

Regards,
BALATON Zoltan

[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

[Howard Spoelstra]

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(a)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(a)openbios.org
 To unsubscribe send an email to openbios-leave(a)openbios.org

[BALATON Zoltan]

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

[Segher Boessenkool]

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

[BALATON Zoltan]

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

[Segher Boessenkool]

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

[BALATON Zoltan]

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

[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

[Mark Cave-Ayland]

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.

[Segher Boessenkool]

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

[BALATON Zoltan]

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

[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

[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

[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

[Jd Lyons]

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(a)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:
 
 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
 _______________________________________________
 OpenBIOS mailing list -- openbios(a)openbios.org
 To unsubscribe send an email to openbios-leave(a)openbios.org

[BALATON Zoltan]

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

[Jd Lyons]

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(a)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(a)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:
 
 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
 _______________________________________________
 OpenBIOS mailing list -- openbios(a)openbios.org
 To unsubscribe send an email to openbios-leave(a)openbios.org

[BALATON Zoltan]

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

[Jd Lyons]

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(a)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(a)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(a)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:
 
 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
 _______________________________________________
 OpenBIOS mailing list -- openbios(a)openbios.org
 To unsubscribe send an email to openbios-leave(a)openbios.org

[BALATON Zoltan]

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