Re: [coreboot] anyone know what happened here?

[Peter Stuge]

Zoran Stojsavljevic wrote:
> > please stop sending HTML emails. Your mails are often very hard to view.
> 
> Better?

Yes! Thank you very much for fixing that setting. Like Nico I've also
struggled with parsing some of your replies. I think the new settings
help a lot!


Happy holidays

//Peter

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] anyone know what happened here?

[Nico Huber]

On 22.12.2017 17:27, Zoran Stojsavljevic wrote:

Off @topic:


please stop sending HTML emails. Your mails are often very hard to
view. Especially the quotations are completely messed up by your MUA
when you play with the font settings.


Better?


Yep, looks perfect. Thank you.

Nico

--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] anyone know what happened here?

[Zoran Stojsavljevic]

Off @topic:

> please stop sending HTML emails. Your mails are often very hard to
> view. Especially the quotations are completely messed up by your MUA
> when you play with the font settings.

Better?

Zoran

On Fri, Dec 22, 2017 at 3:31 PM, Nico Huber  wrote:
> Hi Zoran,
>
> please stop sending HTML emails. Your mails are often very hard to
> view. Especially the quotations are completely messed up by your MUA
> when you play with the font settings.
>
> On 22.12.2017 10:38, Zoran Stojsavljevic wrote:
>> Nice. So now we have Ubuntu INTEL SPI device driver messing up with PCH
>> registry. Setting some of them to make BIOS NVRAM RO.
>
> No, it's about the flash chip's own registers not the PCH.
>
>> 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.
>
> You can't work around a broken driver without a working driver. But if
> they at least didn't compile the driver into the kernel but a module,
> you can blacklist that module and everything should be fine.
>
> Nico

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] anyone know what happened here?

[Philipp Stanner]

Am Freitag, den 22.12.2017, 15:31 +0100 schrieb Nico Huber:
> Hi Zoran,
> 
> please stop sending HTML emails. Your mails are often very hard to
> view. Especially the quotations are completely messed up by your MUA
> when you play with the font settings.

Afaik it's possible to configure mail-servers so they automatically
reject HTML-Mails or transcode them to txt.
Beside that you often can configure it so it doesn't send E-Mails to
people who're subscribed to the list, if they're also in CC.

Maybe reconfiguring coreboot's mailserver would be a good idea :)
My 2 ct.

Philipp

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] anyone know what happened here?

[Nico Huber]

Hi Zoran,

please stop sending HTML emails. Your mails are often very hard to
view. Especially the quotations are completely messed up by your MUA
when you play with the font settings.

On 22.12.2017 10:38, Zoran Stojsavljevic wrote:
> Nice. So now we have Ubuntu INTEL SPI device driver messing up with PCH
> registry. Setting some of them to make BIOS NVRAM RO.

No, it's about the flash chip's own registers not the PCH.

> 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.

You can't work around a broken driver without a working driver. But if
they at least didn't compile the driver into the kernel but a module,
you can blacklist that module and everything should be fine.

Nico

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] anyone know what happened here?

[Nico Huber]

On 22.12.2017 04:36, Matt DeVillier wrote:
> from what I recall, the driver was trying to be responsible and lock SPI
> write access by default,

Yep, I remember something like that too. But in the usual UEFI case
there is nothing you could lock without breaking UEFI runtime at
least ;) These MTD drivers seem to assume that they are the only
entity accessing the chip. I doubt they saw the bigger picture at
Intel when they upstreamed that driver. Maybe it's only meant for
non-UEFI embedded use cases? Also, the Kconfig says (from the very
beginning):

  Say N here unless you know what you are doing. Overwriting the
  SPI flash may render the system unbootable.

I wonder why distros pick it up.

> 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

Yes, there was a train of fixes that took care of this, too. At least I
hope it was the off-by-one fixed here:

  9d63f17661e2 spi-nor: intel-spi: Fix broken software sequencing codes

Nico

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] anyone know what happened here?

[Zoran Stojsavljevic]

> 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.

Nice. So now we have Ubuntu INTEL SPI device driver messing up with PCH
registry. Setting some of them to make BIOS NVRAM RO.

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.

Zoran

On Fri, Dec 22, 2017 at 9:33 AM, Matt DeVillier 
wrote:

>
>
> On Dec 21, 2017 10:51 PM, "Zoran Stojsavljevic" <
> zoran.stojsavlje...@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 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.
>
>
> 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.
>
>
>
> Zoran
>
> On Fri, Dec 22, 2017 at 4:36 AM, Matt DeVillier 
> 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 
>> 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.drw...@gmail.com
>>> "This signature fought the Time Wars, time and again."
>>>
>>>
>>> On Thu, Dec 21, 2017 at 9:42 PM, Nico Huber  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@coreboot.org
>>> > https://mail.coreboot.org/mailman/listinfo/coreboot
>>>
>>> --
>>> coreboot mailing list: coreboot@coreboot.org
>>> https://mail.coreboot.org/mailman/listinfo/coreboot
>>>
>>
>>
>> --
>> coreboot mailing list: coreboot@coreboot.org
>> https://mail.coreboot.org/mailman/listinfo/coreboot
>>
>
>
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] anyone know what happened here?

[Matt DeVillier]

On Dec 21, 2017 10:51 PM, "Zoran Stojsavljevic" <
zoran.stojsavlje...@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 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.


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.



Zoran

On Fri, Dec 22, 2017 at 4:36 AM, Matt DeVillier 
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 
> 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.drw...@gmail.com
>> "This signature fought the Time Wars, time and again."
>>
>>
>> On Thu, Dec 21, 2017 at 9:42 PM, Nico Huber  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@coreboot.org
>> > https://mail.coreboot.org/mailman/listinfo/coreboot
>>
>> --
>> coreboot mailing list: coreboot@coreboot.org
>> https://mail.coreboot.org/mailman/listinfo/coreboot
>>
>
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [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 
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 
> 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.drw...@gmail.com
>> "This signature fought the Time Wars, time and again."
>>
>>
>> On Thu, Dec 21, 2017 at 9:42 PM, Nico Huber  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@coreboot.org
>> > https://mail.coreboot.org/mailman/listinfo/coreboot
>>
>> --
>> coreboot mailing list: coreboot@coreboot.org
>> https://mail.coreboot.org/mailman/listinfo/coreboot
>>
>
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [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 
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.drw...@gmail.com
> "This signature fought the Time Wars, time and again."
>
>
> On Thu, Dec 21, 2017 at 9:42 PM, Nico Huber  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@coreboot.org
> > https://mail.coreboot.org/mailman/listinfo/coreboot
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] anyone know what happened here?

[Gregg Levine]

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.drw...@gmail.com
"This signature fought the Time Wars, time and again."


On Thu, Dec 21, 2017 at 9:42 PM, Nico Huber  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@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] anyone know what happened here?

[Nico Huber]

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@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] anyone know what happened here?

[ron minnich]

http://www.theregister.co.uk/2017/12/21/ubuntu_lenovo_bios/
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot