[flashrom] Request for ideas: Asus as99127f sensor chip on I2C protects flash!

[Michael Karcher]

Am Dienstag, den 23.02.2010, 04:24 +0100 schrieb Carl-Daniel Hailfinger:
> > 1) 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.

> > 2) 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.

> > 3) 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.
> 1. 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.

> 2. Think long and hard about the abstraction and improve it if possible.
OK, mailing list discussion might help with improvement. :)

> 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.
Sounds like a sound plan.

Regards,
  Michael Karcher