Re: Implementing map-in

[BALATON Zoltan]

On Tue, 23 Jul 2019, Mark Cave-Ayland wrote:
> On 23/07/2019 20:13, BALATON Zoltan wrote:
> > I hoped to be able to get some texual name or path that I can make sens than only hex
> > numbers to identify where these point to.
>
> If you do show-devs before running your other commands then the values listed there
> are the phandles. Otherwise you can convert the phandle to a string with the Forth
> word get-package-path in OpenBIOS so:
>
> feval("active-package get-package-path type cr");
>
> and:
>
> feval("my-self ihandle>phandle get-package-path type cr");

OK, adding back the list to cc because I dropped it accidentally in one of 
the replies but maybe someone else might also be interested or be able to 
add something. So now I've added more debug:

static void
ob_pci_bus_map_in(int *idx)
{
         PCI_DPRINTF("ob_pci_bar_map_in idx=%p\n", idx);
     PCI_DPRINTF("active-package: ");
     feval("active-package get-package-path type");
     PCI_DPRINTF(" my-self: ");
     feval("my-self u. my-self ihandle>phandle get-package-path type cd");
     fword(".s");
         fword("pci-map-in");
     fword(".s");
}

and removed 0-ing my-self from pci-map-in for testing. I get:

0 > " /pci/ATY" open-dev >> ob_pci_bar_map_in idx=1fc5ac24
> > active-package: ob_pci_encode_unit space=0 dev=15 fn=0 buf=f

/pci@f2000000/ATY@f>>  my-self: 1fc5abf8 /pci@f2000000
<7> 1 -a1554 1fc5aba4 -7e000000 0 2007818 4000
<0>
ob_pci_bar_map_in idx=1fc5ac24
> > active-package: ob_pci_encode_unit space=0 dev=15 fn=0 buf=f

/pci@f2000000/ATY@f>>  my-self: 1fc5abf8 /pci@f2000000
<3> 0 42007810 1000000
<-3> -c38c0

I think this breaks because my-self pointing to /pci breaks my-#acells 
used by decode-phys while map-in is called during open-dev. If I disable 
the open word in /pci/ATY before calling open-dev to avoid this problem to 
be able to try the FCode ROM I get:

0 > dev /pci/ATY  ok
0 > : open -1 ; open isn't unique.
  ok
0 > load hd:\ati.rom
> > ob_pci_decode_unit idx=1fc5ac54
> > ob_pci_decode_unit idx=1fc5ac54 addr=00000000 00000000 00006000
> > ob_pci_encode_unit space=0 dev=12 fn=0 buf=c

ok
0 > " /pci/ATY" open-dev  ok
1 > .s <1> 1fc5ae2c
  ok
1 > to my-self  ok
0 > load-base 40 + 1 byte-load
dimensions isn't unique.
color! isn't unique.
set-colors isn't unique.
fill-rectangle isn't unique.
> > ob_pci_bar_map_in idx=1fc5ae20
> > active-package: ob_pci_encode_unit space=0 dev=15 fn=0 buf=f

/pci@f2000000/ATY@f>>  my-self: 1fc5adf4 /pci@f2000000
<12> -1 1 0 -1 0 0 -1 -bf5b8 0 0 0 0 0 0 0 0 1007814 100
<b> -1 1 0 -1 0 0 -1 -bf5b8 0 0 -1

byte-load: exception caught!
  ok
0 >

So this still breaks because my-self is /pci here.

Adding back the 0-ing hack to pci-map-in which avoided the first problem 
with open-dev but still broke with FCode ROM:

0 > " /pci/ATY" open-dev >> ob_pci_bar_map_in idx=1fc5ac24
> > active-package: ob_pci_encode_unit space=0 dev=15 fn=0 buf=f

/pci@f2000000/ATY@f>>  my-self: 1fc5abf8 /pci@f2000000
<7> 1 -a1514 1fc5aba4 -7e000000 0 2007818 4000
<4> 1 -a1514 1fc5aba4 -7e000000
ob_pci_bar_map_in idx=1fc5ac24
> > active-package: ob_pci_encode_unit space=0 dev=15 fn=0 buf=f

/pci@f2000000/ATY@f>>  my-self: 1fc5abf8 /pci@f2000000
<7> 1 -a1514 1fc5aba4 -7f000000 0 42007810 1000000
<4> 1 -a1514 1fc5aba4 -7f000000
  ok

my-self and active package is the same yet it works now? I don't 
understand that.

1 > .s <1> 1fc5ac30
  ok
1 > to my-self  ok
0 > load hd:\ati.rom
ob_pci_decode_unit idx=1fc5acf4
> > ob_pci_decode_unit idx=1fc5acf4 addr=00000000 00000000 00006000
> > ob_pci_encode_unit space=0 dev=12 fn=0 buf=c

ok
0 > debug pci-map-in
Stepper keys: <space>/<enter> Up Down Trace Rstack Forth
  ok
0 > dev /pci/ATY  ok
0 > load-base 40 + 1 byte-load
dimensions isn't unique.
color! isn't unique.
set-colors isn't unique.
fill-rectangle isn't unique.
> > ob_pci_bar_map_in idx=1fc5ac24
> > active-package: ob_pci_encode_unit space=0 dev=15 fn=0 buf=f

/pci@f2000000/ATY@f>>  my-self: 1fc5abf8 /pci@f2000000
<12> -1 1 0 -1 0 0 -1 -bf5b8 0 0 0 0 0 0 0 0 1007814 100
  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 0 0 1007814 100 )
fff56d38: drop  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 0 0 1007814 )
fff56d3c: nip  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 0 1007814 )
fff56d40: nip  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1007814 )
fff56d44: my-self  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1007814 1fc5abf8 )
fff56d48: swap  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 )
fff56d4c: 0  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 0 )
fff56d50: (lit)  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 0 fff3c73c )
fff56d58: (to)  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 )
fff56d5c: (")  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 fff56d64 12 )
fff56d78: active-package  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 fff56d64 12 fff5eaec )
fff56d7c: get-package-property  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 fff5ed1c 3c 0 )
fff56d80: 0=  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 fff5ed1c 3c ffffffff )
fff56d84: do?branch  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 fff5ed1c 3c )
fff56d8c: (begin)  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 fff5ed1c 3c )
fff56d90: decode-phys  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 fff5ed28 30 81000000 0 42007810 )

but it does not work here, decode-phys only returns addr.hi because 
my-#acells returns 1 here instead of 3 for some reason but maybe not 
because of my-self as that seems to be the same.

OK, maybe I should set my-self to the same as active-package instead of 
0-ing in pci-map-in? This actually seems to work better (although I don't 
like this but not having any better idea I have to go with this now):

0 > " /pci/ATY" open-dev >> ob_pci_bar_map_in idx=1fc5ac24
> > active-package: ob_pci_encode_unit space=0 dev=15 fn=0 buf=f

/pci@f2000000/ATY@f>>  my-self: 1fc5abf8 /pci@f2000000
<7> 1 -a1510 1fc5aba4 -7e000000 0 2007818 4000
<4> 1 -a1510 1fc5aba4 -7e000000
ob_pci_bar_map_in idx=1fc5ac24
> > active-package: ob_pci_encode_unit space=0 dev=15 fn=0 buf=f

/pci@f2000000/ATY@f>>  my-self: 1fc5abf8 /pci@f2000000
<7> 1 -a1510 1fc5aba4 -7f000000 0 42007810 1000000
<4> 1 -a1510 1fc5aba4 -7f000000
  ok
1 > .s <1> 1fc5ac30
  ok
1 > to my-self  ok
0 > dev /pci/ATY  ok
0 > load hd:\ati.rom ob_pci_decode_unit idx=1fc5acf4
> > ob_pci_decode_unit idx=1fc5acf4 addr=00000000 00000000 00006000
> > ob_pci_encode_unit space=0 dev=12 fn=0 buf=c

ok
0 > debug pci-map-in
Stepper keys: <space>/<enter> Up Down Trace Rstack Forth
  ok
0 > load-base 40 + 1 byte-load
dimensions isn't unique.
color! isn't unique.
set-colors isn't unique.
fill-rectangle isn't unique.
> > ob_pci_bar_map_in idx=1fc5ac24
> > active-package: ob_pci_encode_unit space=0 dev=15 fn=0 buf=f

/pci@f2000000/ATY@f>>  my-self: 1fc5abf8 /pci@f2000000
<12> -1 1 0 -1 0 0 -1 -bf5b8 0 0 0 0 0 0 0 0 1007814 100
  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 0 0 1007814 100 )
fff56d38: drop  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 0 0 1007814 )
fff56d3c: nip  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 0 1007814 )
fff56d40: nip  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1007814 )
fff56d44: my-self  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1007814 1fc5abf8 )
fff56d48: swap  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 )
fff56d4c: active-package  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 fff5eaf0 )
fff56d50: ihandle>phandle  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 0 )
fff56d54: (lit)  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 0 fff3c73c )
fff56d5c: (to)  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 )
fff56d60: (")  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 fff56d68 12 )
fff56d7c: active-package  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 fff56d68 12 fff5eaf0 )
fff56d80: get-package-property  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 fff5ed20 3c 0 )
fff56d84: 0=  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 fff5ed20 3c ffffffff )
fff56d88: do?branch  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 fff5ed20 3c )
fff56d90: (begin)  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 fff5ed20 3c )
fff56d94: decode-phys  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 fff5ed2c 30 81000000 0 42007810 )

Now we have the correct amount of addresses here

fff56d98: dup  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 fff5ed2c 30 81000000 0 42007810 42007810 )
fff56d9c: (lit)  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 fff5ed2c 30 81000000 0 42007810 42007810 fffffff )
fff56da4: and  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 fff5ed2c 30 81000000 0 42007810 2007810 )
fff56da8: (lit)  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 fff5ed2c 30 81000000 0 42007810 2007810 6 )
fff56db0: pick  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 fff5ed2c 30 81000000 0 42007810 2007810 1007814 )
fff56db4: (lit)  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 fff5ed2c 30 81000000 0 42007810 2007810 1007814 fffffff )
fff56dbc: and  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 fff5ed2c 30 81000000 0 42007810 2007810 1007814 )
fff56dc0: =  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 fff5ed2c 30 81000000 0 42007810 0 )
fff56dc4: do?branch  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 fff5ed2c 30 81000000 0 42007810 )
fff56e68: 3drop  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 fff5ed2c 30 )
fff56e6c: decode-int  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 fff5ed30 2c 0 )
fff56e70: drop  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 fff5ed30 2c )
fff56e74: decode-int  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 fff5ed34 28 1000000 )
fff56e78: drop  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 fff5ed34 28 )
fff56e7c: dup  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 fff5ed34 28 28 )
fff56e80: 0=  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 fff5ed34 28 0 )
fff56e84: (until)  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 fff5ed34 28 0 )
fff56e88: do?branch  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 fff5ed34 28 )
fff56d94: decode-phys  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 fff5ed40 1c 1000 0 1007814 )
fff56d98: dup  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 fff5ed40 1c 1000 0 1007814 1007814 )
fff56d9c: (lit)  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 fff5ed40 1c 1000 0 1007814 1007814 fffffff )
fff56da4: and  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 fff5ed40 1c 1000 0 1007814 1007814 )
fff56da8: (lit)  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 fff5ed40 1c 1000 0 1007814 1007814 6 )
fff56db0: pick  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 fff5ed40 1c 1000 0 1007814 1007814 1007814 )
fff56db4: (lit)  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 fff5ed40 1c 1000 0 1007814 1007814 1007814 fffffff )
fff56dbc: and  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 fff5ed40 1c 1000 0 1007814 1007814 1007814 )
fff56dc0: =  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 fff5ed40 1c 1000 0 1007814 ffffffff )
fff56dc4: do?branch  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 fff5ed40 1c 1000 0 1007814 )
fff56dcc: 2drop  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 fff5ed40 1c 1000 )
fff56dd0: -rot  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 1000 fff5ed40 1c )
fff56dd4: decode-int  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 1000 fff5ed44 18 0 )
fff56dd8: drop  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 1000 fff5ed44 18 )
fff56ddc: decode-int  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 1000 fff5ed48 14 100 )
fff56de0: drop  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 1000 fff5ed48 14 )
fff56de4: 2drop  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 1000 )
fff56de8: over  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 1000 1007814 )
fff56dec: (lit)  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 1000 1007814 18 )
fff56df4: rshift  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 1000 1 )
fff56df8: 3  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 1000 1 3 )
fff56dfc: and  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 1000 1 )
fff56e00: 1  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 1000 1 1 )
fff56e04: =  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 1000 ffffffff )
fff56e08: do?branch  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 1000 )
fff56e10: (")  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 1000 fff56e18 3 )
fff56e1c: active-package  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 1000 fff56e18 3 fff5eaf0 )
fff56e20: parent  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 1000 fff56e18 3 fff5b11c )
fff56e24: get-package-property  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 1000 fff5b5bc 8 0 )
fff56e28: 0=  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 1000 fff5b5bc 8 ffffffff )
fff56e2c: do?branch  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 1000 fff5b5bc 8 )
fff56e34: decode-int  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 1000 fff5b5c0 4 f2000000 )
fff56e38: -rot  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 1000 f2000000 fff5b5c0 4 )
fff56e3c: decode-int  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 1000 f2000000 fff5b5c4 0 2000000 )
fff56e40: 3drop  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 1000 f2000000 )
fff56e44: +  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 f2001000 )
fff56e48: nip  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 f2001000 )
fff56e4c: swap  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 f2001000 1fc5abf8 )
fff56e50: (lit)  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 f2001000 1fc5abf8 fff3c73c )
fff56e58: (to)  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 f2001000 )
fff56e5c: exit <f> -1 1 0 -1 0 0 -1 -bf5b8 0 0 0 0 0 0 -dfff000

and getting the correct mapped bar address here

byte-load: exception caught!
  ok
0 >

but it still breaks short after, probably in config-@. How to trace FCode 
execution? I only know about ?fcode-verbose so try that:

400514a :  [ 0x8bc ]
400514c :  [ 0x926 ]
> > ob_pci_bar_map_in idx=1fc5ac24
> > active-package: ob_pci_encode_unit space=0 dev=15 fn=0 buf=f

/pci@f2000000/ATY@f>>  my-self: 1fc5abf8 /pci@f2000000<12> -1 1 0 -1 0 0 
-1 -bf5b8 0 0 0 0 0 0 0 0 1007814 100
<f> -1 1 0 -1 0 0 -1 -bf5b8 0 0 0 0 0 0 -dfff000

byte-load: exception caught!
  ok

still in the same word so likely it's config-b@ is wrong. Is it called at 
all?

0 > " /pci/ATY" open-dev to my-self >> ob_pci_bar_map_in idx=1fc5ac24
> > active-package: ob_pci_encode_unit space=0 dev=15 fn=0 buf=f

/pci@f2000000/ATY@f>>  my-self: 1fc5abf8 /pci@f2000000
<7> 1 -a1510 1fc5aba4 -7e000000 0 2007818 4000
<4> 1 -a1510 1fc5aba4 -7e000000
ob_pci_bar_map_in idx=1fc5ac24
> > active-package: ob_pci_encode_unit space=0 dev=15 fn=0 buf=f

/pci@f2000000/ATY@f>>  my-self: 1fc5abf8 /pci@f2000000
<7> 1 -a1510 1fc5aba4 -7f000000 0 42007810 1000000
<4> 1 -a1510 1fc5aba4 -7f000000
  ok
0 > dev /pci/ATY  ok
0 > debug config-b!
Stepper keys: <space>/<enter> Up Down Trace Rstack Forth
  ok
0 > debug config-b@
Stepper keys: <space>/<enter> Up Down Trace Rstack Forth
  ok
0 > load hd:\ati.rom ob_pci_decode_unit idx=1fc5acf4
> > ob_pci_decode_unit idx=1fc5acf4 addr=00000000 00000000 00006000
> > ob_pci_encode_unit space=0 dev=12 fn=0 buf=c

ok
0 > load-base 40 + 1 byte-load dimensions isn't unique.
color! isn't unique.
set-colors isn't unique.
fill-rectangle isn't unique.
> > ob_pci_bar_map_in idx=1fc5ac24
> > active-package: ob_pci_encode_unit space=0 dev=15 fn=0 buf=f

/pci@f2000000/ATY@f>>  my-self: 1fc5abf8 /pci@f2000000
<12> -1 1 0 -1 0 0 -1 -bf5b8 0 0 0 0 0 0 0 0 1007814 100
<f> -1 1 0 -1 0 0 -1 -bf5b8 0 0 0 0 0 0 -dfff000

byte-load: exception caught!
  ok
0 >

Apparently not, so it probably has to be added as a method of the pci 
node so it can $call-parent it and implemented in C instead of the forth 
hack I've tried to add. (SLOF also seems to call back to rtas for this.) 
So I'll try that and see what happens.

Implementing map-in

[BALATON Zoltan]

On Tue, 23 Jul 2019, BALATON Zoltan wrote:
> Apparently not, so it probably has to be added as a method of the pci node so 
> it can $call-parent it and implemented in C instead of the forth hack I've 
> tried to add. (SLOF also seems to call back to rtas for this.) So I'll try 
> that and see what happens.

And yes, with config-b[!@] implemented as methods in C callbacks it 
finally starts poking the card regs. But it still ends in an exception, 
maybe it also needs map-out or some other words. I'm tweaking it a bit 
more then send the patch for commenting.

Implementing map-in

[BALATON Zoltan]

I've finally ended up with the patch below that now can run the FCode ROM 
although I'm not sure if it's correct or whatever else it breaks or fixes. 
It could likely be enhanced e.g. to add other config access words and 
maybe cleaned up by someone who knows more about this than me. It may also 
allow to clean up other places (like vga.fs) to get rid of some hacks but 
I'll let you (other people on the list, not necessarily Mark alone) finish 
that, an acknowledgement like including my Signed-off-by is still expected 
but I probably don't want to spend more time with it to make it a propert 
patch at the moment but may come back to it later so comments are still 
welcome. This is good enough for me now to test the FCode ROM. It can talk 
to the card now and finish without exception but it cannot get EDID info 
(although it does poke the appropriate reg for that) and probably gets 
some unexpected results that may derail it. It does install the NDRV and 
adds some properties to device node though. The rest needs more debugging 
but I've run out of time for now. This is what I've got after FCode's run:

0 > .properties
name                      "ATY,Rage128Pd"
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,Rage128Pro"
compatible                "VGA"
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
width                     280
height                    1e0
depth                     8
linebytes                 300
driver,AAPL,MacOS,PowerPC -- 14ae0 : 4a 6f 79 21 70 65 66 66 70 77 70 63 
... a lot more bytes here, maybe this should be changed to cut this at 
some sane amount rather than flooding output
address                   81000000
ATY,Status                0
ATY,Flags                 73f0000
ATY,RefCLK                733c
ATY,MCLK                  222e0
ATY,SCLK                  1ccf0
display-type              "NONE"
character-set             "ISO8859-1"
AGP_Address_Range         -- 8 : 00 00 00 00 ff ff ff ff
AGP_Address_Block         2000000
AGP_Alignment             2000000
AGP_AllowOverlap          1
ATY,Rom#                  "113-72701-136"
ATY,Card#                 "109-72700-00"
ATY,Fcode                 "1.78"
 ok

although the mode it's set is probably wrong or we can't handle that:

ati_vga_switch_mode: Switching to 640x480 768 8 @ 8000
qemu-system-ppc: VGA offset is not multiple of pitch, expect bad picture

8bpp 640 pixels per line with 768 pitch (bytes per line)? Starting with an 
offset? Strange, other drivers usually don't do this. Also display-type is 
not detected, probably because of EDID missing. I'll check these later 
when I'll have time, that may fix mode as well. I haven't tried if it does 
anything to MacOS or OSX yet. So here's the patch (surpisingly small, so 
Forth is at least really concise even if virtually unintelligible; oh and 
I managed to do it with avoiding reading the standard doc so far :-) 
thanks for all help in this):

Signed-off-by: BALATON Zoltan

diff --git a/drivers/pci.c b/drivers/pci.c
index 4bc02c9..88b9aa0 100644
--- a/drivers/pci.c
+++ b/drivers/pci.c
@@ -408,20 +408,33 @@ static void ob_pci_unmap(ucell virt, ucell size) {
 static void
 ob_pci_bus_map_in(int *idx)
 {
-	uint32_t ba;
-	ucell size;
-	ucell virt;
-
-	PCI_DPRINTF("ob_pci_bar_map_in idx=%p\n", idx);
+    PCI_DPRINTF("ob_pci_bar_map_in idx=%p\n", idx);
+    fword("pci-map-in");
+}

-	size = POP();
-	POP();
-	POP();
-	ba = POP();
+static void
+ob_pci_bus_map_out(int *idx)
+{
+    /* Should call pci-map-out but nothing to do in it yet */
+    fword("2drop");
+}

-	virt = ob_pci_map(ba, size);
+static void
+ob_pci_config_read8(int *idx)
+{
+    cell hi = POP();
+    pci_addr addr = PCI_ADDR(PCI_BUS(hi), PCI_DEV(hi), PCI_FN(hi));
+    uint8_t val = pci_config_read8(addr, hi & 0xff);
+    PUSH(val);
+}

-	PUSH(virt);
+static void
+ob_pci_config_write8(int *idx)
+{
+    cell hi = POP();
+    pci_addr addr = PCI_ADDR(PCI_BUS(hi), PCI_DEV(hi), PCI_FN(hi));
+    cell val = POP();
+    pci_config_write8(addr, hi & 0xff, val & 0xff);
 }

static void
@@ -459,7 +472,10 @@ NODE_METHODS(ob_pci_bus_node) = {
    { "close",		ob_pci_close		},
    { "decode-unit",	ob_pci_decode_unit	},
    { "encode-unit",	ob_pci_encode_unit	},
-	{ "pci-map-in",		ob_pci_bus_map_in	},
+	{ "map-in",		ob_pci_bus_map_in	},
+	{ "map-out",		ob_pci_bus_map_out	},
+	{ "config-b@",		ob_pci_config_read8	},
+	{ "config-b!",		ob_pci_config_write8	},
    { "dma-alloc",		ob_pci_dma_alloc	},
    { "dma-free",		ob_pci_dma_free		},
    { "dma-map-in",		ob_pci_dma_map_in	},
@@ -473,7 +489,14 @@ static void
 ob_pci_bridge_map_in(int *idx)
 {
    /* As per the IEEE-1275 PCI specification, chain up to the parent */
-	call_parent_method("pci-map-in");
+	call_parent_method("map-in");
+}
+
+static void
+ob_pci_bridge_map_out(int *idx)
+{
+	/* As per the IEEE-1275 PCI specification, chain up to the parent */
+	call_parent_method("map-out");
 }

NODE_METHODS(ob_pci_bridge_node) = {
@@ -481,7 +504,8 @@ NODE_METHODS(ob_pci_bridge_node) = {
    { "close",		ob_pci_close		},
    { "decode-unit",	ob_pci_decode_unit	},
    { "encode-unit",	ob_pci_encode_unit	},
-	{ "pci-map-in",		ob_pci_bridge_map_in	},
+	{ "map-in",		ob_pci_bridge_map_in	},
+	{ "map-out",		ob_pci_bridge_map_out	},
    { "dma-alloc",		ob_pci_dma_alloc	},
    { "dma-free",		ob_pci_dma_free		},
    { "dma-map-in",		ob_pci_dma_map_in	},
diff --git a/drivers/pci.fs b/drivers/pci.fs
index a7b56e1..327c9c9 100644
--- a/drivers/pci.fs
+++ b/drivers/pci.fs
@@ -37,4 +37,45 @@
   then
   ;

+: pci-map-in ( addr.lo addr.mid addr.hi size -- virt )
+  \ Ignore everything but addr.hi and find assigned addr for BAR
+  drop nip nip
+  \ Save my-self and set it to same as active package because otherwise
+  \ decode-phys below seems to be confused. Maybe this should not be needed
+  my-self swap active-package ihandle>phandle to my-self
+  " assigned-addresses" active-package get-package-property 0= if
+    begin
+      decode-phys   ( bar prop prop-len phys.lo phys.mid phys.hi )
+      dup 0fffffff and 6 pick 0fffffff and = if
+        2drop -rot
+        decode-int drop decode-int drop 2drop
+        ( bar addr.lo )
+        \ Now translate addr.lo, This may be wrong
+        \ maybe we should look at parent's ranges instead?
+        over 18 rshift 3 and 1 = if
+          " reg" active-package parent get-package-property 0= if
+            ( bar addr.lo prop prop-len reg.addr reg.size )
+            decode-int -rot decode-int 3drop
+            +
+          then
+        then
+        nip swap to my-self
+        exit
+      else
+        3drop \ no match, try next
+      then
+      \ Drop the size as we don't need it
+      decode-int drop decode-int drop
+      dup 0=
+    until
+    3drop
+    to my-self
+    -1 \ not found
+  else
+    drop
+    to my-self
+    -1 \ could not find assigned-addresses
+  then
+  ;
+
 [THEN]
diff --git a/drivers/vga.fs b/drivers/vga.fs
index 53dcff0..f3ffda7 100644
--- a/drivers/vga.fs
+++ b/drivers/vga.fs
@@ -146,14 +146,14 @@ defer vbe-iow!

: map-fb ( -- )
   cfg-bar0 pci-bar>pci-addr if   \ ( pci-addr.lo pci-addr.mid pci-addr.hi size )
-    " pci-map-in" $call-parent
+    " map-in" $call-parent
     to fb-addr
   then
 ;

: map-mmio ( -- )
   cfg-bar2 pci-bar>pci-addr if   \ ( pci-addr.lo pci-addr.mid pci-addr.hi size )
-    " pci-map-in" $call-parent
+    " map-in" $call-parent
     to mmio-addr
   then
 ;
diff --git a/forth/device/other.fs b/forth/device/other.fs
index 1bed9b8..0ff34b6 100644
--- a/forth/device/other.fs
+++ b/forth/device/other.fs
@@ -58,21 +58,27 @@ defer (poke)
 \ 5.3.7.2 Device-register access

: rb@    ( addr -- byte )
+  ioc@
   ;

: rw@    ( waddr -- w )
+  iow@
   ;

: rl@    ( qaddr -- quad )
+  iol@
   ;

: rb!    ( byte addr -- )
+  ioc!
   ;

: rw!    ( w waddr -- )
+  iow!
   ;

: rl!    ( quad qaddr -- )
+  iol!
   ;

: rx@ ( oaddr - o )

Implementing map-in

[Jd Lyons]

Could you add that patch as an attachment to the list, or email it to me directly?

I never seem to get how to correctly form a patch posted to the list.

Thanks
> On Jul 23, 2019, at 7:25 PM, BALATON Zoltan  wrote:
>
> I've finally ended up with the patch below that now can run the FCode ROM 
> although I'm not sure if it's correct or whatever else it breaks or fixes. 
> It could likely be enhanced e.g. to add other config access words and 
> maybe cleaned up by someone who knows more about this than me. It may also 
> allow to clean up other places (like vga.fs) to get rid of some hacks but 
> I'll let you (other people on the list, not necessarily Mark alone) finish 
> that, an acknowledgement like including my Signed-off-by is still expected 
> but I probably don't want to spend more time with it to make it a propert 
> patch at the moment but may come back to it later so comments are still 
> welcome. This is good enough for me now to test the FCode ROM. It can talk 
> to the card now and finish without exception but it cannot get EDID info 
> (although it does poke the appropriate reg for that) and probably gets 
> some unexpected results that may derail it. It does install the NDRV and 
> adds some properties to device node though. The rest needs more debugging 
> but I've run out of time for now. This is what I've got after FCode's run:
>
> 0 > .properties
> name                      "ATY,Rage128Pd"
> 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,Rage128Pro"
> compatible                "VGA"
> 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
> width                     280
> height                    1e0
> depth                     8
> linebytes                 300
> driver,AAPL,MacOS,PowerPC -- 14ae0 : 4a 6f 79 21 70 65 66 66 70 77 70 63 
> ... a lot more bytes here, maybe this should be changed to cut this at 
> some sane amount rather than flooding output
> address                   81000000
> ATY,Status                0
> ATY,Flags                 73f0000
> ATY,RefCLK                733c
> ATY,MCLK                  222e0
> ATY,SCLK                  1ccf0
> display-type              "NONE"
> character-set             "ISO8859-1"
> AGP_Address_Range         -- 8 : 00 00 00 00 ff ff ff ff
> AGP_Address_Block         2000000
> AGP_Alignment             2000000
> AGP_AllowOverlap          1
> ATY,Rom#                  "113-72701-136"
> ATY,Card#                 "109-72700-00"
> ATY,Fcode                 "1.78"
> ok
>
> although the mode it's set is probably wrong or we can't handle that:
>
> ati_vga_switch_mode: Switching to 640x480 768 8 @ 8000
> qemu-system-ppc: VGA offset is not multiple of pitch, expect bad picture
>
> 8bpp 640 pixels per line with 768 pitch (bytes per line)? Starting with an 
> offset? Strange, other drivers usually don't do this. Also display-type is 
> not detected, probably because of EDID missing. I'll check these later 
> when I'll have time, that may fix mode as well. I haven't tried if it does 
> anything to MacOS or OSX yet. So here's the patch (surpisingly small, so 
> Forth is at least really concise even if virtually unintelligible; oh and 
> I managed to do it with avoiding reading the standard doc so far :-) 
> thanks for all help in this):
>
> Signed-off-by: BALATON Zoltan
>
> diff --git a/drivers/pci.c b/drivers/pci.c
> index 4bc02c9..88b9aa0 100644
> --- a/drivers/pci.c
> +++ b/drivers/pci.c
> @@ -408,20 +408,33 @@ static void ob_pci_unmap(ucell virt, ucell size) {
> static void
> ob_pci_bus_map_in(int *idx)
> {
> uint32_t ba;
> ucell size;
> ucell virt;
> PCI_DPRINTF("ob_pci_bar_map_in idx=%p\n", idx);
> PCI_DPRINTF("ob_pci_bar_map_in idx=%p\n", idx);
> fword("pci-map-in");
>
> +}
> size = POP();
> POP();
> POP();
> ba = POP();
>
> +static void
> +ob_pci_bus_map_out(int *idx)
> +{
> /* Should call pci-map-out but nothing to do in it yet */
> fword("2drop");
>
> +}
> virt = ob_pci_map(ba, size);
>
> +static void
> +ob_pci_config_read8(int *idx)
> +{
> cell hi = POP();
> pci_addr addr = PCI_ADDR(PCI_BUS(hi), PCI_DEV(hi), PCI_FN(hi));
> uint8_t val = pci_config_read8(addr, hi & 0xff);
> PUSH(val);
>
> +}
> PUSH(virt);
>
> +static void
> +ob_pci_config_write8(int *idx)
> +{
> cell hi = POP();
> pci_addr addr = PCI_ADDR(PCI_BUS(hi), PCI_DEV(hi), PCI_FN(hi));
> cell val = POP();
> pci_config_write8(addr, hi & 0xff, val & 0xff);
>
> }
>
> static void
> @@ -459,7 +472,10 @@ NODE_METHODS(ob_pci_bus_node) = {
>    { "close",		ob_pci_close		},
>    { "decode-unit",	ob_pci_decode_unit	},
>    { "encode-unit",	ob_pci_encode_unit	},
> { "pci-map-in",		ob_pci_bus_map_in	},
> { "map-in",		ob_pci_bus_map_in	},
> { "map-out",		ob_pci_bus_map_out	},
> { "config-b@",		ob_pci_config_read8	},
> { "config-b!",		ob_pci_config_write8	},
> { "dma-alloc",		ob_pci_dma_alloc	},
> { "dma-free",		ob_pci_dma_free		},
> { "dma-map-in",		ob_pci_dma_map_in	},
>
> @@ -473,7 +489,14 @@ static void
> ob_pci_bridge_map_in(int *idx)
> {
>    /* As per the IEEE-1275 PCI specification, chain up to the parent */
> call_parent_method("pci-map-in");
> call_parent_method("map-in");
>
> +}
>
> +static void
> +ob_pci_bridge_map_out(int *idx)
> +{
> /* As per the IEEE-1275 PCI specification, chain up to the parent */
> call_parent_method("map-out");
>
> }
>
> NODE_METHODS(ob_pci_bridge_node) = {
> @@ -481,7 +504,8 @@ NODE_METHODS(ob_pci_bridge_node) = {
>    { "close",		ob_pci_close		},
>    { "decode-unit",	ob_pci_decode_unit	},
>    { "encode-unit",	ob_pci_encode_unit	},
> { "pci-map-in",		ob_pci_bridge_map_in	},
> { "map-in",		ob_pci_bridge_map_in	},
> { "map-out",		ob_pci_bridge_map_out	},
> { "dma-alloc",		ob_pci_dma_alloc	},
> { "dma-free",		ob_pci_dma_free		},
> { "dma-map-in",		ob_pci_dma_map_in	},
>
> diff --git a/drivers/pci.fs b/drivers/pci.fs
> index a7b56e1..327c9c9 100644
> --- a/drivers/pci.fs
> +++ b/drivers/pci.fs
> @@ -37,4 +37,45 @@
>   then
>   ;
>
> +: pci-map-in ( addr.lo addr.mid addr.hi size -- virt )
> \ Ignore everything but addr.hi and find assigned addr for BAR
> drop nip nip
> \ Save my-self and set it to same as active package because otherwise
> \ decode-phys below seems to be confused. Maybe this should not be needed
> my-self swap active-package ihandle>phandle to my-self
> " assigned-addresses" active-package get-package-property 0= if
> begin
>  decode-phys   ( bar prop prop-len phys.lo phys.mid phys.hi )
>  dup 0fffffff and 6 pick 0fffffff and = if
>    2drop -rot
>    decode-int drop decode-int drop 2drop
>    ( bar addr.lo )
>    \ Now translate addr.lo, This may be wrong
>    \ maybe we should look at parent's ranges instead?
>    over 18 rshift 3 and 1 = if
>      " reg" active-package parent get-package-property 0= if
>        ( bar addr.lo prop prop-len reg.addr reg.size )
>        decode-int -rot decode-int 3drop
>        +
>      then
>    then
>    nip swap to my-self
>    exit
>  else
>    3drop \ no match, try next
>  then
>  \ Drop the size as we don't need it
>  decode-int drop decode-int drop
>  dup 0=
> until
> 3drop
> to my-self
> -1 \ not found
> else
> drop
> to my-self
> -1 \ could not find assigned-addresses
> then
> ;
>
> [THEN]
> diff --git a/drivers/vga.fs b/drivers/vga.fs
> index 53dcff0..f3ffda7 100644
> --- a/drivers/vga.fs
> +++ b/drivers/vga.fs
> @@ -146,14 +146,14 @@ defer vbe-iow!
>
> : map-fb ( -- )
>   cfg-bar0 pci-bar>pci-addr if   \ ( pci-addr.lo pci-addr.mid pci-addr.hi size )
> " pci-map-in" $call-parent
> " map-in" $call-parent
> to fb-addr
> then
>
> ;
>
> : map-mmio ( -- )
>   cfg-bar2 pci-bar>pci-addr if   \ ( pci-addr.lo pci-addr.mid pci-addr.hi size )
> " pci-map-in" $call-parent
> " map-in" $call-parent
> to mmio-addr
> then
>
> ;
> diff --git a/forth/device/other.fs b/forth/device/other.fs
> index 1bed9b8..0ff34b6 100644
> --- a/forth/device/other.fs
> +++ b/forth/device/other.fs
> @@ -58,21 +58,27 @@ defer (poke)
> \ 5.3.7.2 Device-register access
>
> : rb@    ( addr -- byte )
> ioc@
> ;
>
> : rw@    ( waddr -- w )
> iow@
> ;
>
> : rl@    ( qaddr -- quad )
> iol@
> ;
>
> : rb!    ( byte addr -- )
> ioc!
> ;
>
> : rw!    ( w waddr -- )
> iow!
> ;
>
> : rl!    ( quad qaddr -- )
> iol!
> ;
>
> : rx@ ( oaddr - o )
> _______________________________________________
> OpenBIOS mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]

Implementing map-in

[Jd Lyons]

Can’t apply this patch to the main branch or Mark’s v2 branch, and I can’t be much help if we are not working from the same codebase.
> On Jul 23, 2019, at 7:25 PM, BALATON Zoltan  wrote:
>
> I've finally ended up with the patch below that now can run the FCode ROM 
> although I'm not sure if it's correct or whatever else it breaks or fixes. 
> It could likely be enhanced e.g. to add other config access words and 
> maybe cleaned up by someone who knows more about this than me. It may also 
> allow to clean up other places (like vga.fs) to get rid of some hacks but 
> I'll let you (other people on the list, not necessarily Mark alone) finish 
> that, an acknowledgement like including my Signed-off-by is still expected 
> but I probably don't want to spend more time with it to make it a propert 
> patch at the moment but may come back to it later so comments are still 
> welcome. This is good enough for me now to test the FCode ROM. It can talk 
> to the card now and finish without exception but it cannot get EDID info 
> (although it does poke the appropriate reg for that) and probably gets 
> some unexpected results that may derail it. It does install the NDRV and 
> adds some properties to device node though. The rest needs more debugging 
> but I've run out of time for now. This is what I've got after FCode's run:
>
> 0 > .properties
> name                      "ATY,Rage128Pd"
> 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,Rage128Pro"
> compatible                "VGA"
> 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
> width                     280
> height                    1e0
> depth                     8
> linebytes                 300
> driver,AAPL,MacOS,PowerPC -- 14ae0 : 4a 6f 79 21 70 65 66 66 70 77 70 63 
> ... a lot more bytes here, maybe this should be changed to cut this at 
> some sane amount rather than flooding output
> address                   81000000
> ATY,Status                0
> ATY,Flags                 73f0000
> ATY,RefCLK                733c
> ATY,MCLK                  222e0
> ATY,SCLK                  1ccf0
> display-type              "NONE"
> character-set             "ISO8859-1"
> AGP_Address_Range         -- 8 : 00 00 00 00 ff ff ff ff
> AGP_Address_Block         2000000
> AGP_Alignment             2000000
> AGP_AllowOverlap          1
> ATY,Rom#                  "113-72701-136"
> ATY,Card#                 "109-72700-00"
> ATY,Fcode                 "1.78"
> ok
>
> although the mode it's set is probably wrong or we can't handle that:
>
> ati_vga_switch_mode: Switching to 640x480 768 8 @ 8000
> qemu-system-ppc: VGA offset is not multiple of pitch, expect bad picture
>
> 8bpp 640 pixels per line with 768 pitch (bytes per line)? Starting with an 
> offset? Strange, other drivers usually don't do this. Also display-type is 
> not detected, probably because of EDID missing. I'll check these later 
> when I'll have time, that may fix mode as well. I haven't tried if it does 
> anything to MacOS or OSX yet. So here's the patch (surpisingly small, so 
> Forth is at least really concise even if virtually unintelligible; oh and 
> I managed to do it with avoiding reading the standard doc so far :-) 
> thanks for all help in this):
>
> Signed-off-by: BALATON Zoltan
>
> diff --git a/drivers/pci.c b/drivers/pci.c
> index 4bc02c9..88b9aa0 100644
> --- a/drivers/pci.c
> +++ b/drivers/pci.c
> @@ -408,20 +408,33 @@ static void ob_pci_unmap(ucell virt, ucell size) {
> static void
> ob_pci_bus_map_in(int *idx)
> {
> uint32_t ba;
> ucell size;
> ucell virt;
> PCI_DPRINTF("ob_pci_bar_map_in idx=%p\n", idx);
> PCI_DPRINTF("ob_pci_bar_map_in idx=%p\n", idx);
> fword("pci-map-in");
>
> +}
> size = POP();
> POP();
> POP();
> ba = POP();
>
> +static void
> +ob_pci_bus_map_out(int *idx)
> +{
> /* Should call pci-map-out but nothing to do in it yet */
> fword("2drop");
>
> +}
> virt = ob_pci_map(ba, size);
>
> +static void
> +ob_pci_config_read8(int *idx)
> +{
> cell hi = POP();
> pci_addr addr = PCI_ADDR(PCI_BUS(hi), PCI_DEV(hi), PCI_FN(hi));
> uint8_t val = pci_config_read8(addr, hi & 0xff);
> PUSH(val);
>
> +}
> PUSH(virt);
>
> +static void
> +ob_pci_config_write8(int *idx)
> +{
> cell hi = POP();
> pci_addr addr = PCI_ADDR(PCI_BUS(hi), PCI_DEV(hi), PCI_FN(hi));
> cell val = POP();
> pci_config_write8(addr, hi & 0xff, val & 0xff);
>
> }
>
> static void
> @@ -459,7 +472,10 @@ NODE_METHODS(ob_pci_bus_node) = {
>    { "close",		ob_pci_close		},
>    { "decode-unit",	ob_pci_decode_unit	},
>    { "encode-unit",	ob_pci_encode_unit	},
> { "pci-map-in",		ob_pci_bus_map_in	},
> { "map-in",		ob_pci_bus_map_in	},
> { "map-out",		ob_pci_bus_map_out	},
> { "config-b@",		ob_pci_config_read8	},
> { "config-b!",		ob_pci_config_write8	},
> { "dma-alloc",		ob_pci_dma_alloc	},
> { "dma-free",		ob_pci_dma_free		},
> { "dma-map-in",		ob_pci_dma_map_in	},
>
> @@ -473,7 +489,14 @@ static void
> ob_pci_bridge_map_in(int *idx)
> {
>    /* As per the IEEE-1275 PCI specification, chain up to the parent */
> call_parent_method("pci-map-in");
> call_parent_method("map-in");
>
> +}
>
> +static void
> +ob_pci_bridge_map_out(int *idx)
> +{
> /* As per the IEEE-1275 PCI specification, chain up to the parent */
> call_parent_method("map-out");
>
> }
>
> NODE_METHODS(ob_pci_bridge_node) = {
> @@ -481,7 +504,8 @@ NODE_METHODS(ob_pci_bridge_node) = {
>    { "close",		ob_pci_close		},
>    { "decode-unit",	ob_pci_decode_unit	},
>    { "encode-unit",	ob_pci_encode_unit	},
> { "pci-map-in",		ob_pci_bridge_map_in	},
> { "map-in",		ob_pci_bridge_map_in	},
> { "map-out",		ob_pci_bridge_map_out	},
> { "dma-alloc",		ob_pci_dma_alloc	},
> { "dma-free",		ob_pci_dma_free		},
> { "dma-map-in",		ob_pci_dma_map_in	},
>
> diff --git a/drivers/pci.fs b/drivers/pci.fs
> index a7b56e1..327c9c9 100644
> --- a/drivers/pci.fs
> +++ b/drivers/pci.fs
> @@ -37,4 +37,45 @@
>   then
>   ;
>
> +: pci-map-in ( addr.lo addr.mid addr.hi size -- virt )
> \ Ignore everything but addr.hi and find assigned addr for BAR
> drop nip nip
> \ Save my-self and set it to same as active package because otherwise
> \ decode-phys below seems to be confused. Maybe this should not be needed
> my-self swap active-package ihandle>phandle to my-self
> " assigned-addresses" active-package get-package-property 0= if
> begin
>  decode-phys   ( bar prop prop-len phys.lo phys.mid phys.hi )
>  dup 0fffffff and 6 pick 0fffffff and = if
>    2drop -rot
>    decode-int drop decode-int drop 2drop
>    ( bar addr.lo )
>    \ Now translate addr.lo, This may be wrong
>    \ maybe we should look at parent's ranges instead?
>    over 18 rshift 3 and 1 = if
>      " reg" active-package parent get-package-property 0= if
>        ( bar addr.lo prop prop-len reg.addr reg.size )
>        decode-int -rot decode-int 3drop
>        +
>      then
>    then
>    nip swap to my-self
>    exit
>  else
>    3drop \ no match, try next
>  then
>  \ Drop the size as we don't need it
>  decode-int drop decode-int drop
>  dup 0=
> until
> 3drop
> to my-self
> -1 \ not found
> else
> drop
> to my-self
> -1 \ could not find assigned-addresses
> then
> ;
>
> [THEN]
> diff --git a/drivers/vga.fs b/drivers/vga.fs
> index 53dcff0..f3ffda7 100644
> --- a/drivers/vga.fs
> +++ b/drivers/vga.fs
> @@ -146,14 +146,14 @@ defer vbe-iow!
>
> : map-fb ( -- )
>   cfg-bar0 pci-bar>pci-addr if   \ ( pci-addr.lo pci-addr.mid pci-addr.hi size )
> " pci-map-in" $call-parent
> " map-in" $call-parent
> to fb-addr
> then
>
> ;
>
> : map-mmio ( -- )
>   cfg-bar2 pci-bar>pci-addr if   \ ( pci-addr.lo pci-addr.mid pci-addr.hi size )
> " pci-map-in" $call-parent
> " map-in" $call-parent
> to mmio-addr
> then
>
> ;
> diff --git a/forth/device/other.fs b/forth/device/other.fs
> index 1bed9b8..0ff34b6 100644
> --- a/forth/device/other.fs
> +++ b/forth/device/other.fs
> @@ -58,21 +58,27 @@ defer (poke)
> \ 5.3.7.2 Device-register access
>
> : rb@    ( addr -- byte )
> ioc@
> ;
>
> : rw@    ( waddr -- w )
> iow@
> ;
>
> : rl@    ( qaddr -- quad )
> iol@
> ;
>
> : rb!    ( byte addr -- )
> ioc!
> ;
>
> : rw!    ( w waddr -- )
> iow!
> ;
>
> : rl!    ( quad qaddr -- )
> iol!
> ;
>
> : rx@ ( oaddr - o )
> _______________________________________________
> OpenBIOS mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]

Implementing map-in

[Howard Spoelstra]

On Mon, Jul 29, 2019 at 11:58 AM Jd Lyons via OpenBIOS <
[e-mail]> wrote:
> Can’t apply this patch to the main branch or Mark’s v2 branch, and I can’t
> be much help if we are not working from the same codebase.
> > --- a/forth/device/other.fs
> > +++ b/forth/device/other.fs
> > @@ -58,21 +58,27 @@ defer (poke)
> > \ 5.3.7.2 Device-register access
> >
> > : rb@    ( addr -- byte )
> > ioc@
> > ;
> >
> > : rw@    ( waddr -- w )
> > iow@
> > ;
> >
> > : rl@    ( qaddr -- quad )
> > iol@
> > ;
> >
> > : rb!    ( byte addr -- )
> > ioc!
> > ;
> >
> > : rw!    ( w waddr -- )
> > iow!
> > ;
> >
> > : rl!    ( quad qaddr -- )
> > iol!
> > ;
> >
> > : rx@ ( oaddr - o )
> > _______________________________________________
> > OpenBIOS mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
>
> OpenBIOS mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]

Yes, I had the same issue when copying the patch from:

https://mail.coreboot.org/hyperkitty/list/[e-mail]/message/HAY6...

patching file forth/device/other.fs
Hunk #1 FAILED at 58.
patch unexpectedly ends in middle of line
1 out of 1 hunk FAILED -- saving rejects to file forth/device/other.fs.rej
patch unexpectedly ends in middle of line

Just apply these last 6 entries above to other.fs manually.

Best,
Howard

Implementing map-in

[Segher Boessenkool]

On Mon, Jul 29, 2019 at 12:29:35PM +0200, Howard Spoelstra wrote:
> > > --- a/forth/device/other.fs
> > > +++ b/forth/device/other.fs
> > > @@ -58,21 +58,27 @@ defer (poke)
> > > \ 5.3.7.2 Device-register access
> > >
> > > : rb@    ( addr -- byte )
> > > ioc@
> > > ;
> > >
> > > : rw@    ( waddr -- w )
> > > iow@
> > > ;
> > >
> > > : rl@    ( qaddr -- quad )
> > > iol@
> > > ;
> > >
> > > : rb!    ( byte addr -- )
> > > ioc!
> > > ;
> > >
> > > : rw!    ( w waddr -- )
> > > iow!
> > > ;
> > >
> > > : rl!    ( quad qaddr -- )
> > > iol!
> > > ;
> > >
> > > : rx@ ( oaddr - o )

Note that all those are bus-specific, and a correct implementation of
these words has to look at the FCode 235 (etc.) of the bus you are on,
and inherited from its parent bus, etc.

Segher

Implementing map-in

[BALATON Zoltan]

On Mon, 29 Jul 2019, Segher Boessenkool wrote:
> On Mon, Jul 29, 2019 at 12:29:35PM +0200, Howard Spoelstra wrote:
> > > > --- a/forth/device/other.fs
> > > > +++ b/forth/device/other.fs
> > > > @@ -58,21 +58,27 @@ defer (poke)
> > > > \ 5.3.7.2 Device-register access
> > > >
> > > > : rb@    ( addr -- byte )
> > > > ioc@
> > > > ;
> > > >
> > > > : rw@    ( waddr -- w )
> > > > iow@
> > > > ;
> > > >
> > > > : rl@    ( qaddr -- quad )
> > > > iol@
> > > > ;
> > > >
> > > > : rb!    ( byte addr -- )
> > > > ioc!
> > > > ;
> > > >
> > > > : rw!    ( w waddr -- )
> > > > iow!
> > > > ;
> > > >
> > > > : rl!    ( quad qaddr -- )
> > > > iol!
> > > > ;
> > > >
> > > > : rx@ ( oaddr - o )

Thanks, have you seen the full patch (implementing pci-map-in) or just 
this fragment?
> Note that all those are bus-specific, and a correct implementation of
> these words has to look at the FCode 235 (etc.) of the bus you are on,
> and inherited from its parent bus, etc.

I don't understand any of the above... What's FCode 235? Also OpenBIOS 
only handles one PCI bus at the moment so not sure that additional 
complexity you mention exists in it yet. The io* words do what needs to be 
done to read and write mapped registers (on ppc doing eieio or similar, 
otherwise same as memory read/write as all io is memory mapped on that 
platform) so I think for now this might be sufficient even if not correct 
at least on PPC. (Since I don't have enough knowledge to make it correct I 
had to hack it together so it does what I need to run the FCode I wanted 
to test without exception but it may not be correct.)

OpenBIOS is not OpenHackWare but seems to be equally incomplete, patchy 
and rely on random hacks. Trying to clean it up and implement missing 
stuff seems to be as complex as rewriting OpenFirmware. Given all 
OpenBIOS's missing features and non-existing developer comunity with only 
limited resources to improve it I wonder if we should try to move on to 
OpenFirmware instead eventually to at least have a complete OF 
implementation so we only need to care about porting that to QEMU and 
adding Apple specific stuff and not to implement OF itself. Apparently 
this was already done for QEMU prep a few years ago:

https://tyom.blogspot.com/2014/09/open-firmware-for-qemu-system-ppc-m-prep.h...
https://github.com/artyom-tarasenko/openfirmware/

So how hard would it be to do the same for the Mac machines in QEMU? Would 
that be easier than trying to fix OpenBIOS?

Regards,
BALATON Zoltan

Implementing map-in

[Segher Boessenkool]

On Mon, Jul 29, 2019 at 04:34:18PM +0200, BALATON Zoltan wrote:
> > Note that all those are bus-specific, and a correct implementation of
> > these words has to look at the FCode 235 (etc.) of the bus you are on,
> > and inherited from its parent bus, etc.
>
> I don't understand any of the above... What's FCode 235? Also OpenBIOS

FCode hex 235.  The FCode generated for  rl!  iirc.  This is pretty
trivial to look up, btw.
> only handles one PCI bus at the moment so not sure that additional 
> complexity you mention exists in it yet. The io* words do what needs to be 
> done to read and write mapped registers (on ppc doing eieio or similar,

Which isn't enough in all cases.
> otherwise same as memory read/write as all io is memory mapped on that 
> platform)

It is not, not on PowerMac anyway, which is what you emulate?  Not all
PCI buses have a legacy I/O direct mapped, for example, and later
machines do not even have all config space direct mapped.
> so I think for now this might be sufficient even if not correct 
> at least on PPC. (Since I don't have enough knowledge to make it correct I 
> had to hack it together so it does what I need to run the FCode I wanted 
> to test without exception but it may not be correct.)

Sure it's a step up from not doing anything here, but you will run into
trouble very soon.

Segher

Implementing map-in

[BALATON Zoltan]

On Mon, 29 Jul 2019, Segher Boessenkool wrote:
> On Mon, Jul 29, 2019 at 04:34:18PM +0200, BALATON Zoltan wrote:
> > > Note that all those are bus-specific, and a correct implementation of
> > > these words has to look at the FCode 235 (etc.) of the bus you are on,
> > > and inherited from its parent bus, etc.
> >
> > I don't understand any of the above... What's FCode 235? Also OpenBIOS
>
> FCode hex 235.  The FCode generated for  rl!  iirc.  This is pretty
> trivial to look up, btw.

I did try to look up but haven't succeeded. Checked forth/device/table.fs 
in OpenBIOS but that does not have indexes so it's not obvious what 235 
means (also wasn't sure if it's hex or dec, now I at least know its h# 235 
or 0x $ h or whatever convention one prefers). I've also tried searching 
for "fcode bytecode" to find out which did turn up some docs but not any 
tables about which number means what so it does not look too trivial to 
decode this. Maybe if you know where to look it is so you could tell us.

Now that I look at table.fs again it has these lines:

4 n['], reserved-fcode       \ 22a-22d
64bit? [IF]
   ['], (rx@)
   ['], (rx!)
[ELSE]
    2 n['], reserved-fcode       \ 22e-22f
[THEN]
   ['], rb@
   ['], rb!
   ['], rw@
   ['], rw!
   ['], rl@
   ['], rl!

So 235 may be rl! but it's far from obvious to get from this and only 
possible because there happens to be a comment near that.
> > only handles one PCI bus at the moment so not sure that additional
> > complexity you mention exists in it yet. The io* words do what needs to be
> > done to read and write mapped registers (on ppc doing eieio or similar,
>
> Which isn't enough in all cases.

In what cases is it not enough? For PPC the low level in/out functions 
that the io words use are defined in openbios/include/arch/ppc/io.h (there 
are similar definitions for other archs but I did not really check those; 
it may not work with x86 where io space is different but I don't think 
OpenBIOS currently works on x86 or is used with anything so I did not 
care about that much).
> > otherwise same as memory read/write as all io is memory mapped on that
> > platform)
>
> It is not, not on PowerMac anyway, which is what you emulate?  Not all
> PCI buses have a legacy I/O direct mapped, for example, and later
> machines do not even have all config space direct mapped.

OK we only emulate a few of those machines and the mac99 that I've tested 
is approximately a PowerMac3,1 or not even that but simpified a bit so I 
don't really care if theoretically there could be machines where it's not 
only mmio if we don't have any of those in QEMU. (It might be nice to make 
OpenBIOS work with real machines but currently it doesn't and that's out 
of scope for me.)
> > so I think for now this might be sufficient even if not correct
> > at least on PPC. (Since I don't have enough knowledge to make it correct I
> > had to hack it together so it does what I need to run the FCode I wanted
> > to test without exception but it may not be correct.)
>
> Sure it's a step up from not doing anything here, but you will run into
> trouble very soon.

If you see where we might run into trouble please explain so we don't have 
to debug that when it happens and we're aware of the limitations this 
solution has. If it's not too difficult to improve it I might even try to 
do that but currently I don't know what would need to be improved as my 
understanding is limited and so is my time to broaden my understanding so 
I have to rely on people telling me what they already know.

Regards,
BALATON Zoltan

Implementing map-in

[Segher Boessenkool]

On Mon, Jul 29, 2019 at 06:44:19PM +0200, BALATON Zoltan wrote:
> On Mon, 29 Jul 2019, Segher Boessenkool wrote:
> > On Mon, Jul 29, 2019 at 04:34:18PM +0200, BALATON Zoltan wrote:
> > > > Note that all those are bus-specific, and a correct implementation of
> > > > these words has to look at the FCode 235 (etc.) of the bus you are on,
> > > > and inherited from its parent bus, etc.
> > >
> > > I don't understand any of the above... What's FCode 235? Also OpenBIOS
> >
> > FCode hex 235.  The FCode generated for  rl!  iirc.  This is pretty
> > trivial to look up, btw.
>
> I did try to look up but haven't succeeded. Checked forth/device/table.fs 
> in OpenBIOS but that does not have indexes so it's not obvious what 235 
> means

You look at the Open Firmware specification.  You can for example google
for "of1275.pdf".  Searching in that pdf for the string "235" gets you
to what you need to know immediately.
> (also wasn't sure if it's hex or dec, now I at least know its h# 235 
> or 0x $ h or whatever convention one prefers).

0eb is a reserved FCode.
> I've also tried searching 
> for "fcode bytecode" to find out which did turn up some docs but not any 
> tables about which number means what so it does not look too trivial to 
> decode this. Maybe if you know where to look it is so you could tell us.

Annex G.2, "Assigned FCode numbers", is something you want to know how to
find, just like all of Annex A.
> > > only handles one PCI bus at the moment so not sure that additional
> > > complexity you mention exists in it yet. The io* words do what needs to be
> > > done to read and write mapped registers (on ppc doing eieio or similar,
> >
> > Which isn't enough in all cases.
>
> In what cases is it not enough?

In many cases.  OF requires the access to have been performed wrt to the
actual device that is accessed before the next word starts executing.
This doesn't come natural to PowerPC at all.  You can cheat a little bit
here, but not much.  "eieio" might be enough for stores in some cases,
but it isn't for loads, not on most real hardware at least.
> > Sure it's a step up from not doing anything here, but you will run into
> > trouble very soon.
>
> If you see where we might run into trouble please explain so we don't have 
> to debug that when it happens and we're aware of the limitations this 
> solution has.

That's what I did!

You need to implement  rb@  and friends *per bus node*, and redirect via
FCode for them.  Which is unusual, but there you have it.

Segher

Implementing map-in

[BALATON Zoltan]

On Mon, 29 Jul 2019, Segher Boessenkool wrote:
> On Mon, Jul 29, 2019 at 06:44:19PM +0200, BALATON Zoltan wrote:
> > On Mon, 29 Jul 2019, Segher Boessenkool wrote:
> > > On Mon, Jul 29, 2019 at 04:34:18PM +0200, BALATON Zoltan wrote:
> > > > > Note that all those are bus-specific, and a correct implementation of
> > > > > these words has to look at the FCode 235 (etc.) of the bus you are on,
> > > > > and inherited from its parent bus, etc.
> > > >
> > > > I don't understand any of the above... What's FCode 235? Also OpenBIOS
> > >
> > > FCode hex 235.  The FCode generated for  rl!  iirc.  This is pretty
> > > trivial to look up, btw.
> >
> > I did try to look up but haven't succeeded. Checked forth/device/table.fs
> > in OpenBIOS but that does not have indexes so it's not obvious what 235
> > means
>
> You look at the Open Firmware specification.  You can for example google
> for "of1275.pdf".  Searching in that pdf for the string "235" gets you
> to what you need to know immediately.
> > (also wasn't sure if it's hex or dec, now I at least know its h# 235
> > or 0x $ h or whatever convention one prefers).
>
> 0eb is a reserved FCode.
> > I've also tried searching
> > for "fcode bytecode" to find out which did turn up some docs but not any
> > tables about which number means what so it does not look too trivial to
> > decode this. Maybe if you know where to look it is so you could tell us.
>
> Annex G.2, "Assigned FCode numbers", is something you want to know how to
> find, just like all of Annex A.

You remember what I've told you about reading docs, don't you. Either I 
get pointers to look at from here or I find them via web search but I 
won't spend time reading everything because I'd rather do something else 
than that. If I can't figure it out or not answered here by those who 
already know I won't bother to learn it. This should be fun and reading 
standards docs isn't for me.
> > > > only handles one PCI bus at the moment so not sure that additional
> > > > complexity you mention exists in it yet. The io* words do what needs to be
> > > > done to read and write mapped registers (on ppc doing eieio or similar,
> > >
> > > Which isn't enough in all cases.
> >
> > In what cases is it not enough?
>
> In many cases.  OF requires the access to have been performed wrt to the
> actual device that is accessed before the next word starts executing.
> This doesn't come natural to PowerPC at all.  You can cheat a little bit
> here, but not much.  "eieio" might be enough for stores in some cases,
> but it isn't for loads, not on most real hardware at least.

What would be enough then? Should we replace eieio with sync in these io 
functions? I was under the impression and apparently who implemented the 
io functions in OpenBIOS as well that this was appropriate here. The 
description of eieio in the PPC user manual also says that it's used in 
accessing memory mapped IO. But these io words are preexisting not my 
patch added them so if they are wrong then that's a preexisting bug and 
probably also affects all other existing uses of these so fixing it would 
be a separate patch.

Also for real hardware, to my knowledge running OpenBIOS on real hardware 
is not something that anyone have tried recently so very likely it does 
not work (if it ever did) and it's mostly only used with QEMU now. 
Therefore I'd say if something is better than before even if not perfect 
but works with QEMU at least then we may have it for now and let it get 
fixed later when someone wants to use it on real hardware because 
otherwise we will not get anywhere. If we know it might be wrong we can 
have a comment saying that for people improving it later. This does not 
mean that if something is obviously wrong and can be made better easily 
that should not be fixed but holding back because of some theoretical 
possibility of something breaking in situations that don't occur in 
practice where OpenBIOS is actually used seems counterproductive given the 
slow progress with OpenBIOS to ever reach it's goal to become a full OF 
implementation. Given the scarce resources to advance it at all I'd be 
happy to just make it work in the few cases that are used before worrying 
about making it perfect. This is also against my normal approach as I like 
to do things well but given the limited time and resources, less than 
perfect progress may be the best that we can achieve and that's better 
than no progress.
> > > Sure it's a step up from not doing anything here, but you will run into
> > > trouble very soon.
> >
> > If you see where we might run into trouble please explain so we don't have
> > to debug that when it happens and we're aware of the limitations this
> > solution has.
>
> That's what I did!

Probably you did but I don't know enough to get that so you have to be 
more specific the get the info across.
> You need to implement  rb@  and friends *per bus node*, and redirect via
> FCode for them.  Which is unusual, but there you have it.

OK I still not get it so have a few questions:

If it's unusual how other implementations avoid needing this?

Bus node means /pci? If that's the only one we have in OpenBIOS why do we 
need more than one implementation? (At best we will have two identical 
/pci nodes later maybe but not sure if other machines supported in 
OpenBIOS may already have more.)

If bus node means not only /pci but different other nodes that may have 
children (like usb, ide or i2c, what else?) then what's different about 
them that need separate implementation of these words? Aren't they all 
memory mapped io on PPC Macs that are emulated by QEMU?

If one global implementation is not enough how to make it local to that 
node and how to redirect from FCode to that?

But again what's the usual way and could we do that in OpenBIOS instead?

Regards,
BALATON Zoltan

Implementing map-in

[Mark Cave-Ayland]

On 29/07/2019 15:34, BALATON Zoltan wrote:
> OpenBIOS is not OpenHackWare but seems to be equally incomplete, patchy and rely on
> random hacks. Trying to clean it up and implement missing stuff seems to be as
> complex as rewriting OpenFirmware. Given all OpenBIOS's missing features and
> non-existing developer comunity with only limited resources to improve it I wonder if
> we should try to move on to OpenFirmware instead eventually to at least have a
> complete OF implementation so we only need to care about porting that to QEMU and
> adding Apple specific stuff and not to implement OF itself. Apparently this was
> already done for QEMU prep a few years ago:

I find this attitude unhelpful and disrespectful to the people who have worked on
OpenBIOS over the years, some of whom are still on this mailing list.

Certainly OpenBIOS can be improved in certain areas, but please keep the discussion
on a technical level rather than making sweeping accusations about the state of the
project.

ATB,

Mark.

Implementing map-in

[BALATON Zoltan]

On Tue, 30 Jul 2019, Mark Cave-Ayland wrote:
> On 29/07/2019 15:34, BALATON Zoltan wrote:
> > OpenBIOS is not OpenHackWare but seems to be equally incomplete, patchy and rely on
> > random hacks. Trying to clean it up and implement missing stuff seems to be as
> > complex as rewriting OpenFirmware. Given all OpenBIOS's missing features and
> > non-existing developer comunity with only limited resources to improve it I wonder if
> > we should try to move on to OpenFirmware instead eventually to at least have a
> > complete OF implementation so we only need to care about porting that to QEMU and
> > adding Apple specific stuff and not to implement OF itself. Apparently this was
> > already done for QEMU prep a few years ago:
>
> I find this attitude unhelpful and disrespectful to the people who have worked on
> OpenBIOS over the years, some of whom are still on this mailing list.

Don't take it personal. I did not mean to say that you're not doing all 
you can to improve and advance OpenBIOS and thanks for keeping the project 
alive. But what I'm saying is that alone may not be enough to reach 
project goals. If you look at this page:

https://github.com/openbios/openbios/graphs/contributors

you can see that for the last few years after 2012 you seem to be the only 
one who still cares about OpenBIOS and if your free time does not allow to 
continue in the future it will be pretty much dead. So looking for 
alternatives may be needed unless more people show up and do something to 
help you. Pointing this out to people still on the list who could do 
something to better OpenBIOS is more helpful than unhelpful even if they 
may feel offended by that.

It may be that I'm a bit frustrated by not being able to get a simple fix 
for MorphOS in since 2016 for no clear reason (other than forcing me to 
make bigger changes and more cleanup instead) and to find missing parts to 
implement and things to clean up whenever I try to do something with 
OpenBIOS and I don't see based on this past experience how will I be able 
to make changes I need for Pegasos2 emulation so my attitude may have 
changed a bit, but I'm not accusing you or anyone for this. I still think 
that if you would not do what you do now the project was already dead. But 
I accept the facts and point out that only one free time developer may not 
be enough to make progress fast enough to get OpenBIOS to the level of 
OpenFirmware in the same time than getting OpenFirmware working in place 
of it so considering that alternative is valid in my opinion. This does 
not negate all the work you've put in OpenBIOS so far and it has served 
QEMU well so far so it wasn't useless even if we take a different turn in 
the future. But if your and my limited free time is all what we have then 
getting OpenBIOS working with Pegasos2 to emulate SmartFirmware or even 
reaching the capabilities of OpenFirmware may not be possible any time 
soon.

I think when OpenBIOS was started there were no other free OF 
implementations available yet and making a free implementation of the 
standard was useful to do. By now all other major implementations 
(OpenFirmware and SmartFirmware) are free and some machines in QEMU use 
SLOF instead so it is a valid question if it's worth duplicating all the 
efforts again in OpenBIOS when there may be other alternatives that are 
the same amount of work to make usable. Do not only judge this based on 
how much work you've put already put in OpenBIOS but also what helps to 
reach the goals fastest. Althugh out goals may be different there are 
common points I believe.
> Certainly OpenBIOS can be improved in certain areas, but please keep the discussion
> on a technical level rather than making sweeping accusations about the state of the
> project.

On techincal terms I have three ways to choose from to get a working 
firmware for pegasos2 replacing the original which has closed source parts 
so cannot be distributed or included in QEMU:

1. Reimplement it from its parts which are all open source: SmartFirmware, 
x86emu (used to init video cards but may not be needed on QEMU where we 
can have our own video bios) and maybe pmon where the loader seems to come 
from. The closed parts are mostly board init which we probably don't need 
on QEMU anyway such as setting up memory controller or clocking. This is 
some amount of work but would only be useful for pegasos2 and not for 
other machines in QEMU and would add yet another OF implementation to QEMU 
so not my first option.

2. Get OpenBIOS to be able to emulate SmartFirmware trying to clean up and 
implement as many parts as needed which would also help other machines 
using OpenBIOS. For this I think at least the FDT unflattening should be 
ported from SLOF to be able to define different device trees for different 
machines in QEMU instead of having to add knowledge about every board in 
OpenBIOS which already has too many if old_world/new_world, and hardcoded 
assumptions about memory locations which should be removed by this. This 
also coincides your work on cleaning up PCI tree creation so I though it 
would be useful for multiple use cases and what I'm first trying before 
other options.

3. Try to get some other OF implementation working like OpenFirmware. 
Based on previous work by Atar for the 40p this is possible although to do 
it cleanly may be more work and hindered by the need to do it in Forth 
completely. But Forth is needed to hack on OpenBIOS as well so once 
someone gets over that hurdle it does not matter. I've started looking at 
this posibility to find out how much work would this be that's why I was 
asking the question. I've compiled Atar's work which is now upstram in 
Mitch Bradley's tree and it worked well with 40p and even started with 
pegasos2 but of course it did not init the hardware correctly expecting to 
run on 40p (haven't tried with mac99 but I expect the same result). So 
OpenFirmware already works on PPC and has some QEMU specific drivers what 
we may need is porting drivers for mac specific and pegasos2 devices from 
OpenBIOS from C to Forth (or get equivalents from somewhere else) and 
think about how to pass the initial device tree similar to SLOF to avoid 
having to implement each board in OpenFirmware separately (although doing 
hardcoded board implementation like Atar's 40p might be a quick and dirty 
way to get it working with much less work).

Hope the above explains my question and makes people on the list think so 
we can find the best way to use our limited resources and you don't see 
this as an attack against you or OpenBIOS which I did not mean to do so 
sorry if you took it like that.

Regards,
BALATON Zoltan

Implementing map-in

[BALATON Zoltan]

On Mon, 29 Jul 2019, Jd Lyons wrote:
> Can’t apply this patch to the main branch or Mark’s v2 branch, and I 
> can’t be much help if we are not working from the same codebase.

What error do you get? The new list archive does not make it easy to get 
the patch so maybe it's corrupted by copying it from there? Best bet might 
be to copy from html source and replacing html entities with correct ascii 
chars ot save from your email client as raw source.

The patch should apply on top of master patched with Mark's v2 series:
https://mail.coreboot.org/hyperkitty/list/[e-mail]/thread/5TKME...
but I may have other patches in my tree so unless you tell me what fails 
for you I may not know. (I've saved Mark's 30 patches from the list, 
applied them with git am then created my patch so this should work.)

Regards,
BALATON Zoltan

Implementing map-in

[Mark Cave-Ayland]

On 29/07/2019 12:07, BALATON Zoltan wrote:
> On Mon, 29 Jul 2019, Jd Lyons wrote:
> > Can’t apply this patch to the main branch or Mark’s v2 branch, and I can’t be much
> > help if we are not working from the same codebase.
>
> What error do you get? The new list archive does not make it easy to get the patch so
> maybe it's corrupted by copying it from there? Best bet might be to copy from html
> source and replacing html entities with correct ascii chars ot save from your email
> client as raw source.
>
> The patch should apply on top of master patched with Mark's v2 series:
> https://mail.coreboot.org/hyperkitty/list/[e-mail]/thread/5TKME...
>
> but I may have other patches in my tree so unless you tell me what fails for you I
> may not know. (I've saved Mark's 30 patches from the list, applied them with git am
> then created my patch so this should work.)

FWIW I had to fix up your last patch by hand too. You need to fix up your git
format-patch workflow, and/or push your branch to a public git repository so we can
find your changes there. Otherwise people are much less likely to help if they have
to spend time fixing up your patches by hand just to apply them in the first place.

ATB,

Mark.

Implementing map-in

[BALATON Zoltan]

On Tue, 30 Jul 2019, Mark Cave-Ayland wrote:
> FWIW I had to fix up your last patch by hand too. You need to fix up your git
> format-patch workflow, and/or push your branch to a public git repository so we can
> find your changes there. Otherwise people are much less likely to help if they have
> to spend time fixing up your patches by hand just to apply them in the first place.

How do I know when you're only telling now. I haven't used git format 
patch for this RFC but it should have worked anyway unless I've missed 
somethig which is possible. But I hoped to get feedback on the patch on 
how to break it up or what needs to be changed before I make a proper 
submission. I'm still waiting for that review and I don't know if you will 
accept it or want some changes.

Regards,
BALATON Zoltan