Benjamin Herrenschmidt wrote: >>> Good point. I can't even guarantee that the kernel will work reliably >>> with nobats :-) At least you really want the kernel .text to be fully >>> covered by an IBAT. >>> >> It works with nobats. > > But does it work -reliably- ? :-) >
It does AFAICT. My Wii is a 24x7 linux box although it is not stressed in any way usually. > Any ways, not a big deal right now, as I said, we really want the BATs > for performances anyways, so we should probably just add some kind of > hack in mmu_mapin_ram() for the time being. > Yup. The idea is to map the first 16MB of MEM1 with a BAT. Mapping the whole 24MB with BATs may not be possible because we want the framebuffer in MEM1 for performance reasons. >> I must say that all the patches posted (and the device drivers, which haven't >> been posted yet) are tested and working code. > > That was my impression too, but in this case, I'm talking about a > potential very hard to hit problem that you may well have never managed > to actually trigger. > I haven't actually, if that applies :) >> 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. > Totally agreed. > 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 can be discussed later tho. I'm not that keen on having those info > be in the .dts coming with the kernel since those functions essentially > depend on what FW is loaded on the aux. processor. > I think we can leave this for later as you said. > 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 :-) Then you > can have the boot wrapper or the kernel platform init code use some well > defined (and as stable as possible) IPC API to identify the FW there and > expose all that stuff. > Segher was playing with an OF implementation... > 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 ? Can we > detect what is running there ? Do we care ? > Yes, it can. And it is done. But I think we don't care/need that in mainline. >> It is what Nintendo calls the "Serial Interface" (SI) which is a proprietary >> serial hardware to drive the gamepads (and a custom keyboard too, once >> available >> for an RPG game). > > So I would give it a different name than "serial" then. Make it gpsi > maybe ? (game pad serial interface ?) :-) Or invent something else... > I'd choose "gcnsi" with a compatible like "nintendo,gamecube-si" :) (gcn is the official short abbreviation for the Nintendo GameCube) > Cheers, > Ben. > Thanks, Albert _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
