[coreboot] anyone know what happened here?

[Zoran Stojsavljevic]

> from what I recall, *the driver was trying to be responsible and lock SPI
write access by default, but due to the*
*> off-by-one, ended up setting the 'inverse' bit on the 2nd status
register of some chips, which reversed the RO*
*> and RW regions of the chip*.  This naturally led to the EFI variables
not being able to be saved/changed, the
> firmware not being able to be updated, and in some cases failure to boot
due to either the ME or MRC regions
> being locked.

I assume (in RED), you are talking about Ubuntu 17.10 SPI driver.

One obvious workaround is to stop in BIOS (CMOS), do the configuration
adjustments/changes, save the new setup, and
shutdown while still being in BIOS. This should work, since it will become
new BIOS default.

Zoran

On Fri, Dec 22, 2017 at 4:36 AM, Matt DeVillier <matt.devillier at gmail.com>
wrote:

> from what I recall, the driver was trying to be responsible and lock SPI
> write access by default, but due to the off-by-one, ended up setting the
> 'inverse' bit on the 2nd status register of some chips, which reversed the
> RO and RW regions of the chip.  This naturally led to the EFI variables not
> being able to be saved/changed, the firmware not being able to be updated,
> and in some cases failure to boot due to either the ME or MRC regions being
> locked.
>
> I ran into this issue on Braswell ChromeOS devices using W25Q64FV/DV
> compatible chips; my workaround was to modify Chromium flashrom to clear
> the inverse bit on devices with the 2nd status register when doing
> --wp-disable so I'd always be able to update the firmware on affected
> devices.
>
> Nico -- did this ever get fixed in the upstream kernel?  From what I saw,
> the "fixed" Ubuntu ISO simply omitted the driver in the kernel config/build
>
> On Thu, Dec 21, 2017 at 9:25 PM, Gregg Levine <gregg.drwho8 at gmail.com>
> wrote:
>
>> Hello!
>> I wouldn't want to. Incidentally I run (sometimes) Slackware64 here.
>> Currently its at release 14.2 with the usual updates, and a heck of a
>> lot of things in their current location.
>>
>> And I noticed in that article an interesting smattering of typical
>> English expressions.
>> -----
>> Gregg C Levine gregg.drwho8 at gmail.com
>> "This signature fought the Time Wars, time and again."
>>
>>
>> On Thu, Dec 21, 2017 at 9:42 PM, Nico Huber <nico.h at gmx.de> wrote:
>> > Hi Ron,
>> >
>> > On 22.12.2017 03:30, ron minnich wrote:
>> >>
>> >> http://www.theregister.co.uk/2017/12/21/ubuntu_lenovo_bios/
>> >
>> >
>> > A simple off-by-one. The driver in question always sent one byte
>> > too much which causes trouble if you accidentally write garbage to
>> > your flash chip's second status register. Some chips enable write
>> > protection that way and certain firmware doesn't work reliable any
>> > more in that state :D
>> >
>> > Don't ask me why it writes to the status register at all by default.
>> > I don't remember.
>> >
>> > Nico
>> >
>> > --
>> > coreboot mailing list: coreboot at coreboot.org
>> > https://mail.coreboot.org/mailman/listinfo/coreboot
>>
>> --
>> coreboot mailing list: coreboot at coreboot.org
>> https://mail.coreboot.org/mailman/listinfo/coreboot
>>
>
>
> --
> coreboot mailing list: coreboot at coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.coreboot.org/pipermail/coreboot/attachments/20171222/506e9f45/attachment.html>