<div dir="ltr"><span style="font-size:12.8px">> You can't  -- the UEFI firmware (BIOS) can't write to NVRAM to save settings, because the NVRAM region is now RO.</span><div><span style="font-size:12.8px">> Nothing can be changed until the offending bit in SR2 is cleared, which in some cases even prevents booting from USB. </span><br></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Nice. So now we have Ubuntu INTEL SPI device driver messing up with PCH registry. Setting some of them to make BIOS NVRAM RO.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Another workaround will be to add in /etc/rc.d/rc6.d some K process which will fix this problem by clearing offending bit in SR2.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Zoran</span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 22, 2017 at 9:33 AM, Matt DeVillier <span dir="ltr"><<a href="mailto:matt.devillier@gmail.com" target="_blank">matt.devillier@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Dec 21, 2017 10:51 PM, "Zoran Stojsavljevic" <<a href="mailto:zoran.stojsavljevic@gmail.com" target="_blank">zoran.stojsavljevic@gmail.com</a><wbr>> wrote:<br type="attribution"></span><blockquote class="m_-3167540846339500558quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span class=""><div class="m_-3167540846339500558quoted-text"><span style="font-size:12.8px">> from what I recall, <b><i><u><font color="#ff0000">the driver was trying to be responsible and lock SPI write access by default, but due to the</font></u></i></b></span><div><span style="font-size:12.8px"><b><i><u><font color="#ff0000">> off-by-one, ended up setting the 'inverse' bit on the 2nd status register of some chips, which reversed the RO</font></u></i></b></span></div><div><span style="font-size:12.8px"><b><i><u><font color="#ff0000">> and RW regions of the chip</font></u></i></b>.  This naturally led to the EFI variables not being able to be saved/changed, the</span></div><div><span style="font-size:12.8px">> </span><span style="font-size:12.8px">firmware not being able to be updated, and in some cases failure to boot due to either the ME or MRC regions</span></div><div><span style="font-size:12.8px">> being locked.</span></div><div><span style="font-size:12.8px"><br></span></div></div></span><span class=""><div><span style="font-size:12.8px">I assume (in RED), you are talking about Ubuntu 17.10 SPI driver.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">One obvious workaround is to stop in BIOS (CMOS), do the configuration adjustments/changes, save the new setup, and</span></div><div><span style="font-size:12.8px">shutdown </span><span style="font-size:12.8px">while still being in BIOS. This should work, since it will become new BIOS default.</span></div></span></div></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">You can't  -- the UEFI firmware (BIOS) can't write to NVRAM to save settings, because the NVRAM region is now RO. Nothing can be changed until the offending bit in SR2 is cleared, which in some cases even prevents booting from USB. </div><div><div class="h5"><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="m_-3167540846339500558quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><font color="#888888"><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Zoran</span></div></font></div><div class="m_-3167540846339500558elided-text"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 22, 2017 at 4:36 AM, Matt DeVillier <span dir="ltr"><<a href="mailto:matt.devillier@gmail.com" target="_blank">matt.devillier@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<div><br></div><div>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.</div><div><br></div><div>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</div></div><div class="m_-3167540846339500558m_5413518024850451836HOEnZb"><div class="m_-3167540846339500558m_5413518024850451836h5"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 21, 2017 at 9:25 PM, Gregg Levine <span dir="ltr"><<a href="mailto:gregg.drwho8@gmail.com" target="_blank">gregg.drwho8@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello!<br>
I wouldn't want to. Incidentally I run (sometimes) Slackware64 here.<br>
Currently its at release 14.2 with the usual updates, and a heck of a<br>
lot of things in their current location.<br>
<br>
And I noticed in that article an interesting smattering of typical<br>
English expressions.<br>
-----<br>
Gregg C Levine <a href="mailto:gregg.drwho8@gmail.com" target="_blank">gregg.drwho8@gmail.com</a><br>
"This signature fought the Time Wars, time and again."<br>
<div class="m_-3167540846339500558m_5413518024850451836m_6714842006207338165HOEnZb"><div class="m_-3167540846339500558m_5413518024850451836m_6714842006207338165h5"><br>
<br>
On Thu, Dec 21, 2017 at 9:42 PM, Nico Huber <<a href="mailto:nico.h@gmx.de" target="_blank">nico.h@gmx.de</a>> wrote:<br>
> Hi Ron,<br>
><br>
> On 22.12.2017 03:30, ron minnich wrote:<br>
>><br>
>> <a href="http://www.theregister.co.uk/2017/12/21/ubuntu_lenovo_bios/" rel="noreferrer" target="_blank">http://www.theregister.co.uk/2<wbr>017/12/21/ubuntu_lenovo_bios/</a><br>
><br>
><br>
> A simple off-by-one. The driver in question always sent one byte<br>
> too much which causes trouble if you accidentally write garbage to<br>
> your flash chip's second status register. Some chips enable write<br>
> protection that way and certain firmware doesn't work reliable any<br>
> more in that state :D<br>
><br>
> Don't ask me why it writes to the status register at all by default.<br>
> I don't remember.<br>
><br>
> Nico<br>
><br>
> --<br>
> coreboot mailing list: <a href="mailto:coreboot@coreboot.org" target="_blank">coreboot@coreboot.org</a><br>
> <a href="https://mail.coreboot.org/mailman/listinfo/coreboot" rel="noreferrer" target="_blank">https://mail.coreboot.org/mail<wbr>man/listinfo/coreboot</a><br>
<br>
--<br>
coreboot mailing list: <a href="mailto:coreboot@coreboot.org" target="_blank">coreboot@coreboot.org</a><br>
<a href="https://mail.coreboot.org/mailman/listinfo/coreboot" rel="noreferrer" target="_blank">https://mail.coreboot.org/mail<wbr>man/listinfo/coreboot</a><br>
</div></div></blockquote></div><br></div>
</div></div><br>--<br>
coreboot mailing list: <a href="mailto:coreboot@coreboot.org" target="_blank">coreboot@coreboot.org</a><br>
<a href="https://mail.coreboot.org/mailman/listinfo/coreboot" rel="noreferrer" target="_blank">https://mail.coreboot.org/mail<wbr>man/listinfo/coreboot</a><br></blockquote></div><br></div>
</div></blockquote></div><br></div></div></div></div></div>
</blockquote></div><br></div>