[flashrom] Request for ideas: Asus as99127f sensor chip on I2C protects flash!
c-d.hailfinger.devel.2006 at gmx.net
Tue Feb 23 04:24:25 CET 2010
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?
> 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).
> 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.
> 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. 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
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.
"I do consider assignment statements and pointer variables to be among
computer science's most valuable treasures."
-- Donald E. Knuth
More information about the flashrom