On Mon, 9 May 2016 20:46:18 -0700
David Hendricks <dhendrix(a)google.com> wrote:
> Hi Victor,
> From Flashrom's software perspective all chips with the same ID are
> Part number often includes characteristics such as package and thermal
> tolerance which do not affect software compatibility.
However, we will add the new names to the in-program (and hence
wiki) database so that this new information becomes public. Thanks for
the heads up, Victor.
Kind regards/Mit freundlichen Grüßen, Stefan Tauner
we're hitting the 80 column limit in our code in ways which actually
reduce readability for the code. Examples are various multiline messages
and complicated nested code where refactoring to a separate function
doesn't make sense.
Keeping the old 80 column limit is not really an option anymore.
Standard terminal sizes have one of 80, 100 or 132 columns.
Given the monitor resolutions many people have nowadays, I think it is
safe to say that you can fit two xterms with 100 columns horizonally
next to each other. 100 columns should also be sufficient for a msg_p*
of roughly 80 columns of text.
132 columns provide more leeway, but IMHO that would be too wide for
good readability (and my screen can't fit two xterms side-by-side anymore).
Of course some files have sections where any column limit is not
acceptable (board lists etc.), but the column limit violations should be
limited to the affected file sections, not whole files.
I'd like to get this decided today or tomorrow so we know where we need
line breaks in Stefan Tauner's new struct flashchip patch.
I have successfully managed to fry one W25Q64FW (1.8V only) SPI flash by
using the default 3.3V programing voltage.
The flash chip had been detected successfully from the 3.3V supply
voltage, but I needed to run several failed programming attempts before
I have started to look into the datasheet.
To prevent such an accidents I would like to implement a check after the
device detection to automatically reduce the programming voltage if
needed. I know that only one programmer (dediprog) uses this at the
moment, but I have been working for a while on adding support for an
another one which would support this.
If you have any objections/recommendations please let me know!
On Fri, 19 May 2017 11:20:27 +0300
qma ster <qmastery16(a)gmail.com> wrote:
> Dear coreboot/flashrom mailing list members,
> As you may have noticed it is not that easy or straightforward to
> gain the edit rights for coreboot/flashrom wikipedias so the people
> are mass migrating to the unofficial wikis.
Having already an account, I cound't notice it.
Having good quality and extensive documentation is really important, so
fixing that is important.
> My proposal is to give the edit rights to all the subscribers of the
> coreboot/flashrom mailing lists, or at least to all those who have
> been the subscribers for at least a day / a week / or a month.
Having a human review the subscription would probably be a better
idea, if done correctly:
- Humans could review if the request seems legit.
- The subscribers could have that human as a reference, to ask questions
- The reviewers could help the subscriber if they whish.
However to work correctly:
- The review process would need to be fast for both the reviewer and the
subscriber. An idea would not to have to go trough something that
looks like a job interview, as it was mentioned, but rather explain
why the subscriber wants wiki access. It should then be explained
what kind of description is expected.
- It would be nice if a welcome page is created on the user account
space, like on wikipedia. This would permit to refer to some general
guidelines for the wikis. For instance, some of my edits on the
flashrom wiki were reverted or moved to my user page, because I
didn't properly understand what level of anti-bricking safety was
There are also lot of tutorials on the Internet which uses improper
voltages (like 5V instead of 3.3V) for the flash chip, and as I was
told, it accidentally works probably because the wire setup is so bad
that the voltage drops on the wires, due to the resistance.
Good guidelines/explanation pages would probably be sufficent to
avoid such issues in the flashrom wiki.
 I explained how to reflash the option rom of an old nvidia GPU by
explaining how to bypass the read-only safety in flashrom, and
making several writes attempt to flash the (sgabios) image.
Since the method used always succedded for me, I thought that it
was fine at the time of writing.
Dear coreboot/flashrom mailing list members,
As you may have noticed it is not that easy or straightforward to gain
the edit rights for coreboot/flashrom wikipedias so the people are
mass migrating to the unofficial wikis. For example: recently Zoran
Stojsavljevic had to bring his Coreboot/VBT article to Jimmy Wales
wikipedia instead of coreboot wikipedia, Mike Banon had to put his EC
KB9012 chip flashing article to DangerousPrototypes wikipedia instead
of flashrom wikipedia, and I could provide many other similar examples
Currently, to get the edit rights for coreboot/flashrom wikipedias you
have to personally contact the wikipedias administration, who are the
highly active open source developers with a lot of things to do and
may simply forget to review your request - and you have to provide a
good enough detailed explanation of what exactly you are going to
write or edit, despite that your plans might change and suddenly you
would like to improve another article, write your own, or maybe even
want to improve the many other random articles: doing small changes
like fixing the typos / replacing the broken links / updating the
clearly outdated information / other fixes that are minor by nature
but still are majorly improving the wikipedias quality
I believe that the current administrative barriers are too high: to
gain the edit rights you should not be required to go through what
seems to be like a job interview, especially because this is not like
a job offer and your work at these wikipedias will be unpaid
My proposal is to give the edit rights to all the subscribers of the
coreboot/flashrom mailing lists, or at least to all those who have
been the subscribers for at least a day / a week / or a month. Could
see only the positive outcome from this action, because I strongly
believe that all the members of coreboot/flashrom mailing lists are
responsible smart individuals and their wiki contributions will be of
high quality. Alternatively, the registration could be made completely
open, but with a strong registration/login captcha or maybe even
per-edit captcha to prevent the automatic bots/spammers from ruining
the wiki pages
Please share your opinions about this proposal. It is interesting to
hear your thoughts, and maybe they could influence the
coreboot/flashrom projects future