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.
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.
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 <balaton@eik.bme.hu> 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 )
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 <balaton@eik.bme.hu> 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 <balaton@eik.bme.hu>
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 -- openbios@openbios.org To unsubscribe send an email to openbios-leave@openbios.org
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 <balaton@eik.bme.hu> 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 <balaton@eik.bme.hu>
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 -- openbios@openbios.org To unsubscribe send an email to openbios-leave@openbios.org
On Mon, Jul 29, 2019 at 11:58 AM Jd Lyons via OpenBIOS < openbios@openbios.org> 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 -- openbios@openbios.org To unsubscribe send an email to openbios-leave@openbios.org
OpenBIOS mailing list -- openbios@openbios.org To unsubscribe send an email to openbios-leave@openbios.org
Yes, I had the same issue when copying the patch from: https://mail.coreboot.org/hyperkitty/list/openbios@openbios.org/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
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
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
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
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
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
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
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.
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
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/openbios@openbios.org/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
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/openbios@openbios.org/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.
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
participants (5)
-
BALATON Zoltan -
Howard Spoelstra -
Jd Lyons -
Mark Cave-Ayland -
Segher Boessenkool