Inconsistent `flashrom -r` results

Support
1

Hello,

I have an Acer Chromebook 314 (CB314-4H-C90V). Board name: Craasneto

I built a Suzy Q Cable, opened ccd and did “ccd reset factory” on the cr50 console. So far so good. All ccd capabilities are “Always”.

Before continuing I want to make sure I can potentially unbrick my device. So I created a backup of the firmware using flashrom -r backup.rom from the vt-2 console on the device itself.

I tested reading the firmware via the suzyqable from my Desktop (flashrom -p raiden_debug_spi:target=AP -r backup2.rom), but I noticed that the sha256 of those two backups does not match. So I created some more backups both on the vt-2 console as well as over the suzyqable. The sha256 is different each time.

Looked at the difference in a hex editor and there appears to be some pattern to the changes. Similar areas change each time and never in the readonly section (even with both hardware and software write protect disabled).

Is this expected behavior (part of vboot?) or is there something wrong with my setup?

2

Small udpate:

The checksum of the firmware backup stays the same until I reboot the device. So this leads me to suspect that this is probably expected behavior and maybe related to how vboot marks the firmware versions as “correctly booted”.

Reading the flash over suzyqable always reboots my device afterwards. So if I do that the checksum of the backup changes every time.

Can someone who knows for sure confirm that this is the expected behavior?

3

it’s absolutely expected that a read done from the device itself will differ from one using an external programmer, simply because there are regions marked as unreadable from the device itself (like the ME) for which flashrom will return all 0xFF.

4

Interesting.

If the flashrom -r done on the device from vt-2 does not include the ME firmware, then how is it possible to unbrick a device with such a backup?

5

there’s a reason why the unbricking guide has you use --ifd -i bios when restoring from a backup made by the script.

you never want to overwrite the IFD or ME unless absolutely needed, too much risk of breaking something unnecessarily

1 Like
6

Gotcha. Thx for that information.

So this explains differences in reads from suzyqable vs vt-2.

Only remaining question in my mind is: why do backups from vt-2 differ from each other (when reboot occurs in between). And also suzyqable backups differ from each other (my device always resets after suzycable backup). Is that only due to the A/B firmware stuff that vboot does?

7

repeated suzyq backups should be identical unless something changes with the UEFI NVRAM or other NV storage. you’d have to diff them to know what’s different/where

8

Did some more experimentation.

There are quite a few changed areas. I minimized this by turning the device off after each suzyqable read directly from the "scary’ developer mode screen instead of letting the device boot. In that case the only change is to the end of an area that starts with “ELOG” in ascii. Looks like some type of logging infrastructure (src/drivers/elog/elog.c - chromiumos/third_party/coreboot - Git at Google)

If I let the device fully boot in between reads there are more changed areas (gonna do more investigation). But it definitely looks like those changes are expected then.

9

the firmware has booted, so you’re going to get changes from ELOG (event logger)