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