Allow easy disabling of all programmers except selected ones by setting
Setting CONFIG_DEFAULT=yes has no effect.
# make CONFIG_DUMMY=yes CONFIG_NIC3COM=yes CONFIG_DEFAULT=no
This will disable all programmers except dummy and nic3com.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net>
--- flashrom-Makefile_config_default/Makefile (Revision 1623)
+++ flashrom-Makefile_config_default/Makefile (Arbeitskopie)
@@ -52,6 +52,10 @@
# Compilation will fail for unspecified values.
CONFIG_DEFAULT_PROGRAMMER ?= PROGRAMMER_INVALID
+# This parameter picks the default setting for CONFIG_ variables of programmers not specified explicitly
+# on the command line.
+CONFIG_DEFAULT ?= yes
# If your compiler spits out excessive warnings, run make WARNERROR=no
# You shouldn't have to change this flag.
WARNERROR ?= yes
@@ -322,65 +326,65 @@
SVNDEF := -D'FLASHROM_VERSION="$(VERSION)"'
# Always enable internal/onboard support for now.
-CONFIG_INTERNAL ?= yes
+CONFIG_INTERNAL ?= $(CONFIG_DEFAULT)
# Always enable serprog for now. Needs to be disabled on Windows.
-CONFIG_SERPROG ?= yes
+CONFIG_SERPROG ?= $(CONFIG_DEFAULT)
# RayeR SPIPGM hardware support
-CONFIG_RAYER_SPI ?= yes
+CONFIG_RAYER_SPI ?= $(CONFIG_DEFAULT)
# PonyProg2000 SPI hardware support
-CONFIG_PONY_SPI ?= yes
+CONFIG_PONY_SPI ?= $(CONFIG_DEFAULT)
# Always enable 3Com NICs for now.
-CONFIG_NIC3COM ?= yes
+CONFIG_NIC3COM ?= $(CONFIG_DEFAULT)
# Enable NVIDIA graphics cards. Note: write and erase do not work properly.
-CONFIG_GFXNVIDIA ?= yes
+CONFIG_GFXNVIDIA ?= $(CONFIG_DEFAULT)
# Always enable SiI SATA controllers for now.
-CONFIG_SATASII ?= yes
+CONFIG_SATASII ?= $(CONFIG_DEFAULT)
# Highpoint (HPT) ATA/RAID controller support.
# IMPORTANT: This code is not yet working!
CONFIG_ATAHPT ?= no
# Always enable FT2232 SPI dongles for now.
-CONFIG_FT2232_SPI ?= yes
+CONFIG_FT2232_SPI ?= $(CONFIG_DEFAULT)
# Always enable dummy tracing for now.
-CONFIG_DUMMY ?= yes
+CONFIG_DUMMY ?= $(CONFIG_DEFAULT)
# Always enable Dr. Kaiser for now.
-CONFIG_DRKAISER ?= yes
+CONFIG_DRKAISER ?= $(CONFIG_DEFAULT)
# Always enable Realtek NICs for now.
-CONFIG_NICREALTEK ?= yes
+CONFIG_NICREALTEK ?= $(CONFIG_DEFAULT)
# Disable National Semiconductor NICs until support is complete and tested.
CONFIG_NICNATSEMI ?= no
# Always enable Intel NICs for now.
-CONFIG_NICINTEL ?= yes
+CONFIG_NICINTEL ?= $(CONFIG_DEFAULT)
# Always enable SPI on Intel NICs for now.
-CONFIG_NICINTEL_SPI ?= yes
+CONFIG_NICINTEL_SPI ?= $(CONFIG_DEFAULT)
# Always enable SPI on OGP cards for now.
-CONFIG_OGP_SPI ?= yes
+CONFIG_OGP_SPI ?= $(CONFIG_DEFAULT)
# Always enable Bus Pirate SPI for now.
-CONFIG_BUSPIRATE_SPI ?= yes
+CONFIG_BUSPIRATE_SPI ?= $(CONFIG_DEFAULT)
# Disable Dediprog SF100 until support is complete and tested.
CONFIG_DEDIPROG ?= no
# Always enable Marvell SATA controllers for now.
-CONFIG_SATAMV ?= yes
+CONFIG_SATAMV ?= $(CONFIG_DEFAULT)
# Enable Linux spidev interface by default. We disable it on non-Linux targets.
-CONFIG_LINUX_SPI ?= yes
+CONFIG_LINUX_SPI ?= $(CONFIG_DEFAULT)
# Disable wiki printing by default. It is only useful if you have wiki access.
CONFIG_PRINT_WIKI ?= no
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
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
By the way, some of us have good contacts at ITE, so we can ask ITE for
details about the undocumented registers.
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.
"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
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
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
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?
On Mon, 6 Aug 2012 12:07:47 -0700
Greg Schardt <gschardt(a)ddn.com> wrote:
> Can you explain why doing a read operation failed? I expected that reads would work and writes would fail.
each region can have 4 different access states: read/write, read-only,
write-only (never seen in practice), locked (neither read nor write
allowed) (see FREG in the public datasheets for any newer intel
flashrom disables writes by default if it detects locked or read-only
regions as a safety measurement and still allows reads because they can
not lead to the same severe damage. in case of locked regions reads of
addresses inside those regions will of course fail.
there are some patches available that are not merged yet that allow to
specify the addresses to be read/written, which allow to read/write the
readable/writable address ranges.
Kind regards/Mit freundlichen Grüßen, Stefan Tauner
We enable programmer compilation based on the following criteria:
- Default off unless explicitly enabled (dediprog)
- Default on unless explicitly disabled (dummy)
- Default on if technically possible on target machine (linux_spi)
- Default on if the required libs+headers are available (ft2232_spi)
The last criterion is what causes pains to no end, at least with the
current Makefile infrastructure. Yes, we (I) can maintain it, but in the
long run we either need a separate configure script (which may or may
not work in all envorinments where GNU make works, especially exotic
platforms like Windows), or we switch to something like CMake (which
doesn't have the required features in ancient versions AFAIK), or we use
two chained Makefiles (which would not meet my definition of "fun").
Now why is the last criterion such a PITA? All other criteria have a
hard fail/success test, i.e. if a required lib/header is missing, we
stop compilation. However, this criterion has a soft fail/success test,
i.e. if you enable a feature and the required libraries/headers are
missing, the feature simply will be silently disabled. That sort of
violates the principle of least surprise, and it's the reason why our
current Makefile uses nasty tricks with external files to avoid
I would like to switch ft2232_spi to "Default on if technically possible
on target machine" and spit out an improved error message in case the
headers are missing.