On 21/07/2019 11:11, BALATON Zoltan wrote:
On Sun, 21 Jul 2019, Mark Cave-Ayland wrote:
On 20/07/2019 17:36, BALATON Zoltan wrote:
0 > my-unit? ok 3 > . 7800? ok 2 > . 0? ok 1 > . 0? ok 0 > my-space . 0? ok
^ this is still wrong, should be 7800
0 > my-address . . 0 0? ok 0 > my-address h# 1000014 h# 7800 + h# 100? ok 4 > .s <4> 0 0 1007814 100 ?ok 4 > " map-in" $call-parent
ob_pci_bar_map_in idx=1fc5ac54 ob_pci_map: ba=0x00000000 size=256 ob_pci_map: after decode flags=0x0 space_code=0x2 mask=0xf pci_bus_addr_to_host_addr: space=0x2 ba=0x00000000 ob_pci_map: phys=0x00000000 size=256
?ok
I had a fresh read of the relevant parts of the IEEE-1275 specification this morning and the fallback behaviour related to the reg property I was looking at is only related to my-unit, i.e. after the package has been created. So yes, even with the new code we still need an explicit set-args in there since this is the only thing that can set the probe address which is used for my-space and my-address.
I'm not sure what fallback you mean here but referring to my previous message regarding this:
On Fri, 19 Jul 2019, BALATON Zoltan wrote:
On Mon, 15 Jul 2019, Segher Boessenkool wrote:
my-address is two zeroes for configuration space addresses. But my-space shouldn't be zero, it's 7800 here. my-unit should be exactly identical to my-address my-space , but it isn't for you?
So you say it should be
: my-unit my-address my-space ;
but in OpenBIOS we have (in forth/device/package.fs):
\ \ 5.3.4.3 Get local arguments \
: my-address ( -- phys.lo ... ) ?my-self >in.device-node @ >dn.probe-addr my-#acells tuck /l* + swap 1- 0 ?do /l - dup l@ swap loop drop ;
: my-space ( -- phys.hi ) ?my-self >in.device-node @ >dn.probe-addr @ ;
: my-unit ( -- phys.lo ... phys.hi ) ?my-self >in.my-unit my-#acells tuck /l* + swap 0 ?do /l - dup l@ swap loop drop ;
my-unit seems to get the info from a different place (>in.my-unit vs. > dn.probe-addr) here. Why is that?
Why isn't my-unit is just my-address my-space and how can these return different values? Should these values be stored on the same place and all of these words get it from that one place? Apparently not there are several places these are stored and the problem is that they get out of sync isnt'it?
I'm not sure what you mean about returning different values? At least with my patchset and this morning's patch applied they both looks the same here:
0 > " /pci/usb" open-dev to my-self ok 0 > my-unit ok 3 > u. 6800 ok 2 > u. 0 ok 1 > u. 0 ok 0 > my-address ok 2 > my-space ok 3 > u. 6800 ok 2 > u. 0 ok 1 > u. 0 ok
Segher's comment about my-unit is an implementation detail rather than a definition from the specification, so I wouldn't worry about this. Given that the above looks correct I'd say it's time to move on to the PCI mapping as per the outline given in my previous email.
ATB,
Mark.