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

[Nico Huber (Code Review)]

Attention is currently required from:  Felix Singer, Michał Żygowski, Angel Pons, Michael Niewöhner.
Nico Huber 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?
> > 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.
> 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.