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