80/100/132 column line width policy
by Carl-Daniel Hailfinger
Hi,
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.
Comments?
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.
Regards,
Carl-Daniel
--
http://www.hailfinger.org/
1 month
FOSDEM Hardware Enablement Devroom
by Paul Kocialkowski
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
individuals.
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:
https://lists.fosdem.org/pipermail/fosdem/2017-October/002649.html
Cheers and see you at FOSDEM!
--
Paul Kocialkowski, developer of free digital technology and hardware
support
Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/
1 month, 2 weeks
Re: [flashrom] New chip erase function
by Nico Huber
Hello Max,
On 10/28/18 6:59 PM, M.Altschaeffel(a)gmx.de wrote:
> Hi,
> i have a problem with flashing a new blank bios chip. It´s a MX25L3206E chip.
the failed byte counts in the log look rather random, which usually
means the hardware setup is failing. Did you try to read+verify with
this setup? only if reading is 100% reliable, writing will work.
Do you have the plain chip connected or is it already soldered to the
board? If the former, make sure to connect all input pins, i.e. /HOLD
and /WP too. If the latter, power supply can be a problem; using the
regular laptop PSU works best (might have to get it into a wake-on-lan
state). Also, the T530 lacks pull-ups on the /CS lines of both flash
chips. If that is the case for the T430 too, idk, but if, you should
make sure that the /CS of the chip you _don't_ want to access is
pulled high.
Hope that helps,
Nico
2 months, 3 weeks
Re: [flashrom] Failed p4vxasd2+
by Nico Huber
Hello Ilya,
On 10/28/18 5:47 PM, Илья Пинясов wrote:
> Failed p4vxasd2 +
> I'm using lubuntu 18.04
do you need any help or did you just want to report this?
If you need help, please provide the command you used and the error
message you got (a verbose log would be appreciated).
Nico
2 months, 3 weeks
New chip erase function
by M.Altschaeffel＠gmx.de
Hi,
i have a problem with flashing a new blank bios chip. It´s a MX25L3206E chip.
Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns).
Found Macronix flash chip "MX25L3206E/MX25L3208E" (4096 kB, SPI) on linux_spi.
Reading old flash chip contents... done.
Erasing and writing flash chip... FAILED at 0x00000000! Expected=0xff, Found=0x00, failed byte count from 0x00000000-0x00000fff: 0xffb
ERASE FAILED!
Reading current flash chip contents... done. Looking for another erase function.
FAILED at 0x00000000! Expected=0xff, Found=0x00, failed byte count from 0x00000000-0x0000ffff: 0xc2e5
ERASE FAILED!
Reading current flash chip contents... done. Looking for another erase function.
FAILED at 0x00000136! Expected=0xff, Found=0x00, failed byte count from 0x00000000-0x0000ffff: 0xb25d
ERASE FAILED!
Reading current flash chip contents... done. Looking for another erase function.
FAILED at 0x00000157! Expected=0xff, Found=0xfe, failed byte count from 0x00000000-0x003fffff: 0x2ef018
ERASE FAILED!
Reading current flash chip contents... done. Looking for another erase function.
FAILED at 0x00000073! Expected=0xff, Found=0x00, failed byte count from 0x00000000-0x003fffff: 0x2ed6f7
ERASE FAILED!
Reading current flash chip contents... done. Looking for another erase function.
Looking for another erase function.
Looking for another erase function.
No usable erase functions left.
FAILED!
Uh oh. Erase/write failed. Checking if anything has changed.
Reading current flash chip contents... done.
Apparently at least some data has changed.
Your flash chip is in an unknown state.
Please report this on IRC at chat.freenode.net (channel #flashrom) or
mail flashrom(a)flashrom.org, thanks!
I started flashrom with : " sudo flashrom -n --programmer linux_spi:dev=/dev/spidev0.0,spispeed=512 --chip "MX25L3206E/MX25L3208E" -f --write /tmp/t430.rom "
I can´t skip the erase function, my thought -n and -f would help but no difference.
For any help i would be thankful.
Regards,
max
2 months, 3 weeks
Fwd: Intel QS77 chipet on MBA 2012
by Nico Huber
Sorry, it seems this one got lost in moderation, forwarding...
-------- Forwarded Message --------
Subject: Intel QS77 chipet on MBA 2012
Date: Wed, 24 Oct 2018 23:18:40 +0200
From: Laura Martín <hoshi.utsuku(a)gmail.com>
To: flashrom(a)flashrom.org
Hi all,
I'm trying to fix a corrupted EFI on a Macbook Air 13'' of 2012. I messed
up with efibootmgr and that's the result... It's not a locked EFI, in the
laptop Gentoo is installed, so I can access to the OS, although I can't
boot from USB.
So, I modified an EFI-dump for my laptop (I checked out it's not locked as
well), I made a dump of the current EFI and replaced the serial number and
other parameters. The size is OK, I checked out with hexdump.
The stanza to made the write is:
*# flashrom -p internal:pci=8086:1e56.0 -c "MX25L6406E/MX25L6408E" -V -w
/home/m00n/nueva.rom*
The output:
Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns).
Initializing internal programmer
No coreboot table found.
Using Internal DMI decoder.
No DMI table found.
*Found chipset "Intel QS77" with PCI ID 8086:1e56.*
This chipset is marked as untested. If you are using an up-to-date version
of flashrom *and* were (not) able to successfully update your firmware with
it,
then please email a report to flashrom(a)flashrom.org including a verbose
(-V) log.
Thank you!
Enabling flash write... Root Complex Register Block address = 0xfed1c000
GCS = 0xc21: BIOS Interface Lock-Down: enabled, Boot BIOS Straps: 0x3 (SPI)
...
BIOS_CNTL = 0x01: BIOS Lock Enable: disabled, BIOS Write Enable: enabled
....
BMWAG 0x00, BMRAG 0x00, BRWA 0xff, BRRA 0xff
0x54: 0x00000000 FREG0: Flash Descriptor region (0x00000000-0x00000fff) is
read-write.
0x58: 0x07ff0190 FREG1: BIOS region (0x00190000-0x007fffff) is read-write.
0x5C: 0x018f0001 FREG2: Management Engine region (0x00001000-0x0018ffff) is
read-write.
0x74: 0x866f0190 PR0: Warning: 0x00190000-0x0066ffff is read-only.
0x78: 0x9fff0692 PR1: Warning: 0x00692000-0x01ffffff is read-only.
Writes have been disabled for safety reasons. You can enforce write
support with the ich_spi_force programmer option, but you will most likely
harm your hardware! If you force flashrom you will get no support if
something breaks. On a few mainboards it is possible to enable write
access by setting a jumper (see its documentation or the board itself).
0x90: 0xc4 (SSFS)
SSFS: SCIP=0, FDONE=1, FCERR=0, AEL=0
0x91: 0xf94140 (SSFC)
SSFC: SCGO=0, ACS=0, SPOP=0, COP=4, DBC=1, SME=0, SCF=1
0x94: 0x0606 (PREOP)
0x96: 0x3c6c (OPTYPE)
0x98: 0x0103029f (OPMENU)
0x9c: 0xffd82005 (OPMENU+4)
0xA0: 0x00000000 (BBAR)
0xC4: 0x00800000 (LVSCC)
LVSCC: BES=0x0, WG=0, WSR=0, WEWS=0, EO=0x0, VCL=1
0xC8: 0x00002005 (UVSCC)
UVSCC: BES=0x1, WG=1, WSR=0, WEWS=0, EO=0x20
0xD0: 0x00000000 (FPB)
OK.
Unhandled programmer parameters: pci=8086:1e56.0
Aborting.
Error: Programmer initialization failed.
Restoring MMIO space at 0x7f50ae5978a0
Restoring PCI config space for 00:1f:0 reg 0xdc
So, what I'm doing wrong? It's an old laptop and with external devices I've
read that it's possible to flash, From the same device it should be
possible to do it .... I suppose that I'm missing some parameter.... But I
can't find which.
Any help would be appreciated... KR
2 months, 3 weeks
Intel QS77 chipet on MBA 2012
by Laura Martín
Hi all,
I'm trying to fix a corrupted EFI on a Macbook Air 13'' of 2012. I messed
up with efibootmgr and that's the result... It's not a locked EFI, in the
laptop Gentoo is installed, so I can access to the OS, although I can't
boot from USB.
So, I modified an EFI-dump for my laptop (I checked out it's not locked as
well), I made a dump of the current EFI and replaced the serial number and
other parameters. The size is OK, I checked out with hexdump.
The stanza to made the write is:
*# flashrom -p internal:pci=8086:1e56.0 -c "MX25L6406E/MX25L6408E" -V -w
/home/m00n/nueva.rom*
The output:
Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns).
Initializing internal programmer
No coreboot table found.
Using Internal DMI decoder.
No DMI table found.
*Found chipset "Intel QS77" with PCI ID 8086:1e56.*
This chipset is marked as untested. If you are using an up-to-date version
of flashrom *and* were (not) able to successfully update your firmware with
it,
then please email a report to flashrom(a)flashrom.org including a verbose
(-V) log.
Thank you!
Enabling flash write... Root Complex Register Block address = 0xfed1c000
GCS = 0xc21: BIOS Interface Lock-Down: enabled, Boot BIOS Straps: 0x3 (SPI)
...
BIOS_CNTL = 0x01: BIOS Lock Enable: disabled, BIOS Write Enable: enabled
....
BMWAG 0x00, BMRAG 0x00, BRWA 0xff, BRRA 0xff
0x54: 0x00000000 FREG0: Flash Descriptor region (0x00000000-0x00000fff) is
read-write.
0x58: 0x07ff0190 FREG1: BIOS region (0x00190000-0x007fffff) is read-write.
0x5C: 0x018f0001 FREG2: Management Engine region (0x00001000-0x0018ffff) is
read-write.
0x74: 0x866f0190 PR0: Warning: 0x00190000-0x0066ffff is read-only.
0x78: 0x9fff0692 PR1: Warning: 0x00692000-0x01ffffff is read-only.
Writes have been disabled for safety reasons. You can enforce write
support with the ich_spi_force programmer option, but you will most likely
harm your hardware! If you force flashrom you will get no support if
something breaks. On a few mainboards it is possible to enable write
access by setting a jumper (see its documentation or the board itself).
0x90: 0xc4 (SSFS)
SSFS: SCIP=0, FDONE=1, FCERR=0, AEL=0
0x91: 0xf94140 (SSFC)
SSFC: SCGO=0, ACS=0, SPOP=0, COP=4, DBC=1, SME=0, SCF=1
0x94: 0x0606 (PREOP)
0x96: 0x3c6c (OPTYPE)
0x98: 0x0103029f (OPMENU)
0x9c: 0xffd82005 (OPMENU+4)
0xA0: 0x00000000 (BBAR)
0xC4: 0x00800000 (LVSCC)
LVSCC: BES=0x0, WG=0, WSR=0, WEWS=0, EO=0x0, VCL=1
0xC8: 0x00002005 (UVSCC)
UVSCC: BES=0x1, WG=1, WSR=0, WEWS=0, EO=0x20
0xD0: 0x00000000 (FPB)
OK.
Unhandled programmer parameters: pci=8086:1e56.0
Aborting.
Error: Programmer initialization failed.
Restoring MMIO space at 0x7f50ae5978a0
Restoring PCI config space for 00:1f:0 reg 0xdc
So, what I'm doing wrong? It's an old laptop and with external devices I've
read that it's possible to flash, From the same device it should be
possible to do it .... I suppose that I'm missing some parameter.... But I
can't find which.
Any help would be appreciated... KR
2 months, 3 weeks
Libflashrom development and integration with fwupd
by artur.raglis＠3mdeb.com
Hello,
We would like to contribute to the flashrom project by adding missing
libflashrom
features like queries, proper flashrom_shutdown etc.
Until now, I have implemented and tested missing libflashrom functions
from
query section [https://www.flashrom.org/Libflashrom] (based on patches
from
Łukasz Dmitrowski [https://patchwork.coreboot.org/patch/4316/]). There
are 2
ways to get required information (e.g. supported programmers):
const char **flashrom_supported_programmers(void); //#1
int flashrom_supported_programmers(const char **supported_programmers);
//#2
I suppose that returning function status (#2) is not necessary with
query
functions, so I'll stick to the first approach.
What we want to accomplish is remote firmware updates for brand new
platforms
straight from the factory. To do so, libflashrom will be integrated with
fwupd
which would control all required lib resources. I have read the
conversation in
the https://www.mail-archive.com/flashrom@flashrom.org/msg13518.html
from which
it appears that process callbacks for the progress bar is still high
priority
task. Are there any new ideas / hints that we need to know for further
development?
Best regards,
Artur Raglis
2 months, 3 weeks
