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>
When the script was pulled out of the makefile, it was left as it was
written in the makefile to show the continuity with the original. This
patch cleans up issues identified by shellcheck and adds comments.
Change-Id: I5e6573a4fdfbb397e15db38e2e3dfadeb3430573
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: http://review.coreboot.org/11931
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
To add lint to jenkins testing, we need junit.xml output. This adds an
optional --junit command line parameter to enable output to an xml file
in the lint directory.
Change-Id: I5588190cb050b9dbe99458cb18a71a147769f50e
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: http://review.coreboot.org/11891
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
In preparation for adding junit xml to the lint tests, move the
script out of Makefile.inc and into its own file.
Add a copyright, usage, and error checking that was not needed
inside the Makefile.
Change-Id: I32bebc6a5f1f6fa652812c8a014d84006e2e6c8a
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: http://review.coreboot.org/11890
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The 'what-jenkins-does' makefile target was renaming the junit filename
after abuild finished. Instead, just add a command line parameter to
send it to a different filename.
Change-Id: I66f7d80d621573d77a5154f36f2db49d7b2e948a
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: http://review.coreboot.org/11878
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This chip is still being used and should not have been deleted. It's
a current intel chip, and doesn't even require an ME binary.
This reverts commit 959478a763.
Change-Id: I78594871f87af6e882a245077b59727e15f8021a
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: http://review.coreboot.org/11860
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc@marcjonesconsulting.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
E.g. on my MacbookAir to generate spd.bin to be used
with coreboot I do:
./inteltool -S spd.bin
Change-Id: If165475ed3e1f3262a8926ef619128d25b1e2896
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/11847
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc@marcjonesconsulting.com>
Only one value would work with corresponding gma code currently (which one
depends on board). Going forward, it's possible to compute which number can
be used, so there is no need to keep this info around.
Change-Id: Iadc77ef94b02f892860e3ae8d70a0a792758565d
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/11862
Tested-by: build bot (Jenkins)
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Based on the info by Felix Held.
Change-Id: Iab84dd8a0e3c942da20a6e21db5510e4ad16cadd
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/11857
Tested-by: build bot (Jenkins)
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Currently cbfstool would reject non-alpanumeric characters in
image names. Underscore is not alphanumeric and is used in some
default fmaps. This change allows image names to contain all
"printable" characters except spaces.
Change-Id: I6ba2b581d5623f5b028149ece0169892ea63fd04
Signed-off-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-on: http://review.coreboot.org/11807
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The binutils-2.25 has added some new line, making the hunk
move downward a little. The utility patch can fix the offset
with "fuzz" message. So, recreate the patch to avoid that
message.
Change-Id: Ie659a8faf923465f6d47f7c0c0bf903c5eb903ab
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/11639
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Clang is the default compiler on BSD and OS X. With this
change, we don't have to install gcc any more. Clang can
act as host cc.
This is a known issue on GNU mail list. Please refer
the link below.
https://sourceware.org/bugzilla/show_bug.cgi?id=17473
Change-Id: I0f014b776e86e6d0cbebd560cb17f469f31e1dfb
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/11638
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Grep the output of wget, showing only the percentage.
Leave the final "100%" unerased.
Checking return code of wget is removed.
Change-Id: I4559e88d541738a594dce92e23589992f234cb9b
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/11520
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
mohonpeak is the reference board for Rangeley. I doubt anyone uses it
or cares about it. We jokingly refer to it as "Moron Peak". It's code
with no known users, so we shouldn't be hauling it around for the
eventuality that someone might use it in the future.
Change-Id: Id3c9fc39e1b98707d96a95f2a914de6bbb31c615
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11790
Tested-by: build bot (Jenkins)
Reviewed-by: Philipp Deppenwiese <zaolin@das-labor.org>
We already have two other code paths for this silicon. Maintaining the
FSP path as well doesn't make much sense. There was only one board to
use this code, and it's a reference board that I doubt anyone still
owns or uses.
Change-Id: I4fcfa6c56448416624fd26418df19b354eb72f39
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11789
Tested-by: build bot (Jenkins)
Reviewed-by: Philipp Deppenwiese <zaolin@das-labor.org>
This is a sad story. We have three different code paths for
sandybridge and ivybridge: proper native path, google MRC path, and,
everyone's favorite: Intel FSP path. For the purpose of this patch,
the FSP path lives in its own little world, and doesn't concern us.
Since MRC was first, when native files and variables were added, they
were suffixed with "_native" to separate them from the existing code.
This can cause confusion, as the suffix might make the native files
seem parasitical.
This has been bothering me for many months. MRC should be the
parasitical path, especially since we fully support native init, and
it works more reliably, on a wider range of hardware. There have been
a few board ports that never made it to coreboot.org because MRC would
hang.
gigabyte/ga-b75m-d3h is a prime example: it did not work with MRC, so
the effort was abandoned at first. Once the native path became
available, the effort was restarted and the board is now supported.
In honor of the hackers and pioneers who made the native code
possible, rename things so that their effort is the first class
citizen.
Change-Id: Ic86cee5e00bf7f598716d3d15d1ea81ca673932f
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11788
Tested-by: build bot (Jenkins)
Reviewed-by: Philipp Deppenwiese <zaolin@das-labor.org>
When adding an FSP blob relocate it to its final
destination. This allows FSP to not be hard coded in
the cbfs. In order for the include paths to work
correctly w/ the edk 2 headers we need to supply
a neutered ProcessorBind.h to match up with the
tool environment such that one can get the UEFI
Platform Initialization type definitions.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built glados and booted. Also added FSP with -b and manually
adjusted location in fsp cache-as-ram. Booted as well.
Change-Id: I830d93578fdf745a51195109cf18d94a83ee8cd3
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11778
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
For shared compilation units between coreboot proper
and cbfstool that means one needs to provide printk
logging. Therefore, provide printk() at <console/console.h>
to mimic coreboot's environment.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built cbfstool with code that includes and uses
<console/console.h>.
Change-Id: I8e54d403526a397e4fd117738a367a0a7bb71637
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11774
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Older gcc versions throws a warning when a struct or union is
declared without a valid name (anonymous). This patch enables the
feature for older gcc versions so that no warning will be issued.
Change-Id: Idc5481f4d5723c5090a6f7d7dbb0686a737e11fc
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: http://review.coreboot.org/11779
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.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>
Change-Id: I1c5e3424cb56f1f10e75bb07db084c3500f3ba07
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/11768
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
We need to emit some hex strings.
Change-Id: I9e7e184282f6ad0470f2e269f5dc874e78f8b697
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/11766
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: Iecefdd1e827e4eb8b4da573e4291850d6c47767f
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/11754
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
To catch dependency errors in symbol.c (such as the ones
fixed by I51b4ee326f082c6a656a813ee5772e9c34f5c343) we need
to check for global kconfig warnings before saving config
files.
This patch will produce errors for wrong dependencies and
add catching of errors to conf, nconf and mconf. Sorry,
gconf users, you will have to wait.
Change-Id: Idf7ee406ce3869941af319219aea16fab826df84
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/11291
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
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>
On x86, the bootblock can (and will) become part of the regular file
system, so there's no distinct fixed-size region for the bootblock
there.
Change-Id: Ie139215b73e01027bc0586701361e9a0afa9150e
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/11691
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
$(src) is not defined when building directly from the cbfs directory (that is,
when building cbfs as standalone, running make in the cbfs directory), so we
need to define the path to the commonlib include path relative to $(top).
Change-Id: I72e80b030d4a156ec653ded5ab1457b16f612526
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-on: http://review.coreboot.org/11706
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Instead of reaching into src/include and re-writing code
allow for cleaner code sharing within coreboot and its
utilities. The additional thing needed at this point is
for the utilities to provide a printk() declaration within
a <console/console.h> file. That way code which uses printk()
can than be mapped properly to verbosity of utility parameters.
Change-Id: I9e46a279569733336bc0a018aed96bc924c07cdd
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11592
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
endian.h lives in under sys on the BSDs. Replace htole32() with
swab32(htonl(..)) as a proxy for little endian operations.
Change-Id: I84a88f6882b6c8f14fb089e4b629e916386afe4d
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11695
Tested-by: build bot (Jenkins)
Reviewed-by: Idwer Vollering <vidwer@gmail.com>
Reviewed-by: Jonathan A. Kollasch <jakllsch@kollasch.net>
Since fmap doesn't come with a checksum, we resort to a number of
heuristics to determine if a given location hosts an fmap (instead of
another data structure that happens to store the fmap magic string at
the right location).
The version test is particularly effective against strings containing
the magic (which either terminate with 0, or have some other ASCII data,
but rarely a '\001' byte inside the string).
Change-Id: Ic66eb0015c7ffdfe25e0054b7838445b8ba098e9
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/11690
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The command adds a new cbfs file, fills in the CBFS meta data in cbfs
master header format, then points the master header pointer (which
resides at the last 4 bytes of the CBFS region) to the data area of the
new file.
This can leak some space in CBFS if an old-style CBFS with native master
header gets the treatment, because a new header is created and pointed
at. flashmap based images have no such header, and the attempt to create
a second file with the (hardcoded) name will fail.
Change-Id: I5bc7fbcb5962b35a95261f30f0c93008e760680d
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/11628
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This is more in line with how fmd/fmap specify ranges.
Change-Id: Iecf8250e84d6eb267711ded446909b21147f1a9c
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/11623
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Let's move x86 style bootblocks (and later the others) and the master header
into the CBFS structure. Prepare for this by adding file types.
Change-Id: I1b4149c7f3b8564ee358a2c18ba91e6a7a6797da
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/11627
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
fileno() is a mess on some operating systems. Don't
deliberately convert between FILE * and file handles.
Change-Id: I5be62a731f928333ea2e5843d81f541453fdb396
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/11636
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
flmstr register bits have slightly different meaning for IFD v2.
BUG=chrome-os-partner:45091, chrome-os-partner:43461
TEST=Run `ifdtool -d image.bin` on IFD v1 locked squawks image:
Found Master Section
FLMSTR1: 0x0a0b0000 (Host CPU/BIOS)
Platform Data Region Write Access: disabled
GbE Region Write Access: enabled
Intel ME Region Write Access: disabled
Host CPU/BIOS Region Write Access: enabled
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: 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
Then, run `ifdtool -l image.bin` and verify newly locked image is identical.
Next, run `ifdtool -l image.bin` on unlocked glados image. Verify that locked
and unlocked regions are identical to above.
Finally, burn glados image, run `flashrom -V`, and verify ME regions is
locked and descriptor region is RO.
BRANCH=None
Change-Id: I8a65bdc5edd0d888138b88c1189f8badd1404b64
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 11c434835a66a50ab2c0c01a084edc96cbe052da
Original-Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Original-Change-Id: I875dfce6f5cf57831714702872bfe636f8f953f4
Original-Reviewed-on: https://chromium-review.googlesource.com/298968
Original-Commit-Ready: Shawn N <shawnn@chromium.org>
Original-Tested-by: Shawn N <shawnn@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11658
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
There's no need to maintain two lists of dependencies that need to be
changed every. single. time.
Change-Id: I26bb8c884e98afe74fd9df11464bcf88e130cd92
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/11674
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
It was added to an unused variable.
Change-Id: I869ffdda7e04b5c615931473c760d66b803fb98b
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/11673
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The locate command was previously being used for x86 romstage
linking as well as alignment handling of files. The add command
already supports alignment so there's no more users of the
locate command. Remove the command as well as the '-T' (top-aligned)
option.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built rambi. Noted microcode being directly added.
Change-Id: I3b6647bd4cac04a113ab3592f345281fbcd681af
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11671
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Instead of going through the locate then add-stage
dance while linking romstage twice allow for adding romstage
with --xip flags to perform the relocation while adding it
into CBFS. The -P (page-size) and -a (alignment) parameters
were added as well so one could specify the necessary
parameters for x86 romstage.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built and booted on glados.
Change-Id: I585619886f257e35f00961a1574009a51c28ff2b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11669
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
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>
In order to allow cbfstool to add XIP romstage on x86 without
doing the 'cbfstool locate', relink, then 'cbfstool add' dance
expose the core logic and of rmodule including proving an optional
filter. The filter will be used for ignoring relocations to the
.car.global region.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built rambi.
Change-Id: I192ae2e2f2e727d3183d32fd3eef8b64aacd92f4
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11598
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The core logic of the rmodule parser is ideal for
processing romstage ELF files for XIP. To that
end start the work of exposing the logic from
rmodule so cbfstool can take advantage of it.
The properties that both need require:
- Single program segment
- Relocation information
- Filter relocation processing
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built rambi.
Change-Id: I176d0ae0ae1933cdf6adac67d393ba676198861a
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11595
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
There's no need to whine about missing files, so test for them first.
Change-Id: I906fd04a315de70340ce76d7c38eaaf88cc6580a
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/11642
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
We build the coreboot utilities in a separate step as a minor
optimization. When logging in junit format (for jenkins), we want to
have a report on those as well (instead of an xml error).
Change-Id: Ibcd3b02bce9a314c30b5f7414e9e4cf0149ffd6a
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/11641
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Variable expansion made abuild create board..foo/bar, which are annoying
on jenkins' web UI because it doesn't cope properly with the empty
namespace between the dots. make it create board.foo/bar or
board.$class.foo/bar.
Change-Id: Ifa79cbfd1f263e11a458b3cc320baeed6a3fbc98
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/11640
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
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>
Patrick Georgi