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

Re: [coreboot] [RFH] Draft release notes for coreboot 4.7

[Naveed Ghori]

Hi all,

Going forward would it be worth doing release notes progressively as bug fixes 
and features are added to the code. This may make the actual release process 
easier.
As I have not contributed to bug fixes/features this far I may be missing 
something (e.g. this is already happening)

My 2c.
Regards,
Naveed

-Original Message-
From: coreboot [mailto:coreboot-boun...@coreboot.org] On Behalf Of Paul Menzel
Sent: Thursday, 21 December 2017 4:24 PM
To: coreboot@coreboot.org
Subject: [coreboot] [RFH] Draft release notes for coreboot 4.7

Dear coreboot folks,


Martin said, that the missing/unwritten release notes are the reason holding up 
the coreboot 4.7 release.

Could the maintainers, developers, and users please jump in and help write 
them. Please use the pad [1]. Some coreboot folks already contributed. Big 
thank you to them.

Also, thanks to the now mostly great and elaborate commit messages, the release 
notes should really just give a broad overview. The detail can then be looked 
up.

Additionally, can you think of the something that has to be adapted by someone 
switching from coreboot 4.6 to coreboot 4.7?


Thanks,

Paul


[1] 
https://linkprotect.cudasvc.com/url?a=https://pads.ccc.de/s7c2eXetAu=E,1,jYNN-Jv9ujvYDutxAcDWBlDkhPkoO2Jq8oAI8X4PYtQ7zeuZLh9bn1D2uHLy7YMVUAtUNdCMb3FBPzxNXpO98kzhHUXj62jbpqeLIwjRmHPma5xOv-HkZAk,=1
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Depthcharge License

[Aaron Durbin via coreboot]

https://chromium-review.googlesource.com/c/chromiumos/platform/depthcharge/+/837589

On Thu, Dec 21, 2017 at 11:14 AM,  wrote:

> On 2017-12-19 09:53, David Hendricks wrote:
>
>> To be fair, it appears that many source files refer to a non-existent
>> LICENSE file. Someone on the CrOS team should probably just add the
>> LICENSE file for depthcharge and/or contact mal@ to see how the
>> license info is being collected these days (e.g. for
>> chrome://os-credits [3]).
>>
>>
> Thanks for the input on the DC licensing, and because lawyers are involved
> I need to ask a direct question.
> Can a Depthcharge maintainer (anybody who has +2 gerrit authority would
> suffice) state on this thread
> that the Depthcharge project license is GPLv2 (or later)?
>
> I know this feels redundant and that the question has been asked and
> answered, I'm just trying
> to satisfy our internal legal group.
>
> Per David's point above, this direct question would not be required to
> satisfy the lawyers
> if a top-level COPYING or LICENSE file is added to Depthcharge.  Which I
> will be happy to
> add once I'm able to start contributing to the project.
> Cheers,
> T.mike
>
> On Tue, Dec 19, 2017 at 9:19 AM, ron minnich 
>> wrote:
>>
>> Is there even a question? Looks like aaron just answered the
>>> original question, which boils down to Read The Source?
>>>
>>> On Tue, Dec 19, 2017 at 7:58 AM Aaron Durbin via coreboot
>>>  wrote:
>>>
>>> On Tue, Dec 19, 2017 at 8:03 AM,  wrote:
>>> On 2017-12-15 13:39, ttu...@codeaurora.org wrote:
>>> Preparing to mirror the coreboot.org [1] requires us to vet the
>>> various
>>> licenses, etc.
>>>
>>> There doesn't appear to be a LICENSE or COPYING file in the
>>> Depthcharge tree.
>>>
>>> My understanding is that Depthcharge is licensed GPLv2 (or later).
>>>
>>> How would I confirm this with an online source?
>>>
>>> Cheers,
>>> T.mike
>>>
>>> Should this query be posted on Chromium list rather than Coreboot
>>> list?
>>>
>>
>> Probably. The files in the depthcharge repository  have licenses at
>> the top of each file. They are GPLv2.
>>
>> Cheers,
>>> T.mike
>>>
>>> --
>>> coreboot mailing list: coreboot@coreboot.org
>>> https://mail.coreboot.org/mailman/listinfo/coreboot [2]
>>>
>>  --
>> coreboot mailing list: coreboot@coreboot.org
>> https://mail.coreboot.org/mailman/listinfo/coreboot [2]
>> --
>> coreboot mailing list: coreboot@coreboot.org
>> https://mail.coreboot.org/mailman/listinfo/coreboot [2]
>>
>>
>>
>> Links:
>> --
>> [1] http://coreboot.org
>> [2] https://mail.coreboot.org/mailman/listinfo/coreboot
>> [3] https://www.chromium.org/chromium-os/licenses
>>
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Depthcharge License

[tturne]

On 2017-12-19 09:53, David Hendricks wrote:

To be fair, it appears that many source files refer to a non-existent
LICENSE file. Someone on the CrOS team should probably just add the
LICENSE file for depthcharge and/or contact mal@ to see how the
license info is being collected these days (e.g. for
chrome://os-credits [3]).



Thanks for the input on the DC licensing, and because lawyers are 
involved I need to ask a direct question.
Can a Depthcharge maintainer (anybody who has +2 gerrit authority would 
suffice) state on this thread

that the Depthcharge project license is GPLv2 (or later)?

I know this feels redundant and that the question has been asked and 
answered, I'm just trying

to satisfy our internal legal group.

Per David's point above, this direct question would not be required to 
satisfy the lawyers
if a top-level COPYING or LICENSE file is added to Depthcharge.  Which I 
will be happy to

add once I'm able to start contributing to the project.
Cheers,
T.mike


On Tue, Dec 19, 2017 at 9:19 AM, ron minnich 
wrote:


Is there even a question? Looks like aaron just answered the
original question, which boils down to Read The Source?

On Tue, Dec 19, 2017 at 7:58 AM Aaron Durbin via coreboot
 wrote:

On Tue, Dec 19, 2017 at 8:03 AM,  wrote:
On 2017-12-15 13:39, ttu...@codeaurora.org wrote:
Preparing to mirror the coreboot.org [1] requires us to vet the
various
licenses, etc.

There doesn't appear to be a LICENSE or COPYING file in the
Depthcharge tree.

My understanding is that Depthcharge is licensed GPLv2 (or later).

How would I confirm this with an online source?

Cheers,
T.mike

Should this query be posted on Chromium list rather than Coreboot
list?


Probably. The files in the depthcharge repository  have licenses at
the top of each file. They are GPLv2.


Cheers,
T.mike

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

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



Links:
--
[1] http://coreboot.org
[2] https://mail.coreboot.org/mailman/listinfo/coreboot
[3] https://www.chromium.org/chromium-os/licenses


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

[coreboot] [RFH] Draft release notes for coreboot 4.7

[Paul Menzel]

Dear coreboot folks,


Martin said, that the missing/unwritten release notes are the reason
holding up the coreboot 4.7 release.

Could the maintainers, developers, and users please jump in and help
write them. Please use the pad [1]. Some coreboot folks already
contributed. Big thank you to them.

Also, thanks to the now mostly great and elaborate commit messages, the
release notes should really just give a broad overview. The detail can
then be looked up.

Additionally, can you think of the something that has to be adapted by
someone switching from coreboot 4.6 to coreboot 4.7?


Thanks,

Paul


[1] https://pads.ccc.de/s7c2eXetAu

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot