External programmers
by Carl-Daniel Hailfinger
Hi,
I'm trying to find out which external programmers should be supported next.
1. There was talk of an AVR-based new programmer using the serprog
protocol on IRC by someone with the nick "coldelectrons", but I have no
idea if he/she is reading this mail. IMHO more hardware using the
serprog protocol is always a good idea.
2. All those Willem/Sivava variants. People regularly request those, but
I don't think anyone in here owns the hardware.
3. RayeR's SPIPGM. I have a preliminary patch which could work, but I
don't have the hardware. Will send the patch to the list soon.
4. LPC^2, Milksop, CheapLPC and other programmers from the Xbox modding
community.
5. Dozens of SPI programmer hardware projects scattered over the net.
Too many to count, and I'm not sure which of them has more than one user.
In general, it seems creating a new programmer hardware design is like
writing IRC clients: A nice way to get started in the field. I have no
problems merging flashrom support for all of them, but I won't implement
support for all of them myself.
Regards,
Carl-Daniel
--
http://www.hailfinger.org/
3 years, 4 months
[PATCH] Unlock ST M50FW002 correctly
by Carl-Daniel Hailfinger
Unlock ST M50FW002 correctly
Refactor ST M50 family unlocking
TODO:
Unify write_lockbits_49fl00x() and unlock_block_stm50() and
unlock_w39_fwh_block() and unlock_82802ab() and
write_lockbits_block_49lfxxxc().
They all use exactly the same mechanism, but they don't share any code.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net>
Index: flashrom-stm50fw002_unlock/flashchips.c
===================================================================
--- flashrom-stm50fw002_unlock/flashchips.c (Revision 1437)
+++ flashrom-stm50fw002_unlock/flashchips.c (Arbeitskopie)
@@ -7523,9 +7523,9 @@
.total_size = 256,
.page_size = 64 * 1024,
.feature_bits = FEATURE_REGISTERMAP,
- .tested = TEST_UNTESTED,
+ .tested = TEST_OK_PREW,
.probe = probe_82802ab,
- .probe_timing = TIMING_IGNORED, /* routine doesn't use probe_timing (sst49lfxxxc.c) */
+ .probe_timing = TIMING_IGNORED, /* routine doesn't use probe_timing (82802ab.c) */
.block_erasers =
{
{
@@ -7536,9 +7536,12 @@
{16 * 1024, 1},
},
.block_erase = erase_block_82802ab,
+ }, {
+ .eraseblocks = { {256 * 1024, 1}, },
+ .block_erase = NULL, /* Only in A/A mux mode */
}
},
- .unlock = unlock_stm50flw0x0x,
+ .unlock = unlock_stm50fw002,
.write = write_82802ab,
.read = read_memmapped,
.voltage = {3000, 3600}, /* Also has 12V fast program & erase */
Index: flashrom-stm50fw002_unlock/stm50flw0x0x.c
===================================================================
--- flashrom-stm50fw002_unlock/stm50flw0x0x.c (Revision 1437)
+++ flashrom-stm50fw002_unlock/stm50flw0x0x.c (Arbeitskopie)
@@ -3,6 +3,7 @@
*
* Copyright (C) 2008 Claus Gindhart <claus.gindhart(a)kontron.com>
* Copyright (C) 2009 Sean Nelson <audiohacked(a)gmail.com>
+ * Copyright (C) 2011 Carl-Daniel Hailfinger
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
@@ -31,6 +32,21 @@
#include "flashchips.h"
#include "chipdrivers.h"
+#define STM50_UNLOCKED 0x00
+
+static int unlock_block_stm50(struct flashchip *flash, int offset)
+{
+ chipaddr lock = flash->virtual_registers + offset + 2;
+
+ msg_cdbg("Unlocking at 0x%x\n", offset);
+ chip_writeb(STM50_UNLOCKED, lock);
+ if (chip_readb(lock) != STM50_UNLOCKED) {
+ msg_cerr("Cannot unlock at 0x%x\n", offset);
+ return -1;
+ }
+ return 0;
+}
+
/*
* claus.gindhart(a)kontron.com
* The ST M50FLW080B and STM50FLW080B chips have to be unlocked,
@@ -38,8 +54,6 @@
*/
static int unlock_block_stm50flw0x0x(struct flashchip *flash, int offset)
{
- chipaddr wrprotect = flash->virtual_registers + 2;
- static const uint8_t unlock_sector = 0x00;
int j;
/*
@@ -58,22 +72,12 @@
|| (offset == 0xF0000)) {
// unlock each 4k-sector
- for (j = 0; j < 0x10000; j += 0x1000) {
- msg_cdbg("unlocking at 0x%x\n", offset + j);
- chip_writeb(unlock_sector, wrprotect + offset + j);
- if (chip_readb(wrprotect + offset + j) != unlock_sector) {
- msg_cerr("Cannot unlock sector @ 0x%x\n",
- offset + j);
+ for (j = 0; j < 0x10000; j += 0x1000)
+ if (unlock_block_stm50(flash, offset + j))
return -1;
- }
- }
} else {
- msg_cdbg("unlocking at 0x%x\n", offset);
- chip_writeb(unlock_sector, wrprotect + offset);
- if (chip_readb(wrprotect + offset) != unlock_sector) {
- msg_cerr("Cannot unlock sector @ 0x%x\n", offset);
+ if (unlock_block_stm50(flash, offset))
return -1;
- }
}
return 0;
@@ -93,6 +97,27 @@
return 0;
}
+/* FIXME: Should this be moved to a generic walk_unlockregions()? */
+int unlock_stm50fw002(struct flashchip *flash)
+{
+ static const struct eraseblock unlockregions[4] = {
+ {64 * 1024, 3},
+ {32 * 1024, 1},
+ {8 * 1024, 2},
+ {16 * 1024, 1}};
+ int i, j;
+ int addr = 0;
+
+ for (i = 0; i < 4; i++) {
+ for (j = 0; j < unlockregions[i].count; j++) {
+ if (unlock_block_stm50(flash, addr))
+ return 1;
+ addr += unlockregions[i].size;
+ }
+ }
+ return 0;
+}
+
/* This function is unused. */
int erase_sector_stm50flw0x0x(struct flashchip *flash, unsigned int sector, unsigned int sectorsize)
{
Index: flashrom-stm50fw002_unlock/chipdrivers.h
===================================================================
--- flashrom-stm50fw002_unlock/chipdrivers.h (Revision 1437)
+++ flashrom-stm50fw002_unlock/chipdrivers.h (Arbeitskopie)
@@ -146,5 +146,6 @@
/* stm50flw0x0x.c */
int erase_sector_stm50flw0x0x(struct flashchip *flash, unsigned int block, unsigned int blocksize);
int unlock_stm50flw0x0x(struct flashchip *flash);
+int unlock_stm50fw002(struct flashchip *flash);
#endif /* !__CHIPDRIVERS_H__ */
--
http://www.hailfinger.org/
4 years, 11 months
Re: [flashrom] [PATCH] dummyflasher.c: add an "empty" parameter and initialize with random bytes by default
by Carl-Daniel Hailfinger
Am 21.07.2011 17:54 schrieb Stefan Tauner:
> previously the dummies were initialized to be empty (all ones), which makes writes skip
> erasing altogether. with this patch the default is to fill it with random bytes instead and the
> old behavior can be enforced with stating "empty=yes" on the command line.
>
> Signed-off-by: Stefan Tauner <stefan.tauner(a)student.tuwien.ac.at>
>
Does the following not work for you?
dd if=/dev/urandom bs=1k count=4k of=oldimage.bin
flashrom -p dummy:emulate=SST25VF032B,image=oldimage.bin -w newimage.bin
Regards,
Carl-Daniel
--
http://www.hailfinger.org/
5 years
Add timeout check to SPI bitbang bus request
by Carl-Daniel Hailfinger
Hi Iain,
your Intel 82540EM which hangs on a flashrom run should spew "Timeout!"
messages with this patch. It would be nice if you could tell us how long
it waits for each chip probe so I can adjust the timeout value.
Please note that this patch will _not_ fix the underlying issue, but I
believe that an endless loop on possibly broken hardware is worse than
aborting.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net>
Index: flashrom-bitbang_timeout/flash.h
===================================================================
--- flashrom-bitbang_timeout/flash.h (Revision 1185)
+++ flashrom-bitbang_timeout/flash.h (Arbeitskopie)
@@ -35,6 +35,9 @@
#define ERROR_PTR ((void*)-1)
+/* Error codes */
+#define TIMEOUT_ERROR -101
+
typedef unsigned long chipaddr;
int register_shutdown(void (*function) (void *data), void *data);
Index: flashrom-bitbang_timeout/bitbang_spi.c
===================================================================
--- flashrom-bitbang_timeout/bitbang_spi.c (Revision 1185)
+++ flashrom-bitbang_timeout/bitbang_spi.c (Arbeitskopie)
@@ -53,10 +53,11 @@
return bitbang_spi_master->get_miso();
}
-static void bitbang_spi_request_bus(void)
+static int bitbang_spi_request_bus(void)
{
if (bitbang_spi_master->request_bus)
- bitbang_spi_master->request_bus();
+ return bitbang_spi_master->request_bus();
+ return 0;
}
static void bitbang_spi_release_bus(void)
@@ -86,7 +87,7 @@
bitbang_spi_master = master;
bitbang_spi_half_period = halfperiod;
- /* FIXME: Run bitbang_spi_request_bus here or in programmer init? */
+ /* FIXME: Run bitbang_spi_request_bus here or per command? */
bitbang_spi_set_cs(1);
bitbang_spi_set_sck(0);
bitbang_spi_set_mosi(0);
@@ -131,13 +132,15 @@
int bitbang_spi_send_command(unsigned int writecnt, unsigned int readcnt,
const unsigned char *writearr, unsigned char *readarr)
{
- int i;
+ int i, ret;
/* FIXME: Run bitbang_spi_request_bus here or in programmer init?
* Requesting and releasing the SPI bus is handled in here to allow the
* programmer to use its own SPI engine for native accesses.
*/
- bitbang_spi_request_bus();
+ ret = bitbang_spi_request_bus();
+ if (ret)
+ return ret;
bitbang_spi_set_cs(0);
for (i = 0; i < writecnt; i++)
bitbang_spi_readwrite_byte(writearr[i]);
Index: flashrom-bitbang_timeout/nicintel_spi.c
===================================================================
--- flashrom-bitbang_timeout/nicintel_spi.c (Revision 1185)
+++ flashrom-bitbang_timeout/nicintel_spi.c (Arbeitskopie)
@@ -58,6 +58,8 @@
// #define FL_BUSY 30
// #define FL_ER 31
+#define MAX_REQUEST_LOOPS 10000
+
uint8_t *nicintel_spibar;
const struct pcidev_status nics_intel_spi[] = {
@@ -68,16 +70,27 @@
{},
};
-static void nicintel_request_spibus(void)
+static void nicintel_release_spibus(void);
+
+static int nicintel_request_spibus(void)
{
uint32_t tmp;
+ int i = 0;
tmp = pci_mmio_readl(nicintel_spibar + FLA);
tmp |= 1 << FL_REQ;
pci_mmio_writel(tmp, nicintel_spibar + FLA);
/* Wait until we are allowed to use the SPI bus. */
- while (!(pci_mmio_readl(nicintel_spibar + FLA) & (1 << FL_GNT))) ;
+ while (!(pci_mmio_readl(nicintel_spibar + FLA) & (1 << FL_GNT))) {
+ if (i++ > MAX_REQUEST_LOOPS) {
+ nicintel_release_spibus();
+ msg_perr("%s: Timeout! Aborting.\n", __func__);
+ return TIMEOUT_ERROR;
+ }
+ }
+
+ return 0;
}
static void nicintel_release_spibus(void)
Index: flashrom-bitbang_timeout/mcp6x_spi.c
===================================================================
--- flashrom-bitbang_timeout/mcp6x_spi.c (Revision 1185)
+++ flashrom-bitbang_timeout/mcp6x_spi.c (Arbeitskopie)
@@ -40,22 +40,37 @@
#define MCP6X_SPI_REQUEST 0
#define MCP6X_SPI_GRANT 8
+#define MAX_REQUEST_LOOPS 10000
+
void *mcp6x_spibar = NULL;
/* Cached value of last GPIO state. */
static uint8_t mcp_gpiostate;
-static void mcp6x_request_spibus(void)
+static void mcp6x_release_spibus(void);
+
+static int mcp6x_request_spibus(void)
{
+ int i = 0;
+
mcp_gpiostate = mmio_readb(mcp6x_spibar + 0x530);
mcp_gpiostate |= 1 << MCP6X_SPI_REQUEST;
mmio_writeb(mcp_gpiostate, mcp6x_spibar + 0x530);
/* Wait until we are allowed to use the SPI bus. */
- while (!(mmio_readw(mcp6x_spibar + 0x530) & (1 << MCP6X_SPI_GRANT))) ;
+ while (!(mmio_readw(mcp6x_spibar + 0x530) & (1 << MCP6X_SPI_GRANT))) {
+ if (i++ > MAX_REQUEST_LOOPS) {
+ /* Update the cache. */
+ mcp_gpiostate = mmio_readb(mcp6x_spibar + 0x530);
+ mcp6x_release_spibus();
+ msg_perr("%s: Timeout! Aborting.\n", __func__);
+ return TIMEOUT_ERROR;
+ }
+ }
/* Update the cache. */
mcp_gpiostate = mmio_readb(mcp6x_spibar + 0x530);
+ return 0;
}
static void mcp6x_release_spibus(void)
Index: flashrom-bitbang_timeout/programmer.h
===================================================================
--- flashrom-bitbang_timeout/programmer.h (Revision 1185)
+++ flashrom-bitbang_timeout/programmer.h (Arbeitskopie)
@@ -131,7 +131,7 @@
void (*set_sck) (int val);
void (*set_mosi) (int val);
int (*get_miso) (void);
- void (*request_bus) (void);
+ int (*request_bus) (void);
void (*release_bus) (void);
};
--
http://www.hailfinger.org/
5 years
Flashrom stuck using 100% cpu while probing for a chip
by GatoLoko
I've tried to run flashrom -V to see if it could identify the chip on my
new board (AsRock M3A-GLAN), and it got stuck while probing for the
first chip.
I've tried commenting out that specific chip (AMIC A25L05PT) and then it
gets stuck on the next one. Then commented out all AMIC chips, and it
got stuck on the next one (the first ATMEL on the list)
I've tried with an older flashrom (0.9.2-r1141). It skipped some AMD
chips, then got stuck on AMIC again.
Talked with "tlt" and "stefanct" on irc and they asked for a strace and
a gdb backtrace. Strace produced no results. Gdb log is attached.
"stefanct" tried and reproduced it on a machine with nicintel_spi, but
warned it was with an unsupported nic:
http://paste.flashrom.org/view.php?id=738
--
GatoLoko
5 years
[PATCH] Add git support to the Makefile
by Carl-Daniel Hailfinger
flashrom relies on svn to export tarballs and only prints the last svn
revision in the version message even if flashrom is in a git tree.
Print extended version information (version, svn revision, git hash,
repository URL).
Allow exporting from git trees.
This should make git users first-class citizens like svn users.
Side note: If anyone has an idea how to make the export target more
beautiful (80 column limit etc.), please tell me.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net>
Index: flashrom-gitfriendly/Makefile
===================================================================
--- flashrom-gitfriendly/Makefile (Revision 1145)
+++ flashrom-gitfriendly/Makefile (Arbeitskopie)
@@ -97,13 +97,15 @@
# of the checked out flashrom files.
# Note to packagers: Any tree exported with "make export" or "make tarball"
# will not require subversion. The downloadable snapshots are already exported.
-SVNVERSION := $(shell LC_ALL=C svnversion -cn . 2>/dev/null | sed -e "s/.*://" -e "s/\([0-9]*\).*/\1/" | grep "[0-9]" || LC_ALL=C svn info . 2>/dev/null | awk '/^Revision:/ {print $$2 }' | grep "[0-9]" || LC_ALL=C git svn info . 2>/dev/null | awk '/^Revision:/ {print $$2 }' | grep "[0-9]" || echo unknown)
+SCMVERSION := $(shell LC_ALL=C svnversion -cn . 2>/dev/null | sed -e "s/.*://" -e "s/\([0-9]*\).*/\1/" | grep "[0-9]" || LC_ALL=C svn info . 2>/dev/null | awk '/^Revision:/ {print $$2 }' | grep "[0-9]" || LC_ALL=C git svn info . 2>/dev/null | awk '/^Revision:/ {print $$2 }' | grep "[0-9]" || echo unknown)
+SCMEXTVERSION := $(shell LC_ALL=C git rev-parse HEAD 2>/dev/null | sed 's/^./-\0/')
+SCMURL := $(shell LC_ALL=C svn info 2>/dev/null | grep URL: | sed 's/.*URL:[[:blank:]]*//' | grep ^. || LC_ALL=C git remote show origin 2>/dev/null |grep URL: | sed 's/.*URL:[[:blank:]]*//' | grep ^. || echo unknown )
RELEASE := 0.9.2
-VERSION := $(RELEASE)-r$(SVNVERSION)
+VERSION := $(RELEASE)-r$(SCMVERSION)$(SCMEXTVERSION)
RELEASENAME ?= $(VERSION)
-SVNDEF := -D'FLASHROM_VERSION="$(VERSION)"'
+SCMDEF := -D'FLASHROM_VERSION="$(VERSION)"' -D'FLASHROM_SCMURL="$(SCMURL)"'
# Always enable internal/onboard support for now.
CONFIG_INTERNAL ?= yes
@@ -310,7 +312,7 @@
TAROPTIONS = $(shell LC_ALL=C tar --version|grep -q GNU && echo "--owner=root --group=root")
%.o: %.c .features
- $(CC) -MMD $(CFLAGS) $(CPPFLAGS) $(FEATURE_CFLAGS) $(SVNDEF) -o $@ -c $<
+ $(CC) -MMD $(CFLAGS) $(CPPFLAGS) $(FEATURE_CFLAGS) $(SCMDEF) -o $@ -c $<
# Make sure to add all names of generated binaries here.
# This includes all frontends and libflashrom.
@@ -420,9 +422,12 @@
export:
@rm -rf $(EXPORTDIR)/flashrom-$(RELEASENAME)
- @svn export -r BASE . $(EXPORTDIR)/flashrom-$(RELEASENAME)
- @sed "s/^SVNVERSION.*/SVNVERSION := $(SVNVERSION)/" Makefile >$(EXPORTDIR)/flashrom-$(RELEASENAME)/Makefile
- @LC_ALL=C svn log >$(EXPORTDIR)/flashrom-$(RELEASENAME)/ChangeLog
+ @svn export -r BASE . $(EXPORTDIR)/flashrom-$(RELEASENAME) 2>/dev/null || git checkout-index -a -f --prefix=$(EXPORTDIR)/flashrom-$(RELEASENAME)/
+ @# If SCMVERSION or SCMEXTVERSION contain a slash or SCMURL contains a hash, this will explode
+ @sed "s/^SCMVERSION.*/SCMVERSION := $(SCMVERSION)/;s/^SCMEXTVERSION.*/SCMEXTVERSION := $(SCMEXTVERSION)/;s#^SCMURL.*#SCMURL := $(SCMURL)#" Makefile >$(EXPORTDIR)/flashrom-$(RELEASENAME)/Makefile
+ @# ChangeLog should be in English, but we want UTF-8 for names.
+ @( LC_ALL=en_US.UTF-8 svn log 2>/dev/null || LC_ALL=en_US.UTF-8 git log 2>/dev/null || echo "Unable to extract log from SCM" ) >$(EXPORTDIR)/flashrom-$(RELEASENAME)/ChangeLog
+ @rm -f $(EXPORTDIR)/flashrom-$(RELEASENAME)/.gitignore $(EXPORTDIR)/flashrom-$(RELEASENAME)/.gitattributes $(EXPORTDIR)/flashrom-$(RELEASENAME)/.gitmodules
@echo Exported $(EXPORTDIR)/flashrom-$(RELEASENAME)/
tarball: export
Index: flashrom-gitfriendly/flashrom.c
===================================================================
--- flashrom-gitfriendly/flashrom.c (Revision 1145)
+++ flashrom-gitfriendly/flashrom.c (Arbeitskopie)
@@ -1355,6 +1355,7 @@
void print_version(void)
{
msg_ginfo("flashrom v%s", flashrom_version);
+ msg_ginfo(" from " FLASHROM_SCMURL ",");
print_sysinfo();
}
@@ -1362,7 +1363,6 @@
{
msg_ginfo("flashrom is free software, get the source code at "
"http://www.flashrom.org\n");
- msg_ginfo("\n");
}
int selfcheck(void)
--
http://www.hailfinger.org/
5 years, 9 months
Re: [flashrom] [coreboot] Dualbios on GA-MA770-UD3
by Carl-Daniel Hailfinger
Hi Vadim,
thanks for your mail. I have added the flashrom mailing list in CC:
because we should develop a generic way to handle DualBIOS and similar
techniques.
On 09.04.2010 08:12, Vadim Girlin wrote:
> I'm going to try coreboot on Gigabyte GA-MA770-UD3.
> It's AMD 770 (RX780 / SB700).
>
> My motherboard supports hardware dual bios - with two chips on it.
> I'm going to try flashing backup chip and boot from it. It seems to be
> possible - I've tested it (flashing at least). Chips on this board could
> be switched by changing bit 0 at undocumented register EF on LDN 7 of
> IT8720. I can use slightly patched flashrom for accessing any chip I
> want without any problems. And this is tested many times.
>
> My idea is to use backup chip for debugging - that always keeps my
> chance to reboot from main bios chip. And removes the need for
> desoldering etc.
>
> And second problem is that original bios is checking second chip - and
> trying to recover it by flashing the bios from main chip on reboot?
> rewriting coreboot. AFAICS this could be solved by including some
> signatures etc. It seems to be easy to find out. May be someone is
> working on this?
>
> BTW I can send the patch for flashrom - but I think that with
> information I mentioned above somebody could make it much better than my
> ugly hack. I hope the regs should be the same for all latest Gigabyte
> MBs using IT8720/18
>
It would be great if you could send that patch. It will help us make a
flashrom design decision that works for all boards with multiple flash
chips.
By the way, some of us have good contacts at ITE, so we can ask ITE for
details about the undocumented registers.
Regards,
Carl-Daniel
--
http://www.hailfinger.org/
5 years, 9 months
[RFC] Layout handling...
by Carl-Daniel Hailfinger
Hi,
before we change flashrom to work with current layout requirements, we
should summarize the features we need/want, and then decide how to
handle the individual layout regions internally.
Terms:
"write strategy" describes a combination of erase+write commands with a
given block size, touching some blocks.
"read protected" describes a region which can not be read.
"write protected" describes a region which can not be written.
"write once" describes a region which can be written exactly once in the
chip lifetime.
If you add a feature to the list, please give it a nickname so we know
which feature people are referring to. Some of the features below might
not be desirable, but I want to list them anyway so we can explicitly
declare them as unsupported if needed.
fullwrite-unrestricted: Write a chip-sized image, no special read/write
restrictions of the chip, no layout file needs to be specified. Default
write case right now.
fullwrite-noread: Write a chip-sized image, reading anything from the
chip is not possible. Many DVD writers fall in that category. No
verification, violates our reliability guarantees.
fullwrite-postread: Write a chip-sized image, reading anything from the
chip is only possible after write. Chips which are read-locked until a
full erase/write fall in that category. Do those exist as standalone
flash chips or only integrated into processors?
fullwrite-partialread: Write a chip-sized image, reading is only
possible in some chip regions. Only partial verification, violates our
reliability guarantees.
fullwrite-partialwrite: Write a chip-sized image, but writing is only
possible in some regions. This is obviously a conflict unless the image
has the same contents as the chip in the write-protected regions and
there is a possible write strategy for the whole image which does not
touch the write-protected regions. Should flashrom always refuse this
scenario, or only refuse it in case of conflicts?
partialwrite-unrestricted: Write only parts of an image, the rest of the
chip contents is kept, no special read/write restrictions.
partialwrite-partialread: Write only parts of an image, the rest of the
chip contents is kept, reading is only possible in some chip regions. If
no read-protected regions are written and a suitable write strategy
exists, should flashrom warn? If a read-protected region is written,
should flashrom warn/refuse due to reliability requirements?
partialwrite-partialwrite: Write only parts of an image, the rest of the
chip contents is kept, writing is only possible in some chip regions. If
no write-protected regions are written and a suitable write strategy
exists, should flashrom warn? flashrom will refuse to write a
write-protected region.
fullread-unrestricted: Read the full chip, no special read restrictions
of the chip.
partialread-unrestricted: Read only parts of a chip, no special read
restrictions of the chip.
partialread-partialread: Read only parts of a chip, some regions are
read-protected. flashrom should refuse to read any read-protected regions.
partialread-imagefiller: If only parts of a chip are read and the read
image has full chip size, what should be used as filler for unread
regions? 0x00 or 0xff?
partialread-layout-imagesize: If only parts of a chip are read, should
the read image still have full chip size with all read regions filled in
at the respective locations?
partialread-layout-split: If only parts of a chip are read, should it be
possible to write each region (or a combination thereof) to a separate
image file, and would that mapping be specified in the layout file?
partialwrite-layout-split: If only parts of a chip are written, should
it be possible to collect each part of the new image from a separate
image file, and would that mapping be specified in the layout file?
readwrite-protection-time: Which read protection and write protection
times exist? Temporary lock until unlock, temporary lock until chip soft
reset, temporary lock until chip/programmer hard reset (powerdown or
reset line), permanent eternal lock.
readwrite-protection-type: Which read protection and write protection
types exist? Programmer lock (e.g. Intel SPI), hardware chip lock (WP
pin), software chip lock (chip command).
readwrite-protection-interaction: How should we express this situation:
A region is write-locked with a software chip lock, but to remove that
software chip lock, a hardware chip lock has to be disabled first, then
the software chip lock can be disabled.
partialaccess-crash: Some regions in the chip are really off-limits and
will cause an unrecoverable error (system crash) when accessed (read or
write). That seems to be the case for some EC/flash interactions.
Comments? Any forks of flashrom (e.g. chromium) which need
infrastructure features not mentioned above?
Regards,
Carl-Daniel
--
http://www.hailfinger.org/
5 years, 10 months
Re: [flashrom] [PATCH] automatically round address ranges requested from physmap_common to page boundaries
by Stefan Tauner
On Mon, 30 May 2011 02:45:44 +0200
Stefan Tauner <stefan.tauner(a)student.tuwien.ac.at> wrote:
> this patch also changes the display width of all addresses in physmap.c to 16 hex characters.
>
> FIXME: what about unmappings?
> munmap is safe.
> djgpp's __dpmi_free_physical_address_mapping: unknown.
> DirectHW's unmap_physical: unknown.
>
> FIXME: jakllsch suggested using PRIx64 instead of x, because it's more portable
FIXME: in the case we can not map and 'mayfail' is true we should return
ERROR_PTR instead of ERROR_PTR + diff
--
Kind regards/Mit freundlichen Grüßen, Stefan Tauner
6 years, 4 months
