[The two theories provided by Mika Westerberg, verbatim]
"""
Instead I have a theory since as far as I know there have been to kinds
of issues.
1. Flash is left locked. This makes the BIOS impossible to save
settings.
This seems to happen only for GigaDevice flashes and for all of those
there is this flag in "spi-nor.c" set: SPI_NOR_HAS_LOCK.
Normally Linux only reads JEDEC ID of the chip and nothing else.
However, in this case it may be possible that Linux does unlock +
operation + lock which leaves the flash locked and confuses BIOS.
2. Flash corrupted
We've seen once on Apollo Lake systems where the BIOS image had
configured to use Quad mode instead of Single but the chip was
connected only with single data lane or so. Trying to access the flash
using HW sequencer then does damage to the chip because it is in wrong
mode. This only happened with certain Winbond chips.
In any case it would require some more analysis to find the root cause.
"""
[The two theories provided by Mika Westerberg, verbatim]
"""
Instead I have a theory since as far as I know there have been to kinds
of issues.
1. Flash is left locked. This makes the BIOS impossible to save
settings.
This seems to happen only for GigaDevice flashes and for all of those
there is this flag in "spi-nor.c" set: SPI_NOR_HAS_LOCK.
Normally Linux only reads JEDEC ID of the chip and nothing else.
However, in this case it may be possible that Linux does unlock +
operation + lock which leaves the flash locked and confuses BIOS.
2. Flash corrupted
We've seen once on Apollo Lake systems where the BIOS image had
configured to use Quad mode instead of Single but the chip was
connected only with single data lane or so. Trying to access the flash
using HW sequencer then does damage to the chip because it is in wrong
mode. This only happened with certain Winbond chips.
In any case it would require some more analysis to find the root cause.
"""