Hi list,
I modified the rayer spi programmer source to be used with a Xilinx
parallel III (also called DLC5) programmer cable.
It's a trivial change of parallel port pins, but I did not know how the
support for this cable should be included into the source code. Copying
the same code to a separate file may not be a good idea.
--- flashrom/rayer_spi.c 2010-09-18 19:48:27.000000000 +0200
+++ ../flashrom/rayer_spi.c 2010-09-18 02:12:59.000000000 +0200
@@ -37,11 +37,11 @@
* independent and are bitshift values, not real pin numbers.
*/
/* Pins for master->slave direction */
-#define SPI_CS_PIN 5
-#define SPI_SCK_PIN 6
-#define SPI_MOSI_PIN 7
+#define SPI_CS_PIN 2
+#define SPI_SCK_PIN 1
+#define SPI_MOSI_PIN 0
/* Pins for slave->master direction */
-#define SPI_MISO_PIN 6
+#define SPI_MISO_PIN 4
static int lpt_iobase;
Thank you for working on this software, with access to the source code I
was able to program my w25q64 flash chip.
--
Peter JAKAB http://jap.hu/
Hi List,
this patch adds support for the Linux SPI subsystem. See
http://www.kernel.org/doc/Documentation/spi/spidev for a
short introduction.
Usage is as follows:
flashrom -p linux_spi:dev=/dev/spidevX.Y
where X is the bus number, and Y device. It accepts an optional
parameter 'speed' which allows to set the SPI CLK speed in KHz.
I'm using a AVR32 Board
(http://www.atmel.com/dyn/products/tools_card.asp?tool_id=4102) to
program my ThinkPad X60, but it should work on every Linux system.
Signed-off-by: Sven Schnelle <svens(a)stackframe.org>
On Wed, Aug 18, 2010 at 06:27:15PM +0200, Michael Karcher wrote:
> + * - ASUS P5LP-LE (Epson/HP OEM)
OK, this one is going to be interesting.
The board is made by ASUS for HP, it seems. HP calls it "Leonite" or "Leonite-GL8E".
http://h10025.www1.hp.com/ewfrf/wc/document?lc=en&dlc=en&cc=us&docname=c008…
But that would have been too easy. There are a bunch of other boards
on the HP site which are also called P5LP-LE, but have different HP code
names. From a quick glance I see at least:
P5LP-LE (Leonite)
P5LP-LE (Leonite2)
P5LP-LE (Lithium)
P5LP-LE (Limestone)
P5LP-LE (Emery)
Fun! I don't know how to differ between them, the dmidecode from Leon
Zhang <leoncamel(a)gmail.com> said:
DMI string system-manufacturer: "EPSON DIRECT CORP."
DMI string system-product-name: "Endeavor MT7700"
DMI string system-version: ""
DMI string baseboard-manufacturer: "ASUSTek Computer INC."
DMI string baseboard-product-name: "P5LP-LE"
We don't know if other "P5LP-LE" might have the "Leonite" (or other) HP code
name in there or not. Maybe something is printed as silkscreen on the board?
An then one of these HP OEM boards is built into the Epson
"Endeavor MT7700" system/PC.
So it's a bit unclear which vendor/board name we should use in this
case. It's probably best to mention all of them for better googling
results.
Attached is a slightly updated patch for review, let me know what you
think.
Uwe.
--
http://hermann-uwe.de | http://sigrok.orghttp://randomprojects.org | http://unmaintained-free-software.org
This patch is intended to avoid compilation issues caused by the ordering of
#includes in source files that use chipdrivers.h.
Signed-off-by: David Hendricks <dhendrix(a)google.com>
--
David Hendricks (dhendrix)
Systems Software Engineer, Google Inc.
Here is a new version of the internal dmi decoding. To use the new
decoder, the user needs to use "-p internal:dmi=new", to cross-check
with the external dmidecode use "-p internal:dmi=check". Hopefully if
this is comitted, it will make it easier for people to test the new
internal decoder.
Signed-off-by: Sean Nelson <audiohacked(a)gmail.com>
Always read the flash chip before writing. This will allow flashrom to
skip erase of already-erased blocks and to skip write of blocks which
already have the wanted contents.
Avoid emergency messages by checking if the chip contents after a failed
write operation (erase/write) are unchanged.
Keep the emergency messages after a failed pure erase. That part is
debatable because if someone wants erase, he pretty sure doesn't care
about the flash contents anymore.
Please note that this introduces additional overhead of a full chip read
before write. This is frowned upon by people with slow programmers.
Maybe we should make this configurable. Either way, this patch needs a
review to make sure I'm not going in the wrong direction.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net>
Index: flashrom-always_read_no_scary_warning/flash.h
===================================================================
--- flashrom-always_read_no_scary_warning/flash.h (Revision 1212)
+++ flashrom-always_read_no_scary_warning/flash.h (Arbeitskopie)
@@ -239,7 +239,7 @@
/* layout.c */
int read_romlayout(char *name);
int find_romentry(char *name);
-int handle_romentries(uint8_t *buffer, struct flashchip *flash);
+int handle_romentries(struct flashchip *flash, uint8_t *oldcontents, uint8_t *newcontents);
/* spi.c */
struct spi_command {
Index: flashrom-always_read_no_scary_warning/layout.c
===================================================================
--- flashrom-always_read_no_scary_warning/layout.c (Revision 1212)
+++ flashrom-always_read_no_scary_warning/layout.c (Arbeitskopie)
@@ -205,7 +205,7 @@
return -1;
}
-int handle_romentries(uint8_t *buffer, struct flashchip *flash)
+int handle_romentries(struct flashchip *flash, uint8_t *oldcontents, uint8_t *newcontents)
{
int i;
@@ -225,13 +225,12 @@
// normal will be updated and the rest will be kept.
for (i = 0; i < romimages; i++) {
-
if (rom_entries[i].included)
continue;
- flash->read(flash, buffer + rom_entries[i].start,
- rom_entries[i].start,
- rom_entries[i].end - rom_entries[i].start + 1);
+ memcpy(newcontents + rom_entries[i].start,
+ oldcontents + rom_entries[i].start,
+ rom_entries[i].end - rom_entries[i].start + 1);
}
return 0;
Index: flashrom-always_read_no_scary_warning/flashrom.c
===================================================================
--- flashrom-always_read_no_scary_warning/flashrom.c (Revision 1212)
+++ flashrom-always_read_no_scary_warning/flashrom.c (Arbeitskopie)
@@ -1343,6 +1343,19 @@
return ret;
}
+void nonfatal_help_message(void)
+{
+ msg_gerr("Writing to the flash chip apparently didn't do anything.\n"
+ "This means we have to add special support for your board, "
+ "programmer or flash chip.\n"
+ "Please report this on IRC at irc.freenode.net (channel "
+ "#flashrom) or\n"
+ "mail flashrom(a)flashrom.org!\n"
+ "-------------------------------------------------------------"
+ "------------------\n"
+ "You may now reboot or simply leave the machine running.\n");
+}
+
void emergency_help_message(void)
{
msg_gerr("Your flash chip is in an unknown state.\n"
@@ -1602,9 +1615,10 @@
*/
int doit(struct flashchip *flash, int force, char *filename, int read_it, int write_it, int erase_it, int verify_it)
{
- uint8_t *buf;
+ uint8_t *oldcontents;
+ uint8_t *newcontents;
int ret = 0;
- unsigned long size;
+ unsigned long size = flash->total_size * 1024;
if (chip_safety_check(flash, force, filename, read_it, write_it, erase_it, verify_it)) {
msg_cerr("Aborting.\n");
@@ -1612,9 +1626,6 @@
return 1;
}
- size = flash->total_size * 1024;
- buf = (uint8_t *) calloc(size, sizeof(char));
-
/* Given the existence of read locks, we want to unlock for read,
* erase and write.
*/
@@ -1627,6 +1638,12 @@
return ret;
}
if (erase_it) {
+ /* FIXME: Do we really want the scary warning if erase failed?
+ * After all, after erase the chip is either blank or partially
+ * blank or it has the old contents. A blank chip won't boot,
+ * so if the user wanted erase and reboots afterwards, the user
+ * knows very well that booting won't work.
+ */
if (erase_flash(flash)) {
emergency_help_message();
programmer_shutdown();
@@ -1634,33 +1651,71 @@
}
}
+ newcontents = (uint8_t *) calloc(size, sizeof(char));
+
if (write_it || verify_it) {
- if (read_buf_from_file(buf, flash->total_size * 1024, filename)) {
+ if (read_buf_from_file(newcontents, size, filename)) {
programmer_shutdown();
return 1;
}
#if CONFIG_INTERNAL == 1
- show_id(buf, size, force);
+ if (programmer == PROGRAMMER_INTERNAL)
+ show_id(newcontents, size, force);
#endif
}
+ oldcontents = (uint8_t *) calloc(size, sizeof(char));
+
+ /* Read the whole chip to be able to check whether regions need to be
+ * erased and to give better diagnostics in case write fails.
+ * The alternative would be to read only the regions which are to be
+ * preserved, but in that case we might perform unneeded erase which
+ * takes time as well.
+ */
+ msg_cdbg("Reading old flash chip contents...\n");
+ if (flash->read(flash, oldcontents, 0, size)) {
+ programmer_shutdown();
+ return 1;
+ }
+
// This should be moved into each flash part's code to do it
// cleanly. This does the job.
- handle_romentries(buf, flash);
+ handle_romentries(flash, oldcontents, newcontents);
// ////////////////////////////////////////////////////////////
if (write_it) {
if (erase_flash(flash)) {
+ msg_cerr("Uh oh. Erase failed. Checking if anything "
+ "changed.\n");
+ if (!flash->read(flash, newcontents, 0, size)) {
+ if (!memcmp(oldcontents, newcontents, size)) {
+ msg_cinfo("Good. It seems nothing was "
+ "changed.\n");
+ nonfatal_help_message();
+ programmer_shutdown();
+ return 1;
+ }
+ }
emergency_help_message();
programmer_shutdown();
return 1;
}
msg_cinfo("Writing flash chip... ");
- ret = flash->write(flash, buf, 0, flash->total_size * 1024);
+ ret = flash->write(flash, newcontents, 0, size);
if (ret) {
- msg_cerr("FAILED!\n");
+ msg_cerr("Uh oh. Write failed. Checking if anything "
+ "changed.\n");
+ if (!flash->read(flash, newcontents, 0, size)) {
+ if (!memcmp(oldcontents, newcontents, size)) {
+ msg_cinfo("Good. It seems nothing was "
+ "changed.\n");
+ nonfatal_help_message();
+ programmer_shutdown();
+ return 1;
+ }
+ }
emergency_help_message();
programmer_shutdown();
return 1;
@@ -1673,7 +1728,7 @@
/* Work around chips which need some time to calm down. */
if (write_it)
programmer_delay(1000*1000);
- ret = verify_flash(flash, buf);
+ ret = verify_flash(flash, newcontents);
/* If we tried to write, and verification now fails, we
* might have an emergency situation.
*/
--
http://www.hailfinger.org/
Hi Guys
I run into trouble using flashrom.
first I downloaded the ROM to flash
then I downloaded flashrom
and run the following command
----------
sudo flashrom
---------- Result:
flashrom v0.9.1-r946
No coreboot table found.
Found chipset "Intel ICH7/ICH7R", enabling flash write... OK.
This chipset supports the following protocols: FWH.
Calibrating delay loop... OK.
Found chip "SST SST49LF004A/B" (512 KB, FWH) at physical address
0xfff80000.
No operations were specified.
---------
I assumed that flashrom can burn my BIOS (since there was no warning given)
Then I tried
---------
sudo flashrom -wv Desktop/Downloads/P5LD2-2002.ROM
---------
Result was that two opperations are not permittet or so
After studying the man page I ran the following command
---------
sudo flashrom -w Desktop/Downloads/P5LD2-2002.ROM
---------
and got panic!!!!!!!
--------
flashrom v0.9.1-r946
No coreboot table found.
Found chipset "Intel ICH7/ICH7R", enabling flash write... OK.
This chipset supports the following protocols: FWH.
Calibrating delay loop... OK.
Found chip "SST SST49LF004A/B" (512 KB, FWH) at physical address
0xfff80000.
Flash image seems to be a legacy BIOS. Disabling checks.
Writing flash chip... Erasing flash chip... ERASE FAILED at
0x000002c8! Expected=0xff,
Read=0x4c, failed byte count from 0x00000000-0x00000fff: 0xd12
ERASE FAILED!
ERASE FAILED at 0x000002c8! Expected=0xff, Read=0x4c, failed byte
count from
0x00000000-0x0000ffff: 0xfc2b
ERASE FAILED!
FAILED!
ERASE FAILED!
FAILED!
Your flash chip is in an unknown state.
Get help on IRC at irc.freenode.net (channel #flashrom) or
mail flashrom(a)flashrom.org!
-------------------------------------------------------------------------------
DO NOT REBOOT OR POWEROFF!
-----------------------------------
PLEASE ADVICE what to do next.
LOOKING EAGERLY FORWARD to YOUR REPLY
Regards
Benjamin
--
Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief!
Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail
