flashrom

flashrom@flashrom.org

5 participants
9161 discussions

Re: [flashrom] flashrom Digest, Vol 83, Issue 4
by Max 06 Apr '16

06 Apr '16

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 > > >

1 0

Adding some functionality to the FTDI driver
by Salvador Eduardo Tropea 05 Apr '16

05 Apr '16

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

1 0

Adding support for MX25L6455EMI
by The Raven 05 Apr '16

05 Apr '16

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}, },

1 0

Re: [flashrom] MX25L6445E erase and write failed!
by The Raven 05 Apr '16

05 Apr '16

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

1 0

VT6421 sata card with sst39Vf512 eprom
by Antonio Estrada Respeto 05 Apr '16

05 Apr '16

I have tried the below flashrom option (code tested) in order to find a right response on my no name VT6421A pci sata card, but no luck. Environment is Freedos in an usb boot sdcard device in a standard PC. Address was from 0xffff0000 to others. The card is found by flashrom at 1106:3249 BDF 02:0b.0 . The card has an Eprom flashable sst39Vf512 at is printed in top of it. Final messages are: Requested bar is of type rom. Error: No suported PCI found. Error: Program initialization failed. I managed flashrom to work with my 3C905TX and do it in the same environment as a charm. I know VT6421A hardware is very tricky depending on every pci maker. The final goal is to flash a 64k boot rom ins this card. Any help will be wellcome. Thanks in advance. The code tested: flashrom –p atavia offset=(different address) –V

3 3

Re: [flashrom] [PATCH] 4 byte address mode for Macronix MX25L25735F
by Tim Chick 05 Apr '16

05 Apr '16

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<mailto:Tim.Chick@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<http://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.

2 1

[PATCH] 4 byte address mode for Macronix MX25L25735F
by Tim Chick 05 Apr '16

05 Apr '16

Hi List, Flashrom would not detect this chip. When the definition was added, everything failed as the chip only supports 4 byte address operation. 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! Thanks, Tim

2 1

[PATCH] Add support for GD25Q21B, GD25Q41B, GD25Q80C and GD25Q16C
by Hatim Kanchwala 04 Apr '16

04 Apr '16

Hello, This patch supersedes the corresponding one I sent earlier as part of a chain (http://patchwork.coreboot.org/patch/4420). Stefan's suggestions on previous patches (discussed on list and IRC) are incorporated. The new definitions are combined with their counterparts. Thanks. :) Signed-off-by: Hatim Kanchwala <hatim(a)hatimak.me> --- flashchips.c | 28 ++++++++++++++++------------ flashchips.h | 4 ++-- 2 files changed, 18 insertions(+), 14 deletions(-) diff --git a/flashchips.c b/flashchips.c index 40b6b8e..7947256 100644 --- a/flashchips.c +++ b/flashchips.c @@ -5933,37 +5933,38 @@ const struct flashchip flashchips[] = { .block_erase = spi_block_erase_60, }, { .eraseblocks = { {128 * 1024, 1} }, .block_erase = spi_block_erase_c7, } }, .printlock = spi_prettyprint_status_register_bp4_srwd, .unlock = spi_disable_blockprotect_bp4_srwd, /* TODO: 2nd status reg (read with 0x35) */ .write = spi_chip_write_256, .read = spi_chip_read, /* Fast read (0x0B) and multi I/O supported */ .voltage = {2700, 3600}, }, { .vendor = "GigaDevice", - .name = "GD25Q20(B)", + .name = "GD25Q20(B)/GD25Q21B", .bustype = BUS_SPI, .manufacture_id = GIGADEVICE_ID, .model_id = GIGADEVICE_GD25Q20, .total_size = 256, .page_size = 256, - .feature_bits = FEATURE_WRSR_WREN, + /* OTP (GD25Q21B only): 1536B total; read 0x48, write 0x42, erase 0x44 */ + .feature_bits = FEATURE_WRSR_WREN | FEATURE_OTP | FEATURE_QPI, .tested = TEST_OK_PREW, .probe = probe_spi_rdid, .probe_timing = TIMING_ZERO, .block_erasers = { { .eraseblocks = { {4 * 1024, 64} }, .block_erase = spi_block_erase_20, }, { .eraseblocks = { {32 * 1024, 8} }, .block_erase = spi_block_erase_52, }, { .eraseblocks = { {64 * 1024, 4} }, .block_erase = spi_block_erase_d8, }, { @@ -5971,76 +5972,78 @@ const struct flashchip flashchips[] = { .block_erase = spi_block_erase_60, }, { .eraseblocks = { {256 * 1024, 1} }, .block_erase = spi_block_erase_c7, } }, .printlock = spi_prettyprint_status_register_bp4_srwd, .unlock = spi_disable_blockprotect_bp4_srwd, /* TODO: 2nd status reg (read with 0x35) */ .write = spi_chip_write_256, .read = spi_chip_read, /* Fast read (0x0B) and multi I/O supported */ .voltage = {2700, 3600}, }, { .vendor = "GigaDevice", - .name = "GD25Q40(B)", + .name = "GD25Q40(B)/GD25Q41B", .bustype = BUS_SPI, .manufacture_id = GIGADEVICE_ID, .model_id = GIGADEVICE_GD25Q40, .total_size = 512, .page_size = 256, - .feature_bits = FEATURE_WRSR_WREN, - .tested = TEST_UNTESTED, + /* OTP (GD25Q41B only): 1536B total; read 0x48, write 0x42, erase 0x44 */ + .feature_bits = FEATURE_WRSR_WREN | FEATURE_OTP | FEATURE_QPI, + .tested = TEST_OK_PREW, .probe = probe_spi_rdid, .probe_timing = TIMING_ZERO, .block_erasers = { { .eraseblocks = { {4 * 1024, 128} }, .block_erase = spi_block_erase_20, }, { .eraseblocks = { {32 * 1024, 16} }, .block_erase = spi_block_erase_52, }, { .eraseblocks = { {64 * 1024, 8} }, .block_erase = spi_block_erase_d8, }, { .eraseblocks = { {512 * 1024, 1} }, .block_erase = spi_block_erase_60, }, { .eraseblocks = { {512 * 1024, 1} }, .block_erase = spi_block_erase_c7, } }, .printlock = spi_prettyprint_status_register_bp4_srwd, .unlock = spi_disable_blockprotect_bp4_srwd, /* TODO: 2nd status reg (read with 0x35) */ .write = spi_chip_write_256, .read = spi_chip_read, /* Fast read (0x0B) and multi I/O supported */ .voltage = {2700, 3600}, }, { .vendor = "GigaDevice", - .name = "GD25Q80(B)", + .name = "GD25Q80(B)(C)", .bustype = BUS_SPI, .manufacture_id = GIGADEVICE_ID, .model_id = GIGADEVICE_GD25Q80, .total_size = 1024, .page_size = 256, - /* OTP: 1024B total, 256B reserved; read 0x48; write 0x42, erase 0x44 (B version only) */ - .feature_bits = FEATURE_WRSR_WREN | FEATURE_OTP, + /* OTP: 1024B total; read 0x48, write 0x42, erase 0x44 (B and C revisions only) */ + /* supports SFDP (C revision only) */ + .feature_bits = FEATURE_WRSR_WREN | FEATURE_OTP | FEATURE_QPI, .tested = TEST_OK_PREW, .probe = probe_spi_rdid, .probe_timing = TIMING_ZERO, .block_erasers = { { .eraseblocks = { {4 * 1024, 256} }, .block_erase = spi_block_erase_20, }, { .eraseblocks = { {32 * 1024, 32} }, .block_erase = spi_block_erase_52, }, { .eraseblocks = { {64 * 1024, 16} }, .block_erase = spi_block_erase_d8, }, { @@ -6048,38 +6051,39 @@ const struct flashchip flashchips[] = { .block_erase = spi_block_erase_60, }, { .eraseblocks = { {1024 * 1024, 1} }, .block_erase = spi_block_erase_c7, } }, .printlock = spi_prettyprint_status_register_bp4_srwd, .unlock = spi_disable_blockprotect_bp4_srwd, /* TODO: 2nd status reg (read with 0x35) */ .write = spi_chip_write_256, .read = spi_chip_read, /* Fast read (0x0B) and multi I/O supported */ .voltage = {2700, 3600}, }, { .vendor = "GigaDevice", - .name = "GD25Q16(B)", + .name = "GD25Q16(B)(C)", .bustype = BUS_SPI, .manufacture_id = GIGADEVICE_ID, .model_id = GIGADEVICE_GD25Q16, - .total_size = 2048, + .total_size = 2* 1024, .page_size = 256, - /* OTP: 1024B total, 256B reserved; read 0x48; write 0x42, erase 0x44 (B version only) */ - .feature_bits = FEATURE_WRSR_WREN | FEATURE_OTP, + /* OTP: 1024B total; read 0x48, write 0x42, erase 0x44 (B and C revisions only) */ + /* supports SFDP (C revision only) */ + .feature_bits = FEATURE_WRSR_WREN | FEATURE_OTP | FEATURE_QPI, .tested = TEST_OK_PREW, .probe = probe_spi_rdid, .probe_timing = TIMING_ZERO, .block_erasers = { { .eraseblocks = { {4 * 1024, 512} }, .block_erase = spi_block_erase_20, }, { .eraseblocks = { {32 * 1024, 64} }, .block_erase = spi_block_erase_52, }, { .eraseblocks = { {64 * 1024, 32} }, .block_erase = spi_block_erase_d8, }, { diff --git a/flashchips.h b/flashchips.h index 9ffb30f..997b3cb 100644 --- a/flashchips.h +++ b/flashchips.h @@ -353,32 +353,32 @@ #define FUJITSU_MBM29LV008TA 0x3E #define FUJITSU_MBM29LV080A 0x38 #define FUJITSU_MBM29LV200BC 0xBF #define FUJITSU_MBM29LV200TC 0x3B #define FUJITSU_MBM29LV400BC 0xBA #define FUJITSU_MBM29LV400TC 0xB9 #define FUJITSU_MBM29LV800BA 0x5B /* Same as MBM29LV800BE */ #define FUJITSU_MBM29LV800TA 0xDA /* Same as MBM29LV800TE */ #define FUJITSU_MBM29LV160BE 0x49 /* 16 b mode 0x2249 */ #define FUJITSU_MBM29LV160TE 0xC4 /* 16 b mode 0x22C4 */ #define GIGADEVICE_ID 0xC8 /* GigaDevice */ #define GIGADEVICE_GD25T80 0x3114 #define GIGADEVICE_GD25Q512 0x4010 #define GIGADEVICE_GD25Q10 0x4011 -#define GIGADEVICE_GD25Q20 0x4012 /* Same as GD25QB */ -#define GIGADEVICE_GD25Q40 0x4013 /* Same as GD25QB */ +#define GIGADEVICE_GD25Q20 0x4012 /* Same as GD25Q21B which supports OTP */ +#define GIGADEVICE_GD25Q40 0x4013 /* Same as GD25Q41B which supports OTP */ #define GIGADEVICE_GD25Q80 0x4014 /* Same as GD25Q80B (which has OTP) */ #define GIGADEVICE_GD25Q16 0x4015 /* Same as GD25Q16B (which has OTP) */ #define GIGADEVICE_GD25Q32 0x4016 /* Same as GD25Q32B */ #define GIGADEVICE_GD25Q64 0x4017 /* Same as GD25Q64B */ #define GIGADEVICE_GD25Q128 0x4018 /* GD25Q128B and GD25Q128C only, can be distinguished by SFDP */ #define GIGADEVICE_GD25VQ21B 0x4212 #define GIGADEVICE_GD25VQ41B 0x4213 /* Same as GD25VQ40C, can be distinguished by SFDP */ #define GIGADEVICE_GD25VQ80C 0x4214 #define GIGADEVICE_GD25VQ16C 0x4215 #define GIGADEVICE_GD25LQ40 0x6013 #define GIGADEVICE_GD25LQ80 0x6014 #define GIGADEVICE_GD25LQ16 0x6015 #define GIGADEVICE_GD25LQ32 0x6016 #define GIGADEVICE_GD25LQ64 0x6017 /* Same as GD25LQ64B (which is faster) */ #define GIGADEVICE_GD25LQ128 0x6018 -- Regards, Hatim Kanchwala http://hatimak.me B. Tech. Electrical Engineering Indian Institute of Technology Patna

1 1

Programming N25Q128
by Steve Miller 01 Apr '16

01 Apr '16

FYI, This is informational only. I can program the ROM. When programming the N25Q128 from the Raspberry PI, I will get verification errors. If I push it up the hill several times, it will eventually pass. The N25Q128 remains on the target board, I am hold the ARM processor on that board in RESET. The Raspberry PI is attached via a ribbon cable and 100 ohm series resistors. Since my system is unique, it is entirely possible that this is just an artifact of my setup. However, the message as pasted below, asked me to report it, so I am doing that. I tried both the release and the latest snapshot. Both seem to operate the same. I tried three different target boards with the N25Q128 and all operate the same. Verification fails, but if I repeat the programming operation several times, it will pass. Please note the message at the end. The previous program and verify attempt failed. However, when I tried again, it aborted early because what I was attempting to program into the part already matched the parts contents. AKA, nothing to do. ---- Steve ************************************************************************************************************* Verifying flash... FAILED at 0x00022f00! Expected=0x61, Found=0xff, failed byte count from 0x00000000-0x00ffffff: 0x100 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! Verifying flash... FAILED at 0x0001cc92! Expected=0x83, Found=0x9f, failed byte count from 0x00000000-0x00ffffff: 0x68 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! Warning: Chip content is identical to the requested image. Erase/write done.

1 0

Re: [flashrom] Programming N25Q256 ?
by Steve Miller 01 Apr '16

01 Apr '16

Thanks David for the very quick feedback. For others that might see a similar symptom of MISO not toggling, here is what I did wrong. This part is a QSPI. It can work in a number of modes, for single bit SPI, up through four bit SPI. On the board, there were some missing pullup resistors. MISO, #HOLD, and #WP did not have pullups. When I added 4.7K ohm pullups to those three pins, the MISO started toggling and flashrom reported that “This flash part has status NOT WORKING for operations: PROBE READ ERASE WRITE “ This is to be expected, as the N25Q256 is not supported. On this Micron part, the #HOLD, and #WIP pins are dual function. In four bit mode, they are data bits. Therefore, the need for pullups is not obvious. However, until I added them, the part was dead as a mackerel. I could not find the Chromium branch, so I could not try that version. I did try the latest release candidate, but it operated the same. However, we don’t really need that large a PROM, so we have N25Q128 chips on order for delivery tomorrow. I believe that one is supported, so we should be able to program after swapping the chip. From: David Hendricks [mailto:dhendrix@google.com] Sent: Wednesday, March 30, 2016 06:11 PM To: Steve Miller Cc: flashrom(a)flashrom.org Subject: Re: [flashrom] Programming N25Q256 ? On Wed, Mar 30, 2016 at 3:14 PM, Steve Miller <stevem(a)tanisys.com<mailto:stevem@tanisys.com>> wrote: Hi, I have the code built and running on a Raspberry PI. Unfortunately, the target part I am trying to program is a Micron N25Q256. I don’t see that part in the list. When I execute the program with –VV it seems to scan lots of devices. I see activity on CLK, CS, MOSI with an oscilloscope. But MISO remains logic low. When the program terminates, it just tells me No EEPROM/Flash device found. Stupid Noob Questions: 1. Is the static level on MISO to be expected? Or should it at least toggle? You should definitely see some activity on MISO. Flashrom sends identification instructions (RDID, REMS, etc) to the chip and the chip should respond with its JEDEC-assigned manufacturer ID and vendor-specific device info. That said, the N25Q256 is not currently added in upstream flashrom. There is limited support in the Chromium branch, though. 2. Is there any hope with this device? Can I perhaps force it to think the chip is smaller? Yep, that's what we currently do in the Chromium branch*. The chip uses 24-bit addresses unless either a bit in a nonvolatile config register is set or alternate instructions which accept 32-bit addresses are used. *Full 4-byte address support should be ready soon, I just need to find a few spare cycles to finish up what I have written... -- David Hendricks (dhendrix) Systems Software Engineer, Google Inc.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

flashrom