Hello flashrom people,
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.
Here some logs from an Asus A7V133 board: State after reboot: Parallel flash accepts no write cycles http://coreboot.pastebin.com/m2801f3ff Using i2cget (from i2c-tools), after loading i2c-dev module and unloading w83781d (to prevent contention) http://coreboot.pastebin.com/f1255a2cc Flash protect is bit 3, so clearing this bit and running flashrom again makes the chip visible: http://coreboot.pastebin.com/f35e34cf3
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. 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. 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.
Regards, Michael Karcher
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
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
-
Carl-Daniel Hailfinger -
Michael Karcher