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

View Change

1 comment:

• Patchset:

  • Patch Set #4:

    Ah, it's already there, what I meant: There is that project id (tuxedo_ec_read_project), the firmware version and the chip ID. Having the projectid + chip id together as identifier sounds good to me. What do you think?

    How do you get any of it without first making assumptions about
    register layouts?

    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

    I'm still wondering where would you get that string from?

    Forget the string. What I meant was the project id ;-)

    
    >
    > > 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)?
    >
    > The point is, that you can't flash at all with a broken/incompatible firmware, using that code here. So it doesn't help to know the mainboard IMO

    Knowing the mainboard avoids running the code on the wrong board
    where it's more likely to do harm. It's not about the flashing process,
    flash contents or the contents to be flashed. The code starts with
    `ec_write_reg(0xf9, 0x20, EC_MAX_STATUS_CHECKS)`. There may be
    EC firmware that reacts badly to such a write (or chips that com-
    pletely misunderstand what is written to their registers). Knowing
    the board it runs on, makes it much less likely to hit such a case.

    Ah, thank you. I got you point. Well, that's indeed a very valid argument.

    
    > 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,

    I'm pretty sure that people hacking on EC firmware can add a DMI
    string.

    like when overriding a test-firmware with a productive one.

    That wouldn't be about the DMI check but the one that currently
    compares flash & file contents. Something that should be discussed
    separately, imho.

    Agreed

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