With the introduction of flashmap cbfs alignment of files gets
broken because flashmap is located at the beginning of the flash
and cbfstool didn't take care about that offset.
This commit fixes the alignment in cbfs.
Change-Id: Idebb86d4c691b49a351a402ef79c62d31622c773
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/13417
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Adding new files overwrote the header with the empty file (ie 0xff),
so carve out some space.
BUG=chromium:445938
BRANCH=none
TEST=none
Change-Id: I91c292df381c2bac41c6cb9dda74dae99defd81d
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/12789
Tested-by: build bot (Jenkins)
These need to go together, so the commit became a bit larger than
typial.
- Add an option -R for the copy source fmap region.
Use: cbfstool copy -r target-region -R source-region.
- Don't generate a CBFS master header because for fmap regions, we
assume that the region starts with a file header.
Use cbfstool add-master-header to add it afterwards, if necessary.
- Don't copy files of type "cbfs master header" (which are what cbfstool
add-master-header creates)
- Leave room for the master header pointer
- Remove -D command line option as it's no longer used.
BUG=chromium:445938
BRANCH=none
TEST=Manual test on image and integration test w/ bundle_firmware
changes.
CQ-DEPEND=CL:313770,CL:313771
Change-Id: I2a11cda42caee96aa763f162b5f3bc11bb7992f9
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/12788
Tested-by: build bot (Jenkins)
This allows adding support for FMAP based cbfstool copy more easily.
BUG=chromium:445938
Change-Id: I72e7bc4da7d27853e324400f76f86136e3d8726e
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/12787
Tested-by: build bot (Jenkins)
If HOSTCC=clang, the -Wtautological-constant-out-of-range-compare is
set automaticaaly. That assume the value of type enum is in the defined
range. Then testing if a type enum is out of range causes build error.
Error:
coreboot/util/cbfstool/cbfs_image.c:1387:16: error:
comparison of constant 4 with expression of type 'enum vb2_hash_algorithm'
is always false [-Werror,-Wtautological-constant-out-of-range-compare]
if (hash_type >= CBFS_NUM_SUPPORTED_HASHES)
~~~~~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.
clang version:
FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512
Target: x86_64-unknown-freebsd10.2
Thread model: posix
Change-Id: I3e1722bf6f9553793a9f0c7f4e790706b6938522
Signed-off-by: zbao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/12330
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
When using FMAP regions (with option -r) that were generated with a
master header (as done by cbfstool copy, eg. in Chrome OS' build
system), there were differences in interpretation of the master header's
fields.
Normalize for that by not sanity-checking the master header's size field
(there are enough other tests) and by dealing with region offsets
properly.
BUG=chromium:445938
BRANCH=tot
TEST=`cbfstool /build/veyron_minnie/firmware/image.dev.bin print -r
FW_MAIN_A` shows that region's directory (instead of claiming that
there's no CBFS at all, or showing an empty directory).
Change-Id: Ia840c823739d4ca144a7f861573d6d1b4113d799
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 0e5364d291f45e4705e83c0331e128e35ab226d3
Original-Change-Id: Ie28edbf55ec56b7c78160000290ef3c57fda0f0e
Original-Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/312210
Original-Commit-Ready: Patrick Georgi <pgeorgi@chromium.org>
Original-Tested-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/12416
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
It encourages users from writing to the FSF without giving an address.
Linux also prefers to drop that and their checkpatch.pl (that we
imported) looks out for that.
This is the result of util/scripts/no-fsf-addresses.sh with no further
editing.
Change-Id: Ie96faea295fe001911d77dbc51e9a6789558fbd6
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/11888
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
With the previous ELF stage extract support the resulting
ELF files wouldn't handle rmodules correctly in that the
rmodule header as well as the relocations were a part of
the program proper. Instead, try an initial pass at
converting the stage as if it was an rmodule first. If it
doesn't work fall back on the normal ELF extraction.
TEST=Pulled an rmodule out of Chrome OS shellball. Manually
matched up the metadata and relocations.
Change-Id: Iaf222f92d145116ca4dfaa955fb7278e583161f2
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/12222
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Instead of dumping the raw stage data when cbfstool
extract is used on stage create an equivalent ELF file.
Because there isn't a lot of information within a stage
file only a rudimentary ELF can be created.
Note: this will break Chrome OS' current usage of extract
since the file is no longer a cbfs_stage. It's an ELF file.
TEST=Extracted romstage from rom.
Change-Id: I8d24a7fa4c5717e4bbba5963139d0d9af4ef8f52
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/12219
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
In order to prepare allowing for one to extract a stage
into an ELF file provide an optional -m ARCH option. This
allows one to indicate to cbfstool what architecture type
the ELF file should be in.
Longer term each stage and payload will have an attribute
associated with it which indicates the attributes of
the executable.
Change-Id: Id190c9719908afa85d5a3b2404ff818009eabb4c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/12217
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
In order to actually do something useful with the
resulting file after being extracted decompress stage
files' content. That way one can interrogate the
resulting file w/o having to decompress on the fly.
Note: This change will cause an unexpected change to
Chrome OS devices which package up individual stage
files in the RW slots w/o using cbfs. The result will
be that compressed stages are now decompressed.
Longer term is to turn these files into proper ELF
files on the way out.
Change-Id: I373ecc7b924ea21af8d891a8cb8f01fd64467360
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/12174
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Currently cbfs stage files that are compressed do not have
the decompressed size readily available. Therefore there's
no good way to know actual size of data after it is
decompressed. Optionally return the decompressed data size
if requested.
Change-Id: If371753d28d0ff512118d8bc06fdd48f4a0aeae7
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/12173
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Currently, cbfstool regressed that removing a file from CBFS the space
is marked as empty but the filename is still shown, preventing adding a
file with the same name again. [1]
```
$ echo a > a
$ echo b > b
$ ./util/cbfstool/cbfstool test.rom create -m x86 -s 1024
Created CBFS (capacity = 920 bytes)
$ ./util/cbfstool/cbfstool test.rom add -f a -n a -t raw
$ ./util/cbfstool/cbfstool test.rom add -f b -n b -t raw
$ cp test.rom test.rom.original
$ ./util/cbfstool/cbfstool test.rom remove -n
$ diff -up <(hexdump -C test.rom.original) <(hexdump -C test.rom)
--- /dev/fd/63 2015-08-07 08:43:42.118430961 -0500
+++ /dev/fd/62 2015-08-07 08:43:42.114430961 -0500
@@ -1,4 +1,4 @@
-00000000 4c 41 52 43 48 49 56 45 00 00 00 02 00 00 00 50 |LARCHIVE.......P|
+00000000 4c 41 52 43 48 49 56 45 00 00 00 02 ff ff ff ff |LARCHIVE........|
00000010 00 00 00 00 00 00 00 28 61 00 00 00 00 00 00 00 |.......(a.......|
00000020 00 00 00 00 00 00 00 00 61 0a ff ff ff ff ff ff |........a.......|
00000030 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
$ ./util/cbfstool/cbfstool test.rom add -f c -n c -t raw
$ ./util/cbfstool/cbfstool test.rom print
test.rom: 1 kB, bootblocksize 0, romsize 1024, offset 0x0
alignment: 64 bytes, architecture: x86
Name Offset Type Size
c 0x0 raw 2
b 0x40 raw 2
(empty) 0x80 null 792
```
So it is “deteled” as the type changed. But the name was not changed to
match the *(empty)* heuristic.
So also adapt the name when removing a file by writing a null byte to
the beginning of the name, so that the heuristic works. (Though remove
doesn't really clear contents.)
```
$ ./util/cbfstool/cbfstool test.rom remove -n c
$ ./util/cbfstool/cbfstool test.rom print
test.rom: 1 kB, bootblocksize 0, romsize 1024, offset 0x0
alignment: 64 bytes, architecture: x86
Name Offset Type Size
(empty) 0x0 null 2
b 0x40 raw 2
(empty) 0x80 null 792
```
[1] http://www.coreboot.org/pipermail/coreboot/2015-August/080201.html
Change-Id: I033456ab10e3e1b402ac2374f3a887cefd3e5abf
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/11632
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
They allow optimizing a verification of a whole CBFS image by only
dealing with the headers (assuming you choose to trust the hash
algorithm(s)).
The format allows for multiple hashes for a single file, and cbfstool
can handle them, but right now it can't generate such headers.
Loosely based on Sol's work in http://review.coreboot.org/#/c/10147/,
but using the compatible file attribute format. vboot is now a hard
dependency of the build process, but we import it into the tree for
quite a while now.
Change-Id: I9f14f30537d676ce209ad612e7327c6f4810b313
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/11767
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Up to now, if both fmap and a master header existed, the master header
was used. Now, use the master header only if no fmap is found.
Change-Id: Iafbf2c9dc325597e23a9780b495549b5d912e9ad
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/11629
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The cbfs_locate_entry() function had a hack in there which
assumed a struct cbfs_stage data was being added in addition
to the struct cbfs_file and name. Move that logic out to the
callers while still maintaining the logic for consistency.
The only impacted commands cbfs_add and cbfs_locate, but
those are using the default 'always adding struct cbfs_stage'
in addition to cbfs_file + name. Eventually those should be
removed when cbfs_locate is removed as cbfs_add has no smarts
related to the cbfs file type provided.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built rambi.
Change-Id: I2771116ea1ff439ea53b8886e1f33e0e637a79d4
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11668
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
We had two mappings of filetype IDs to strings. We shouldn't.
Change-Id: I08e478b92f3316139f14294e50ede657c7d5fb01
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/11626
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Display compressed and decompressed sizes, as well as the compression
algorithm used, when a compressed file is encountered.
Change-Id: I13c2332702c4a5bec379e1ebda72753e06f8e135
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/11359
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
We have tons of file types now that can be safely extracted.
It's pretty much only stages and payloads that aren't.
Change-Id: Ibf58a2c721f863d654537850c6f93d68a8a5bbeb
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/11360
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
My concern was that compilers may something stupid under the assumption
of a fixed struct size, but filename is already variable, so things are
okay.
Change-Id: I5348faf68f0a7993294e9de4c0b6c737278b28af
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/11331
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
They're passed as part of the header now.
Change-Id: I7cd6296adac1fa72e0708b89c7009552e272f656
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/11327
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The header is now created before the "converters" are run.
Adding new capabilities (and fields to the header) will happen there,
so we're close.
Change-Id: I0556df724bd93816b435efff7d931293dbed918f
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/11326
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
It's sole use was comparing it to the header's "len" field.
Change-Id: Ic3657a709dee0d2b9288373757345a1a56124f37
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/11324
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
->len used to be set to the file data length plus the size of the
padding used for the cbfs_file header. This isn't the case anymore,
so no patching of this field is necessary anymore.
->offset still needs to be patched in that case because its final
value can only be determined when the file's actual location is known.
Change-Id: I1037885f81b4ed3b68898dd7d0e515cf7a9c90a8
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/11322
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Up to now cbfstool creates the cbfs_file header at the latest possible
time, which is unsuitable when the idea is to add further fields to it
that need to be configured earlier.
Thus, have it ripple up the call chain.
Change-Id: I7c160681c31818bc550ed2098008146043d0ee01
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/11320
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
"target", for what? It's the offset where the file header of the currently
added file will be located, name it as such.
Change-Id: I382f08f81991faf660e217566849773d9a7ec227
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/11319
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
After the preparation in earlier commits, it is now possible to handle the
more general case of position independent files using the special code path
for fixed location files.
This leads to a single place where non-empty cbfs file headers are actually
written into the image, allowing us to move it up the chain more easily.
Change-Id: I8c1fca5e4e81c20971b2960c87690e982aa3e274
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/11222
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
... and the assert is gone.
The actual action of adding a just-right file can be moved after the tests
since it's exactly the condition those tests don't continue or break on.
Change-Id: I6d0e829e0158198301136ada9a0de2f168ceee3f
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/11221
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The assert() makes sure the if() holds true. But that assert won't survive for
long.
Change-Id: Iab7d2bc7bfebb3f3b3ce70dc5bd041902e14bd7a
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/11220
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
We will want to create headers that live outside the final image at some point
(eg. to build the file before we even know where to place it).
Change-Id: Ie4c0323df8d5be955aec3621b75309e8f11fae49
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/11219
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Pass the file type into it instead of creating an entry, then modifying the
header field again after the fact.
Change-Id: I655583218f5085035b0f80efff7f91a66b5b296e
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/11218
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
If an earlier stage built a larger header, cbfs_add_entry_at() shouldn't
decide to go with the most boring, least featureful header type (and its size)
instead.
Change-Id: Icc5dcd9a797a0f3c42f91cddd21b3b3916095b63
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/11217
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Headers vary in size soon, and more places need to be able to calculate their
size.
Change-Id: I30761bb9da0756418993dee21d8fa18cf3174c40
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/11214
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This is in preparation of creating the cbfs_file header much earlier
in the process. For now, size is enough because lots of things need to
move before it makes sense to deal with cbfs_file at a higher level.
Change-Id: I47589247c3011cb828170eaa10ef4a1e0f85ab84
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/11213
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The code for removing a file had its own merge routine. Use the generic one
instead.
Change-Id: I90ed007ab86f78a2728f529fa0143c5c1dfbbdc3
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/10967
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
So far it's still unused, but its purpose will change:
It will become an offset to another structure that contains additional file
attributes.
This change is compatible because the binary format doesn't change and so far
the field was always set to 0, which can serve nicely as 'unused' field.
Change-Id: I2dafb06866713d43a236556f9492641526270837
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10933
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Trailing commas are useful for lists that can be extended. These lists are
0-terminated, and there should be no elements following that.
Change-Id: Iea8c6d5579d6363e77e1f5af666948160c4a9bf9
Signed-off-by: Sol Boucher <solb@chromium.org>
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Change-Id: I1a117a9473e895feaf455bb30d0f945f57de51eb
Original-Signed-off-by: Sol Boucher <solb@chromium.org>
Reviewed-on: http://review.coreboot.org/10932
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Parse compression algorithm arguments using a single list.
Change-Id: Idc5b14a53377b29964f24221e42db6e09a497d48
Signed-off-by: Sol Boucher <solb@chromium.org>
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Change-Id: I1a117a9473e895feaf455bb30d0f945f57de51eb
Original-Signed-off-by: Sol Boucher <solb@chromium.org>
Reviewed-on: http://review.coreboot.org/10931
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
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>
The cbfstool handling of new-style FMAP-driven "partitioned" images
originally disallowed the use of x86-style top-aligned addresses with
the add.* and layout actions because it wasn't obvious how they should
work, especially since the normal addressing is done relative to each
individual region for these types of images. Not surprisingly,
however, the x86 portions of the build system make copious use of
top-aligned addresses, so this allows their use with new images and
specifies their behavior as being relative to the *image* end---not
the region end---just as it is for legacy images.
Change-Id: Icecc843f4f8b6bb52aa0ea16df771faa278228d2
Signed-off-by: Sol Boucher <solb@chromium.org>
Reviewed-on: http://review.coreboot.org/10136
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Werner Zeh