Hi Michael,
On 23.02.2010 01:35, Michael Karcher wrote:
I have a confirmed report now that unlocking of some Asus boards (most likely many Asus boards with the VIA VT82C686 south bridge "Apollo Super South") needs i2c communication with the custom hardware sensor interface chip named as99127f, which is a derivate of the winbond w83782d, which is supported by the w83781d module. Contrary to the Winbond chip, the Asus chip is *only* reachable via I2C, connected to the I2C port of the south bridge, no ISA interface. And it has a register at I2C address 0x80 in bank one (accessed using the first subdevice) that contains a flash write protect bit. The original w83782d has no register addresses above 0x7f. [...] How do we approach these boards?
- 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).
- 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.
- 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. Definitely the most clean way on linux, but needs a kernel patch, which OTOH should be easy to get into new kernels, but still makes them a prerequisite of running flashrom on these boards. No idea about non-Linux systems.
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.
So we can choose between portability nightmares, high-risk code, and loads of coding (pick at least one, pick up to three).
To be honest, I'm tempted to handle it like MSR access. 1. Design a nice I2C abstraction for the code to use. 2. Think long and hard about the abstraction and improve it if possible. 3. Start implementing the OS-specific general access (method 2). 4. 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.
This is only a suggestion, in the end the person with working code wins.
Regards, Carl-Daniel