Re: Reverse engeneering the SMU (iMac G5, newer single-pro G5)
All,
thanks a lot for your much appreciated feedback.
> Great ! time to get a proper driver for it :)
Well, driver coding is uncharted water to me. If I can do anything even
remotely useful I'll be more than happy :-).
> You may also want to keep in touch with Markus Demleitner
> <msdemlei@cl.uni-heidelberg.de> who got some basic fan control working
> after looking at the forth OF code. I append some of his code below.
Will do!
> Note that the source code for the Neo2 platform plugin _is_ available in
> Darwin. What is not is the AppleSMU driver.
When I do a 'find . -type f -name "*SMU*"' in /System, here is what I get:
./Library/Extensions/AppleMacRISC4PE.kext/Contents/PlugIns/SMU_Neo2_PlatformPlugin.kext/Contents/MacOS/SMU_Neo2_PlatformPlugin
./Library/Extensions/AppleSMU.kext/Contents/MacOS/AppleSMU
./Library/Extensions/AppleSMUMonitor.kext/Contents/MacOS/AppleSMUMonitor
./Library/Extensions/IOI2CControllerSMU.kext/Contents/MacOS/IOI2CControllerSMU
Is AppleSMU the only lib whose code is not available?
> This is a C++ method call via vtable.
> [..]
> No, the constan t here is meaningless I'm afraid. I think in the above
> case, r3 is an object pointer, r2 gets loaded with the vtable pointer,
> and r12 is the method pointer extracted from the vtable. Unfortunately,
> I don't know how to decrypt those things more than that. What you might
> want to do is to hook 2 machines in OS X if you have access to 2 of
> course and use Apple's kgdb over network to step through the kext and
> see what it ends up calling...
Knowing it's C++ is already a start! I've got a G4 (powerbook). Do you
think Apple's kgdb would be able to tap from my G4 into the G5? The
architectures are probably too different. Otherwise I'll try to find a
friendly colleague to get me an account on his machine...
> Yah, well, I'm still working for the iMac G5 ... I've done some cleanup
> work on the initial driver written by somebody else but haev no HW to
> play with yet. An iMac G5 was delivered to IBM a while ago but ended up
> beeing dead on arrival, so I'm waiting for Apple to send a new one ..
Ah! The contingencies of the snail mail... Incidentally have you seen
IBM's report on power/thermal measurements in the G5 under Linux? [1].
They explicitly mention you and the therm_pm72 driver code. Maybe you
could get some funding to program an SMU driver during your work hours
[just joking here] :-)
[1]http://domino.watson.ibm.com/library/cyberdig.nsf/papers/E6EBD3C859FB49F785256ED8006A3F4A/$File/rc23276.pdf
Francois
On Fri, 2005-04-15 at 00:59, Benjamin Herrenschmidt wrote:
> On Thu, 2005-04-14 at 13:48 +0100, Francois wrote:
> > Hi all,
> >
> > I don't know if this is the right place to ask this question, but I
> > don't know of any others, so here it goes:
> >
> > One of the last critical things missing on my G5 to run Debian is fan
> > control. To see if I could help understand how it works under Darwin, I
> > tried to have a look at the corresponding libraries (the whole thing is
> > called SMU, System Management Unit, a replacement for the older PMU
> > system).
>
> Hi !
>
> Great ! time to get a proper driver for it :)
>
> You may also want to keep in touch with Markus Demleitner
> <msdemlei@cl.uni-heidelberg.de> who got some basic fan control working
> after looking at the forth OF code. I append some of his code below.
>
> > With 'otool' (disassembling), some ad-hoc awk scripts, and dot (graph
> > layout), I now get this kind of call graph:
> >
> > http://ftaiani.ouvaton.org/ressources/SMU_Neo2_PlatformPlugin-exemple.ps
>
> Note that the source code for the Neo2 platform plugin _is_ available in
> Darwin. What is not is the AppleSMU driver.
>
> (The Neo2 stuff is along with other plugins in the AppleMacRISC4PE
> project)
>
> > In this graph A->B means the code for A contains an 'jbsr B,0xfoo'
> > instruction (jump pseudo instruction). I've interpreted it as being a
> > call from A to B. My knowledge of PPC assembly is pretty limited, so
> > this might be wrong.
> >
> > There are far more branching instructions than don't use jbsr, but I
> > don't know how to interpret them. For instance:
> >
> > ---
> > lwz r2,__ZN23SMU_Neo2_PlatformPluginC2EPK11OSMetaClass(r3)
> > lwz r12,0x368(r2)
> > mtspr ctr,r12
> > bctrl
> > ---
>
> This is a C++ method call via vtable.
>
> > Looks like a jump to __ZN23SMU_Neo2_PlatformPluginC2EPK11OSMetaClass (is
> > this right?).
>
> No, the constan t here is meaningless I'm afraid. I think in the above
> case, r3 is an object pointer, r2 gets loaded with the vtable pointer,
> and r12 is the method pointer extracted from the vtable. Unfortunately,
> I don't know how to decrypt those things more than that. What you might
> want to do is to hook 2 machines in OS X if you have access to 2 of
> course and use Apple's kgdb over network to step through the kext and
> see what it ends up calling...
>
> > The above graph is an extract of the whole picture (I've used a small
> > graph manipulation tool). Showing all symbols just yields a big crammed
> > graph.
> >
> > My problem is that I can't make much sense of it. I also wonder whether
> > it can actually be of any use to understand the SMU (I know Ben
> > Herrenschmidt is working on it). In particular, I suspect that some
> > symbol entangling is at work:
>
> Yah, well, I'm still working for the iMac G5 ... I've done some cleanup
> work on the initial driver written by somebody else but haev no HW to
> play with yet. An iMac G5 was delivered to IBM a while ago but ended up
> beeing dead on arrival, so I'm waiting for Apple to send a new one ..
>
> > __ZN23SMU_Neo2_CPUFanCtrlLoop13acquireSampleEv
> >
> > looks like the method 'acquireSampleEv' of some object
> > '__ZN23SMU_Neo2_CPUFanCtrlLoop'. Maybe '__ZN23SMU_Neo2_' is also some
> > kind of name space.
> >
> > Would someone more knowledgeable than me in the Mac-O object format know
> > how to interpret such symbol names? Also would someone know how to
> > extract more information from the assembly code that only the jbsr
> > jumps?
> >
> > Many thanks for your help!
> >
> > Francois
> >
> >
Reply to: