On Mon, 9 May 2016 20:46:18 -0700
David Hendricks <dhendrix(a)google.com> wrote:
> Hi Victor,
> From Flashrom's software perspective all chips with the same ID are
> indistinguishable.
>
> Part number often includes characteristics such as package and thermal
> tolerance which do not affect software compatibility.
However, we will add the new names to the in-program (and hence
wiki) database so that this new information becomes public. Thanks for
the heads up, Victor.
--
Kind regards/Mit freundlichen Grüßen, Stefan Tauner
Hi,
we're hitting the 80 column limit in our code in ways which actually
reduce readability for the code. Examples are various multiline messages
and complicated nested code where refactoring to a separate function
doesn't make sense.
Keeping the old 80 column limit is not really an option anymore.
Standard terminal sizes have one of 80, 100 or 132 columns.
Given the monitor resolutions many people have nowadays, I think it is
safe to say that you can fit two xterms with 100 columns horizonally
next to each other. 100 columns should also be sufficient for a msg_p*
of roughly 80 columns of text.
132 columns provide more leeway, but IMHO that would be too wide for
good readability (and my screen can't fit two xterms side-by-side anymore).
Of course some files have sections where any column limit is not
acceptable (board lists etc.), but the column limit violations should be
limited to the affected file sections, not whole files.
Comments?
I'd like to get this decided today or tomorrow so we know where we need
line breaks in Stefan Tauner's new struct flashchip patch.
Regards,
Carl-Daniel
--
http://www.hailfinger.org/
I have a spansion S25FL128P......X chip and can do some tests.
The "problem" is that i don't know if its an 0 or an 1.
On the chip i see only "FL128PIF" and one line lower i see "00299012 C".
Probing works (id1 0x01, id2 0x2018):
Calibrating delay loop... OK.
serprog: Programmer name is "serprog-duino"
Found Spansion flash chip "S25FL128P......0" (16384 kB, SPI) on serprog.
Found Spansion flash chip "S25FL128P......1" (16384 kB, SPI) on serprog.
Found Spansion flash chip "S25FL128S......0" (16384 kB, SPI) on serprog.
Found Spansion flash chip "S25FL128S......1" (16384 kB, SPI) on serprog.
Found Spansion flash chip "S25FL129P......0" (16384 kB, SPI) on serprog.
Found Spansion flash chip "S25FL129P......1" (16384 kB, SPI) on serprog.
Multiple flash chip definitions match the detected chip(s):
"S25FL128P......0", "S25FL128P......1", "S25FL128S......0",
"S25FL128S......1", "S25FL129P......0", "S25FL129P......1"
Please specify which chip definition to use with the -c <chipname> option.
BTW: Chip was fund on a Dell-Systemboard.
On Sun, 31 Jul 2016 15:34:18 +0530
Pradeep Ch <pradeepsysargus(a)gmail.com> wrote:
> favorite
> <http://stackoverflow.com/questions/38674226/flashrom-tool-command-has-fai...>
>
> I am able to detect my flash chip when I use the command:
>
> ./flashrom -p ft2232_spi:type=arm-usb-ocd -c EN25Q64
>
> If use the below command to write binary file to the flash memory using
> JTAG - ARM-USB-OCD debugger for my target board RT5350F-OLinuXino-EVB,
>
> ./flashrom -p ft2232_spi:type=arm-usb-ocd -w
> FlashImage_RT5350F_OLinuXino_EVB.bin
>
> I am getting an error, the error is:
>
> Found Eon flash chip "EN25Q64" (8192 kB, SPI) on ft2232_spi.
> ftdi_write_data: -110, usb bulk write failed
> send_buf failed before read: 1
> Reading old flash chip contents... ftdi_read_data: -110, usb bulk read failed
> get_buf failed: 1
> FAILED.
Do you power the whole setup via the OCD? That might be the culprit. I
presume that it can not supply enough current in all operating modes.
Apparently it is enough to probe for the chip though...
--
Kind regards/Mit freundlichen Grüßen, Stefan Tauner
favorite
<http://stackoverflow.com/questions/38674226/flashrom-tool-command-has-fai...>
I am able to detect my flash chip when I use the command:
./flashrom -p ft2232_spi:type=arm-usb-ocd -c EN25Q64
If use the below command to write binary file to the flash memory using
JTAG - ARM-USB-OCD debugger for my target board RT5350F-OLinuXino-EVB,
./flashrom -p ft2232_spi:type=arm-usb-ocd -w
FlashImage_RT5350F_OLinuXino_EVB.bin
I am getting an error, the error is:
Found Eon flash chip "EN25Q64" (8192 kB, SPI) on ft2232_spi.
ftdi_write_data: -110, usb bulk write failed
send_buf failed before read: 1
Reading old flash chip contents... ftdi_read_data: -110, usb bulk read failed
get_buf failed: 1
FAILED.
Please let me know,
Thanks,
Pradeep Ch.
Allow myusec_calibrate_delay() to indicate errors and abort
in cli_classic if that happens.
Signed-off-by: Stefan Tauner <stefan.tauner(a)alumni.tuwien.ac.at>
---
cli_classic.c | 6 +++++-
programmer.h | 2 +-
udelay.c | 22 ++++++++++++++--------
3 files changed, 20 insertions(+), 10 deletions(-)
Roxfan on IRC had major problems getting flashrom to even start because
of some hardware-related timing problems. Without this patch his hardware
would (almost?) endlessly loop during timer calibration. This patch
aborts instead after a while and should not trigger any regressions.
One can test it by overriding the gettimeofday results in measure_delay()
by adding following assignments:
start.tv_sec = 0;
end.tv_sec = 0;
start.tv_usec = 0;
end.tv_usec = 0;
diff --git a/cli_classic.c b/cli_classic.c
index a2c2014..4a68f0b 100644
--- a/cli_classic.c
+++ b/cli_classic.c
@@ -414,7 +414,11 @@ int main(int argc, char *argv[])
}
/* FIXME: Delay calibration should happen in programmer code. */
- myusec_calibrate_delay();
+ if (myusec_calibrate_delay() != 0) {
+ msg_perr("Error: Custom timer calibration failed.\n");
+ ret = 1;
+ goto out_shutdown;
+ }
if (programmer_init(prog, pparam)) {
msg_perr("Error: Programmer initialization failed.\n");
diff --git a/programmer.h b/programmer.h
index bd8e98d..b39fba4 100644
--- a/programmer.h
+++ b/programmer.h
@@ -268,8 +268,8 @@ extern const struct board_info laptops_known[];
#endif
/* udelay.c */
+int myusec_calibrate_delay(void);
void myusec_delay(unsigned int usecs);
-void myusec_calibrate_delay(void);
void internal_sleep(unsigned int usecs);
void internal_delay(unsigned int usecs);
diff --git a/udelay.c b/udelay.c
index 7c6961d..3562268 100644
--- a/udelay.c
+++ b/udelay.c
@@ -85,7 +85,7 @@ static unsigned long measure_delay(unsigned int usecs)
return timeusec;
}
-void myusec_calibrate_delay(void)
+int myusec_calibrate_delay(void)
{
unsigned long count = 1000;
unsigned long timeusec, resolution;
@@ -106,16 +106,21 @@ recalibrate:
if (timeusec > 1000000 / 4)
break;
if (count >= ULONG_MAX / 2) {
- msg_pinfo("timer loop overflow, reduced precision. ");
+ msg_pwarn("timer loop overflow (count=%lu, micro=%lu, timeusec=%lu), reduced precision.\n",
+ count, micro, timeusec);
break;
}
count *= 2;
}
tries ++;
- /* Avoid division by zero, but in that case the loop is shot anyway. */
- if (!timeusec)
- timeusec = 1;
+ /* Something is completely wrong. Avoid a possible endless loop and fall back to internal_delay(). */
+ if (timeusec == 0) {
+ micro = 0;
+ msg_pwarn("Timing measurement seems to be broken.\n"
+ "Falling back to possibly insufficient timing sources!\n");
+ return 1;
+ }
/* Compute rounded up number of loops per microsecond. */
micro = (count * micro) / timeusec + 1;
@@ -168,6 +173,7 @@ recalibrate:
msg_pdbg("%ld myus = %ld us, ", resolution * 4, timeusec);
msg_pinfo("OK.\n");
+ return 0;
}
/* Not very precise sleep. */
@@ -187,7 +193,7 @@ void internal_sleep(unsigned int usecs)
void internal_delay(unsigned int usecs)
{
/* If the delay is >1 s, use internal_sleep because timing does not need to be so precise. */
- if (usecs > 1000000) {
+ if (micro == 0 || usecs > 1000000) {
internal_sleep(usecs);
} else {
myusec_delay(usecs);
@@ -197,9 +203,9 @@ void internal_delay(unsigned int usecs)
#else
#include <libpayload.h>
-void myusec_calibrate_delay(void)
+int myusec_calibrate_delay(void)
{
- get_cpu_speed();
+ return get_cpu_speed() == 0; // Return 1 on errors, i.e. if get_cpu_speed() returns 0
}
void internal_delay(unsigned int usecs)
--
Kind regards, Stefan Tauner
Hi,
Following patches add new infrastructure for status register(s) and locking/unlocking of access protection. Detailed points for explaining each patch are included within them.
Some general thoughts -
- The code has a lot TODOs and FIXMEs (most of which I have addressed to myself). They are short-term targets and represent the work-in-progress nature of the patches. Future revisions will resolve them.
- There are a lot of comments. Eventually much of that will be relocated to documentation and wiki, so comments in future revisions will shrink.
- Some CLI code is borrowed from the ChromiumOS fork (https://chromium.googlesource.com/chromiumos/third_party/flashrom/). IMO, the exact words to use for the options is subjective.
- The names for struct status_register and struct wp defines (in statusreg_layouts.c and writeprotect_layouts.c respectively) are not very creative and tend to be long. I couldn't come up with a generic scheme that captures most of the information regarding it. You are welcome to offer creative suggestions ;)
Further work -
- Read and write "configuration" registers (a lot of Spansion chips have those)
- Add tested/untested status for new infrastructure similar to what we have for chips (like TEST_PREW, etc.)
- write protection modes
- protection ranges
- Access protection for non-SPI chips (pointed to by Stefan over IRC)
- Reuse layouts for locking/unlocking (pointed to by Stafan and David over IRC)
- Handling WPS bit (a couple of GigaDevice chips have this)
- Exotic chips (mostly Atmel, now Adesto, chips fall under this category)
This is what I particularly seek -
- Feedback on code
- Feedback on CLI
- Any other ideas that you'd like to add tu further work
- Please add support for a few chips that you might have, and if possible also test them - would like to know how cumbersome it is
Thank you for your time. I am looking forward to your feedback and having a discussion. I hope this contribution (and many more in the future) adds value to flashrom and its community.
Bye,
Hatim
Hatim Kanchwala (6):
Status register infrastructure
Locking/unlocking access protection infrastructure
WIP: Add support for status register infrastructure to existing chips
WIP: Add support for access protection infrastructure to existing
chips
Integrate new infrastructure with existing codebase
Add command-line interface to expose new infrastructure
Makefile | 6 +-
chipdrivers.h | 24 +++
cli_classic.c | 200 +++++++++++++++++++++++-
flash.h | 46 +++++-
flashchips.c | 176 +++++++++++++++++----
flashrom.8.tmpl | 56 ++++++-
flashrom.c | 17 +-
spi.h | 8 +-
spi25.c | 164 +++++++++++++++----
spi25_statusreg.c | 416 +++++++++++++++++++++++++++++++++++++++++++++++++
spi25_statusreg.h | 115 ++++++++++++++
statusreg_layouts.c | 320 +++++++++++++++++++++++++++++++++++++
writeprotect.c | 405 +++++++++++++++++++++++++++++++++++++++++++++++
writeprotect.h | 40 +++++
writeprotect_layouts.c | 166 ++++++++++++++++++++
15 files changed, 2083 insertions(+), 76 deletions(-)
create mode 100644 spi25_statusreg.h
create mode 100644 statusreg_layouts.c
create mode 100644 writeprotect.c
create mode 100644 writeprotect.h
create mode 100644 writeprotect_layouts.c
--
2.7.4
This kind of chip seems to be behind Altera's EPCQ16 that is used
to store configuration of FPGAs on some boards. No official
datasheet matching the chip is available. The chip definition
bases on the datasheet of the EPCQ16 and other Micron chips
of the same familiy.
Its existence and functionality via SFDP was reported by Peter Ma.
Signed-off-by: Stefan Tauner <stefan.tauner(a)alumni.tuwien.ac.at>
On Thu, 28 Jul 2016 19:59:59 +0000
"Ma, Peter" <peter.ma(a)intel.com> wrote:
> I just received a new set of boards with the Altera EPCQ16 that we discussed before. Something odd happened: I would use flashrom and it would do the usual "SFDP-capable chip" (2048 kB, SPI).
>
> But on subsequent tries (even after re-boots), flashrom is coming back with:
> Found ST flash chip "unknown ST SPI chip" (0 kB, SPI)
>
> Have any idea as to what could be going wrong?
Not exactly, no. Apparently something you did changed the chip's reaction
to the SFDP query opcode or something similar. You could try lowering the
SPI frequency and look for a changed behavior while probing for SFDP.
If that fails you could also try the attached patch that adds a chip
definition that should work for your variation as well.
---
flashchips.c | 39 ++++++++++++++++++++++++++++++++++++++-
flashchips.h | 2 ++
2 files changed, 40 insertions(+), 1 deletion(-)
diff --git a/flashchips.c b/flashchips.c
index 40b6b8e..30c50ca 100644
--- a/flashchips.c
+++ b/flashchips.c
@@ -9505,7 +9505,7 @@ const struct flashchip flashchips[] = {
{
.vendor = "Micron/Numonyx/ST",
- .name = "N25Q016",
+ .name = "N25Q016..1E",
.bustype = BUS_SPI,
.manufacture_id = ST_ID,
.model_id = ST_N25Q016__1E,
@@ -9542,6 +9542,43 @@ const struct flashchip flashchips[] = {
{
.vendor = "Micron/Numonyx/ST",
+ .name = "N25Q016..3E",
+ .bustype = BUS_SPI,
+ .manufacture_id = ST_ID,
+ .model_id = ST_N25Q016__3E,
+ .total_size = 2048,
+ .page_size = 256,
+ /* supports SFDP */
+ /* OTP: 64B total; read 0x4B, write 0x42 */
+ .feature_bits = FEATURE_WRSR_WREN | FEATURE_OTP,
+ .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,
+ }, {
+ .eraseblocks = { {2 * 1024 * 1024, 1} },
+ .block_erase = spi_block_erase_c7,
+ }
+ },
+ .printlock = spi_prettyprint_status_register_n25q, /* TODO: config, lock, flag regs */
+ .unlock = spi_disable_blockprotect_n25q, /* TODO: per 64kB sector lock registers */
+ .write = spi_chip_write_256, /* Multi I/O supported */
+ .read = spi_chip_read, /* Fast read (0x0B) and multi I/O supported */
+ .voltage = {2700, 3600},
+ },
+
+ {
+ .vendor = "Micron/Numonyx/ST",
.name = "N25Q032..1E",
.bustype = BUS_SPI,
.manufacture_id = ST_ID,
diff --git a/flashchips.h b/flashchips.h
index 9ffb30f..7dfe985 100644
--- a/flashchips.h
+++ b/flashchips.h
@@ -839,6 +839,8 @@
#define ST_MT28GU256___2 0x8904
#define ST_MT28GU512___1 0x887E
#define ST_MT28GU512___2 0x8881
+/* The N25Q family is also used by Altera in its EPCQ series. */
+#define ST_N25Q016__3E 0xBA15 /* N25Q016, 3.0V, (uniform sectors expected) */
#define ST_N25Q016__1E 0xBB15 /* N25Q016, 1.8V, (uniform sectors expected) */
#define ST_N25Q032__3E 0xBA16 /* N25Q032, 3.0V, (uniform sectors expected) */
#define ST_N25Q032__1E 0xBB16 /* N25Q032, 1.8V, (uniform sectors expected) */
--
Kind regards, Stefan Tauner
On Thu, 30 Jun 2016 17:21:54 +0000
"Ma, Peter" <peter.ma(a)intel.com> wrote:
> I understand the not wanting to allow casual users to not accidentally mis-program their BIOS. But it does make flashrom not very useful for non-BIOS uses -- like programming FPGA bitstreams, etc.
One more thing regarding that: the way to go in that case at least for
now is to pad the payload data with 0xFF to reach the flash chip size
(either in front or back of the payload depending on the application's
need).
Cf. https://www.flashrom.org/pipermail/flashrom/2013-October/011828.html
--
Kind regards/Mit freundlichen Grüßen, Stefan Tauner
