[coreboot] anyone know what happened here?

[Matt DeVillier]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.coreboot.org/pipermail/coreboot/attachments/20171221/ffaa591a/attachment.html>