# ./flashrom -p internal:boardenable=force -V -w P5GD114.ROM
flashrom v0.9.9-r1955 on Linux 2.6.32-573.22.1.el6.x86_64 (x86_64)
flashrom is free software, get the source code at https://flashrom.org
flashrom was built with libpci 3.1.10, GCC 4.4.7 20120313 (Red Hat 4.4.7-16), little endian
Command line (5 args): ./flashrom -p internal:boardenable=force -V -w P5GD114.ROM
Calibrating delay loop... OS timer resolution is 1 usecs, 1753M loops per second, 10 myus = 9 us, 100 myus = 91 us, 1000 myus = 959 us, 10000 myus = 9145 us, 4 myus = 3 us, OK.
Initializing internal programmer
No coreboot table found.
Using Internal DMI decoder.
DMI string chassis-type: "Desktop"
DMI string system-manufacturer: "System manufacturer"
DMI string system-product-name: "System Product Name"
DMI string system-version: "System Version"
DMI string baseboard-manufacturer: "ASUSTeK Computer INC."
DMI string baseboard-product-name: "P5GD1"
DMI string baseboard-version: "Rev 1.xx"
Found Winbond Super I/O, id 0x88
Found chipset "Intel ICH6/ICH6R" with PCI ID 8086:2640.
Enabling flash write... 0xfff80000/0xffb80000 FWH IDSEL: 0x0
0xfff00000/0xffb00000 FWH IDSEL: 0x0
0xffe80000/0xffa80000 FWH IDSEL: 0x3
0xffe00000/0xffa00000 FWH IDSEL: 0x1
0xffd80000/0xff980000 FWH IDSEL: 0x2
0xffd00000/0xff900000 FWH IDSEL: 0x2
0xffc80000/0xff880000 FWH IDSEL: 0x3
0xffc00000/0xff800000 FWH IDSEL: 0x3
0xff700000/0xff300000 FWH IDSEL: 0x4
0xff600000/0xff200000 FWH IDSEL: 0x5
0xff500000/0xff100000 FWH IDSEL: 0x6
0xff400000/0xff000000 FWH IDSEL: 0x7
0xfff80000/0xffb80000 FWH decode enabled
0xfff00000/0xffb00000 FWH decode disabled
0xffe80000/0xffa80000 FWH decode disabled
0xffe00000/0xffa00000 FWH decode disabled
0xffd80000/0xff980000 FWH decode disabled
0xffd00000/0xff900000 FWH decode disabled
0xffc80000/0xff880000 FWH decode disabled
0xffc00000/0xff800000 FWH decode disabled
0xff700000/0xff300000 FWH decode disabled
0xff600000/0xff200000 FWH decode disabled
0xff500000/0xff100000 FWH decode disabled
0xff400000/0xff000000 FWH decode disabled
Maximum FWH chip size: 0x80000 bytes
SPI Read Configuration: prefetching disabled, caching enabled,
BIOS_CNTL = 0x01: BIOS Lock Enable: disabled, BIOS Write Enable: enabled
OK.
NOTE: Running an untested board enable procedure.
Please report success/failure to flashrom(a)flashrom.org.
Enabling full flash access for board "ASUS P5GD1(-VM)"...
Intel ICH LPC bridge: Raising GPIO21.
OK.
The following protocols are supported: FWH.
Probing for Atmel AT49LH002, 256 kB: probe_82802ab: id1 0x3a, id2 0x4e, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for Atmel AT49LH00B4, 512 kB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for Atmel AT49LH004, 512 kB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for Intel 82802AB, 512 kB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for Intel 82802AC, 1024 kB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for PMC Pm49FL002, 256 kB: probe_jedec_common: id1 0xda, id2 0x34
Probing for PMC Pm49FL004, 512 kB: probe_jedec_common: id1 0xda, id2 0x34
Probing for Sharp LHF00L04, 1024 kB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for SST SST49LF002A/B, 256 kB: probe_jedec_common: id1 0xda, id2 0x34
Probing for SST SST49LF003A/B, 384 kB: probe_jedec_common: id1 0xda, id2 0x34
Probing for SST SST49LF004A/B, 512 kB: probe_jedec_common: id1 0xda, id2 0x34
Probing for SST SST49LF004C, 512 kB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for SST SST49LF008A, 1024 kB: probe_jedec_common: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for SST SST49LF008C, 1024 kB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for SST SST49LF016C, 2048 kB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for ST M50FLW040A, 512 kB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for ST M50FLW040B, 512 kB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for ST M50FLW080A, 1024 kB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for ST M50FLW080B, 1024 kB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for ST M50FW002, 256 kB: probe_82802ab: id1 0x3a, id2 0x4e, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for ST M50FW016, 2048 kB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for ST M50FW040, 512 kB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for ST M50FW080, 1024 kB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for Winbond W39V040FA, 512 kB: probe_jedec_common: id1 0xda, id2 0x34
Found Winbond flash chip "W39V040FA" (512 kB, FWH) mapped at physical address 0x00000000fff80000.
Lockout bits:
Hardware bootblock locking (#TBL) is not active.
Hardware remaining chip locking (#WP) is not active..
Software 64 kB bootblock locking is not active.
Software 16 kB bootblock locking is not active.
Lock status of block at 0x00007f28936d8002 is Full Access.
Lock status of block at 0x00007f28936e8002 is Full Access.
Lock status of block at 0x00007f28936f8002 is Full Access.
Lock status of block at 0x00007f2893708002 is Full Access.
Lock status of block at 0x00007f2893718002 is Full Access.
Lock status of block at 0x00007f2893728002 is Full Access.
Lock status of block at 0x00007f2893738002 is Full Access.
Lock status of block at 0x00007f2893748002 is Full Access.
Probing for Winbond W39V040FB, 512 kB: probe_jedec_common: id1 0xda, id2 0x34
Probing for Winbond W39V040FC, 512 kB: probe_jedec_common: id1 0xda, id2 0x34
Probing for Winbond W49V002FA, 256 kB: probe_jedec_common: id1 0xda, id2 0x34
Probing for Winbond W39V080FA, 1024 kB: probe_jedec_common: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for Winbond W39V080FA (dual mode), 512 kB: probe_jedec_common: id1 0xda, id2 0x34
Found Winbond flash chip "W39V040FA" (512 kB, FWH).
Flash image seems to be a legacy BIOS. Disabling coreboot-related checks.
Reading old flash chip contents... done.
Erasing and writing flash chip... Trying erase function 0... 0x000000-0x000fff:E, 0x001000-0x001fff:E, 0x002000-0x002fff:EW, 0x003000-0x003fff:EW, 0x004000-0x004fff:EW, 0x005000-0x005fff:EW, 0x006000-0x006fff:EW, 0x007000-0x007fff:EW, 0x008000-0x008fff:EW, 0x009000-0x009fff:EW, 0x00a000-0x00afff:EW, 0x00b000-0x00bfff:EW, 0x00c000-0x00cfff:EW, 0x00d000-0x00dfff:EW, 0x00e000-0x00efff:EW, 0x00f000-0x00ffff:EW, 0x010000-0x010fff:EW, 0x011000-0x011fff:EW, 0x012000-0x012fff:EW, 0x013000-0x013fff:EW, 0x014000-0x014fff:EW, 0x015000-0x015fff:EW, 0x016000-0x016fff:EW, 0x017000-0x017fff:EW, 0x018000-0x018fff:EW, 0x019000-0x019fff:EW, 0x01a000-0x01afff:EW, 0x01b000-0x01bfff:EW, 0x01c000-0x01cfff:EW, 0x01d000-0x01dfff:EW, 0x01e000-0x01efff:EW, 0x01f000-0x01ffff:EW, 0x020000-0x020fff:EW, 0x021000-0x021fff:EW, 0x022000-0x022fff:EW, 0x023000-0x023fff:EW, 0x024000-0x024fff:EW, 0x025000-0x025fff:EW, 0x026000-0x026fff:EW, 0x027000-0x027fff:EW, 0x028000-0x028fff:EW, 0x029000-0x029fff:EW, 0x02a000-0x02afff:EW, 0x02b000-0x02bfff:EW, 0x02c000-0x02cfff:EW, 0x02d000-0x02dfff:EW, 0x02e000-0x02efff:EW, 0x02f000-0x02ffff:EW, 0x030000-0x030fff:EW, 0x031000-0x031fff:EW, 0x032000-0x032fff:EW, 0x033000-0x033fff:EW, 0x034000-0x034fff:EW, 0x035000-0x035fff:EW, 0x036000-0x036fff:EW, 0x037000-0x037fff:EW, 0x038000-0x038fff:EW, 0x039000-0x039fff:EW, 0x03a000-0x03afff:EW, 0x03b000-0x03bfff:EW, 0x03c000-0x03cfff:EW, 0x03d000-0x03dfff:EW, 0x03e000-0x03efff:EW, 0x03f000-0x03ffff:EW, 0x040000-0x040fff:EW, 0x041000-0x041fff:EW, 0x042000-0x042fff:EW, 0x043000-0x043fff:EW, 0x044000-0x044fff:EW, 0x045000-0x045fff:EW, 0x046000-0x046fff:EW, 0x047000-0x047fff:EW, 0x048000-0x048fff:EW, 0x049000-0x049fff:EW, 0x04a000-0x04afff:EW, 0x04b000-0x04bfff:EW, 0x04c000-0x04cfff:EW, 0x04d000-0x04dfff:EW, 0x04e000-0x04efff:EW, 0x04f000-0x04ffff:EW, 0x050000-0x050fff:EW, 0x051000-0x051fff:EW, 0x052000-0x052fff:EW, 0x053000-0x053fff:EW, 0x054000-0x054fff:EW, 0x055000-0x055fff:EW, 0x056000-0x056fff:EW, 0x057000-0x057fff:EW, 0x058000-0x058fff:EW, 0x059000-0x059fff:EW, 0x05a000-0x05afff:EW, 0x05b000-0x05bfff:EW, 0x05c000-0x05cfff:EW, 0x05d000-0x05dfff:EW, 0x05e000-0x05efff:EW, 0x05f000-0x05ffff:EW, 0x060000-0x060fff:EW, 0x061000-0x061fff:EW, 0x062000-0x062fff:EW, 0x063000-0x063fff:EW, 0x064000-0x064fff:S, 0x065000-0x065fff:S, 0x066000-0x066fff:S, 0x067000-0x067fff:S, 0x068000-0x068fff:S, 0x069000-0x069fff:S, 0x06a000-0x06afff:S, 0x06b000-0x06bfff:EW, 0x06c000-0x06cfff:E, 0x06d000-0x06dfff:E, 0x06e000-0x06efff:E, 0x06f000-0x06ffff:S, 0x070000-0x070fff:EW, 0x071000-0x071fff:EW, 0x072000-0x072fff:EW, 0x073000-0x073fff:EW, 0x074000-0x074fff:EW, 0x075000-0x075fff:EW, 0x076000-0x076fff:EW, 0x077000-0x077fff:EW, 0x078000-0x078fff:EW, 0x079000-0x079fff:EW, 0x07a000-0x07afff:EW, 0x07b000-0x07bfff:EW, 0x07c000-0x07cfff:EW, 0x07d000-0x07dfff:S, 0x07e000-0x07efff:S, 0x07f000-0x07ffff:EW
Erase/write done.
Verifying flash... VERIFIED.
Restoring PCI config space for 00:1f:0 reg 0xdc
--------------------------------------
NOTICE OF CONFIDENTIALITY This e-mail, including all materials contained in or attached to this e-mail, contains proprietary and confidential information solely for the internal use of the intended recipient. If you have received this email in error, please notify us immediately by return e-mail or otherwise and ensure that it is permanently deleted from your systems, and do not print, copy, distribute or read its contents.
AVIS DE CONFIDENTIALITÉ Le présent courriel, y compris tous les documents qu'il contient ou qui y sont joints, renferme des renseignements exclusifs et confidentiels destinés uniquement à l'usage interne du destinataire prévu. Si vous avez reçu le présent courriel par erreur, veuillez nous aviser immédiatement, notamment par retour de courriel, et vous assurer qu'il est supprimé de façon permanente de vos systèmes; veuillez également vous abstenir d'imprimer, de copier, de distribuer ou de lire son contenu.
Hi!
The following patch adds support to configure Lattice iCE40 FPGAs
(formerly Silicon Blue parts). The support is to add support for the SPI
flash memories attached to the FPGA.
iCE40 FPGAs read its configuration from an SPI memory.
This patch should support the HW-USBN-2B Lattice cable, but I used a
generic FTDI FT2232 cable.
It works very well for the iCE40 Blink Evaluation Kit. This kit have an
M25P10-A SPI flash.
Note that Lattice provides a tool for free, but I had problems with the
command line version of the tool. Not to mention that the GUI version
takes 1 minute, 6 seconds to configure the memory and flashrom 6 seconds ;-)
About the patch:
- The patch is for ft2232_spi.c file, it adds a new cable type to the
ft2232_spi driver.
- The type is named ice40
- Lattice's cable used GPIOL0 as CS (named SS), for this reason the
patch uses this pin.
- During the flash configuration the FPGA must in reset state. GPIOL3
controls the RESET line (active low), this is the same line used by
Lattice cable.
- Before even trying to detect a memory you must wake-up it. This is
because the FPGA puts the memory to sleep. I know it sound a little bit
crazy to send a command to a memory that you don't even know is there,
but you can't detect it (read ID commands are ignored when the memory is
in deep power down mode).
- At exit the patch puts the memory to sleep and disconnects the cable.
This releases the reset and hence the FPGA boots from the memory.
Ideally you should check if the FPGA successfully loaded the memory
content. But for this you need to read the CDONE line, lamentably this
line can't be accessed in the Blink kit.
Is this patch acceptable?
Regards, SET
--
Ing. Salvador Eduardo Tropea http://utic.inti.gob.ar/
INTI - Micro y Nanoelectrónica (CMNB) http://www.inti.gob.ar/
Unidad Técnica Sistemas Inteligentes Av. General Paz 5445
Tel: (+54 11) 4724 6300 ext. 6919 San Martín - B1650KNA
FAX: (+54 11) 4754 5194 Buenos Aires * Argentina
Hi!
I have the following problem: the flash memory I need to program is
usually at sleep. So I must wake-up it, sending a "Release from
Power-down" (0xAB) command.
This command (and the one to make it sleep again: Deep Power Down
(0xB9)), seems to be widely supported by SPI flash chips.
The most annoying detail is that you must try to wake-up the memory,
even before you really know the memory is there. The memory won't reply
an ID when sleeping.
Right now I have a patched flashrom with support for a new SPI cable. I
added the wake-up/sleep commands to the cable, but it looks confusing,
because this is something that belongs to the memory.
Any advice?
Regards, SET
--
Ing. Salvador Eduardo Tropea http://utic.inti.gob.ar/
INTI - Micro y Nanoelectrónica (CMNB) http://www.inti.gob.ar/
Unidad Técnica Sistemas Inteligentes Av. General Paz 5445
Tel: (+54 11) 4724 6300 ext. 6919 San Martín - B1650KNA
FAX: (+54 11) 4754 5194 Buenos Aires * Argentina
Antonio, seems you have purchased typical Chineese VT6421 card with fake
ROM.
VT6421 supports only LPC chips. Nowadays China manufacturers simply
utilizes old parallel flash chips by this manner. Look thoroughly, this IC,
most likely, even not connected to flash chip interface pins of VT6421
(sometimes it even soldered only on corner pins).
Look with Google translate on this thread:
http://forum.ixbt.com/topic.cgi?id=11:38403, with this key post:
http://forum.ixbt.com/topic.cgi?id=11:38403:488#488.
There's enthusiast who developed flash tool and heavily modified RAID BIOS
and explored Chinese flash chip phenomenon. There are also described flash
addressing issues. It's possible to desolder fake chip, add required few
component and set real working BIOS chip.
Actually, I done all that, soldered IC socket for BIOs chip and nowadays
searching for supported LPC flash chip.
===================================
Message: 2
Date: Tue, 5 Apr 2016 14:01:43 +0200
From: "Antonio Estrada Respeto" <aestradarespeto(a)gmail.com>
To: <flashrom(a)flashrom.org>
Subject: Re: [flashrom] VT6421 sata card with sst39Vf512 eprom
Message-ID: <6FBFE9CEFEF54581B7BA6A024BA7C6B3@Asrock960gm>
Content-Type: text/plain; format=flowed; charset="UTF-8";
reply-type=original
Thank you for your support.
I have tried to take the output file as you request, but no luck. I always
start freedos in my usb sdcard boot choosing the number 3 option, then input
cswdpr0, and then execute flashrom comand. But if I try to make -o
logfilename.txt, the system refuses to save the file (it says that the file
does not exists). If I do not execute cswdpr0 at first time, always have a
disk write error. I suppose it will be related to the file log error.
Best regards,
Max Arephin.
2016-04-05 20:05 GMT+03:00 <flashrom-request(a)flashrom.org>:
> Send flashrom mailing list submissions to
> flashrom(a)flashrom.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://www.flashrom.org/mailman/listinfo/flashrom
> or, via email, send a message with subject or body 'help' to
> flashrom-request(a)flashrom.org
>
> You can reach the person managing the list at
> flashrom-owner(a)flashrom.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of flashrom digest..."
>
>
> Today's Topics:
>
> 1. Re: [PATCH] 4 byte address mode for Macronix MX25L25735F
> (Peter Martini)
> 2. Re: VT6421 sata card with sst39Vf512 eprom
> (Antonio Estrada Respeto)
> 3. Re: MX25L6445E erase and write failed! (The Raven)
> 4. Adding support for MX25L6455EMI (The Raven)
> 5. Adding some functionality to the FTDI driver
> (Salvador Eduardo Tropea)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 5 Apr 2016 05:06:56 -0400
> From: Peter Martini <petercmartini(a)gmail.com>
> To: Tim Chick <Tim.Chick(a)mediatek.com>
> Cc: David Hendricks <dhendrix(a)google.com>, "flashrom(a)flashrom.org"
> <flashrom(a)flashrom.org>
> Subject: Re: [flashrom] [PATCH] 4 byte address mode for Macronix
> MX25L25735F
> Message-ID:
> <
> CAFyW6MS_YkaA2_wM2H8RCeSHK2xDAFjEdCFyHv55_+TtMdw+NA(a)mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi all,
>
> I'd asked about support for the MX25L25635E earlier on this list [
> https://www.flashrom.org/pipermail/flashrom/2015-September/013855.html],
> and have confirmed with the patches referenced there that I can read and
> flash my chip. I'll try this patch tonight when I get home and report
> back; I'd love to see this support main-lined.
>
> Peter
>
> On Tue, Apr 5, 2016 at 3:18 AM, Tim Chick <Tim.Chick(a)mediatek.com> wrote:
>
> > Hi David,
> >
> >
> >
> > There was a mistake in the logic, which I have corrected.
> >
> >
> >
> > I was also asked by someone else on the list if it worked with the
> > MX25L25635F, which is 32Mbytes, but uses 3-byte addressing by default.
> >
> >
> >
> > So I made the attached changes, which switch the chip to 4-byte mode. It
> > also has some dedicated 4-byte commands, and a BAR register, but it
> seemed
> > easiest to just use what I had tested for the MX25L25735F. I can?t
> actually
> > test the MX25L25635F though, as I don?t have one.
> >
> >
> >
> > Thanks,
> > Tim
> >
> >
> >
> >
> >
> > *From:* David Hendricks [mailto:dhendrix@google.com]
> > *Sent:* 04 April 2016 23:21
> > *To:* Tim Chick
> > *Cc:* flashrom(a)flashrom.org
> > *Subject:* Re: [flashrom] [PATCH] 4 byte address mode for Macronix
> > MX25L25735F
> >
> >
> >
> > On Thu, Mar 31, 2016 at 8:21 AM, Tim Chick <Tim.Chick(a)mediatek.com>
> wrote:
> >
> > Hi List,
> >
> >
> >
> > Flashrom would not detect this chip. When the definition was added,
> > everything failed as the chip only supports 4 byte address operation.
> >
> >
> >
> > Interesting - I didn't know such chips existed. The ones I've used have
> > backwards-compatible commands that support 3-byte addresses. FYI - Some
> > other high-capacity chips have 4-byte address enable bit in a config
> > register that will make the usual read/write/erase instructions accept 4
> > byte addresses. And yet other large chips have alternative instructions
> > that function the same but only accept a 4-byte address.
> >
> >
> >
> > The attached patch adds 4 byte address support for 4 byte only chips, as
> > determined by the JEDEC flash parameter table, and support for this chip
> > specifically.
> >
> >
> >
> > I?ve only allowed it to work with the SPI_CONTROLLER_FT2232 controller,
> as
> > that is the only one I have to test.
> >
> >
> >
> > I?ve also only ported spi_block_erase_20 ? the other block erase
> functions
> > will fail.
> >
> >
> >
> > Please let me know what you think!
> >
> >
> >
> > Good stuff! FWIW, I have a work-in-progress patch on chromium.org (
> > https://chromium-review.googlesource.com/#/c/323359/) for the other
> types
> > of high-capacity flash chips. I've tested on a Spansion S25FS256 using
> > linux_spi and ft2232. It needs a lot of clean-up, but might be of help.
> > Most of the changes were to convert read/write/erase functions to use
> > allocated buffers whose length depends on whether we're using a 3- or
> > 4-byte address.
> >
> >
> >
> > I'll borrow some ideas from your patch as well to support the "4-byte
> > address only" chips.
> >
> >
> >
> > --
> >
> > David Hendricks (dhendrix)
> > Systems Software Engineer, Google Inc.
> >
> > ************* Email Confidentiality Notice ********************
> > The information contained in this e-mail message (including any
> > attachments) may be confidential, proprietary, privileged, or otherwise
> > exempt from disclosure under applicable laws. It is intended to be
> > conveyed only to the designated recipient(s). Any use, dissemination,
> > distribution, printing, retaining or copying of this e-mail (including
> its
> > attachments) by unintended recipient(s) is strictly prohibited and may
> > be unlawful. If you are not an intended recipient of this e-mail, or
> believe
> > that you have received this e-mail in error, please notify the sender
> > immediately (by replying to this e-mail), delete any and all copies of
> > this e-mail (including any attachments) from your system, and do not
> > disclose the content of this e-mail to any other person. Thank you!
> >
> >
> > _______________________________________________
> > flashrom mailing list
> > flashrom(a)flashrom.org
> > https://www.flashrom.org/mailman/listinfo/flashrom
> >
>
Hi!
flashrom is a very nice tool. I'm using it to configure Lattice iCE40
FPGAs. These FPGAs uses an SPI configuration memory (M25P10-A in my case).
To communicate with the flash I'm using an FTDI 2232H cable (my own
version, supports 0.9 to 5 V signals).
The software provided by Lattice works. But I had problems with the
command line version of the tool (the GUI is fine).
So I searched for solutions and found flashrom.
I was able to flash the chip and start the FPGA without problems.
Flashrom is really fast and very easy to use.
Now I want to avoid some annoying details, and I thought about adding a
couple of new options to flashrom.
My problem is that I need to control a system reset line. I can't access
the SPI flash if the FPGA isn't in reset state (is directly connected to
the SPI flash).
It means that I must assert the reset line, do all the flashrom stuff
and then deassert reset. This is quite easy to implement. In fact I
could add a new "cable" to the ftdi.c file. But this won't solve similar
problems. So I was thinking about adding options to the FTDI driver to
control the initial and final state of the FTDI I/O lines. This is a
little bit more complex, but will add support for a lot of situations.
So my questions are:
1) Is this kind of addition desired.
2) Which way is preferred? simple/limited, complex/versatile.
Regards, SET
--
Ing. Salvador Eduardo Tropea http://utic.inti.gob.ar/
INTI - Micro y Nanoelectrónica (CMNB) http://www.inti.gob.ar/
Unidad Técnica Sistemas Inteligentes Av. General Paz 5445
Tel: (+54 11) 4724 6300 ext. 6919 San Martín - B1650KNA
FAX: (+54 11) 4754 5194 Buenos Aires * Argentina
Hi
I have two of those chips and added support for them.
This chip looks similar to the "MX25L6406E", so i took this part of code
and modified it to fit the MX25L6455EMI.
I have tested all erase modes (logs available if needed).
spi_block_erase_20
spi_block_erase_52
spi_block_erase_d8
spi_block_erase_60
spi_block_erase_c7
I am not a coder and it's years ago since my last patch. So sorry for
not posting a patch. :-(
Here are my modifications (are the correct?):
File flashchips.h
#define MACRONIX_MX25L6455EMI 0x2617 /* MX25L6455EMI (4k 0x20) */
File flashchips.c
{
.vendor = "Macronix",
.name = "MX25L6455EMI",
.bustype = BUS_SPI,
.manufacture_id = MACRONIX_ID,
.model_id = MACRONIX_MX25L6455EMI,
.total_size = 8192,
.page_size = 256,
.feature_bits = FEATURE_WRSR_WREN | FEATURE_OTP,
.tested = TEST_OK_PREW,
.probe = probe_spi_rdid,
.probe_timing = TIMING_ZERO,
.block_erasers =
{
{
.eraseblocks = { {4 * 1024, 2048} },
.block_erase = spi_block_erase_20,
}, {
.eraseblocks = { {64 * 1024, 128} },
.block_erase = spi_block_erase_52,
}, {
.eraseblocks = { {64 * 1024, 128} },
.block_erase = spi_block_erase_d8,
}, {
.eraseblocks = { {8 * 1024 * 1024, 1} },
.block_erase = spi_block_erase_60,
}, {
.eraseblocks = { {8 * 1024 * 1024, 1} },
.block_erase = spi_block_erase_c7,
}
},
.printlock = spi_prettyprint_status_register_bp3_srwd,
.unlock = spi_disable_blockprotect_bp3_srwd,
.write = spi_chip_write_256,
.read = spi_chip_read, /* Fast read (0x0B), dual I/O read
supported */
.voltage = {2700, 3600},
},
Hi again
I think the problem was that this (my) chips are defective. :-(
Tested now some of them and only two are not working as they should.
So i think this case can be closed.
THX
