On Sat, 31 May 2014 05:04:56 +0200
Stefan Tauner <stefan.tauner(a)alumni.tuwien.ac.at> wrote:
> diff --git a/flashrom.c b/flashrom.c
> index 98101b7..fdb5cf7 100644
> --- a/flashrom.c
> +++ b/flashrom.c
> @@ -1770,6 +1770,8 @@ int selfcheck(void)
> }
> }
>
+ #if CONFIG_INTERNAL == 1
> + ret |= selfcheck_board_enables();
+ #endif
> +
> /* TODO: implement similar sanity checks for other arrays where deemed necessary. */
> return ret;
> }
because the whole board_enable.c file is not compiled in without it
--
Kind regards/Mit freundlichen Grüßen, Stefan Tauner
CID1130005: Array compared against 0
The address of an array is never NULL, so the comparison will always evaluate
the same way.
In selfcheck: Array compared against NULL pointer
Since the array is defined unconditionally in C code the check does not really
make sense. It might make more sense to check whether there are entries in the
array, but that is not required on all platforms so far.
Signed-off-by: Stefan Reinauer <stefan.reinauer(a)coreboot.org>
Index: print.c
===================================================================
--- print.c (revision 1763)
+++ print.c (working copy)
@@ -1073,7 +1073,7 @@
B("ZOTAC", "ZBOX HD-ID11", OK, NULL, NULL),
#endif
- {0},
+ {NULL},
};
/* Please keep this list alphabetically ordered by vendor/board. */
@@ -1101,6 +1101,6 @@
B("Lenovo", "3000 V100 TF05Cxx", OK, "http://www5.pc.ibm.com/europe/products.nsf/products?openagent&brand=Lenovo3…", NULL),
#endif
- {0},
+ {NULL},
};
#endif
Index: flashrom.c
===================================================================
--- flashrom.c (revision 1763)
+++ flashrom.c (working copy)
@@ -1759,24 +1759,6 @@
if (selfcheck_eraseblocks(chip))
ret = 1;
-#if CONFIG_INTERNAL == 1
- if (chipset_enables == NULL) {
- msg_gerr("Chipset enables table does not exist!\n");
- ret = 1;
- }
- if (board_matches == NULL) {
- msg_gerr("Board enables table does not exist!\n");
- ret = 1;
- }
- if (boards_known == NULL) {
- msg_gerr("Known boards table does not exist!\n");
- ret = 1;
- }
- if (laptops_known == NULL) {
- msg_gerr("Known laptops table does not exist!\n");
- ret = 1;
- }
-#endif
return ret;
}
Hello,
I had some success programming the Spansion "S25FL128S......0" with
usbblaster_spi (Altera USB blaster cheap clone).
The read function works OK. The write function fails the first time but if
I run it again it works the second time (this is consistent, I've done it
on 3 different chips). It appears the first time it does Erase then Write,
but only the erasing works. The second time it's already erased from the
first run and the write works OK.
Log attached.
Best regards,
Liviu Toma
Signed-off-by: Stefan Tauner <stefan.tauner(a)alumni.tuwien.ac.at>
---
print_wiki.c | 30 ++++++++++++++++++++++++++----
1 file changed, 26 insertions(+), 4 deletions(-)
diff --git a/print_wiki.c b/print_wiki.c
index b01ab75..6af277a 100644
--- a/print_wiki.c
+++ b/print_wiki.c
@@ -29,11 +29,33 @@
static const char wiki_header[] = "= Supported devices =\n\n\
<div style=\"margin-top:0.5em; padding:0.5em 0.5em 0.5em 0.5em; \
-background-color:#eeeeee; text-align:right; border:1px solid #aabbcc;\">\
+background-color:#eeeeee; text-align:left; border:1px solid #aabbcc;\">\
<small>\n\
-Please do '''not''' edit these tables in the wiki directly, they are \
-generated by pasting '''flashrom -z''' output.<br />\
-'''Last update:''' %s(generated by flashrom %s)\n</small></div>\n";
+'''Last update:''' %s(generated by flashrom %s)<br />\n\
+The tables below are generated from flashrom's source by copying the output of '''flashrom -z'''.<br /><br />\n\
+A short explanation of the cells representing the support state follows:<br />\n\
+{| border=\"0\" valign=\"top\"\n\
+! style=\"text-align:left;\" |\n\
+! style=\"text-align:left;\" |\n\
+|-\n\
+|{{OK}}\n\
+| The feature was '''tested and should work''' in general unless there is a bug in flashrom or another component in \
+the system prohibits some functionality.\n\
+|-\n\
+|{{Dep}}\n\
+| '''Configuration-dependent'''. The feature was tested and should work in general but there are common \
+configurations that drastically limit's flashrom capabilities or make it completely stop working.\n\
+|-\n\
+|{{?3}}\n\
+| The feature is '''untested''' but believed to be working.\n\
+|-\n\
+|{{NA}}\n\
+| The feature is '''not applicable''' in this configuration (e.g. Write operations on ROM chips).\n\
+|-\n\
+|{{No}}\n\
+| The feature is '''known to not work'''. Don't bother testing (nor reporting).\n\
+|}\n\
+</small></div>\n";
static const char th_start[] = "| valign=\"top\"|\n\n\
{| border=\"0\" style=\"font-size: smaller\" valign=\"top\"\n\
--
Kind regards, Stefan Tauner
Author: stefanct
Date: Fri May 30 21:34:00 2014
New Revision: 1806
URL: http://flashrom.org/trac/flashrom/changeset/1806
Log:
Fix PMC Pm25LV512 and Pm25LV010 probing.
Apparently PMC did not understand the purpose of the JEDEC
continuation code. These chips reply to RES (the only supported ID
command) with the prefix-less vendor ID, a device ID, eventually
followed by the continuation byte for the vendor ID.
This fix uses only the first two bytes instead of appending the
continuation code to the device ID. The problem was reported by The
Raven who also tested the fix on a Pm25LV010 (with an imprint of
"Pm25LV010E").
Signed-off-by: Stefan Tauner <stefan.tauner(a)alumni.tuwien.ac.at>
Acked-by: Stefan Tauner <stefan.tauner(a)alumni.tuwien.ac.at>
Modified:
trunk/flashchips.c
trunk/flashchips.h
Modified: trunk/flashchips.c
==============================================================================
--- trunk/flashchips.c Thu May 29 13:51:24 2014 (r1805)
+++ trunk/flashchips.c Fri May 30 21:34:00 2014 (r1806)
@@ -8595,13 +8595,13 @@
.vendor = "PMC",
.name = "Pm25LV512(A)",
.bustype = BUS_SPI,
- .manufacture_id = PMC_ID,
+ .manufacture_id = PMC_ID_NOPREFIX,
.model_id = PMC_PM25LV512,
.total_size = 64,
.page_size = 256,
.feature_bits = FEATURE_WRSR_WREN,
.tested = TEST_UNTESTED,
- .probe = probe_spi_res3,
+ .probe = probe_spi_res2, /* The continuation code is transferred as the 3rd byte m( */
.probe_timing = TIMING_ZERO,
.block_erasers =
{
@@ -8627,13 +8627,13 @@
.vendor = "PMC",
.name = "Pm25LV010",
.bustype = BUS_SPI,
- .manufacture_id = PMC_ID,
+ .manufacture_id = PMC_ID_NOPREFIX,
.model_id = PMC_PM25LV010,
.total_size = 128,
.page_size = 256,
.feature_bits = FEATURE_WRSR_WREN,
- .tested = TEST_UNTESTED,
- .probe = probe_spi_res3,
+ .tested = TEST_OK_PREW,
+ .probe = probe_spi_res2, /* The continuation code is transferred as the 3rd byte m( */
.probe_timing = TIMING_ZERO,
.block_erasers =
{
Modified: trunk/flashchips.h
==============================================================================
--- trunk/flashchips.h Thu May 29 13:51:24 2014 (r1805)
+++ trunk/flashchips.h Fri May 30 21:34:00 2014 (r1806)
@@ -503,7 +503,8 @@
/*
* Programmable Micro Corp is listed in JEP106W in bank 2, so it should
* have a 0x7F continuation code prefix.
- * Apparently this name is owned by "Chingis Technology Corporation" http://www.chingistek.com.
+ * Apparently this name is owned by "Chingis Technology Corporation" http://www.chingistek.com which is now a
+ * subsidiary of ISSI. They continue to use the PMC manufacturer ID nevertheless.
*/
#define PMC_ID 0x7F9D /* PMC */
#define PMC_ID_NOPREFIX 0x9D /* PMC, missing 0x7F prefix */
On Thu, 29 May 2014 10:38:01 -0500
Bernardo Kuri <contact(a)bkuri.com> wrote:
> Hello,
>
> Looks like everything went smoothly. I have attached the output in a text
> file.
> BTW, the board is a Zotac IONITX-F-E Intel Atom 330.
Hello Bernardo,
thanks for your report!
I have added your board to our list of supported hardware and will
commit that later together with other small changes.
The flash chip was already marked as fully tested.
--
Kind regards/Mit freundlichen Grüßen, Stefan Tauner