I have an Spansion/ Cypress FL256SAIF00
(http://www.cypress.com/file/177966/download) , I'd like to write to.
I added the diff to recognize the chip, but I believe I did something
wrong- can you help?
The __MINGW_PRINTF_FORMAT constant has been defined back in 2012
However older toolchains are still around and some user reported the
following compilation failure:
flash.h:336:1: error: '__MINGW_PRINTF_FORMAT' is an unrecognized format function type [-Werror=format=]
__attribute__((format(__MINGW_PRINTF_FORMAT, 2, 3)));
Fix this by defining the constant when it isn't already; the change does
not affect other compilers because it's guarded by "#ifdef __MINGW32__".
Setting __MINGW_PRINTF_FORMAT to gnu_printf is exactly what newer MinGW
versions do when __USE_MINGW_ANSI_STDIO is defined, which it is in
Tested-by: Miklos Marton <martonmiklosqdev(a)gmail.com>
Signed-off-by: Antonio Ospite <ao2(a)ao2.it>
flash.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/flash.h b/flash.h
index a80a9c2..40a7f1a 100644
@@ -360,6 +360,9 @@ int flashrom_print_cb(enum flashrom_log_level level, const char *fmt, va_list ap
/* Let gcc and clang check for correct printf-style format strings. */
int print(enum flashrom_log_level level, const char *fmt, ...)
+# ifndef __MINGW_PRINTF_FORMAT
+# define __MINGW_PRINTF_FORMAT gnu_printf
__attribute__((format(__MINGW_PRINTF_FORMAT, 2, 3)));
__attribute__((format(printf, 2, 3)));
I just flashed my Gigabyte Brix GB-BXi7H-5500, Intel Broadwell U Premium,
under Linux (debian sid), using flashrom v0.9.9-r1954 on Linux
Worked like a charm, I just needed to boot using iomem=relaxed.
The chip is marked as "untested", hope this success report will help.
Big thanx for the great job, please keep-on doing it !
On 06.03.2018 22:13, Luca Bacci Bonotti wrote:
> In your opinion is better the raspberry pi or ch341a to reach my goal?
I don't know. I doubt it makes much of a difference. If one fails, you
can try the other. Though, the RPi is much faster.
> Should I buy a breadboard for create better connections ?
Better than what?
> Can you draw a schematic that I can follow?
Sigh, I guess I can.
Programmer SPI Flash
/CS ------------ /CS
MISO ---50-Ohm--- MISO
GND ------------ GND
MOSI ------------ MOSI
CLK ------------ CLK
VCC ------------ VCC
This is about the minimum setup I'd use for a plain (unsoldered)
chip. Resistor ratings may vary.
> Il 6 mar 2018 21:55, "Nico Huber" <nico.h(a)gmx.de> ha scritto:
>> Hello Luca,
>> On 06.03.2018 07:25, Luca Bacci Bonotti wrote:
>>> I tried with chip soldered and unsoldered. Same results.
>> same results? probably due to very different problems. Especially when
>> the chip is not part of a circuitry (that might already take care), you
>> have to connect all input pins of the chip. Also, very often, a series
>> resistor at least on the MISO output is required.
>>> I previously tried programming with raspberry PI but it was unable to see
>>> my chip.
>>> I have both CH341A and Raspberry Pi.
>> When you use the Raspberry Pi, make sure you set the `spispeed` parame-
>> ter of linux_spi to something reasonable (I'd start trying around 1000,
>> i.e. 1MHz), the default is OS dependent and often not reliable.
>>> Where should i connect /HOLD /WP on the CH341A ?
>> /HOLD should be pulled up towards VCC (i.e. using a series resistor,
>> 10kOhm maybe), state of /WP usually only matters when the chip has some
>> write-protection set up, so either pull up towards VCC or down towards
>> GND (if in doubt, up).
On 06.03.2018 00:20, Jesse Li wrote:
> I'm trying to read from and flash to a W25X40ALSNIG  that's still
> mounted to its hard drive PCB. Following the table from the raspberry pi
> wiki page , and assuming the raspberry pi pin numbers it mentions are
> physical pin numbers (and not the pi's strange GPIO numbering scheme) I
> connected the legs of the flash chip to the raspberry pi's GPIO pins.
> However, when the two are attached, the pi won't boot (it'll show the three
> raspberries in the corner, then it shuts off). I've isolated this to the
> VCC (connected to header 17, 3v3) and GND (connected to header 25, GND) ,
> where having all of the legs of the flash chip detached from the pi except
> for those two will reproduce my problem (I hope testing that didn't
> actually kill the chip). What am I missing?
the circuitry of your hard drive is most likely not prepared for powe-
ring the flash chip directly at its VCC pin. You probably power all 3V3
parts on that PCB which is too much for your RPi's PSU / voltage conver-
Killing the SPI flash is unlikely. I can't say the same about other
chips on the board, though. Reading the flash while the hard drive is
up and running, probably also isn't a good idea. You could desolder the
flash chip, or try a stronger PSU, both ways have chances to break some-
On 06.03.2018 23:20, Matthew Leon wrote:
> Hey Nico,
> I am talking about the internal programmer for a piix4 chipset. For the
> read, I have gotten to spi_chip_read that returns
> flash->mst->spi.read(flash,buf,start,len) and I am trying to figure out
> where mst gets set, or how flashrom gathers the information to set it. For
> the write, I have gotten to spi_send_multicommand, after digging through
> spi_nbyte_program. Could you clue me in with a sample piix4 chipset?
AFAICS (from following the code in chipset_enable.c), PIIX4 doesn't
support SPI at all. Only parallel flash chips. And these work much
`flash->mst` gets set in probe_flash(). It's just the programmer you
select on the command line. For the `internal` programmer this is hard
to follow, though. In chipset_enable(), it's decided what that master
`mst` actually can do for a given chipset, mostly based on the PCI id
list in `chipset_enables`.
> flashrom read and write to hardware registers? Thank-you so much!
Yes, it does. In case of internal SPI controllers, it pokes registers
of that controller. In case of internal parallel flash chips, it seems
to directly access memory mapped registers of the flash chip. For the
latter have a look at jedec.c and the functions at the end of
Hope that helps,
On 06.03.2018 07:25, Luca Bacci Bonotti wrote:
> I tried with chip soldered and unsoldered. Same results.
same results? probably due to very different problems. Especially when
the chip is not part of a circuitry (that might already take care), you
have to connect all input pins of the chip. Also, very often, a series
resistor at least on the MISO output is required.
> I previously tried programming with raspberry PI but it was unable to see
> my chip.
> I have both CH341A and Raspberry Pi.
When you use the Raspberry Pi, make sure you set the `spispeed` parame-
ter of linux_spi to something reasonable (I'd start trying around 1000,
i.e. 1MHz), the default is OS dependent and often not reliable.
> Where should i connect /HOLD /WP on the CH341A ?
/HOLD should be pulled up towards VCC (i.e. using a series resistor,
10kOhm maybe), state of /WP usually only matters when the chip has some
write-protection set up, so either pull up towards VCC or down towards
GND (if in doubt, up).
I'm curious to know if it is possible to flash iPXE to these nics.
PCI-Id is listed in supported devices - 8086:1533 .
[root@urzospoc01 src]# flashrom -p nicintel_eeprom:pci=01:00.0
flashrom v1.0 on Linux 3.10.0-693.17.1.el7.x86_64 (x86_64)
flashrom is free software, get the source code at https://flashrom.org
Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns).
Found Programmer flash chip "Opaque flash chip" (4 kB,
Programmer-specific) on nicintel_eeprom.
No operations were specified.
When i build a rom for this specific nic the file has a size of 70kB.
Is there a way to get this rom to the nics?
Universität Leipzig / URZ
04109 Leipzig, Augustusplatz 10
Of all the gin joints in all the towns in all the world, Alex Henderson had to
walk into mine at 09:08 on Tuesday 06 March 2018 and say:
> Usually programming the firmware ROMs for Intel NICs requires software
> from Intel.
> e/manageability-products.html may do the trick. Alex
Yeah, except Intel's tools only support ROM images generated by Intel and
stored in their magic file format. You can't use them to flash your own custom
images. You can only do that with flashrom. :)
The problem here is that flashrom has to know the flash programming interface
used on the NIC, and sadly they aren't all the same. When I tried it, I used
an 82574L card. At the time it was not supported. However, the 82574 uses the
same programming interface as the 82571, which _was_ supported, so making it
work was just a matter of adding the 82574's device ID to the right table in
You can attempt to do the same thing with the i210, but I don't know offhand
if that will work. If it doesn't, then you'll have to download the programming
manual for the i210 and add a new programming algorithm to flashrom.
> -----Original Message-----
> From: flashrom [mailto:firstname.lastname@example.org] On Behalf Of Vadim
> Bulst Sent: Tuesday, March 6, 2018 12:51 AM
> To: flashrom(a)flashrom.org
> Subject: [flashrom] Flashing iPXE on Intel i210 on Supermicro X11SSL-F
> Dear list,
> I'm curious to know if it is possible to flash iPXE to these nics.
> PCI-Id is listed in supported devices - 8086:1533 .
> [root@urzospoc01 src]# flashrom -p nicintel_eeprom:pci=01:00.0 flashrom
> v1.0 on Linux 3.10.0-693.17.1.el7.x86_64 (x86_64) flashrom is free
> software, get the source code at https://flashrom.org
> Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns).
> Found Programmer flash chip "Opaque flash chip" (4 kB,
> Programmer-specific) on nicintel_eeprom.
> No operations were specified.
> When i build a rom for this specific nic the file has a size of 70kB.
> Is there a way to get this rom to the nics?
> Vadim Bulst
> Universität Leipzig / URZ
> 04109 Leipzig, Augustusplatz 10
> phone: +49-341-97-33380
> mail: vadim.bulst(a)uni-leipzig.de
> flashrom mailing list
-Bill Paul (510) 749-2329 | Senior Member of Technical Staff,
wpaul(a)windriver.com | Master of Unix-Fu - Wind River Systems
"I put a dollar in a change machine. Nothing changed." - George Carlin