tree 49b5163834504c40ffdb373be4360426ba99204e
parent 5feb8cdb6ff497e45cda73839dacafc240bf83bb
author Douglas Anderson <dianders@chromium.org> 1611966924 -0800
committer Felix Singer <felixsinger@posteo.net> 1664471143 +0000

linux_mtd: Disable buffering on the mtd device

We open the device node for the MTD device with this:
  dev_fp = fopen(dev_path, "r+")

In C fopen() is allowed to provide _buffered_ access to the file.
That means that the standard library is allowed to read ahead and/or
return cached data.  That's really not what we want for something like
this.  Let's turn it off.

This fixes a problem where flashrom would sometimes fail to "verify"
that it erased the flash.  The error message would look something like
this:

Erasing and writing flash chip... FAILED at 0x0000e220! Expected=0xff, Found=0xe9, failed byte count from 0x0000e200-0x0000e2ff: 0xdc
 failed byte count from 0x0000e000-0x0000efff: 0xffffffff
 ERASE_FAILED
FAILED!
Uh oh. Erase/write failed. Checking if anything changed.

After the failure I could read the flash device with a new invocation
of flashrom and I would see that, indeed, the erase had worked.

Tracing in the kernel showed that when the failure happened we saw a
pattern that looked like this:
* Read 0x0b00 bytes starting at 0x0000d000
* Read 0x1000 bytes starting at 0x0000db00
* Erase 0x1000 bytes starting at 0x0000e000

...and then there was _not_ a read after the erase.  It can be assumed
that, since userspace had already read 0xdb00 - 0xeaff that it was
looking at old buffered data after the erase.

Signed-off-by: Douglas Anderson <dianders@chromium.org>
Change-Id: I989afd83a33013b2756a0090d6b08245613215c6
Reviewed-on: https://review.coreboot.org/c/flashrom/+/50155
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/67871
Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-by: Felix Singer <felixsinger@posteo.net>