Thanks to Niels Ole Salscheider for the problem report.
Signed-off-by: Peter Stuge <peter@stuge.se>
Acked-by: Peter Stuge <peter@stuge.se>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3798 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
flashrom used to exit 0 even if erase failed. Not anymore.
Signed-off-by: Peter Stuge <peter@stuge.se>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3797 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
* PMBASE dumping now knows the registers.
* Add support for i965, i975, ICH8M
* Add support for Darwin OS using DirectIO
Signed-off-by: Stefan Reinauer <stepan@coresystems.de>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3794 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
SST_25VF512A_REMS
SST_25VF010_REMS
SST_25VF020_REMS
SST_25VF040_REMS
SST_25VF040B_REMS
SST_25VF080_REMS
SST_25VF080B_REMS
SST_25VF032B_REMS
SST_26VF016
SST_26VF032
W_25X16
W_25X32
W_25X64
Straight from the data sheets.
The REMS IDs help in case the RDID opcode is unavailable (due to opcode
lockdown) or unsupported by the chip.
Some day, we need to pair probe functions together with IDs. Multiple
pairs can exist per chip and duplicating chip definitions does not
really make sense.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3793 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Bug from r3791.
Signed-off-by: Peter Stuge <peter@stuge.se>
Acked-by: Peter Stuge <peter@stuge.se>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3792 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
If flashbase was set before probe_flash() it would only ever be used once, for
the very first flash chip probe.
Signed-off-by: Peter Stuge <peter@stuge.se>
Acked-by: Peter Stuge <peter@stuge.se>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3791 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
make sure the temporary files are created in the same directory as the
target files so they can be rename()d. This fixes a compilation issue on
machines with the build directory living on another partition than /tmp.
Pretty trivial.
Signed-off-by: Stefan Reinauer <stepan@coresystems.de>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3789 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
hwmon has generic registers and banked registers, mostly temperature
handling, and SMI/GPIO stuff.
Not all LDNs are switched via register offset 0x07, make it a parameter.
Add support for dumping the hardware monitor of Winbond W83627THF/THG
parts with the -e option.
Signed-off-by: Stefan Reinauer <stepan@coresystems.de>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3784 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
- create temp files and move them afterwards
- remove dummy option -b
- fix usage
- drop implicit creation of .c file if no --option is specified.
Now let's see if this fixes the issue. :-) We don't want to take 24s
instead of 6s to build an image reliably (Yes, yes, I know Tiano takes
over 20 minutes)
Signed-off-by: Stefan Reinauer <stepan@coresystems.de>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3783 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Signed-off-by: Jason Wang<Qingpei.wang@amd.com>
Reviewed-by: Joe, Bao <Zheng.Bao@amd.com>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3782 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
unsupported functions, giving the user the impression that the
unsupported functions are tested.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Peter Stuge <peter@stuge.se>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3780 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
This has been tested by Uwe Hermann on an RS690/SB600 board.
Signed-off-by: Jason Wang <Qingpei.Wang@amd.com>
Reviewed-by: Joe Bao <zheng.bao@amd.com>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3779 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
running twice at the same time, overwriting its output files. This caused
a depending rule to produce an object file with no symbols in it.
This should silence up the regularly happening build failure messages on
the mailing list since we moved to the newer, much faster server.
Signed-off-by: Stefan Reinauer <stepan@coresystems.de>
Signed-off-by: Patrick Georgi <patrick.georgi@coresystems.de>
Acked-by: Peter Stuge <peter@stuge.se>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3777 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
This is the first chip which uses the infrastructure for alternative
erase commands, namely spi_chip_erase_60_c7().
Signed-off-by: Jason Wang <Qingpei.Wang@amd.com>
Reviewed-by: Joe Bao <zheng.bao@amd.com>
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3776 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
- probe_spi_rdid with opcode 0x9f, usually 3 bytes ID
- probe_spi_res with opcode 0xab, usually 1 byte ID
We are missing the following probe function:
- probe_spi_rems with opcode 0x90, usually 2 bytes ID
RDID provides best specifity (manufacturer, device class and device) and
RES is supported by quite a few old chips. However, RES only returns one
byte and there are multiple flash chips with different sizes on the
market and all of them have the same RES ID.
REMS is from the same age as RES, but it provides a manufacturer and a
device ID. It is therefore on par with the probing for parallel flash
chips and specific enough.
The order in which chips should be detected is as follows:
1. RDID
2. REMS
3. RES
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Peter Stuge <peter@stuge.se>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3775 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
which support all commands, but may not exist.
For controllers which support only a subset of commands, it will fail in
unexpected ways. Even if a command is supported by the controller, it
may be unavailable if the controller is locked down.
The new logic checks if RDID could be issued and its return values made
sense (not 0xff 0xff 0xff). In that case, RES probing is not performed.
Otherwise, we try RES.
There is one drawback: If RDID returned unexpected values, we don't
issue a RES probe. However, in that case we should try to match RDID
anyway.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: FENG yu ning <fengyuning1984@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3774 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
And some more notes in TODO.
Signed-off-by: Peter Stuge <peter@stuge.se>
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3770 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
File util/flashrom/flash.h already had correct ID for that part.
Signed-off-by: Tero O Peippola <xeropp@gmail.com>
Acked-by: Peter Stuge <peter@stuge.se>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3769 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
msrtool can decode MSRs and print the value of every field in human
readable form. It can also be used to save a set of MSRs to a file,
and at a later time compare the saved values with current values in
hardware.
Signed-off-by: Peter Stuge <peter@stuge.se>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3766 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
SPI opcodes should be placed in which location. Move to a less
optimistic implementation and actually use the generic SPI read
functions. They're useful for abstracting exactly this stuff and that
makes them the preferred choice.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3758 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
does not have a mechanism to signal command failure, the SPI host may be
unable to send a given command over the wire due to security or hardware
limitations. The current code ignores these mechanisms completely and
simply assumes almost every command succeeds. Complain if SPI command
execution fails.
Since locked down Intel chipsets (like the one we had problems with
earlier) only allow a small subset of commands, find the common subset
of commands between the chipset and the ROM in the chip erase case. That
is accomplished by the new spi_chip_erase_60_c7() which can be used for
chips supporting both 0x60 and 0xc7 chip erase commands.
Both parts of the patch address problems seen in the real world. The
increased verbosity for the error case will help us diagnose and address
problems better.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Otherwise: Acked-by: Stefan Reinauer <stepan@coresystems.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3757 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
AT25DF021
AT25DF041A
AT25DF081
AT25DF161
AT25DF321A
AT25DF641
AT25F512B
AT25FS010
AT25FS040
AT26DF041
AT26DF081A
AT26DF161
AT26DF161A
AT26DF321
AT26F004
I double-checked the data sheets and am confident this will work.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3756 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Tested fully on a ThinCan DBE61A
Signed-off-by: Mart Raudsepp <mart.raudsepp@artecdesign.ee>
Acked-by: Mart Raudsepp <mart.raudsepp@artecdesign.ee>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3755 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
The AT45 series SPI chips are DataFlash EEPROMs which means they have
odd (non-power-of-two) sector sizes, but some of the DataFlash chips can
be configured or ordered with power-of-two sector sizes.
Add probe support for the following Atmel SPI chips:
AT25DF021
AT25DF041A
AT25DF081
AT25DF161
AT25DF321A
AT25DF641
AT25F512B
AT25FS010
AT25FS040
AT26DF041
AT26DF081A
AT26DF161
AT26DF161A
AT26DF321
AT26F004
AT45CS1282
AT45DB011D
AT45DB021D
AT45DB041D
AT45DB081D
AT45DB161D
AT45DB321C
AT45DB321D
AT45DB642D
Add an explanation why the following chips can't be probed:
AT45BR3214B
AT45D011
AT45D021A
AT45D041A
AT45D081A
AT45D161
AT45DB011
AT45DB011B
AT45DB021A
AT45DB021B
AT45DB041A
AT45DB081A
AT45DB161
AT45DB161B
AT45DB321
AT45DB321B
AT45DB642
Add the ID, but no probing function for this chip:
AT25F512A
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Tested-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Tested-by: Andriy Gapon <avg@icyb.net.ua>
Acked-by: Myles Watson <mylesgw@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3754 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
IT8780F, and Fintek F71863FG.
Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de>
Acked-by: Peter Stuge <peter@stuge.se>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3750 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Per report from Mario Rogen. Thanks!
Signed-off-by: Peter Stuge <peter@stuge.se>
Acked-by: Peter Stuge <peter@stuge.se>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3736 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
This helps a lot if we have to track down configuration weirdnesses.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3723 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
flashrom. Not all chips support all commands, so allow the implementer
to select the matching function.
Fix a layering violation in ICH SPI code to be less bad. Still not
perfect, but the new code is shorter, more generic and
architecturally
more sound.
TODO (in a separate patch):
- move the generic sector erase code to spi.c
- decide which erase command to use based on info about the chip
- create a generic spi_erase_all_sectors function which calls the
generic sector erase function
Thanks to Stefan for reviewing and commenting.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3722 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
This is slightly slower (ha, ha), but works on boards with a locked opmenu. Tested on ICH7 and works.
Signed-off-by: Stefan Reinauer <stepan@coresystems.de>
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3721 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
as we've done with the superiotool and flashrom manpages, too (trivial).
Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3714 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
- SST SST39SF010A
- Winbond W29C011
Tested by me on actual hardware, all operations.
Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3708 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
using block erase d8 as discussed with Peter Stuge
Signed-off-by: Stefan Reinauer <stepan@coresystems.de>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3707 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Martin Stecklum <stecky@gmx.net> (both write and erase).
The tests were done on an MSI MS-7065 board, so that's supported now
too (wiki page will be updated).
Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3697 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Untested, but should work just as well as the other *PIIX* southbridges
according to the datasheets.
Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3696 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
They all use a different init sequence than the more modern ITE Super I/Os.
For now we only use 0x370 as config port, but 0x3f0 or 0x3bd would also be
valid. Contrary to other Super I/Os, the config port for these is _not_
hardcoded via hardware, instead it can be programmed by software, i.e.
you get to choose whether you want to use 0x370, 0x3f0, or 0x3bd.
Tested on IT8671F by Uwe Hermann and on IT8770F by Urja Rannikko.
Signed-off-by: Urja Rannikko <urjaman@gmail.com>
Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de>
Acked-by: Urja Rannikko <urjaman@gmail.com>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3692 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
This has been tested on hardware by me.
Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3682 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
specification and local testing.
Also tweak a little bit algorithm for (internal) device ID calculation:
Chips from the W83627HF/F/HG/G family have an ID of 0x52 and a multitude of
revisions (0x1x, 0x3a, 0x41, maybe more), chips from the W83627HF/GF family
have the same device ID but revisions 0xfx.
Please note that the last line of the patch simply fixes the comment
about internal device ID composition (upper half of reg 0x21 is used).
I chose the most conservative way of detecting W83627HF - only if reg
0x21 value matches 0xFx we skip the previous logic and keep using it for
all other revisions.
Signed-off-by: Andriy Gapon <avg@icyb.net.ua>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3670 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Peter Stuge