OpenBIOS

openbios@openbios.org

4289 discussions

Re: Implementing map-in
by BALATON Zoltan 30 Jul '19

30 Jul '19

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.

5 16

[PATCH v2 00/30] pci: build device tree from root
by Mark Cave-Ayland 28 Jul '19

28 Jul '19

This patchset started off with the aim of building the PCI-based machine device trees downwards from the root node to avoid switching either the active package and/or current instance at various points during the tree construction. The basis for this was to try and remove all named nodes (those which are placed at a given path) and instead build the hierarchy in order by using new-device and finish-device as per the IEEE-1275 specification. This was realised by creating a new BIND_NODE_METHODS() macro which is similar to REGISTER_NAMED_NODE() except that it doesn't alter either the active package or the current instance, and then working through the device tree from the root converting all the devices for the PCI-based machines to use it. Once this conversion has been completed for all devices beneath the PCI node, it becomes possible to remove both the REGISTER_NAMED_NODE() and REGISTER_NAMED_NODE_PHANDLE() macros to prevent future patches from accidentally changing the tree construction order. Next the x86, PPC and SPARC64 device tree roots were altered to set the active package and current instance, allowing the remaining places where the PCI code alters either of them to be removed. At this point instance variables were working correctly, and I noticed that there were several PCI devices which made use of C initialisation functions and/or properties for initial configuration. These can now be replaced with instance variables to keep everything simple and consistent. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> v2: - Fix up NVRAM initialisation so that -prom-env 'vga-ndrv?=false' works again Mark Cave-Ayland (30): libopenbios: introduce BIND_NODE_METHODS() macro pc_kbd: convert to use BIND_NODE_METHODS() macro pc_serial: convert to use BIND_NODE_METHODS() macro floppy: convert to use BIND_NODE_METHODS() macro ide: convert to use BIND_NODE_METHODS() macro adb: convert to use BIND_NODE_METHODS() macro escc: convert to use BIND_NODE_METHODS() macro cuda: convert to use BIND_NODE_METHODS() macro macio: convert to use BIND_NODE_METHODS() macro pmu: convert to use BIND_NODE_METHODS() macro usbhid: convert to use BIND_NODE_METHODS() macro nvram: convert to use BIND_NODE_METHODS() macro lsi: don't change active package when setting device alias lsi: convert to use BIND_NODE_METHODS() macro virtio: convert to use BIND_NODE_METHODS() macro pci: convert to use BIND_NODE_METHODS() macro pci: remove ob_pci_initialize() and ob_pci_empty_node libopenbios: remove REGISTER_NAMED_NODE and REGISTER_NAMED_NODE_PHANDLE macros nvram: ensure that NVRAM configuration is separate from NVRAM node creation ppc: move New World uninorth and nvram device node creation to the root device ppc: set active package and current instance to root device node before probe SPARC64: set active package and current instance to root device node before probe x86: set active package and current instance to root device node before probe pci: remove explicit find-device from PCI devices pci: remove explicit setting of my-self from PCI devices pci: call set-args before configuring PCI device nodes pc_serial: remove separate init word pc_kbd: use instance value to initialise C instance parameter lsi: use instance value to hold sd_private_t pointer virtio: use instance value to initialise C instance parameter arch/ppc/qemu/init.c | 13 +++ arch/sparc64/openbios.c | 6 ++ arch/x86/openbios.c | 9 +- drivers/adb_bus.c | 57 +++++++----- drivers/adb_kbd.c | 25 ++++-- drivers/adb_mouse.c | 31 ++++--- drivers/cuda.c | 158 ++++++++++++++++++++------------- drivers/escc.c | 113 ++++++++++++++--------- drivers/floppy.c | 68 +++++++------- drivers/ide.c | 123 +++++++++++++++---------- drivers/lsi.c | 65 +++++++------- drivers/macio.c | 118 ++++++++++++------------ drivers/macio.h | 1 - drivers/pc_kbd.c | 48 +++++----- drivers/pc_serial.c | 32 +++---- drivers/pci.c | 123 ++++++++++++------------- drivers/pmu.c | 152 +++++++++++++++++++++---------- drivers/usbhid.c | 16 ++-- drivers/virtio.c | 56 +++--------- include/drivers/drivers.h | 2 + include/libopenbios/bindings.h | 19 ++-- include/packages/nvram.h | 4 +- libopenbios/bindings.c | 10 +++ packages/nvram.c | 35 ++++++-- 24 files changed, 744 insertions(+), 540 deletions(-) -- 2.20.1

2 38

Re: Debugging FCode ROM
by Jd Lyons 25 Jul '19

25 Jul '19

I think old world Macs always booted in 640x480x8, but new world can boot at a higher screen resolution setup in NVRAM. The change in modes to 640x480x8 maybe for compatibility with Old World Macs. I think reduced ATI ROM’s, that we removed the ‘NDRV’ so it would fit on a 64k EEROM always booted at 640x480x8 until the disk based “NDRV’ loaded. I don’t think anyone ever flashed a reduced Rage128 Pro ROM without the ‘NDRV’ sos I don’t really know how a new world Mac would handle that, if it could still set a higher screen resolution. Maybe we can we can get some info from the sources of the linux r128 driver? > On Jul 25, 2019, at 5:53 AM, BALATON Zoltan <balaton(a)eik.bme.hu> wrote: > > On Thu, 25 Jul 2019, Jd Lyons wrote: >> I take it you’ve seen this: >> >> https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=2ahUKEw… > > Sure, that's what I use for register reference all the time (and is linked from my qmiga.osdn.io page although not directly to avoid possible copyright problems but the card page where the doc is available linked and I've told you that before and also hinted on that page. There are more docs available from the pages linked from my qmiga page, all those might have useful info (the prg and sdk guides too, even though they are for different cards but these are similar so some details are the same). > > However it does not explain what AMCGPIO is, only what are the bits in those regs or did I miss that part where it actually says what should be accessible via that register? From the access pattern it looks similar to GPIO_MONID where we have the EDID so maybe the card has another connector the DDC/EDID of which is accessed via the AMCGPIO reg? The FCode checks both but switches mode after reading AMCGPIO and before getting EDID from GPIO_MONID so maybe we need to add EDID to the AMCGPIO reg? But I don't know which bits to connect it. Probably one could find out by reading the detok-ed FCode source to see what it does with the EDID and how does it select mode or find an open source driver that accesses this to find out how this should work. > > But the problem currently is with the offset 8000 in the selected mode which the QEMU VGA emulation can't handle or I don't know how to make it handle. That's why picture is wrong at the moment. So either we should allow this offset or find out why FCode wants that and when it uses different mode is that better aligned then? Where does it get this 640x480x8 mode and shouldn't it use something higher by default? I don't know how MacOS works and what its default mode is. > > Regards, > BALATON Zoltan

1 0

Implementing map-in
by BALATON Zoltan 23 Jul '19

23 Jul '19

On Sun, 21 Jul 2019, Mark Cave-Ayland wrote: > 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 Good that you're only confused now. :-) I was and still am confused about it all the time so please bear with me. > 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? Apparently I was confused... Now I realise that this usage of map-in in FCode ROM really wants to map the IO BAR1. My confusion probably comes from that after mapping it it uses config-b[!@] to tweak some regs so I thought it may want config space. (I'm still confused though after reading the description of map-in and addresses in the PCI binding doc. And we probably will need access to config space if we want to implement config-* words in Forth. We could add callbacks to C for those but that's not the nicest way.) >> 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. No FCode here, just started OpenBIOS with patched openbios-elf and typed commands that I've seen in the FCode. All this comes from OpenBIOS, don't ask me why it calls this for open-dev. >> 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. Where does OpenBIOS copy and advance these values and what do *io_base and *mem_base refer to here? I assume the map-in word runs after the device tree is already constucted so these should already be mapped and map-in might just need to return a virt address for the already mapped bars. > 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 Which values? > 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. My patch called pci_bus_addr_to_host_addr in ob_pci_bus_map_in with the space decoded from phys.hi on the stack yet the virt address came out wrong at the end. Now I've tried to do instead what SLOF's map-in does: https://github.com/aik/SLOF/blob/master/slof/fs/pci-config-bridge.fs#L59 and ignore everything except phys.hi and get bar address from that like: size = POP(); phys[0] = POP(); phys[1] = POP(); phys[2] = POP(); PCI_DPRINTF("%s idx=%p, hi=%"PRIx32", mid=%"PRIx32", lo=%"PRIx32", size=" FMT_ucell"\n", __func__, idx, phys[0], phys[1], phys[2], size); pci_decode_phys_addr(phys, &flags, &space_code, &dev, &reg, &addr); /* Check if reg is actually a Base Address Reg */ if (reg < PCI_BASE_ADDR_0 || (reg > PCI_BASE_ADDR_5 && reg != PCI_ROM_ADDRESS)) { PUSH(-1); return; } addr = pci_config_read32(reg, dev); PCI_DPRINTF("%s bar=%"PRIx32"\n", __func__, addr); virt = ob_pci_map(addr, size); but then bar==-1 (even for MMIO regions which were mapped before) so it looks like it's not mapped at this point so map-in should program the BAR reg or call another function for that? > 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. Does it map then unmap the region without freeing the allocated MMIO space? Or if it's still mapped we should just return a pointer to the already mapped space. Could we just get that from assigned-addresses? > 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? I've tried to do that but forgot to update the subject. This thread is now about implementing map-in. The goal is still to run FCode ROMs but first step is to get map-in working. Thank you, BALATON Zoltan

3 13

RFC: porting SLOF's fdt.fs to OpenBIOS
by BALATON Zoltan 21 Jul '19

21 Jul '19

Hello, This is an attempt to port ftd.fs for FDT unflattening from SLOF to OpenBIOS. This compiles but I have not tried to feed it any fdt yet because I'm sure it won't work yet as some words are wrong. The words I had to implement for it (marked with a FIXME comment) should be reviewed and checked if they could work and the set-unit word is still missing so that needs to be implemented. Also 64bit stuff and claim usage should be clarified. Those words that are copied and do work may have better alternatives that I haven't found so could be replaced. Anyway this is a start to try to get this done. Once it works it will expect an FDT in memory at address fdt-start then the fdt-doit word at the end is an example of how to unflatten that into an OF device-tree (at least that's what SLOF does if I got that right). Any insight or comments on this are welcome. Regards, BALATON Zoltan diff --git a/forth/util/build.xml b/forth/util/build.xml index 4839d2c..25e02db 100644 --- a/forth/util/build.xml +++ b/forth/util/build.xml @@ -11,6 +11,7 @@ <dictionary name="openbios" target="forth"> <object source="util.fs"/> <object source="pci.fs"/> + <object source="fdt.fs"/>  diff --git a/forth/util/fdt.fs b/forth/util/fdt.fs new file mode 100644 index 0000000..af29bba --- /dev/null +++ b/forth/util/fdt.fs @@ -0,0 +1,586 @@ +\ ***************************************************************************** +\ * Copyright (c) 2011 IBM Corporation +\ * All rights reserved. +\ * This program and the accompanying materials +\ * are made available under the terms of the BSD License +\ * which accompanies this distribution, and is available at +\ * http://www.opensource.org/licenses/bsd-license.php +\ * +\ * Contributors: +\ * IBM Corporation - initial implementation +\ ****************************************************************************/ +\ Changes for OpenBIOS: BALATON Zoltan, 2019 + +1 VALUE fdt-debug +TRUE VALUE fdt-cas-fix? +0 VALUE fdt-start + +struct + 4 field >fdth_magic + 4 field >fdth_tsize + 4 field >fdth_struct_off + 4 field >fdth_string_off + 4 field >fdth_rsvmap_off + 4 field >fdth_version + 4 field >fdth_compat_vers + 4 field >fdth_boot_cpu + 4 field >fdth_string_size + 4 field >fdth_struct_size +constant /fdth + +h# d00dfeed constant OF_DT_HEADER +h# 1 constant OF_DT_BEGIN_NODE +h# 2 constant OF_DT_END_NODE +h# 3 constant OF_DT_PROP +h# 4 constant OF_DT_NOP +h# 9 constant OF_DT_END + +\ Create some variables early +0 value fdt-start-addr +0 value fdt-struct +0 value fdt-strings + + +\ FIXME: review the following words which were added for OpenBIOS +\ some of these copied verbatim from SLOF others try to implement +\ alternatives +\ +\ definitely wrong/missing: set-unit and claim disabled further below +\ +\ may be wrong: find-node, and other related node words and 64bit stuff +\ (SLOF seems to always be in 64bit mode and not sure if that's needed +\ to parse FDT or could it be changed for 32bit as OpenBIOS does not +\ define some words in 32bit mode.) + +: get-node ?active-package ; +: set-node active-package! ; +: node>path " ?" ; \ only used for debugging and errors +: get-parent get-node parent ; +: my-#address-cells my-#acells ; +: get-property get-package-property ; +: find-node ( path len -- phandle|0 ) + find-dev 0= if \ find-dev returns ( phandle true | false ) + 0 + then +; + +\ : set-space get-node dup >r node>space ! true r> node>space? ! ; +\ : set-address +\ my-#address-cells 1 ?DO +\ get-node node>space i cells + ! LOOP +\ ; +: set-unit 3drop ; \ set-space set-address ; + +: str= ( str1 len1 str2 len2 -- equal? ) + rot over <> IF 3drop false ELSE comp 0= THEN ; + +: from-cstring ( addr - len ) + dup dup BEGIN c@ 0 <> WHILE 1 + dup REPEAT + swap - +; + +: test-string ( param len -- true | false ) + 0 ?DO + dup i + c@ \ Get character / byte at current index + dup 20 < swap 7e > OR IF \ Is it out of range 32 to 126 (=ASCII) + drop FALSE UNLOOP EXIT \ FALSE means: No ASCII string + THEN + LOOP + drop TRUE \ Only ASCII found --> it is a string +; + +: find-substr ( basestr-ptr basestr-len substr-ptr substr-len -- pos ) + \ if substr-len == 0 ? + dup 0 = IF + \ return 0 + 2drop 2drop 0 exit THEN + \ if substr-len <= basestr-len ? + dup 3 pick <= IF + \ run J from 0 to "basestr-len"-"substr-len" and I from 0 to "substr-len"-1 + 2 pick over - 1+ 0 DO dup 0 DO + \ substr-ptr[i] == basestr-ptr[j+i] ? + over i + c@ 4 pick j + i + c@ = IF + \ (I+1) == substr-len ? + dup i 1+ = IF + \ return J + 2drop 2drop j unloop unloop exit THEN + ELSE leave THEN + LOOP LOOP + THEN + \ if there is no match then exit with basestr-len as return value + 2drop nip +; + +CREATE $catpad 400 allot +: $cat ( str1 len1 str2 len2 -- str3 len3 ) + >r >r dup >r $catpad swap move + r> dup $catpad + r> swap r@ move + r> + $catpad swap ; + +: split ( str len char -- left len right len ) + >r 2dup r> findchar IF >r over r@ 2swap r> 1+ /string ELSE 0 0 THEN ; +: generic-decode-unit ( str len ncells -- addr.lo ... addr.hi ) + dup >r -rot BEGIN r@ WHILE r> 1- >r [char] , split 2swap + $number IF 0 THEN r> swap >r >r REPEAT r> 3drop + BEGIN dup WHILE 1- r> swap REPEAT drop ; +: generic-encode-unit ( addr.lo ... addr.hi ncells -- str len ) + 0 0 rot ?dup IF 0 ?DO rot (u.) $cat s" ," $cat LOOP 1- THEN ; +: hex-decode-unit ( str len ncells -- addr.lo ... addr.hi ) + base @ >r hex generic-decode-unit r> base ! ; +: hex-encode-unit ( addr.lo ... addr.hi ncells -- str len ) + base @ >r hex generic-encode-unit r> base ! ; + +64bit? [IF] +: hex64-decode-unit ( str len ncells -- addr.lo ... addr.hi ) + dup 2 <> IF + hex-decode-unit + ELSE + drop + base @ >r hex + $number IF 0 0 ELSE xlsplit THEN + r> base ! + THEN +; +: hex64-encode-unit ( addr.lo ... addr.hi ncells -- str len ) + dup 2 <> IF + hex-encode-unit + ELSE + drop + base @ >r hex + lxjoin (u.) + r> base ! + THEN +; +[ELSE] +: hex64-decode-unit hex-decode-unit ; +: hex64-encode-unit hex-encode-unit ; +: x@ l@ ; +: xlsplit ( o -- quad.lo quad.hi ) + dup h# ffffffff and swap d# 32 rshift + ; +[THEN] + +\ functions to review end here, also see fdt-claim-reserve below + + +: fdt-init ( fdt-start -- ) + dup to fdt-start-addr + dup dup >fdth_struct_off l@ + to fdt-struct + dup dup >fdth_string_off l@ + to fdt-strings + drop +; + +\ Dump fdt header for all to see and check FDT validity +: fdt-check-header ( -- ) + fdt-start-addr dup 0 = IF + ." No flat device tree !" cr drop -1 throw EXIT THEN + hex + fdt-debug IF + ." Flat device tree header at 0x" dup . s" :" type cr + ." magic : 0x" dup >fdth_magic l@ . cr + ." total size : 0x" dup >fdth_tsize l@ . cr + ." offset to struct : 0x" dup >fdth_struct_off l@ . cr + ." offset to strings: 0x" dup >fdth_string_off l@ . cr + ." offset to rsvmap : 0x" dup >fdth_rsvmap_off l@ . cr + ." version : " dup >fdth_version l@ decimal . hex cr + ." last compat vers : " dup >fdth_compat_vers l@ decimal . hex cr + dup >fdth_version l@ 2 >= IF + ." boot CPU : 0x" dup >fdth_boot_cpu l@ . cr + THEN + dup >fdth_version l@ 3 >= IF + ." strings size : 0x" dup >fdth_string_size l@ . cr + THEN + dup >fdth_version l@ 11 >= IF + ." struct size : 0x" dup >fdth_struct_size l@ . cr + THEN + THEN + dup >fdth_magic l@ OF_DT_HEADER <> IF + ." Flat device tree has incorrect magic value !" cr + drop -1 throw EXIT + THEN + dup >fdth_version l@ 10 < IF + ." Flat device tree has usupported version !" cr + drop -1 throw EXIT + THEN + + drop +; + +\ Fetch next tag, skip nops and increment address +: fdt-next-tag ( addr -- nextaddr tag ) + 0 ( dummy tag on stack for loop ) + BEGIN + drop ( drop previous tag ) + dup l@ ( read new tag ) + swap 4 + swap ( increment addr ) + dup OF_DT_NOP <> UNTIL ( loop until not nop ) +; + +\ Parse unit name and advance addr +: fdt-fetch-unit ( addr -- addr $name ) + dup from-cstring \ get string size + 2dup + 1 + 3 + fffffffc and -rot +; + +\ Update unit with information from the reg property... +\ ... this is required for the PCI nodes for example. +: fdt-reg-unit ( prop-addr prop-len -- ) + decode-phys ( prop-addr' prop-len' phys.lo ... phys.hi ) + set-unit ( prop-addr' prop-len' ) + 2drop +; + +\ Lookup a string by index +: fdt-fetch-string ( index -- str-addr str-len ) + fdt-strings + dup from-cstring +; + +: fdt-create-dec s" decode-unit" $CREATE , DOES> @ hex64-decode-unit ; +: fdt-create-enc s" encode-unit" $CREATE , DOES> @ hex64-encode-unit ; + +\ Check whether array contains an zero-terminated ASCII string: +: fdt-prop-is-string? ( addr len -- string? ) + dup 1 < IF 2drop FALSE EXIT THEN \ Check for valid length + 1- + 2dup + c@ 0<> IF 2drop FALSE EXIT THEN \ Check zero-termination + test-string +; + +\ Encode fdt property to OF property +: fdt-encode-prop ( addr len -- ) + 2dup fdt-prop-is-string? IF + 1- encode-string + ELSE + encode-bytes + THEN +; + +\ Method to unflatten a node +: fdt-unflatten-node ( start -- end ) + \ this can and will recurse + recursive + + \ Get & check first tag of node ( addr -- addr) + fdt-next-tag dup OF_DT_BEGIN_NODE <> IF + s" Weird tag 0x" type . " at start of node" type cr + -1 throw + THEN drop + + new-device + + \ Parse name, split unit address + fdt-fetch-unit + dup 0 = IF drop drop " /" THEN + 40 left-parse-string + \ Set name + device-name + + \ Set preliminary unit address - might get overwritten by reg property + dup IF + " #address-cells" get-parent get-package-property IF + 2drop + ELSE + decode-int nip nip + hex-decode-unit + set-unit + THEN + ELSE 2drop THEN + + \ Iterate sub tags + BEGIN + fdt-next-tag dup OF_DT_END_NODE <> + WHILE + dup OF_DT_PROP = IF + \ Found property + drop dup ( drop tag, dup addr : a1 a1 ) + dup l@ dup rot 4 + ( fetch size, stack is : a1 s s a2) + dup l@ swap 4 + ( fetch nameid, stack is : a1 s s i a3 ) + rot ( we now have: a1 s i a3 s ) + fdt-encode-prop rot ( a1 s pa ps i) + fdt-fetch-string ( a1 s pa ps na ns ) + 2dup s" reg" str= IF + 2swap 2dup fdt-reg-unit 2swap + THEN + property + + 8 + 3 + fffffffc and + ELSE dup OF_DT_BEGIN_NODE = IF + drop ( drop tag ) + 4 - + fdt-unflatten-node + ELSE + drop -1 throw + THEN THEN + REPEAT drop \ drop tag + + \ Create encode/decode unit + " #address-cells" get-node get-package-property IF ELSE + decode-int dup fdt-create-dec fdt-create-enc 2drop + THEN + + finish-device +; + +\ Start unflattening +: fdt-unflatten-tree + fdt-debug IF + ." Unflattening device tree..." cr THEN + fdt-struct fdt-unflatten-node drop + fdt-debug IF + ." Done !" cr THEN +; + +\ Find memory size +: fdt-parse-memory + \ XXX FIXME Handle more than one memory node, and deal + \ with RMA vs. full access + " /memory@0" find-device + " reg" get-node get-package-property IF throw -1 THEN + + \ XXX FIXME Assume one entry only in "reg" property for now + decode-phys 2drop decode-phys + my-#address-cells 1 > IF 20 << or THEN + + fdt-debug IF + dup ." Memory size: " . cr + THEN + \ claim.fs already released the memory between 0 and MIN-RAM-SIZE, + \ so we've got only to release the remaining memory now: +\ MIN-RAM-SIZE swap MIN-RAM-SIZE - release + 2drop device-end +; + +\ FIXME: Find out if this is needed and what should it do +: claim 3drop ; + +\ Claim fdt memory and reserve map +: fdt-claim-reserve + fdt-start-addr + dup dup >fdth_tsize l@ 0 claim drop + dup >fdth_rsvmap_off l@ + + BEGIN + dup dup x@ swap 8 + x@ + dup 0 <> + WHILE + fdt-debug IF + 2dup swap ." Reserve map entry: " . ." : " . cr + THEN + 0 claim drop + 10 + + REPEAT drop drop drop +; + +\ The following functions are use to replace the FDT phandle and +\ linux,phandle properties with our own OF1275 phandles... + +\ This is used to check whether we successfully replaced a phandle value +0 VALUE (fdt-phandle-replaced) + +\ Replace phandle value in "interrupt-map" property +: fdt-replace-interrupt-map ( old new prop-addr prop-len -- old new ) + BEGIN + dup ( old new prop-addr prop-len prop-len ) + WHILE + \ This is a little bit ugly ... we're accessing the property at + \ hard-coded offsets instead of analyzing it completely... + swap dup 10 + ( old new prop-len prop-addr prop-addr+10 ) + dup l@ 5 pick = IF + \ it matches the old phandle value! + 3 pick swap l! + TRUE TO (fdt-phandle-replaced) + ELSE + drop + THEN + ( old new prop-len prop-addr ) + 1c + swap 1c - + ( old new new-prop-addr new-prop-len ) + REPEAT + 2drop +; + +: (fdt-replace-phandles) ( old new propname propnamelen node -- ) + get-property IF 2drop EXIT THEN + BEGIN + dup + WHILE ( old new prop-addr prop-len ) + over l@ + 4 pick = IF + 2 pick 2 pick l! \ replace old with new in place + TRUE TO (fdt-phandle-replaced) + THEN + 4 - swap 4 + swap + REPEAT + 2drop 2drop +; + +\ Replace one phandle "old" with a phandle "new" in "node" and recursively +\ in its child nodes: +: fdt-replace-all-phandles ( old new node -- ) + \ ." Replacing in " dup node>path type cr + >r + s" interrupt-map" r@ get-property 0= IF + ( old new prop-addr prop-len R: node ) + fdt-replace-interrupt-map + THEN + + 2dup s" interrupt-parent" r@ (fdt-replace-phandles) + 2dup s" ibm,gpu" r@ (fdt-replace-phandles) + 2dup s" ibm,npu" r@ (fdt-replace-phandles) + 2dup s" ibm,nvlink" r@ (fdt-replace-phandles) + 2dup s" memory-region" r@ (fdt-replace-phandles) + + \ ... add more properties that have to be fixed here ... + r> + \ Now recurse over all child nodes: ( old new node ) + child BEGIN + dup + WHILE + 3dup RECURSE + PEER + REPEAT + 3drop +; + +\ Replace one FDT phandle "val" with a OF1275 phandle "node" in the +\ whole tree: +: fdt-update-phandle ( val node -- ) + >r + FALSE TO (fdt-phandle-replaced) + r@ s" /" find-node ( val node root ) + fdt-replace-all-phandles + (fdt-phandle-replaced) IF + r@ set-node + s" phandle" delete-property + s" linux,phandle" delete-property + ELSE + diagnostic-mode? IF + cr ." Warning: Did not replace phandle in " r@ node>path type cr + THEN + THEN +r> drop +; + +\ Check whether a node has "phandle" or "linux,phandle" properties +\ and replace them: +: fdt-fix-node-phandle ( node -- ) + >r + s" phandle" r@ get-property 0= IF + decode-int nip nip + \ ." found phandle: " dup . cr + r@ fdt-update-phandle + THEN + r> drop +; + +\ Recursively walk through all nodes to fix their phandles: +: fdt-fix-phandles ( node -- ) + \ ." fixing phandles of " dup node>path type cr + dup fdt-fix-node-phandle + child BEGIN + dup + WHILE + dup RECURSE + PEER + REPEAT + drop + device-end +; + +: fdt-create-cas-node ( name -- ) + 2dup + 2dup " memory@" find-substr 0 = IF + fdt-debug IF ." Creating memory@ " cr THEN + new-device + 2dup " @" find-substr nip device-name \ Parse the node name + 2dup + 2dup " @" find-substr rot over + 1 + -rot - 1 - \ Jump to addr afte "@" + parse-2int nip xlsplit set-unit \ Parse and set unit + finish-device + ELSE + 2dup " ibm,dynamic-reconfiguration-memory" find-substr 0 = IF + fdt-debug IF ." Creating ibm,dynamic-reconfiguration-memory " cr THEN + new-device + device-name + finish-device + ELSE + 2drop 2drop + false to fdt-cas-fix? + ." Node not supported " cr + EXIT + THEN + THEN + + find-node ?dup 0 <> IF set-node THEN +; + +: fdt-fix-cas-node ( start -- end ) + recursive + fdt-next-tag dup OF_DT_BEGIN_NODE <> IF + ." Error " cr + false to fdt-cas-fix? + EXIT + THEN drop + fdt-fetch-unit + dup 0 = IF drop drop " /" THEN + 40 left-parse-string + 2swap ?dup 0 <> IF + nip + 1 + + \ Add the string len +@ + ELSE + drop + THEN + fdt-debug IF ." Setting node: " 2dup type cr THEN + 2dup find-node ?dup 0 <> IF + set-node 2drop + ELSE + fdt-debug IF ." Node not found, creating " 2dup type cr THEN + fdt-create-cas-node + THEN + fdt-debug IF ." Current now: " pwd cr THEN + BEGIN + fdt-next-tag dup OF_DT_END_NODE <> + WHILE + dup OF_DT_PROP = IF + fdt-debug IF ." Found property " cr THEN + drop dup ( drop tag, dup addr : a1 a1 ) + dup l@ dup rot 4 + ( fetch size, stack is : a1 s s a2) + dup l@ swap 4 + ( fetch nameid, stack is : a1 s s i a3 ) + rot ( we now have: a1 s i a3 s ) + fdt-encode-prop rot ( a1 s pa ps i) + fdt-fetch-string ( a1 s pa ps na ns ) + property + fdt-debug IF ." Setting property done " cr THEN + + 8 + 3 + fffffffc and + ELSE dup OF_DT_BEGIN_NODE = IF + drop ( drop tag ) + 4 - + fdt-fix-cas-node + get-parent set-node + fdt-debug IF ." Returning back " pwd cr THEN + ELSE + ." Error " cr + drop + false to fdt-cas-fix? + EXIT + THEN + THEN + REPEAT + drop \ drop tag +; + +: fdt-fix-cas-success + fdt-cas-fix? +; + +: fdt-doit + \ Bail out if no fdt + fdt-start 0 = IF + ." No fdt-start" cr + -1 throw + THEN + fdt-start fdt-init + fdt-check-header + fdt-unflatten-tree + fdt-parse-memory + fdt-claim-reserve + s" /" find-node fdt-fix-phandles +;

3 4

Re: [Qemu-ppc] ATY 'NDRV'
by Jd Lyons 21 Jul '19

21 Jul '19

With nVidia FCode ROM’s these AGP properties were just ignored by Open Firmware and the drivers for a hacked PCI nVidia card. I don’t think they will be any trouble with ATI cards either, but we’ll burn that bridge when we get there, tho PCI FCode RoM’s have Fast-back-to-back. 0 > .properties vendor-id 00001002 device-id 00005245 revision-id 00000000 class-code 00030000 interrupts 00000001 min-grant 00000008 max-latency 00000000 subsystem-vendor-id 0000b530 subsystem-id 00000408 devsel-speed 00000001 fast-back-to-back fcode-rom-offset 00000000 ATY,Status 00000000 ATY,Flags 0717009b EDID 00ffffff ffffff00 1e6ddb56 f7470200 0c130103 6a301b78 ea3d85a6 564a9a24 125054a7 6b80b300 81808140 714f0101 01010101 0101023a 80187138 2d40582c 4500dd0c 1100001a 21399030 621a2740 68b03600 dd0c1100 001c0000 00fd0038 4b1e530f 000a2020 20202020 000000fc 00573232 35330a20 20202020 2020008a depth 00000008 device_type display character-set ISO8859-1 iso6429-1983-colors reg 00011800 00000000 00000000 00000000 00000000 02011830 00000000 00000000 00000000 00020000 42011810 00000000 00000000 00000000 08000000 02011818 00000000 00000000 00000000 00004000 name ATY,Rage128y model ATY,Rage128 ATY,Rom# 3131332d 35373430 312d3131 3600 ATY,Card# 3130392d 35373430 322d3030 00 ATY,Fcode 312e3633 00 driver,AAPL,MacOS,PowerPC 4a6f7921 70656666 70777063 00000001 b2943306 00000000 00000000 00000000 00030002 00000000 ffffffff 00000000 0000c4a8 0000c4a8 0000c4a8 00000630 00040400 ffffffff 00000000 00002b61 000026c3 00001c34 0000cae0 02010400 ffffffff 00000000 00000000 00000000 000005b0 00000080 04040400 00000000 ffffffff 00000000 ffffffff 00000000 ffffffff 00000000 00000005 0000002a 00000001 00000164 000001d0 0000058c 00000001 00000002 00000000 00000000 00000000 00000011 00000000 00000000 00000012 00000000 00000000 00000001 00000011 00000000 0000001f 00000000 00000000 0000000e 00000012 00000000 ... 0000e714 bytes total assigned-addresses c2011810 00000000 88000000 00000000 08000000 82011830 00000000 800a0000 00000000 00020000 82011818 00000000 80088000 00000000 00004000 address 88000000 width 00000280 height 000001e0 linebytes 00000280 ok > On Jul 20, 2019, at 11:31 AM, BALATON Zoltan <balaton(a)eik.bme.hu> wrote: > > On Sat, 20 Jul 2019, Howard Spoelstra wrote: >> This rom does define some AGP stuff, so I don't know whether that will be a >> problem with PCI? > > Not sure but maybe not unless it wants to do something with AGP. As far as I could get from the FCode that only adds some AGP related parameters to device tree that are hard-coded and does not do anything with AGP itself so it should not be a problem for the ROM itself, maybe the OS later wants to set some AGP stuff but those are probably just ignored and if the right addresses of the card are available for frame buffer and mmio regs it should then work. But we'll see, this is again something that I don't know much about so will have to learn when it turns out to cause problem but until then I'm going to ignore it. > > Regards, > BALATON Zoltan

2 5

Re: [Qemu-ppc] ATY 'NDRV'
by Jd Lyons 21 Jul '19

21 Jul '19

Th ATI Driver Update extension from 9.2.2 has these ‘NDRV’s for the Rage128. ATY,Rage128k ATY,Rage128Pk ATY,Rage128Ps ATY,Rage128s ATY,Rage128y ATY,Rage128Pd ATY,Rage128P2ks I thought I was able to use them in a very limited mode, however checking the IOReg I see the display “NDRV’ from the Mac OS ROM. So the Rage128 ‘NDRV’s try to load, but at some point they abort and never get built in the device tree for the card. So maybe the FCode can fix these issues. BTW does anyone know how to trail the serial output of Qemu? May debug trace of “ate*” and “pci*" is longer than the line buffer of my terminal and I’d like to be able to save it as a text file. Something like -serial stdio > atidebug.txt. > On Jul 20, 2019, at 4:53 PM, BALATON Zoltan <balaton(a)eik.bme.hu> wrote: > > On Sat, 20 Jul 2019, Howard Spoelstra wrote: >> I used Graphiccelerator ( http://thomas.perrier.name/graphiccelerator.html > > This page lists compatibility with these ROMs: > > Rage 128 Pro OEM, rev 108, 110, 125, 130 and 136 > Rage 128 OEM, rev 108, 112, 116 and 204 > > So I think there are ROMs (and NDRVs) for Rage128 which are not compatible with the ati-vga emulation as that's for a Rage128 chip and there are ROMs/NDRVs for Rage 128 Pro of which we have 110 and 136 (there are other versions as well but these two are probably enough). So we should not try yo use a Rage128 ROM/NDRV only Rage 128 Pro one. > > For the RV100 emulation maybe these could work (eventually, as rv100 emulation is very incomplete yet but in case you want to try anyway): > > Radeon 7000 Mac Edition, rev 119, 208, 218 and 226 > Radeon 7000 OEM, rev 109 and 110 > > although we really emulate a Mobility Radeon 7000 aka M6 chip as that's what is found on the fulong2e board also emulated by QEMU but these are probably not much different on the register level. I'm not sure this is correct though and don't know what the other Radeon ROMs are without a specific model number on that page. But the above are probably the only ROMs (and corresponding NDRVs) that are supposed to work, anything else is not useful for testing. > > (The rv100 emulation is less likely to work because its drivers usually try to talk to the card via memory buffers and assume 3D is there but none of these are emulated yet, so trying it would likely only confirm this but not get you anywhere currently.) > > Regards, > BALATON Zoltan

1 0

Re: ATY 'NDRV'
by Jd Lyons 20 Jul '19

20 Jul '19

Hmmmmm. Using ATI ROM Xtender 1.2 with OS 9 and the ATY,Rage128v ‘NDRV’ i.e. dev /pci/@f “ ATY,Rage128v” encode-string “ name” property boot ATY,Rage128ns ATY,Rage128n ATY,Rage128o ATY,Rage128v qemu-system-ppc -M mac99 -m 512 -hda '/home/jam/os9/os9.img' -device ati-vga -prom-env 'vga-ndrv?=false' -display sdl -prom-env 'boot-args=-v romndrv=1' -prom-env 'auto-boot?=false' -bios '/home/jam/openbios-qemu.elf' -prom-env "aapl,debug=3013FFF" -trace enable="ati" -trace enable="pci" -serial stdio qemu-system-ppc: -trace enable=ati: warning: trace event 'ati' does not exist qemu-system-ppc: -trace enable=pci: warning: trace event 'pci' does not exist >> ============================================================= >> OpenBIOS 1.1 [Jul 14 2019 16:58] >> 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. >> switching to new context: Nanodebugger activated. Init ready queue 00000000 00000000 00019603 Init ready queue 00000001 00000000 000cb018 Init ready queue 00000002 00000000 006580c0 Init ready queue 00000003 00000000 032c0600 System context at 0x1f7ff100 Vector save area at 0x1f7fb880 SDR1 0x1f80003f Adding blue task 00050001 to the ready queue Starting timeslicing Adding idle task 00070001 to the ready queue NKCreateAddressSpaceSub - group at 0x1f7fc1c0 00010001 Priming the system free list with 81 pages. VMMaxVirtualPages: 0005fffe VMLogicalPages: 00000000 Interrupt handler kind: 06 Converting PMDTs to areas CreateArea [ 00000000 1f7c2fff ] ID 000a0001 placed ... created CreateArea [ 5fffe000 5fffefff ] ID 000b0001 placed ... created CreateArea [ 64000000 6417ffff ] ID 000c0001 placed ... created CreateArea [ 68fef000 68feffff ] ID 000d0001 placed ... created CreateArea [ 68ff5000 68ffefff ] ID 000e0001 placed ... created CreateArea [ 68fff000 68ffffff ] ID 000f0001 placed ... created CreateArea [ 80000000 8fffffff ] ID 00100001 placed ... created CreateArea [ f0000000 ffffffff ] ID 00110001 placed ... created CreateArea [ 68f16000 68f16fff ] ID 00120001 placed ... created CreateArea [ deadb000 deadbfff ] ID 00130001 placed ... created Reset system - Into the 68K fire: 0000d032 6806e8c0 ResetSystem trap entered Kernel code base at 0x00f10000 Physical RAM size 0x1fffc000 bytes Created motherboard coherence group. ID 00010001 NKCreateAddressSpaceSub - group at 0x1f7fc1c0 00010001 Created system address space. ID 00030001 BATs ffc0007f 00c00043 6800001f 00f00043 00000000 00000000 00000000 00000000 Nanodebugger activated. Init ready queue 00000000 00000000 00019603 Init ready queue 00000001 00000000 000cb018 Init ready queue 00000002 00000000 006580c0 Init ready queue 00000003 00000000 032c0600 System context at 0x1f7ff100 Vector save area at 0x1f7fb880 SDR1 0x1f80003f Adding blue task 00050001 to the ready queue Starting timeslicing Adding idle task 00070001 to the ready queue NKCreateAddressSpaceSub - group at 0x1f7fc1c0 00010001 Priming the system free list with 81 pages. VMMaxVirtualPages: 0005fffe VMLogicalPages: 0001f7c3 Interrupt handler kind: 06 Converting PMDTs to areas CreateArea [ 00000000 1f7c2fff ] ID 000a0001 placed ... created CreateArea [ 5fffe000 5fffefff ] ID 000b0001 placed ... created CreateArea [ 64000000 6417ffff ] ID 000c0001 placed ... created CreateArea [ 68fef000 68feffff ] ID 000d0001 placed ... created CreateArea [ 68ff5000 68ffefff ] ID 000e0001 placed ... created CreateArea [ 68fff000 68ffffff ] ID 000f0001 placed ... created CreateArea [ 80000000 8fffffff ] ID 00100001 placed ... created CreateArea [ f0000000 ffffffff ] ID 00110001 placed ... created CreateArea [ 68f16000 68f16fff ] ID 00120001 placed ... created CreateArea [ deadb000 deadbfff ] ID 00130001 placed ... created Reset system - Into the 68K fire: 0002d032 6806c9e8 CPU plugin registered ati_vga_switch_mode: 0 -> 1 ati_mm_write: Display enabled ati_vga_switch_mode: 1 -> 1 ati_mm_write: Display enabled ati_vga_switch_mode: 1 -> 1 ati_vga_switch_mode: 1 -> 0 ati_vga_switch_mode: 0 -> 0 ati_vga_switch_mode: 0 -> 1 qemu-system-ppc: /home/jam/aty/qemu/hw/display/ati.c:88: ati_vga_switch_mode: Assertion `bpp != 0' failed. Aborted > On Jul 20, 2019, at 6:57 AM, BALATON Zoltan <balaton(a)eik.bme.hu> wrote: > > On Fri, 19 Jul 2019, Jd Lyons wrote: >> Ok I enabled ati debuging and with an ‘NDRV’ loaded I get: >> >> ATI_vga_switch_mode 0 > 1 > > This just means the driver has enabled extended mode as opposed to VGA mode but this could also happen through OpenBIOS using VBE extension so only those are really the driver that happen after the Swtiching to new context message from OpenBIOS (maybe use -serial stdio to see these in your log). More interesting are the Switching to mode messages that tells what the emulation thinks what mode the driver has programmed the CRTC. This can be cross checked by seeing the register writes before that and decoding it from the docs. Those I've checked so far looked good but I don't think I've verified MacOS yet. > >> I noted this is in the ati.c but I only understand some of it( 15bit mode???, never saw that before;-) > > 15 bpp is just RGB555, it's stored in 16 bits but one bit is unused as opposed to RGB565 where the G component gets the additional bit. Maybe MacOS does not tell this difference and just says 16 bit mode but uses RBG555 internally? > >> Under OS 9 I get the error just after we jump into the 68k fire( right about the point it would draw the Happy Mac to the screen, booting continues, the CPU Plugin is registered and we get to count 9, and booting halts, normally to get to the desktop we would get to count 14 in the Nano Kernel log. >> >> Under OS X I see: >> >> >> ATI_vga_switch_mode 0 > 1 >> >> Just before >> >> ATY: not usable > > This is interesting, maybe we can try to find the condition where it decides it's not usable and see why it thinks so. Is this from an open source part of the kernel or from closed source driver? > >> I see that where we would see: >> ATY: vram [8100000:0100000] >> >> So something we are doing in ATI_vga_switch_mode isn’t working the way we need it to for the Mac OS, I’m just not sure what that would be? > > I'm not sure it's the mode switching part which is wrong here (although could be). But if the driver decides it does not like the card before it tries to switch mode or it expects the FCode to already set up the mode then it's not a problem in ati_vga_switch_mode but that the emulated card is not in a state expected by the driver. I think that's more likely, that's why I'm trying to get the FCode run to have it work the same way as on real hardware and see if that makes it any better. But there are still some work on OpenBIOS to get to that point. > > Regards, > BALATON Zoltan

2 3

[PATCH 00/28] pci: build device tree from root
by Mark Cave-Ayland 20 Jul '19

20 Jul '19

This patchset started off with the aim of building the PCI-based machine device trees downwards from the root node to avoid switching either the active package and/or current instance at various points during the tree construction. The basis for this was to try and remove all named nodes (those which are placed at a given path) and instead build the hierarchy in order by using new-device and finish-device as per the IEEE-1275 specification. This was realised by creating a new BIND_NODE_METHODS() macro which is similar to REGISTER_NAMED_NODE() except that it doesn't alter either the active package or the current instance, and then working through the device tree from the root converting all the devices for the PCI-based machines to use it. Once this conversion has been completed for all devices beneath the PCI node, it becomes possible to remove both the REGISTER_NAMED_NODE() and REGISTER_NAMED_NODE_PHANDLE() macros to prevent future patches from accidentally changing the tree construction order. Next the x86, PPC and SPARC64 device tree roots were altered to set the active package and current instance, allowing the remaining places where the PCI code alters either of them to be removed. At this point instance variables were working correctly, and I noticed that there were several PCI devices which made use of C initialisation functions and/or properties for initial configuration. These can now be replaced with instance variables to keep everything simple and consistent. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Mark Cave-Ayland (28): libopenbios: introduce BIND_NODE_METHODS() macro pc_kbd: convert to use BIND_NODE_METHODS() macro pc_serial: convert to use BIND_NODE_METHODS() macro floppy: convert to use BIND_NODE_METHODS() macro ide: convert to use BIND_NODE_METHODS() macro adb: convert to use BIND_NODE_METHODS() macro escc: convert to use BIND_NODE_METHODS() macro cuda: convert to use BIND_NODE_METHODS() macro macio: convert to use BIND_NODE_METHODS() macro pmu: convert to use BIND_NODE_METHODS() macro usbhid: convert to use BIND_NODE_METHODS() macro nvram: convert to use BIND_NODE_METHODS() macro lsi: don't change active package when setting device alias lsi: convert to use BIND_NODE_METHODS() macro virtio: convert to use BIND_NODE_METHODS() macro pci: convert to use BIND_NODE_METHODS() macro pci: remove ob_pci_initialize() and ob_pci_empty_node libopenbios: remove REGISTER_NAMED_NODE and REGISTER_NAMED_NODE_PHANDLE macros ppc: move New World uninorth and nvram device node creation to the root device ppc: set active package and current instance to root device node before probe SPARC64: set active package and current instance to root device node before probe x86: set active package and current instance to root device node before probe pci: remove explicit find-device from PCI devices pci: remove explicit setting of my-self from PCI devices pc_serial: remove separate init word pc_kbd: use instance value to initialise C instance parameter lsi: use instance value to hold sd_private_t pointer virtio: use instance value to initialise C instance parameter arch/ppc/qemu/init.c | 13 +++ arch/sparc64/openbios.c | 6 ++ arch/x86/openbios.c | 9 +- drivers/adb_bus.c | 57 +++++++----- drivers/adb_kbd.c | 25 ++++-- drivers/adb_mouse.c | 31 ++++--- drivers/cuda.c | 158 ++++++++++++++++++++------------- drivers/escc.c | 113 ++++++++++++++--------- drivers/floppy.c | 68 +++++++------- drivers/ide.c | 123 +++++++++++++++---------- drivers/lsi.c | 65 +++++++------- drivers/macio.c | 117 ++++++++++++------------ drivers/macio.h | 1 - drivers/pc_kbd.c | 48 +++++----- drivers/pc_serial.c | 32 +++---- drivers/pci.c | 102 +++++++-------------- drivers/pmu.c | 152 +++++++++++++++++++++---------- drivers/usbhid.c | 16 ++-- drivers/virtio.c | 49 +++------- include/drivers/drivers.h | 2 + include/libopenbios/bindings.h | 19 ++-- include/packages/nvram.h | 4 +- libopenbios/bindings.c | 10 +++ packages/nvram.c | 32 ++++++- 24 files changed, 722 insertions(+), 530 deletions(-) -- 2.20.1

1 28

set package unit in forth
by BALATON Zoltan 19 Jul '19

19 Jul '19

Hello, I'm trying to port fdt unflattening from SLOF to OpenBIOS but need some help with understanding and implementing equivalent forth words, The SLOF fdt.fs uses set-unit which is defined in https://github.com/aik/SLOF/blob/master/slof/fs/node.fs : set-space get-node dup >r node>space ! true r> node>space? ! ; : set-address my-#address-cells 1 ?DO get-node node>space i cells + ! LOOP ; : set-unit set-space set-address ; These set the unit address manipulating the fields of the node struct as far as I understand. But I don't know how to do the same in OpenBIOS. OpenBIOS implements the word that returns these values that set-unit is supposed to change in https://github.com/openbios/openbios/blob/master/forth/device/package.fs#L1… as : my-unit ( -- phys.lo ... phys.hi ) ?my-self >in.my-unit my-#acells tuck /l* + swap 0 ?do /l - dup l@ swap loop drop ; but I don't understand how these are stored in OpenBIOS and how to change them. Could somone who understands forth or know OpenBIOS more suggest an implementation of set-unit for OpenBIOS please? We'll also need set-node which sets active-package I think so suggestions for that are also welcome. Thank you, BALATON Zoltan

2 3

← Newer
1
...
6
7
8
9
10
11
12
...
429
Older →

Jump to page: