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/
Attaching a patch which works around the valloc() issue in the DJGPP.
Please apply before the flashrom 1.0.
In the meanwhile, it would be great if someone could test it too,
if needed I will distribute the executable for a test to Rayer (on CC).
I will also try to get some help on DJGPP list, as this issue happens
even with the official RPMs of DJGPP 2.05.
Signed-off-by: Rudolf Marek <r.marek(a)assembler.cz>
Fix the documentation and DOS port.
Update the DOS cross-compile documentation,
and workaround issue with valloc() with the
I'm trying to get a backup of the bios of my desktop computer, but it
fails with this message:
# flashrom -V -p internal -r bios.rom
flashrom v0.9.9-91-g0bfa819 on Linux 4.13.0-0.bpo.1-amd64 (x86_64)
flashrom is free software, get the source code at https://flashrom.org
flashrom was built with libpci 3.5.2, GCC 6.3.0 20170516, little endian
Command line (3 args): /home/as/src/flashrom/flashrom -V -p internal
Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns).
Initializing internal programmer
No coreboot table found.
Using Internal DMI decoder.
DMI string chassis-type: "Desktop"
DMI string system-manufacturer: "0000"
DMI string system-product-name: "OEM"
DMI string system-version: "OEM"
DMI string baseboard-manufacturer: "Foxconn"
DMI string baseboard-product-name: "G31MVP"
DMI string baseboard-version: "FAB:1.0"
Found ITE Super I/O, ID 0x8718 on port 0x2e
Found chipset "Intel ICH7/ICH7R" with PCI ID 8086:27b8.
Enabling flash write... Root Complex Register Block address = 0xfed1c000
Error accessing ICH RCRB, 0x4000 bytes at 0x00000000fed1c000
/dev/mem mmap failed: Operation not permitted
Error: Programmer initialization failed.
I tried with flashrom "v0.9.9-r1954" from debian/stable as well as the
latest version from the git repository. Both gave the same results.
Here are the results of the recommended steps fom https://flashrom.org/FAQ :
- The page "https://www.flashrom.org/Supported_hardware" lists
ICH7/ICH7R as supported, but this does not seem to be the case for me.
The user manual of the motherboard is available here:
- The manual does also not show any jumpers that protect against bios
- The bios setting "Super BIOS Protect" is disabled.
Do you have any suggestions how to proceed ?
On 30.12.2017 07:20, Branden Waldner wrote:
> I could probably do some testing of the dos build if you still need someone to.
thanks, it's tested now. Though if you want to, you can of course give
it some more testing. Just probing the chip should suffice (if probing
would work but anything else not, it's likely not DOS related). Probing
/should/ be safe (with the usual exception of unsupported laptops).
On 29.12.2017 15:00, Michael Zhilin wrote:
> Compilation on FreeBSD 12-current is fine,
thanks for the confirmation.
> but could you please merge
> https://patchwork.coreboot.org/patch/4498/ before release?
We've merged your patch to the master branch already. But I deliberately
didn't forward it to the 1.0.x release branch (yet), because nobody con-
firmed yet that it doesn't regress on Linux (I doubt it does after rea-
ding about IEXTEN, but think we should run it at least once anyway; I
don't have any serprog programmer).
Patch is here, if anyone wants to give it a shot on Linux
I could probably do some testing of the dos build if you still need someone to.
Currently I just have freedos setup to run aflash.exe on a board that
doesn't work with flashrom, but I can run it on other boards. Mainly
just the sis630 board (parallel flash) I've got that uses the same
flash chip and is supported and socketed, but I can try reading on
other boards for testing LPC or FWH as well, but I don't have any
socketed to make it easy to just test writes on a spare flash chip
(have several off of failed boards). I don't feel like messing around
with any of my spi flash boards, so at best I could try reading if you
think it's safe.
Cross-compiling it seems kind of annoying, but not overly complicated.
I'd be builidng with a debian stretch i686.
Just send me a response with what you'd like me to test if you still
need it tested.
we've just tagged a release candidate for flashrom-1.0. It seems very
stable; though, testing of this specific revision was rather limited
. So please test! especially if you use a rare setup (e.g. non-Linux
If you don't use Git, you can find a tarball here:
 Beside being used by developers, it's currently build tested on the
following OS's (mostly thanks to Docker multiarch images):
NetBSD 7.1 amd64
NetBSD 7.1 i386