The get_region() function was using fixed masks for
the base and limit. However, newer descriptors (on
skylake, e.g.) use a 15-bit mask -- not a 12-bit one.
Choose the right mask based on ifd_version.
BUG=chrome-os-partner:43461
BRANCH=None
TEST=Built glados bootimage.
Original-Change-Id: Ibcbfd649a561d36b17ea2cc8fbeb30ffdbbb2c96
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/293250
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Change-Id: I7f2ef9fb8e5b6c7114225fecc2798668d6507ac3
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11229
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The descriptor format has changed with Skylake and some fields have
moved or been expanded.
This includes new SPI frequencies and chip densities, though unfortunately
30MHz in the new format conflicts with 50MHz in the old format...
There are also new regions with a few reserved regions inserted before
a new embedded controller region.
Unfortunately there does not seem to be a documented version field
so there does not seem to be an official way to determine if a
specific descriptor is new or old. To work around this ifdtool
checks the hardcoded "SPI Read Frequency" to see if it set for
20MHz (old descriptor) or 17MHz (new descriptor).
BUG=chrome-os-partner:40635
BUG=chrome-os-partner:43461
BRANCH=none
TEST=run ifdtool on skylake and broadwell images
Original-Change-Id: I0561b3c65fcb3e77c0a24be58b01db9b3a36e5a9
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/281001
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Queue: Aaron Durbin <adurbin@chromium.org>
Change-Id: I9a08c26432e13c4000afc50de9d8473e6f911805
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/293240
Reviewed-on: http://review.coreboot.org/11228
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Used command line to remove empty lines at end of file:
find . -type f -exec sed -i -e :a -e '/^\n*$/{$d;N;};/\n$/ba' {} \;
Change-Id: I816ac9666b6dbb7c7e47843672f0d5cc499766a3
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: http://review.coreboot.org/10446
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
As per discussion with lawyers[tm], it's not a good idea to
shorten the license header too much - not for legal reasons
but because there are tools that look for them, and giving
them a standard pattern simplifies things.
However, we got confirmation that we don't have to update
every file ever added to coreboot whenever the FSF gets a
new lease, but can drop the address instead.
util/kconfig is excluded because that's imported code that
we may want to synchronize every now and then.
$ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, *MA[, ]*02110-1301[, ]*USA:Foundation, Inc.:" {} +
$ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin Street, Suite 500, Boston, MA 02110-1335, USA:Foundation, Inc.:" {} +
$ find * -type f -exec sed -i "s:Foundation, Inc., 59 Temple Place[-, ]*Suite 330, Boston, MA *02111-1307[, ]*USA:Foundation, Inc.:" {} +
$ find * -type f -exec sed -i "s:Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.:Foundation, Inc.:" {} +
$ find * -type f
-a \! -name \*.patch \
-a \! -name \*_shipped \
-a \! -name LICENSE_GPL \
-a \! -name LGPL.txt \
-a \! -name COPYING \
-a \! -name DISCLAIMER \
-exec sed -i "/Foundation, Inc./ N;s:Foundation, Inc.* USA\.* *:Foundation, Inc. :;s:Foundation, Inc. $:Foundation, Inc.:" {} +
Change-Id: Icc968a5a5f3a5df8d32b940f9cdb35350654bef9
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/9233
Tested-by: build bot (Jenkins)
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Windows requires O_BINARY when opening a binary file. Otherwise
\n characters get expanded to \r\n and <ctrl>z is treated as
end of file. For compatibility with non-Windows hosts, the patch
defines O_BINARY if it is not already defined.
Change-Id: I04cd609b644b1edbe9104153b43b9996811ffd38
Signed-off-by: Scott Duplichan <scott@notabs.org>
Reviewed-on: http://review.coreboot.org/7789
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
While the result will not be pretty (ie. ifdtool will
mis-parse string components longer than 255 characters),
at least it doesn't overflow stack variables anymore.
Change-Id: I263c5cf823a2d8a863dcece7c4ee0b26475f9fc4
Found-by: Coverity Scan
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/6562
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Tested-by: build bot (Jenkins)
Check if the new file could in fact be opened before
writing to it.
Change-Id: I6b2d31bf5c18f657fca4dc14fee2f2d5a2e33080
Found-by: Coverity Scan
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/6477
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Filenames of 4091 bytes or more lead to a buffer overflow.
Change-Id: I1b4b3932af096f0fcbfb783ab708ed273d3a844e
Found-by: Coverity Scan
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/6476
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
There are five firmware regions that are (currently) defined. This
was assumed throughout the ifdtool code with many literal 4s and
5s. This patch changes them to refer to a new #define NUM_REGIONS.
Change-Id: I523d3763942f875025ebc4b9ba8b2ccf1db5b2f5
Signed-off-by: Christopher Douglass <cdouglass.orion@gmail.com>
Reviewed-on: http://review.coreboot.org/5313
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The new option "--newlayout <file>" will read <file> in flashrom's
layout format and copy flash regions from the current flash image
file to a new flash image file.
If a region grows, the padding is added at the beginning of the target
region in the new file so that the data is "right-aligned" to the
end of the region.
If a region shrinks, a warning is given and the tail end of existing
data is copied to the target region in the new file.
Regions of zero or negative size are ignored. (In the example below
00fff000:00000fff regions are an artifact of the address encoding
in the register fields.)
Example Usage:
Given a flash image for a board with a Sandy Bridge processor and
Intel 6-Series chipset in the file vpx7654.bin
ifdtool --layout layout.txt vpx7564.bin
will yield the file layout.txt:
00000000:00000fff fd
00180000:003fffff bios
00001000:0017ffff me
00fff000:00000fff gbe
00fff000:00000fff pd
Notice that the "bios" portion extends to the end of the 4MB flash.
It may be edited to extend the bios portion to consume to the extent
of an 8MB flash. like layout2.txt:
00000000:00000fff fd
00180000:007fffff bios
00001000:0017ffff me
00fff000:00000fff gbe
00fff000:00000fff pd
ifdtool --newlayout layout.txt vpx7654.bin
will create a file vpx7654.bin.new that is 8MB.
Change-Id: I0e0925a725c40fa44d8c4b6e86552028779d0523
Signed-off-by: Christopher Douglass <cdouglass.orion@gmail.com>
Reviewed-on: http://review.coreboot.org/5312
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Dump the Intel Flash Descriptor map in the format expected
by flashrom's "layout" option.
Example usage:
Given a 4MB flash image vpx7654.bin that was generated by Intel's
FITC tool for a 6-Series chipset...
./ifdtool --layout l.txt vpx7654.bin
cat l.txt
00000000:00000fff fd
00180000:003fffff bios
00001000:0017ffff me
00fff000:00000fff gbe
00fff000:00000fff pd
Change-Id: Ib740178ed6935b5f6e1dba1be674303f9f980429
Signed-off-by: Christopher Douglass <cdouglass.orion@gmail.com>
Reviewed-on: http://review.coreboot.org/5306
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
ifdtool will now dump access permissions of system comonents to
certain IFD sections:
Found Master Section
FLMSTR1: 0xffff0000 (Host CPU/BIOS)
Platform Data Region Write Access: enabled
GbE Region Write Access: enabled
Intel ME Region Write Access: enabled
Host CPU/BIOS Region Write Access: enabled
Flash Descriptor Write Access: enabled
Platform Data Region Read Access: enabled
GbE Region Read Access: enabled
Intel ME Region Read Access: enabled
Host CPU/BIOS Region Read Access: enabled
Flash Descriptor Read Access: enabled
Requester ID: 0x0000
FLMSTR2: 0x0c0d0000 (Intel ME)
Platform Data Region Write Access: disabled
GbE Region Write Access: enabled
Intel ME Region Write Access: enabled
Host CPU/BIOS Region Write Access: disabled
Flash Descriptor Write Access: disabled
Platform Data Region Read Access: disabled
GbE Region Read Access: enabled
Intel ME Region Read Access: enabled
Host CPU/BIOS Region Read Access: disabled
Flash Descriptor Read Access: enabled
Requester ID: 0x0000
FLMSTR3: 0x08080118 (GbE)
Platform Data Region Write Access: disabled
GbE Region Write Access: enabled
Intel ME Region Write Access: disabled
Host CPU/BIOS Region Write Access: disabled
Flash Descriptor Write Access: disabled
Platform Data Region Read Access: disabled
GbE Region Read Access: enabled
Intel ME Region Read Access: disabled
Host CPU/BIOS Region Read Access: disabled
Flash Descriptor Read Access: disabled
Requester ID: 0x0118
Also, ifdtool -u /path/to/image will unlock the host's
access to the firmware descriptor and ME region.
ifdtool -l /path/to/image will lock down the host's
access to the firmware descriptor and ME region.
Change-Id: I3e081b80a9bcb398772416f143b794bf307b1c36
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1755
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
If a section is bigger than the FD file it is injected into, and the FD
lies about the size of the FD file, ifdtool would crash because reading
in the section writes beyound the FD file in memory.
Change-Id: Idcfac2b1e2b5907fad34799e44a8abfd89190fcc
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1754
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
The "Error while writing." error messages did not output a new line
which made the output look weird. With this patch, it should look like
this:
$ ifdtool -x 3rdparty/mainboard/google/parrot/descriptor.bin
File 3rdparty/mainboard/google/parrot/descriptor.bin is 4096 bytes
Found Flash Descriptor signature at 0x00000010
Flash Region 0 (Flash Descriptor): 00000000 - 00000fff
Flash Region 1 (BIOS): 00200000 - 007fffff
Error while writing: Bad address
Flash Region 2 (Intel ME): 00001000 - 001fffff
Error while writing: Bad address
Flash Region 3 (GbE): 00fff000 - 00000fff (unused)
Flash Region 4 (Platform Data): 00fff000 - 00000fff (unused)
Change-Id: I784ff72d0673f167dbf0bd10921406abd685ce72
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1299
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Tested-by: build bot (Jenkins)
To avoid having two copies for every firmware descriptor (one for
EM100 use and one for real SPI flash use), add an EM100 mode to
ifdtool that allows to "dumb down" a fast image to the settings
required for the EM100 to work.
Change-Id: I0ed989f0a49316bc63d8627cb5d4bd988ae7a103
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1039
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
idftool was failing to add the ME blobs into the output image in case
the blob size does not exactly match the size allocated for it in the
flashrom structure.
It is difficult to set the field in the structure to exactly match the
size (for some reason Intel flash tool fails to insert the correct
size even when given the exact ME blob). On the other hand there is no
harm in using am ME blob smaller than the allocated size, this change
modifies the tool building the image to allow for smaller components.
Change-Id: I1b04f90051b91157391943c9bad0eb06dd297431
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/751
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Fix issues reported by new lint test.
Change-Id: I077a829cb4a855cbb3b71b6eb5c66b2068be6def
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/646
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Aaron Durbin