Change in flashrom[master]: tuxedo_ec: Implement support for flashing ECs on TUXEDO laptops

[Michael Niewöhner (Code Review)]

Attention is currently required from:  Felix Singer, Nico Huber, Michał Żygowski, Angel Pons.
Michael Niewöhner has posted comments on this change. ( https://review.coreboot.org/c/flashrom/+/55715 )

Change subject: tuxedo_ec: Implement support for flashing ECs on TUXEDO laptops
......................................................................

Patch Set 4:

(1 comment)

Patchset:

PS4:
> > 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