Re: Reverse engeneering the SMU (iMac G5, newer single-pro G5)
> 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?
No, the 3 last ones unfortunately. The first one is the only one whose
code is available. I suppose pestering apple to release them would be
useless... they "removed" the PMU driver from open source darwin a while
ago and never bothered explaining why nor replying to my requests.
The problem with the SMU is that unlike the PMU for which there was a
driver opensource in the past (even one in MkLinux) and that is old
enough to be a well known beast, the SMU is brand new and never had an
open driver. We did figure out some stuffs already from the OF driver,
but far from everything is there.
> > 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?
Yes.
> The
> architectures are probably too different. Otherwise I'll try to find a
> friendly colleague to get me an account on his machine...
No, they aren't too different. OS X is running the same kernel binary on
both you know :)
> > 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].
Nope.
> 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
Hehe :) I prefer not commenting publically on what IBM pays me to do and
what not :)
> 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
> > >
> > >
>
>
--
Benjamin Herrenschmidt <benh@kernel.crashing.org>
Reply to: