On Wed, May 9, 2018 at 1:12 PM, Elmar Stellnberger <estellnb@elstel.org> wrote:
When I boot with iomem=relaxed and enable flash writing in my BIOS I get the following result with my Celsius H265 notebook:

> flashrom -p internal:laptop=force_I_want_a_brick --read celsius2.rom
flashrom p1.0-74-g2568357 on Linux 4.17.0-rc3+ (x86_64)
flashrom is free software, get the source code at https://flashrom.org

Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns).
========================================================================
WARNING! You seem to be running flashrom on an unsupported laptop.
Laptops, notebooks and netbooks are difficult to support and we
recommend to use the vendor flashing utility. The embedded controller
(EC) in these machines often interacts badly with flashing.
See the manpage and https://flashrom.org/Laptops for details.

If flash is shared with the EC, erase is guaranteed to brick your laptop
and write may brick your laptop.
Read and probe may irritate your EC and cause fan failure, backlight
failure and sudden poweroff.
You have been warned.
========================================================================
Proceeding anyway because user forced us to.
Found chipset "Intel ICH9M-E".
Enabling flash write... OK.
Found Winbond flash chip "W25X32" (4096 kB, SPI) mapped at physical address 0x00000000ffc00000.
Reading flash... done.

However if I execute this twice I get two different images:
wget https://www.elstel.org/uploads/celsius.rom
wget https://www.elstel.org/uploads/celsius2.rom

Using vbindiff I can see that quite a lot is different between both images. - which would be difficult to achieve if the firmware was changed while I am running my computer. The image may be somehow corrupted as me_cleaner (BIOS offers Intel AMT) can not process the image:

python ../me_cleaner/me_cleaner.py -S -O celsius-no-me.rom celsius.rom
Unknown image

See also the dmidecode that I have attached.
How can it be that both images are different?
Do you think that the images are corrupted?
If so what could we do about it?

There is probably an embedded controller (EC) connected to the SPI ROM that is accessing the ROM at the same time as flashrom. See https://flashrom.org/Laptops for details.

If this is the case, then you will need to figure out how to prevent the EC from reading/writing the ROM at the same time as flashrom. This could be as simple as disabling your OS's power management daemon to avoid stimulating it, or it may require sending a command to the EC (likely a sequence of OUTBs) to put it into an update or recovery mode to prevent it from accessing the firmware ROM.