On Sat, 2006-07-29 at 12:53 -0500, Richard Smith wrote:
You are in luck. I've actually got booting code for my ASUS P2b. Both
My main question is: The W83977TF has support under v1, but not v2 - any tips on porting from one to the other?
I've done this already. I'll push the code up in a few hours or so. Its on a machine I don't have local access to right now.
I just committed my framework for the Asus P2B. Hopefully it works for you. It should come up and try to dump the contents of the SPD on the RAM. But like I said its broken even without the Asus magic. I'm going to try and work on that today and see if I can discover something.
So step one for P2B is to work with the board booted under factory BIOS and see if we can figure out what GPIO is used to enable the memory SMbus.
2.6 kernels know how to dump the SPD for a i440bx so see if you can do that. If that works then we just need to start comparing a northbridge dump of the Asus vs a non-asus 440bx and see if any of the GPIO are different.
Thanks for your help on this, Richard!
This took a little longer than I expected due to my son's fourth birthday and having to change the p2b configuration to output via the second serial port (my board's first serial port has been flaky in the past), but I'm getting some results.
Here's what I get from i2cdump 0 0x5{0-3} under Linux running with the factory BIOS:
[root@matthias ~]# i2cdump 0 0x50 No size specified (using byte-data access) WARNING! This program can confuse your I2C bus, cause data loss and worse! I will probe file /dev/i2c-0, address 0x50, mode byte Continue? [Y/n] 0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef 00: 80 08 04 0c 0a 02 48 00 01 a0 60 02 80 08 08 01 ??????H.??`????? 10: 07 04 04 01 01 1f 0e 00 00 00 00 14 14 14 32 20 ???????....???2 20: 20 10 20 10 00 00 00 00 00 00 00 00 00 00 00 00 ? ?............ 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 12 be ..............?? 40: 7f 98 00 00 00 00 00 00 46 4b 47 4d 31 30 30 78 ??......FKGM100x 50: 37 32 52 43 33 2f 32 35 36 00 00 00 00 01 26 18 72RC3/256....?&? 60: 1a f2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ??.............. 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 64 84 ..............d? 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ f0: 39 39 36 32 32 32 38 2d 30 30 31 2e 41 30 30 ff 9962228-001.A00.
[root@matthias ~]# i2cdump 0 0x51 No size specified (using byte-data access) WARNING! This program can confuse your I2C bus, cause data loss and worse! I will probe file /dev/i2c-0, address 0x51, mode byte Continue? [Y/n] 0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef 00: 80 08 04 0c 0a 02 48 00 01 a0 60 02 80 08 08 01 ??????H.??`????? 10: 07 04 04 01 01 1f 0e 00 00 00 00 14 14 14 32 20 ???????....???2 20: 20 10 20 10 00 00 00 00 00 00 00 00 00 00 00 00 ? ?............ 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 12 be ..............?? 40: 7f 98 00 00 00 00 00 00 46 4b 47 4d 31 30 30 78 ??......FKGM100x 50: 37 32 52 43 33 2f 32 35 36 00 00 00 00 01 23 18 72RC3/256....?#? 60: 04 25 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ?%.............. 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 64 84 ..............d? 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
[root@matthias ~]# i2cdump 0 0x52 No size specified (using byte-data access) WARNING! This program can confuse your I2C bus, cause data loss and worse! I will probe file /dev/i2c-0, address 0x52, mode byte Continue? [Y/n] 0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef 00: 80 08 04 0c 0a 02 48 00 01 a0 60 02 80 08 08 01 ??????H.??`????? 10: 07 04 04 01 01 1f 0e 00 00 00 00 14 14 14 32 20 ???????....???2 20: 20 10 20 10 00 00 00 00 00 00 00 00 00 00 00 00 ? ?............ 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 12 be ..............?? 40: 7f 98 00 00 00 00 00 00 46 4b 47 4d 31 30 30 78 ??......FKGM100x 50: 37 32 52 43 33 2f 32 35 36 00 00 00 00 01 23 1c 72RC3/256....?#? 60: 04 b8 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ??.............. 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 64 84 ..............d? 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
[root@matthias ~]# i2cdump 0 0x53 No size specified (using byte-data access) WARNING! This program can confuse your I2C bus, cause data loss and worse! I will probe file /dev/i2c-0, address 0x53, mode byte Continue? [Y/n] 0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef 00: 80 08 04 0c 0a 02 48 00 01 a0 60 02 80 08 08 01 ??????H.??`????? 10: 07 04 04 01 01 1f 0e 00 00 00 00 14 14 14 32 20 ???????....???2 20: 20 10 20 10 00 00 00 00 00 00 00 00 00 00 00 00 ? ?............ 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 12 be ..............?? 40: 7f 98 00 00 00 00 00 00 46 4b 47 4d 31 30 30 78 ??......FKGM100x 50: 37 32 52 43 33 2f 32 35 36 00 00 00 00 02 21 01 72RC3/256....?!? 60: 26 7c 26 00 00 00 00 00 00 00 00 00 00 00 00 00 &|&............. 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 64 84 ..............d? 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ f0: 39 39 36 32 32 32 38 2d 30 30 31 2e 41 30 30 00 9962228-001.A00.
These probes are byte-for-byte identical with what the p2b target LinuxBIOSv2 outputs when I flash it and start up my system.
When I ran the program to setup lm_sensors, I got this:
Driver `lm78' (may not be inserted): Misdetects: * Bus `SMBus PIIX4 adapter at e800' (Algorithm unavailable) Busdriver `i2c-piix4', I2C address 0x2d ISA bus address 0x0290 (Busdriver `i2c-isa') Chip `National Semiconductor LM78' (confidence: 6)
Driver `w83781d' (should be inserted): Detects correctly: * Bus `SMBus PIIX4 adapter at e800' (Algorithm unavailable) Busdriver `i2c-piix4', I2C address 0x2d (and 0x48 0x49) ISA bus address 0x0290 (Busdriver `i2c-isa') Chip `Winbond W83781D' (confidence: 8)
Driver `eeprom' (should be inserted): Detects correctly: * Bus `SMBus PIIX4 adapter at e800' (Algorithm unavailable) Busdriver `i2c-piix4', I2C address 0x50 Chip `SPD EEPROM' (confidence: 8) * Bus `SMBus PIIX4 adapter at e800' (Algorithm unavailable) Busdriver `i2c-piix4', I2C address 0x51 Chip `SPD EEPROM' (confidence: 8) * Bus `SMBus PIIX4 adapter at e800' (Algorithm unavailable) Busdriver `i2c-piix4', I2C address 0x52 Chip `SPD EEPROM' (confidence: 8) * Bus `SMBus PIIX4 adapter at e800' (Algorithm unavailable) Busdriver `i2c-piix4', I2C address 0x53 Chip `SPD EEPROM' (confidence: 8)
So - does this mean that the w83781d is controlling the memory SMBUS, since it's detected correctly?
Also, you mentioned a couple of changes to the 440bx code that you'd like to do. Would it be OK for me to take a shot at these changes - probably tonight or tomorrow - as a way to get my feet wet with the codebase and hopefully make a small contribution? I'd guess that the southbridge name change would be pretty trivial, but the other change might need a little more smarts - but I'd like to take a shot at 'em.
Take care,
Don