I think cereal is what reads the SPD (Serial Presence Detect) i2c chip 
on the RAM modules. That is just off the top of my head though, 
probably wrong.

On Dec 12, 2004, at 12:26 PM, Michael wrote:

> Hello,
>
>>> That said, Apple laptops have more thermal sensors than the one on 
>>> the
>>> CPU, so finding them (probably i2c devices with OFW entries 
>>> somewhere)
>>> and adding them to envsys would be a nice little project.
>> I added a quick hack to ki2c.c to scan for devices but either I'm 
>> doing something wrong, the code doesn't really work for some
>> reason or there are no devices connected. ( 12" iBook G4 )
>> The first one seems to be the most probable though :)
>
> ofdump2 should be included in the base macppc distribution :)
> It seems to show three i2c buses in my iBook:
>
> /uni-n@f8000000/i2c@f8001000:
> ff95d178:       /fan@15c
> ff95e7c8:       /i2c-hwclock@1d2
> ff95fdd0:       /cereal@1c0
>
> /pci@f2000000/mac-io@17/via-pmu@16000/pmu-i2c
> with no children
>
> /pci@f2000000/mac-io@17/i2c@18000:
> ff977af0:         /cereal@1c0
> ff978268:         /deq@6a
> ff9c91a8:         /i2c-modem
>
> So, which one does ki2c attach to? via-pmu@16000 or i2c@18000 ? Since 
> it attaches to obio is should be i2c@18000 but then I should see a 
> device at 6a - or deq doesn't support reading. So I'll try to figure 
> out how extended i2c addressing works with ki2c and see if there's 
> anything at 1c0
>
> the properties for /uni-n@f8000000/i2c@f8001000 contain
> name                    69326300 ........ ........ ........   "i2c"
> device_type             69326300 ........ ........ ........   "i2c"
> reg                     f8001000 00001000 ........ ........   ........
> compatible              6b657977 6573742d 69326300 ........   
> "keywest-i2c"
>
> fan@15c has interesting properties:
> reg                     0000015c ........ ........ ........   ...\
> hwsensor-params-version 00000001 ........ ........ ........   ....
> hwsensor-id             00000000 00000001 00000002 00000010   
> ................
>             0010:       00000020 ........ ........ ........   ...
> hwsensor-zone           00000000 00000000 00000000 00000000   
> ................
>             0010:       00000000 ........ ........ ........   ....
> hwsensor-type           74656d70 65726174 75726500 74656d70   
> temperature.temp
>             0010:       65726174 75726500 74656d70 65726174   
> erature.temperat
>             0020:       75726500 766f6c74 61676500 66616e73   
> ure.voltage.fans
>             0030:       70656564 00...... ........ ........   peed.
> hwsensor-location       5057522f 4d454d4f 52592042 4f54544f   
> PWR/MEMORY BOTTO
>             0010:       4d534944 45004350 5520424f 54544f4d   
> MSIDE.CPU BOTTOM
>             0020:       53494445 00475055 204f4e20 44494500   SIDE.GPU 
> ON DIE.
>             0030:       43505520 434f5245 00524541 52204d41   CPU 
> CORE.REAR MA
>             0040:       494e2045 4e434c4f 53555245 00......   IN 
> ENCLOSURE.
> hwsensor-polling-period 00000005 00000005 00000005 00000005   
> ................
>             0010:       00000005 ........ ........ ........   ....
> hwctrl-params-version   00000001 ........ ........ ........   ....
>
> Hey, seems to be exactly what we're looking for :)
>
> /pci@f2000000/mac-io@17/i2c@18000:
> compatible              6b657977 6573742d 69326300 ........   
> "keywest-i2c"
> AAPL,address            80018000 ........ ........ ........   ....
>
> so it /is/ a different one.
>
> /cereal@1c0
> reg                     000001c0 ........ ........ ........   ....
> name                    63657265 616c00.. ........ ........   "cereal"
> device_type             73657269 616c00.. ........ ........   "serial"
>
> Hmm, doesn't tell us anything.
>
> /deq@6a
>
> name                    64657100 ........ ........ ........   "deq"
> device_type             64657100 ........ ........ ........   "deq"
> reg                     0000006a ........ ........ ........   ...j
> i2c-address             0000006a ........ ........ ........   ...j
>
> even less informative.
>
> So, in theory I only need to get ki2c to attach to uninorth's i2c 
> child - since OF says it's also a keywest - and then try to talk to 
> device 15c :)
> Ok, after that it's some gruntwork to put the sensor stuff into its 
> own driver that attaches to keywest ( or better its i2c bus ) - 
> shouldn't be too hard since OF tells us where to look for devices.
>
> Tim - I didn't forget about the interrupt problems but I can't 
> reproduce them so I need to wait for reports from others. Experience 
> shows that it usually helps to do something else when you're stuck and 
> look at it later with a different mindset.
>
> have fun
> Michael