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.
A Hardware Enablement devroom will be taking place at FOSDEM this year,
on Sunday 10 December 2017. This newly-created devroom is the result of
3 proposals that were merged together. It is co-organized by several
The devroom covers all aspects related to hardware enablement and
support with free software, including aspects related to boot software,
firmwares, drivers and userspace tools and adaptation.
Proposals for talks related to these topics are welcome and can be
submitted until Sunday 26 November 2017 via the pentabarf interface.
Short talks are encouraged over longer ones in order to cover a wide
range of topics.
The announcement for the devroom, that contains all the useful
information, was published at:
Cheers and see you at FOSDEM!
Paul Kocialkowski, developer of free digital technology and hardware
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/https://git.code.paulk.fr/
I have tried to build the flashrom with mingw on Windows, but the build
process fails with:
flash.h:336:1: error: '__MINGW_PRINTF_FORMAT' is an unrecognized format
__attribute__((format(__MINGW_PRINTF_FORMAT, 2, 3)));
I have checked the stdio.h shipped with the mingw installation, but it
does not contains the __MINGW_PRINTF_FORMAT macro.
I have used the latest available mingw-get-setup, because the 20110530
version (which mentioned in the wiki as known t obe working) segfaults
when I select the MSYS Basic System feature.
I can build with WARNERROR=no, but some more permanent fix
recommentation would be warmly welcome!
Just tried to contact you guys via irc chat. Here is the transcript:
13:47 -!- Irssi: Join to #flashrom was synced in 1 secs
13:47 < quinn> hello, need help with a failed flash on an Intel Bay Trail
13:48 < quinn> Detected flash chip is Winbond W25Q64.W 8192 kB, SPI mapped at
phy addr 0xff800000
13:50 < quinn> System is an industry pc with model LEC-3030T
13:51 < quinn> Bios made by Aptio.
13:52 < quinn> dmidecode says Vendor is AMI with bios version 5.6.5 and release
13:52 < quinn> BIOS revision 5.6 according to dmidecode
13:54 < quinn> Re-reading the flash results in same size rom file but filled
13:55 < quinn> I have the original rom saved.
13:56 < quinn> flashrom shows warning when reading or writing: BIOS region SMM
protection is enabled!
13:57 < quinn> flashrom version used is v0.9.9-rc1-r1942
Senior Network Engineer - BLUETOWN
+45 53 70 85 67 - q(a)bluetown.com - Skype ID: dalilai
Per Henrik Lings Allé 4, 3rd Floor - 2100 Copenhagen O - DK - +45 31 66 00 07 - www.bluetown.com
Hello flashrom developers!
I have submitted two PRs to github (as the wiki mentions it is also a
possible contribution channel).
Do I need to do anything else with that? I am not intended to seems to
be impatient I just would like to make sure that everything is in place
(this is my first contribution to flashrom this way).
If I remember correctly the coreboot gerrit was used to do code review.
Is it going to be moved there or we will perform the code review at the
I've just noticed that most of flashrom is licensed under GPLv2 + any
later version, while about a third of the code base is GPLv2 only.
I wonder if that is intentional, or if any of the license headers was
just copy pasted and spread too much?
Does somebody know any previous discussion on the topic?
Here are some patches for flashrom, which adds whitelist for:
Also Taurinus X200, which is a version of the ThinkPad X200 with
libreboot, with boardinfo modified slightly
Followed the coreboot wiki entry perfectly, and had no issues reading the flash chip.
The 4MB Bios chip in my x1 differs from the Wiki Entry:
Found Micron/Numonyx/ST flash chip "N25Q032..3E" (4096 kB, SPI) on linux_spi.
Not sure if that impacts anything, however booting I am faced with a Black Screen. Fan is not running at all, and appears nothing is happening.
I found this link as well: http://coreboot.coreboot.narkive.com/zUOsG1zN/lenovo-x1-carbon-3460-scree...
Flashed the rom at the end of the suggested mailing list comment, and still black screen.
I have included the vbios in my build, so I'm not sure what's wrong.
you dropped the mailing list in your reply; by accident, I assume.
On 27.01.2018 11:01, realraw(a)tuta.io wrote:
> The stock bios is currently set at 1.40 and I decided I was going to try
> to update to the latest BIOS. However the stock BIOS update utility
> does not work, and neither does the USB Bios Boot Utility. Now I see an
> error pop up on boot saying, 'Intel ME is in Recovery Mode'.
The ME is a microcontroller built into the chipset. You always have
to assume that it's running while you flash externally, so it's not
unlikely that it gets confused.
> I believe the BIOS has some sort of write protection on, that will not
> allow me to erase the BIOS. Is there anything that can be done besides
> physically removing the BIOS chip and swapping it for another?
The BIOS has no means to control the flash chip, while the system is
shut down. Removing the chip to flash, should always work, though. I
don't see any reason to swap the chip.
> My setup is the Pomona SOIC 8 Pin clip, female to female jumpers and the
> RPi3. I am SSHing into the Pi3 from my w530, and issuing the commands
> through that. The RPi3 is connected via the standard power cable that
> came with it, and the Thinkpad has Wake - On LAN enabled, but at this
> point I believe the issue had to do with something other than my
> equipment. Currently the BIOS is on version 1.40, and it was a custom
> BIOS that had been floating around the internet.
What I missed was what device you are trying to flash. I figured it now
from the subject line. I little hidden, IMHO. You should always mention
what you are trying to do in the email's body.
I'm confident that your problem is not related to any write-protection
(nobody else run into such issues with an X220, AFAIK). There are basi-
cally two ways to flash an X220:
1. Remove all power (battery + AC) from the board and power the flash
chip over the clip.
This is generally discouraged unless you know exactly that the other
chips on your board are protected against powering up as well (some
ThinkPads have a diode on the VCC trace to the flash chip for that).
You connect VCC to the clip in this case.
2. Wake-on-LAN state: Use the regular AC to power the board but keep
the machine shut down. In this state a lot of components on the
board are already active, including the flash chip. Do not attach
VCC through the clip, if you do this!
I would generally recommend 2. if you have a multimeter and can check
that the flash chip is indeed powered. When you attach a network cable
you can also see if the LEDs at the ethernet port light up, but this
is no 100% reliable indication.
Last but not least, the flash chip has two pins /HOLD and /WP that
should be pulled up (to VCC). The mainboard should already take care
of that, but you should check with a multimeter if that is the case.
If not, or if you can't verify it, you should pull these two pins high.
Hope that helps,