On Sun, 14 Jul 2019, Mark Cave-Ayland wrote:
On 13/07/2019 21:34, BALATON Zoltan wrote:
I think we can conclude that it gets exception because all the words it tries to use: map-in, config-b@, config-b! are missing in OpenBIOS so it can't really work and likely trips on map-in already.
Right. Certainly words like my-parent won't work in FCode for PCI devices until I finish work getting the PCI ihandle instance chain fixed up, and as JD mentioned before, the PCI config words aren't yet implemented but should be fairly trivial.
Now this is a separate problem to what's discussed in previous message. That one was about porting SLOF's fdt.fs to use in OpenBIOS, this one is about running an ATI FCode ROM to test QEMU ati-vga emulation with MacOS. Sorry if this was confusing, hope this is now cleared.
I might be able to try to implement config-* words based on the config-l you've added but not sure if these should all call back to C or should we base them on config-l or config-b or some other generic C helper in Forth? For reading bytes one could do config-l@ then extract the needed byte somehow (need to find the forth for that) but for storing we may be better off with a helper otherwise we need to 'config-l@ modify-it config-l!' if we only have config-l! or if we base it on config-b! then we need to do multiple of these for config-l so C helpers or a generic one like do_config_{read,write}(addr, size) might be simpler. I should check how other open firmware implementation do this in forth (although probably I won't understand it). Do you think it's worth trying to do in Forth or should I try to do that in pci.c?
I don't understand map-in map-out enough to try to implement those so I'll need some help with that. I've seen there are pci-map-in and dma-map-in but this is plain map-in which is probably different. I think it should make a phys addr accessible in forth by assigning a virt addr to it. It we have virt == phys then this should be simple do nothing. If so we may try with : map-in 2drop ; or something similar?
In the meantime we've managed to run the FCode ROM in SLOF but data sent to the device turned out byte swapped so not sure if SLOF does something differently or Apple's OpenFirmware.
Regards, BALATON Zoltan