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.
Regards, BALATON Zoltan