| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
| |
Change-Id: I7bfc339673cbf5ee2d2ff7564c4db04ca088d0a4
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/25381
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Even if fwrite() succeeds the data is not necessarily out of the clib's buffers
and writing it eventually could fail. Even if the data is flushed out (explicitly by
fflush() or implicitly by fclose()) the kernel might still hold a buffer.
Previously we have ignored this to a large extent - even in important cases
like writing the flash contents to a file. The results can be truncated
images that would brick the respective machine if written back as is (though
flashrom would not allow that due to a size mismatch). flashrom would not
indicate the problem in any output - so far we only check the return value
of fwrite() that is not conclusive.
This patch checks the return values of all related system calls like fclose()
unless we only read the file and are not really interested in output errors.
In the latter case the return value is casted to void to document this fact.
Additionally, this patch explicitly calls fflush() and fsync() (on regular files only)
to do the best we can to guarantee the read image reaches the disk safely
and at least inform the user if it did not work.
Corresponding to flashrom svn r1902.
Signed-off-by: Stefan Tauner <stefan.tauner@alumni.tuwien.ac.at>
Acked-by: Urja Rannikko <urjaman@gmail.com>
|
| |
|
|
|
|
|
| |
Corresponding to flashrom svn r1565.
Signed-off-by: Peter Lemenkov <lemenkov@gmail.com>
Acked-by: Stefan Tauner <stefan.tauner@alumni.tuwien.ac.at>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
We want to avoid calls to strlen at runtime if the string is already
known at compile time.
Turns out that gcc and clang will recognize constant strings and compute
the strlen result already at compile time, so trickery with sizeof only
reduces readability but does not improve the code.
Corresponding to flashrom svn r1352.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Sean Nelson <audiohacked@gmail.com>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
CONFIG_BITBANG_SPI was not selected if CONFIG_NICINTEL_SPI was on by default.
Wiki output was missing all flash chips if CONFIG_INTERNAL was not
selected.
Use correct type for toupper()/tolower()/isspace() functions.
Specify software requirements in a generic way.
Non-x86 compilation does not work with the default programmer set, so
list the make parameters which result in a working build.
Corresponding to flashrom svn r1203.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Michael Karcher <flashrom@mkarcher.dialup.fu-berlin.de>
|
| |
|
|
|
|
|
| |
Corresponding to flashrom svn r1183.
Signed-off-by: Vladimir 'phcoder' Serbinenko <phcoder@gmail.com>
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Programmer specific functions are of absolutely no interest to any file
except those dealing with programmer specific actions (special SPI
commands and the generic core).
The new header structure is as follows (and yes, improvements are
possible):
flashchips.h flash chip IDs
chipdrivers.h chip-specific read/write/... functions
flash.h common header for all stuff that doesn't fit elsewhere
hwaccess.h hardware access functions
programmer.h programmer specific functions
coreboot_tables.h header from coreboot, internal programmer only
spi.h SPI command definitions
Corresponding to flashrom svn r1112.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>
|
|
|
unknown
The internal programmer needs correct information about flash_base and
chip window top/bottom alignment on non-x86 before it can be used. Abort
any internal programmer action for now until the code is fixed.
Add the concept of a processor enable for systems where flashing is
impacted by processor settings or processor model.
Corresponding to flashrom svn r1031.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>
|
