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>
As with most other languages, a pre-installed Ada toolchain is needed
to build gcc's Ada frontend. To support building with older host tool-
chains, the patch `gcc-5.2.0_gnat.patch` disables warnings for unknown
pragmas. Building has been tested with host gcc-4.9 and hopefully works
with newer versions, too.
For convenience, the gnattools (e.g. gnatmake etc.) will be build if
'ada' is specified as a target language.
Change-Id: Ia78c29d1aba2943de5238421a324cfff8eb08875
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/11590
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Add an option `--languages` which takes a list of target languages to
buildgcc. That list gets passed through to the configure step for
building gcc.
Also alter the Makefile to pass $(BUILD_LANGUAGES) to that option, if
this variable is set.
Change-Id: I6a74ab2c75871ea8d03a499cca33d88938b59c8d
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/11589
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
There are currently 2 uses for rmodule programs: stand alone
programs that are separate from the coreboot stages and a
relocatable ramstage. For the ramstage usage there's no reason
to require a rmodule parameter section. Therefore make this
optional.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built ramstage w/ normal linking (w/o a rmodule parameter
section). No error.
Change-Id: I5f8a415e86510be9409a28068e3d3a4d0ba8733e
Signed-off-by: Aaron Durbin <adubin@chromium.org>
Reviewed-on: http://review.coreboot.org/11523
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Bring rmodule linking into the common linking method.
The __rmodule_entry symbol was removed while using
a more common _start symbol. The rmodtool will honor
the entry point found within the ELF header. Add
ENV_RMODULE so that one can distinguish the environment
when generating linker scripts for rmodules. Lastly,
directly use program.ld for the rmodule.ld linker script.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built rambi and analyzed the relocatable ramstage,
sipi_vector, and smm rmodules.
Change-Id: Iaa499eb229d8171272add9ee6d27cff75e7534ac
Signed-off-by: Aaron Durbin <adubin@chromium.org>
Reviewed-on: http://review.coreboot.org/11517
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Whenever we want to add a file to CBFS with a specific alignment, we
have to do two cbfstool invocations: one to find a place for the file,
and another to actually add the file to CBFS. Get rid of this nonsense
and allow this to be done in one step.
Change-Id: I526483296b494363f15dc169f163d93a6fc71bb0
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11525
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
According to https://gcc.gnu.org/gcc-4.6/changes.html it's only in gcc 4.6,
not 4.5, which I mistakenly believed.
Change-Id: I8212e7921bd9d1436a0ba491cbe6c4d473228956
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/11476
Reviewed-by: Jonathan A. Kollasch <jakllsch@kollasch.net>
Tested-by: build bot (Jenkins)
This isn't required for correct execution, and doesn't need to be tested
on every single compiler out there.
Since GCC < 4.5 has no idea about _Static_assert, hide it there. Our
build tests will make sure that the test is run before changes are
submitted to master.
Change-Id: I4141f4aa23b140d2d1017ca7b4dace5aa7db0c04
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/11475
Tested-by: build bot (Jenkins)
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Jonathan A. Kollasch <jakllsch@kollasch.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>
Currently, compression is only allowed at subheader level (e.g. cbfs_stage,
cbfs_payload_segment). This change adds compression field to each file's
header so that any cbfs file can be compressed.
With the necessary additions in coreboot and libpayload, the following sample
code can load a compressed file:
const char *name = "foo.bmp";
struct cbfs_file *file = cbfs_get_file(media, name);
void *dst = malloc(ntohl(file->uncompressed_size));
dst = cbfs_get_file_content(media, name, type, file, dst);
cbfs_stage and cbfs_payload_segment continue to support compression at
subheader level because stages and payloads have to be decompressed to the load
address, which is stored in the subheader. For these, file level compression
should be turned off.
Change-Id: I9a00ec99dfc68ffb2771bb4a3cc5ba6ba8a326f4
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10935
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
In order to make analysis easier provide an option (-T) to
print timestamps in a parseable format:
ID<tab>raw timestamp<tab>time from previous entry<tab>description
BUG=chrome-os-partner:44669
BRANCH=firmware-strago-7287.B
TEST=Built and tested on glados. Used the following script:
cbmem -T | awk 'BEGIN { FS="\t" } { tot += $3 } END { print tot }'
Change-Id: I06dc0487d1462b6a78924130f0ad74b0d787d3f8
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11471
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Add the timestamp tick frequency within the timestamp table so
the cbmem utility doesn't try to figure it out on its own. Those
paths still exist for x86 systems which don't provide tsc_freq_mhz().
All other non-x86 systems use the monotonic timer which has a 1us
granularity or 1MHz.
One of the main reasons is that Linux is reporting
/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq as the true
turbo frequency on turbo enables machines. This change also fixes
the p-state values honored in cpufreq for turbo machines in that
turbo p-pstates were reported as 100MHz greater than nominal.
BUG=chrome-os-partner:44669
BRANCH=firmware-strago-7287.B
TEST=Built and booted on glados. Confirmed table frequency honored.
Change-Id: I763fe2d9a7b01d0ef5556e5abff36032062f5801
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11470
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Change-Id: Ie3a44c6db9c9c186c52b4743334266ec5411ba8a
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/11472
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Change-Id: I9f59a00e735f39df813b2216290da62eea3c595d
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/11372
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Previously, X4X was incorrectly named because it provides
support for SKUs within XX4X range. This is renamed.
This patch provides support for all X4X SKUs according to
datasheet Intel 4 Series Chipset Family Specification Update,
namely: Q45, Q43, P45, P43, G45, G43, G41 and B43 (both versions).
Tested on Gigabyte GA-G41M-ES2L
Change-Id: I032265e80d9ca51e2fef29201280832ea3210a0b
Signed-off-by: Damien Zammit <damien@zamaudio.com>
Reviewed-on: http://review.coreboot.org/11245
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Whatever it is, it likely won't be cros/chromeos-2013.04 anymore.
Change-Id: I020b65a7406e3bef7d1c8fad8c530354b1f78819
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/11438
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
This patch adds support to enable a linker workaround to a hardware
erratum on some early Cortex-A53 revisions. Since the linker option was
added very recently, we use xcompile to test whether the toolchain
supports it first. It is also guarded by a Kconfig since only a few
ARM64 SoCs will need this and it incurs a performance penalty.
BRANCH=none
BUG=none
TEST=Turned it on or off for Smaug and confirmed that it (dis)appeared
in verbose make output accordingly.
Change-Id: I01c9642d3cf489134645f0db6f79f1c788ddb00d
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Original-Commit-Id: 57128785760c4dfa32d6e6d764756443a9323cb7
Original-Change-Id: Ia5dd124f484e38460d75fb864304e7e8b18d16b7
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/294745
Original-Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/11403
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Julius Werner <jwerner@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>
These functions can do all kinds of things, such as converting an ELF
image into SELF, or (in the future) compress or checksum entire files.
This may require changing or adding fields to the header, so they
need to have access to it.
The header_size parameter that was provided (but never used) is
equivalent to cbfs_file's offset field.
Change-Id: I7c10ab15f3dff4412461103e9763a1d78b7be7bb
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/11325
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>
Refactor the code to be better understandable.
Change-Id: Ia815a27f7cc83c226a32e87485d712a5fbf4168e
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/11318
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
In testing other localization changes, I found that I couldn't build
anymore because xcompile wasn't picking up my toolchain. I traced it
to the regex comparison of '.*format \(.[a-z0-9-]*\)' to the string
'formato del fichero elf32-i386'. Forcing the localization of
objdump to C before doing the comparison fixes the issue.
Change-Id: I6bed5a9824807dd5bc5a38b711ab47e2af4b0c29
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: http://review.coreboot.org/11304
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Zheng Bao <zheng.bao@amd.com>
There doesn't seem to have been an olddefconfig target in the coreboot
version of the Kconfig makefile. It's listed in the .PHONY, but it
doesn't seem like it's ever been there. This is useful for expanding
a miniconfig saved with 'make savedefconfig'.
Change-Id: I3798f8469135b58d32da68d4b0e434ab5351b501
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: http://review.coreboot.org/11273
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Some patch implementations (eg. BSD) create new files by taking the "---" file
name instead of the "+++" one, so set both to the file name that is to be
created.
Change-Id: I6f37748b4cf0852d292f8f5156fc27ab8fd481b6
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reported-by: Idwer Vollering <vidwer@gmail.com>
Reported-by: Jonathan A. Kollasch <jakllsch@kollasch.net>
Reviewed-on: http://review.coreboot.org/11303
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
It still needs to pass --32 (yes, 32) to the assembler.
x86_64-linux does this (through some other config file),
x86_64-elf did not.
This fixes building SeaBIOS with our x86_64-elf multilib compiler.
Change-Id: Ibe2a70e46e64e71c947482be5ec0eaf7f7bf300d
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/11289
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
All compilers built, incl. x86_64-elf as multilib and riscv-elf.
Change-Id: Iafa61b1d2ffc9c737ab67a417c62417593b69372
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/10975
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
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>
Display the total accumulated time using each timestamp
entry. It purposefully doesn't take into account the first
timestamp because that can be a platform dependent value
that may not contribute to the concept of "total".
BUG=None
BRANCH=None
TEST=Ran cbmem on glados where TSC doesn't reset to 0 on
reboots. Clear total value given at end.
Original-Change-Id: Idddb8b88d3aaad11d72c58b18e8fd9fd1447a30e
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/291480
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Original-Trybot-Ready: David James <davidjames@chromium.org>
Change-Id: I79a0954d3b738323aaebb3e05171bcf639e5d977
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11202
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
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>
The idea is that they can at some point add extended attributes to the header.
That also needs to be passed, but let's start simple.
Change-Id: I80359843078b149ac433ee3d739ea192592e16e7
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/11216
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
It will at some point create the header, and pass it with its size. We can
start with the size already.
Change-Id: I8f26b2335ffab99a664d1ff7bc88e33ed62cf9ca
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/11215
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>
No need to read the file before bailing out.
Change-Id: Ida7226c6ec227e1105724cdb1e5a0927217a69c7
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/11212
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This is a generic structure, not unlike the cbtables design, based on which we
can build specialized TLV data structures.
Change-Id: I98a75eef19f049ad67d46cdc2790949dcd155797
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10937
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
1. Add -P|--package to build iasl
2. Remove -G|--skip-gdb, which was to skip gdb.
3. Add -S|--scripting to build gdb
4. Remove -C|--clang, which was to build clang.
All these changes are aligned with the options parsing below.
The help text is correct.
Change-Id: I897ea5e8ab002086e45bf05ff33230815b246057
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/11158
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Vladimir Serbinenko