Am Dienstag, den 23.02.2010, 04:24 +0100 schrieb Carl-Daniel Hailfinger:
- Direct port access of the i2c bus in the south bridge: is a bad idea,
as it might conflict with the i2c driver from the OS.
Probably the easiest way (no new OS specific code needed).
This is also how the DOS flasher is doing it. But that obviously doesn't mean that this approach is any good in a multitasking/multiuser system.
- OS specific general i2c access: Probably working, but might interfere
with hardware monitor drivers that try to access the same chip. i2c support has to be added for each OS.
Reminds me of all the ioport access stuff, only worse. Basically, we have to support each OS version differently, not to mention differens OS.
Correct. I don't even know about generic i2c access on Windows. All the programs like Mainboard Monitor do it, but I don't know how low-level they are.
- Chip-specific driver for enabling flashing: In Linux this means
adding a "flash_protect" sysfs property in the w83781d driver if the Asus chip is detect.
Cool idea, but old hardware tends to run old kernels, and this driver wouldn't make it into any of the pending releases of the big four distributions, so it is only a long-term solution, and has quite a few portability problems.
Correct again.
To be honest, I'm tempted to handle it like MSR access.
- Design a nice I2C abstraction for the code to use.
This already is more complicated than expected on the first look, as the design of an abstraction layer begins with choosing at what level the abstraction is. What first comes to mind is something like i2c_bus *my_bus = i2c_find_bus(I2CBUS_SOUTHBRIDGE) i2c_dev *my_dev = i2c_get_dev(my_bus,0x48); i2c_writeb(my_dev, 0x80, i2c_readb(my_dev,0x80) & ~0x08);
This kind of code will nicely integrate with the Linux raw i2c stuff, but you could think of many problems with this abstraction: It means that the OS allows access to I2C devices *by* *address*. If the OS just presents devices and type of the device ("Hardware monitor chip"), but not the addresses, this abstraction layer breaks down, even if the hardware monitor chip driver would also allow arbitrary I2C accesses, which I could imagine in Windows' layered driver system.
This abstraction layer definitely will not work with method 3, as method 3 is on a higher level than the whole i2c stuff, but this could be approached on a different level.
- Think long and hard about the abstraction and improve it if possible.
OK, mailing list discussion might help with improvement. :)
- Start implementing the OS-specific general access (method 2).
- Assuming there is no I2C driver loaded in the OS, either fall back to
method 1 or load a good driver, then proceed with method 2.
Sounds like a sound plan.
Regards, Michael Karcher