Re: Reverse engeneering the SMU (iMac G5, newer single-pro G5)
Hello Franck,
thanks a lot for your help proposal. Just to give you an idea of what I
know and I don't: the last assembly programming I did was on a 8 bit Z80
years ago (I guess I could reuse this knowledge today to program
dishwasher and coffee machines :-). So far, I've worked my way through
the ppc code I've looked at using Motorola's ppc manual [1].
[1] http://www.freescale.com/files/product/doc/MPCFPE32B.pdf
My hope was to get an idea of the structure of Apple's code (who is
calling what etc). Maybe there is no real need for that, as, as you've
said, symbol names are often clear enough to spot basic functions. What
do you think?
Francois
On Fri, 2005-04-15 at 10:17, Franck Stauffer wrote:
> Hi,
>
> I looked at the AppleSMU.kext's assembly a while ago when the original
> patch bringing basic shutdown/reboot (and other stuff i don't
> remember...it's the patch that ben says he has cleaned up) was posted.
> You can easily see the sections with the equivalent commands in that
> kext...I haven't started looking at the next two ones and but i'd be
> glad to help you as much as I can.
>
> Franck
>
>
>
> Le 15 avr. 05, à 10:52, Francois a écrit :
>
> > 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
> >>>
> >>>
> >
> >
> > --
> > To UNSUBSCRIBE, email to debian-powerpc-REQUEST@lists.debian.org
> > with a subject of "unsubscribe". Trouble? Contact
> > listmaster@lists.debian.org
> >
> >
Reply to: