quoted

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