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
> indistinguishable.
>
> 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
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/
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/
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
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
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
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
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
