[XL] Change in flashrom[master]: ite_ecfw: Implement support for flashing ITE ECs found on TUXEDO laptops

[Michael Niewöhner (Code Review)]

Attention is currently required from: Nico Huber, Michał Żygowski, Paul Menzel.

Michael Niewöhner has posted comments on this change. ( https://review.coreboot.org/c/flashrom/+/55715 )

Change subject: ite_ecfw: Implement support for flashing ITE ECs found on TUXEDO laptops
......................................................................

Patch Set 30:

(2 comments)

File ite_ecfw.c:

https://review.coreboot.org/c/flashrom/+/55715/comment/e62cb60f_0f79b1c4 
PS29, Line 495: (uint8_t *)
> To be honest I don't see such modifications in the flashrom tool. Wouldn't mind […]

I did a bunch of tests on the autoload feature and read datasheets and leaked ec code again. It seems, all this is meant to be a recovery mechanism in case something goes wrong during flashing. Since under normal circumstances the external flash is not being modified at all, there is always a working firmware image present.

The autoload feature is copying the external flash contents to the eFlash on power-on and it is controlled by
- the autoload strap (pull-up on GPG2) - let's ignore this, as this pull-up is usually present and thus, autoload is active
- a signature on the external flash
- a signature on the eFlash
- firmware (see below)

The signature is used for determining the code base address, internal/external clock selection and configuring autoload. The relevant bits and bytes for autoload are:

byte 7:
- bit 7 : pwm blink during mirror : 0=on, 1=off
- bit 5 : autoload on 0=on, 1=off
- bit 2 : check crc and halt EC on error : 0=on, 1=off
- bit 0 : select PWM0/PWM1 for blinking

byte 13 :
- mirror length : len = 1024b * (val + 1)
- must be 0xaa if byte 7[5]=1(off)
- 0x00 disables autoload

The signature initially (when the eFlash is empty) is located on the external flash. When autoload is enabled (b7[5]=0) and len (b13) > 0, the EC copies len+1 blocks from the external flash to eFlash, then starts executing from the eFlash.

On the next power cycle the EC evaluates BOTH signatures! Tests showed that:
- eFlash b7[5] overrides external b7[5]
- only external length byte (b13) controls copied range (any eFlash b13 > 0 has no influence at all)
- eFlash b13 == 0 disables mirroring
- eFlash b7[5]=0 (on) && ext Flash b7[5]=1 (off) leads to weird resulting contents in eFlash o.O (1024 bytes 0x55, rest 0xfe)

ITE's reference firmware / fw framework disables autoload on the first startup by writing 0x00 to b13. They call it "mirror once". Vendors like Clevo or Lenovo usually keep this mechanism.

If any (older?) firmware image is missing that "mirror once" mechanism, this might lead to overwriting the flashed image on the next power cycle. Maybe that's the reason for the options in the vendor tool?

=> Anyway, the risk is low, since the worst thing that could happen is a downgrade of the firmware to the one on the external flash. If required we can try to find a solution if such case is being reported.

The signature(s) is/are generated during firmware build and we should expect the clock / code base settings to be correct. We shouldn't mess with these settings, even though the vendor tool does. If anyone wants to modify them, they could use a hex editor or adapt the source code (if built from source).

=> Let's drop patching any of these bits.

If someone really wants to force-off autoload manually, they could use a hex editor for now or write a simple tool for it.

=> I still need to test this to be 100% sure but I'm pretty confident now that we can drop any patching of the signature without affecting the function of this safeguard feature.

File ite_ecfw.c:

https://review.coreboot.org/c/flashrom/+/55715/comment/265b910e_d62fddcf 
PS30, Line 580: 	if (ctx_data->support_ite5570)
              : 		return ite_ecfw_chunkwise_erase(ctx_data, blockaddr, blocklen);
hm, I wonder why this is only done for it5570. (I know, the vendor tool does it... but why?). at least clevo l140cu/l140mu firmware provide the full erase function as well.