Re: Reverse engeneering the SMU (iMac G5, newer single-pro G5)
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: