Attention is currently required from: Felix Singer, Nico Huber, Angel Pons, Michael Niewöhner.
1 comment:
Patchset:
I am open to suggestions how to generalize it. I am not familiar with ITE EC firmware framework. We have been working purely with EFI binaries to update the firmware and this is the result.
Oh, good to know. We don't need to perform any DMI checks, then: given that no probing is done (one has to explicitly choose this programmer), the drawbacks of safeguarding against using it on a "wrong" machine by accident outweigh the benefits.
With this in mind, one could add some sanity checks for ITE ECs: Have users specify the Super I/O port pair (e.g. 0x2e/0x2f or 0x4e/0x4f), retrieve the chip ID at indices 0x20/0x21 and find a match in a table of supported ECs. This could also be used to handle the ITE IT5570E differences.
I can do that. Probing both port pairs should not be a problem, why bother the user to select the ports.
Users could also specify the PMC (Power Management I/F Channel) to use to talk to the EC, have the code ensure the specified PMC LDN is enabled, and use the port pair values from the LDN IOBADx registers (indices 0x60 to 0x63) instead of having the user specify them.
I don't have the datasheet of these ECs so I don't exactly know what to do with it. If if understood correclty, the PMC LDN holds the I/O port pairs at indices 0x60 and higher?
The other approach is direct flashing via the flash registers (see it85spi.c, it87spi.c for example), which *should* also work on various ITE ec's even without firmware support.
Good to know, however I am obliged to implement and prove the firmware support way.
So basically we can rename the programmer to something like ite_ec. Any other suggestions?
To view, visit change 55715. To unsubscribe, or for help writing mail filters, visit settings.