Attention is currently required from: Felix Singer, Nico Huber, Michał Żygowski, Angel Pons.

View Change

1 comment:

• Patchset:

  • Patch Set #4:

    I think it's awesome that the DMI checks were there from the beginning. This
    is the way to go. Great work!

    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.

    There is no standard for these registers, any chip could return the same
    as an ITE one. There is not even a guarantee that the 0x2e/0x2ef ports are
    used as a register/data pair. Probing such things is ok for a development
    tool like `inteltool`, who cares if the developer's machine resets/bricks?
    But flashrom is not a hacking tool, it's users are humble. There will be
    people who'll simply try the programmer.

    Good point. I forget about flashrom not being a hacking tool.

    While I agree that it's not a hacking tool,

    a) some people want to use it during development of alternative ec firmware.

    b) you still cannot save all people from bricking their devices. Even with parameters like --please-set-my-house-on-fire, there will be someone who runs it...

    However, I'd like to have some safety checks, too, and maybe a warning but still would like to have some possibility to override that when I really know what I am doing or have ways to recover, like when overriding a test-firmware with a productive one.

    
    > > or better the firmware id (e.g. the "ITE string" or sth else) because support for this firmware-based programming mechanism is implemented in EC fw
    >
    > That's right, we would not only have to detect the chip without probing
    > any non-standard ports, we'd also have to figure out what firmware it
    > runs. How would one get this string without making assumptions that can
    > be broken (e.g. by not using ITEs firmware framework)?
    >
    > Maintaining a table of compatible boards is much likely the least work.
    > Having said that, it might not be a bad idea to add additional checks
    > after the board detection, i.e. when we know the board, we know that
    > there is an ITE chips, can find the PMC pair, try to check for a com-
    > patible firmware (currently the code starts with writes without
    > knowing if the firmware is compatible; e.g. did somebody replace it
    > with the System76 one?).

    I'm unsure if having a list of mainboards (like vendor/mainboard) is really required. I need to take another look but IIRC the EC fw framework has capabilities of identifying the firmware/mainboard combination. That should be sufficient.

    
    I agree. If a board isn't in the compatibility list, it can be added once it's known to work.

    So basically we can rename the programmer to something like ite_ec. Any other suggestions?

    I'd say `ite_ecfw.c`. After all it's not a driver for their chips but
    for their firmware framework?.

    +1

    sounds good

To view, visit change 55715. To unsubscribe, or for help writing mail filters, visit settings.