flashrom

flashrom@flashrom.org

1 participants
9182 discussions

Re: [flashrom] Surface UEFI Bios flash
by Mike Banon 16 Mar '18

16 Mar '18

tear down that surface, locate a BIOS chip on the motherboard, write down the markings on the chip and look through this page https://www.flashrom.org/Supported_hardware to see if your chip is supported by flashrom On Fri, Mar 16, 2018 at 3:08 AM, dsingh <dsingh(a)wavestek.com> wrote: > Any idea if this software can flash surface pro 4 BIOS? > > Starting from surface pro4 Chip is manufactured by Microsoft. > > Thank you > > Dharmpreet Singh > > _______________________________________________ > flashrom mailing list > flashrom(a)flashrom.org > https://mail.coreboot.org/mailman/listinfo/flashrom

1 0

Surface UEFI Bios flash
by dsingh 16 Mar '18

16 Mar '18

Any idea if this software can flash surface pro 4 BIOS? Starting from surface pro4 Chip is manufactured by Microsoft. Thank you Dharmpreet Singh

1 0

Spansion FL256SAIF00
by Michael Fuckner 14 Mar '18

14 Mar '18

Hi, 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? Regards, Michael!

2 5

[PATCH] Fix compilation with older MinGW versions
by Antonio Ospite 13 Mar '18

13 Mar '18

The __MINGW_PRINTF_FORMAT constant has been defined back in 2012 https://sourceforge.net/p/mingw-w64/mingw-w64/ci/77bc5d6103b5fb9f59fbddab15… 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 flashrom Makefile. 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 --- a/flash.h +++ b/flash.h @@ -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, ...) #ifdef __MINGW32__ +# ifndef __MINGW_PRINTF_FORMAT +# define __MINGW_PRINTF_FORMAT gnu_printf +# endif __attribute__((format(__MINGW_PRINTF_FORMAT, 2, 3))); #else __attribute__((format(printf, 2, 3))); -- 2.16.2

1 1

lspci -nnvx of Asrock X370 Killer SLI Board
by "Björn Broden" 09 Mar '18

09 Mar '18

1 0

Success report - Intel Broadwell U Premium
by Laurent Grimaud 07 Mar '18

07 Mar '18

Hi there, 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 4.15.0-1-amd64. 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 ! -- Laurent

1 0

Re: [flashrom] Problem while erasing chip prior write bin file.
by Nico Huber 07 Mar '18

07 Mar '18

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 \ `-10kOhm--- /WP \ `-10kOhm- /HOLD This is about the minimum setup I'd use for a plain (unsoldered) chip. Resistor ratings may vary. Nico > > 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). >> >> Nico >> >

2 1

Re: [flashrom] Some troubles connecting a W25X40ALSNIG flash chip to raspberry pi (v3 model B)
by Nico Huber 07 Mar '18

07 Mar '18

Hi, On 06.03.2018 00:20, Jesse Li wrote: > Hey, > > I'm trying to read from and flash to a W25X40ALSNIG [0] that's still > mounted to its hard drive PCB. Following the table from the raspberry pi > wiki page [1], 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- ter. 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- thing. Nico

2 1

Re: [flashrom] Flashrom innerworkings
by Nico Huber 06 Mar '18

06 Mar '18

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 differently. `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`. > Does > 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 `internal.c`. Hope that helps, Nico

1 0

Re: [flashrom] Problem while erasing chip prior write bin file.
by Nico Huber 06 Mar '18

06 Mar '18

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). Nico

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

flashrom