On Tue, 23 Jul 2019, BALATON Zoltan wrote:
On Tue, 23 Jul 2019, BALATON Zoltan wrote:
On Sun, 21 Jul 2019, BALATON Zoltan wrote:
On Sun, 21 Jul 2019, Mark Cave-Ayland wrote:
On 21/07/2019 15:16, BALATON Zoltan wrote:
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.
This comes from open-dev calling (path-resolution) which calls invoke-open which ends up in the vga.fs FCode that maps these bars. This probably should not happen for ati-vga but OpenBIOS does that for all VGA devices.
I've experimented with the pci-map-in forth implementation I've posted last but it fails when called from open-dev like above because decode-phys seems to return only addr.hi in this case instead of the lo, mid, hi triplet. No idea why is that or how to find out what did decode-phys returned as apparently it returns different number of values depending on how or when it's called.
decode-phys returns only 1 address becuase my-#acells returns 1 instead of 3 when that happens but I don't know why.
my-#acells looks at my-self or active-package so probably my-self is not what I expected but I don't know how to verify it. How to get the number of a node that is to be put to my-self when open-dev is not working (as I'm trying to debug that right now)? The call-package word that is called from $call-parent seems to set my-self and also the path-resolution called from open-dev messes with it so I can't follow what's happening and why my pci-map-in word gets only one addr from decode-phys when called as the map-in method (while gets lo,mid,hi when called directly last time I tested). Is my-self the /pci node in this case so I should use something else instead of decode-phys here?
Is there anyone who actually understands anything about this here to at least give me some hint if I'm going in the right direction at all with this?
Regards, BALATON Zoltan