There you can find the hardware interface that supports the IPC
mechanism.
It is made up of a pair of registers to pass data between the
processors and a
pair of control/flags registers.
The hardware can interrupt the PowerPC side when there is data
available for it.
Ok. So the right way to do that would be to have a node purely
representing the HW IPC, unrelated to whatever is running on the
secondary processor.
Or you can keep it implicit in the Hollywood control registers.
It is one 512-byte block with lots of things thrown together (and
then mixed up real good).
However, it's ok to have -below- that node, a set of device nodes or a
node with properties or whatever representing the FW in there and the
function it exposes.
That's not really useful though, it's easy to probe for.
What might do however is to have a way for that FW itself to
provide you
with the nodes and properties for the functions it provides :-)
You get a pointer at the very last word of memory. It point to an
info header that has everything you need to know (most importantly,
a version identifier).
Of course that wouldn't work with FW we don't have control on. Can
Linux
run on the wii with the original N. FW on the aux. processor ?
It _can_, but there are no advantages to doing that, and lots and
lots of
disadvantages, so the plan is to not add support for that in mainline.
Can we
detect what is running there ? Do we care ?
You can detect this for anything that uses a mini-compatible interface.
You shouldn't care for anything else ;-)
Segher
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
