On 21.02.2018 03:42, Bruno Doutriaux - ABCD Informatique wrote:
> I tried using flashrom 0.9.9 on debian stretch i686
> i typed flashrom --programmer internal -r out.rom
> then the same but with -w 315.rom
> but they both failed
> output: found winbond super i/o id 0x60
> and chipset via vt8237(r)
> enabling flash write ok
> no eeprom/flash device found
> note: flashrom can never write if the flashchip isn't found automatically
I'm afraid this is not enough information to say anything. Though,
I suspect that flashrom just doesn't know your chip (yet). Please
capture a verbose log (just `flashrom -p internal -o logfile.txt`) and
> it's an old hp pc
> pavilion t817.fr
> i have the new rom file
> motherboard is an asus a7v8x-LA
> firefox won't let me access https://paste.flashrom.org
Yes, that often makes trouble (the website is sometimes misconfigured
and Firefox, like most other browsers, is broken regarding reasonable
TLS security anyway). Please use another paste service, or just attach
your log to an email.
I tried using flashrom 0.9.9 on debian stretch i686
i typed flashrom --programmer internal -r out.rom
then the same but with -w 315.rom
but they both failed
output: found winbond super i/o id 0x60
and chipset via vt8237(r)
enabling flash write ok
no eeprom/flash device found
note: flashrom can never write if the flashchip isn't found automatically
it's an old hp pc
i have the new rom file
motherboard is an asus a7v8x-LA
firefox won't let me access https://paste.flashrom.org
Ligne Domicile: 03 27 40 22 66
Mobile: 06 61 17 38 95<div
id="DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2"><br /> <table
style="border-top: 1px solid #D3D4DE;">
<td style="width: 55px; padding-top: 18px;"><a
alt="" width="46" height="29" style="width: 46px; height: 29px;"
<td style="width: 470px; padding-top: 17px; color: #41424e;
font-size: 13px; font-family: Arial, Helvetica, sans-serif;
line-height: 18px;">Garanti sans virus. <a
target="_blank" style="color: #4453ea;">www.avast.com</a> </td>
<a href="#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2" width="1" height="1"></a></div>
I'm trying to build flashrom 1.0 for Dos on Ubuntu. But I'm still failing.
At first, I was having problems at the Checking for libpci/libz step.
Despite all the changes I made to the makefile, I always ended up with Not
sufficient. Then I commented that part out. Because all my library files
(libpci, libz, libgetopt, librt,...) are in the lib/ folder of my LIBS_BASE
(../libpci) which has the same parent folder as flashrom directory. I
followed the instructions of the README. For compiling pciutils, the
instructions say to apply the pciutils.gz.patch I don't know if I got that
part right. I just copy-pasted the file inside pciutils.gz.patch into
pciutils/ Then went on to compile pciutils, libz and libgetopt. And I
copied all the necessary header and library files into libpci/. After
commenting out the part that checks libpci, I then had to comment out the
real time clock test portion of makefile as well, because it was always
returning Not found. Compilation now proceeded but ended with errors, many
undefined references. All having to do with pci. I'm looking forward to ur
On 11.02.2018 12:53, CyberPK wrote:
> Thank you for the reply. You are true, it only takes a lot of time.
Good to hear it's working.
> Finally I've used the older flashrom 0.9.7 successfully.
> I've noticed that using this version with -VVV flags give me a feedback of
> the progresses printing 'pickit2_spi_send_command'
> Also, there is a way to use flashrom to read the OTP and write it to a new
> It's a GD25LB64C, cannot find its datasheet but has the same id of the
> supported GD25LB64C
Same here. Only clue I could find was a product list from GigaDevice
. No datasheet though, and their webpage also doesn't find it. At
least, in that list, the GD25LB64C and GD25LQ64C have the same voltage
and erase block organization. So they might be compatible indeed (some
vendors release incompatible chips with the same id...).
 "https://www.endrich.com/fm/2474/GIGADEVICE - SPI NOR FLASH PRODUCT
PS. You dropped the mailing list, please keep it always in CC.
I have two of these chips (found on a HDD) and try to add it to flashrom.
My "problem" is the device id.
id1 0x40, id2 0x11
This looks very strange to me, because normally it should look something
Ex: "MX25U8032E" -> id1 0xc2, id2 0x2534
Any idea why i get this "strange" ID?
On 11.02.2018 02:37, CyberPK wrote:
> Hello, I'm trying to read and write the flash memory into a GD25LB64C which
> is automatically recognized as GD25LQ64C.
Did it really say GD25LQ64C? I could only find an entry for GD25LQ64(B),
wondering what version of flashrom you are using.
> I'm using a pickit2 setting 1.8V and flashrom 1.0 compiled from source
> I'm using the -VVV flag, but the read process remains stuck in reading and
> the writing process remains stuck in "reading old flash chip contents".
> I've also tried to erase the content using the -E flag in addition to the
> verbose -VVV flag and I can see the slow advancements through the
> addresses appearing to n the screen.
> But I'm still unable to read or write. What I can do? Any idea?
You probably just need more patience. Reading has no progress indication
(because most programmers are fast). Maybe the pickit is just slow.
Hello, I'm trying to read and write the flash memory into a GD25LB64C which
is automatically recognized as GD25LQ64C.
I'm using a pickit2 setting 1.8V and flashrom 1.0 compiled from source
I'm using the -VVV flag, but the read process remains stuck in reading and
the writing process remains stuck in "reading old flash chip contents".
I've also tried to erase the content using the -E flag in addition to the
verbose -VVV flag and I can see the slow advancements through the
addresses appearing to n the screen.
But I'm still unable to read or write. What I can do? Any idea?
sorry for taking that long. I guess I was waiting for more people to
chime in (I'll still not abandon that hope, generally).
On 25.01.2018 08:12, David Hendricks wrote:
> On Wed, Jan 24, 2018 at 10:36 AM, Nico Huber <nico.h(a)gmx.de> wrote:
>> Hey folks,
>> during review of commits that port per-region file arguments  from
>> CrOS flashrom over here, we ran into a discussion about the command line
>> interface changes. The basic question that arose is
>> Do we want to maintain full CLI compatibility to CrOS flashrom?
>> This would have the upside, that it would ease remerging of the two
>> flashrom versions (in some unknown future). And anybody currently
>> using CrOS flashrom could transition more smoothly. OTOH, depending on
>> how the compatibility is achieved, it might increase the costs for
>> review and development heavily (for a project with 0 spare resources).
>> To not have to discuss this each and every time when some non-trivial
>> feature is ported over from CrOS, I'd like to have some opinions, how
>> valuable CLI compatibility is to you all and how we want to achieve it.
>> I have currently some alternative ideas in mind that I'll sketch below.
>> Feel free to add other ideas or just to comment them.
> Option #2 seems pretty good IMHO. I suspect that CrOS will need to maintain
> their legacy behavior for a while longer, but that does not need to hold
> back upstream. We should of course improve our testing to avoid breaking
> one or the other, at least without sufficient reason and time to adjust.
Sounds good to me. Though for testing, we'd have to implement the CrOS
compatible CLI rather sooner than later.
> Some background on this: CrOS currently maintains a separate CLI in their
> tree, cli_mfg.c, specifically because the upstream CLI was not well-suited
> for their manufacturing needs. Things like syntax changes, additional
> options, verbosity, error handling, etc. were simply different from what
> typical users expect. The partial read/write/verify syntax was developed to
> meet specific needs of the manufacturing flow, and the write-protection
> syntax was added specifically to address the way write-protection works on
> Chromebooks. Stuff like "combining multiple files" was done to avoid
> wasting valuable time on the assembly line and at runtime during normal OS
> maintenance (yes, seconds really do matter).
Hmmm, that valuable-time requirement is really something that would
suffer with a wrapper script. So let's try to keep compatibility inter-
> I'd still like to see CrOS converge with upstream so we share development
> and testing efforts. It would also be great to have more device
> manufacturers working with upstream. Having an alternate CLI coexist
> alongside the "classic" CLI seems like a decent compromise IMO. Both sides
> will benefit from a converged codebase, let's not make the CLI a blocking
Agreed. Though, convergence will need effort on both sides...
I made a Patch for adding "MX25U8032E" Chip.
Hope the Patch is ok, i took the data from "MX25U1635E" and changed it
to fit the "MX25U8032E".
Tested (with arduino-serprog):
- Reading (i readed the chip 3 times and make a diff, all diffs are same)
- Writing data1
- Writing data2 (overwriting)
The Vcc must be at max 2V, it does NOT work if Vcc is at 3.3V!
This ends in read and write errors (data corruption)! Tested ;-)