| Age | Commit message (Collapse) | Author |
|---|
|
Add support for PE32+ binaries which can be found on X64 UEFI
builds.
TEST: Able to relocate and boot a X64 FSP.
Change-Id: I22586834d7c9f3ab3a5e31bba957584587ec14e0
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82680
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Include `fsp_header.h` from vendorcode for dynamic FSP_INFO_HEADER
selection.
BUG=b:242829490
TEST=google/rex0 builds successfully with 64-bit FSP.
Change-Id: If165e0517752f320d898cf82f298aa9f5699ae86
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81624
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Commit 1df1cf994aa9 ("commonlib/fsp_relocate: add PE32 section
support") introduced a potential NULL pointer dereference if there is
PE32 binary to relocate outside of the first firmware volume.
The `fih_offset' pointer was used as an output variable but now it is
also used as an input variable to pass the FSP information header to
the `pe_relocate()' function.
This commit resolves this potential NULL-pointer dereference by
passing the pointer systematically and without affecting the logic as
it is only set if it has not been set before.
Change-Id: I9fad90a60854d5f050aa044a5c0b3af91c99df4a
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78501
Reviewed-by: Bora Guvendik <bora.guvendik@intel.com>
Reviewed-by: Eric Lai <ericllai@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Similarly to te_relocate(), on success pe_relocate() should return 0.
It has never been an issue so far as pe_relocate() return value is not
tested.
Change-Id: I8e531662952d12e1f0ffa34042dab778ea602bfc
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76891
Reviewed-by: Pratikkumar V Prajapati <pratikkumar.v.prajapati@intel.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Anil Kumar K <anil.kumar.k@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
|
|
Use C99 flexible arrays instead of older style of one-element or
zero-length arrays.
It allows the compiler to generate errors when the flexible array does
not occur at the end in the structure.
Change-Id: I52b5a83e7e484889bfef5a4e45a0279fadd58890
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76784
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
On a 32-bit host, uintptr_t is defined as 'unsigned int' instead of
'unsigend long int' like on a 64-bit host. When cbfstool is built on a
32-bit host, the printk format specifier '%lx' expects a 'long int'
while new_addr is of type 'uintptr_t', aka 'unsigned int'.
This in the end leads to a build error.
To fix this and make it build on both, 32- and 64-bit hosts, use PRIxPTR
as the format specifier. This macro will be resolved at compile time in
the right way on both, 32- and 64-bit hosts.
Test=Build cbfstool on 32- and 64-bit hosts.
Change-Id: Ia917d2ed31778f3a29c0a6c7368f74c15319b099
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69682
Reviewed-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
Change-Id: Ib20f02cc9e5be0efea8bc29fce6bd148adf28ead
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69817
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
It is no longer necessary to explicitly add "ERROR: "/"WARNING: " in
front of every BIOS_ERR/BIOS_WARN message.
Change-Id: I22ee6ae15c3d3a848853c5460b3b3c1795adf2f5
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69405
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
|
|
Recently published Intel CedarIslandFSP binary contains PE images in
FSP-M and FSP-S. This causes coreboot boot hang on DeltaLake servers.
PI spec PI_Spec_1_7_final_Jan_2019 on uefi.org talks about FV files
requiring to support SECTION_PE32 sections and FSP specification
states that FSP images are created in alignment with PI specification.
FSP images are relocated at build time and run time using the func
fsp_component_relocate. That code only supported TE image relocation
so far.
The change required to add support for pe_relocate in fsp-relocate.c
I had to move a few functions to top of file as they need to be used
by pe_relocate but were placed below the te_relocate function. I chose
to place pe_relocate function next to te_relocate.
The code supports PE32 format, not PE32+, at this time.
Links for PE and FSP specs are provided below for reference.
Link= https://www.intel.com/content/dam/www/public/us/en/documents/technical-specifications/fsp-architecture-spec-v2.pdf
Link= https://uefi.org/sites/default/files/resources/PI_Spec_1_7_final_Jan_2019.pdf
TESTED=
This code is tested with FSP version 33A for DeltaLake boot which has
FSP-M and FSP-S as PE32 sections. This FSP version does not boot on
DeltaLake without this change.
Change-Id: I01e2c123d74f735a647b994aa66419c9796f193e
Signed-off-by: Eddie Sharma <aeddiesharma@fb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66819
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Nathaniel L Desimone <nathaniel.l.desimone@intel.com>
|
|
It seems fixup or adjustment addition for relocation type
EFI_IMAGE_REL_BASED_DIR64 is missing in the fsp rebasing code. The
patch address the miss. Without extending the fixup for the relocation
type, build system throws warnings during the rebasing of FSP-M and
FSP-S blobs which are built with 64bit.
Portion of build output containing warning with debug enabled cbfs lib:
...................................................
E: file offset: 9218
E: file type = 4
E: file attribs = 0
E: section offset: 9230
E: section type: 12
E: TE image at offset 9234
E: TE Image 0xffed80d4 -> 0xff256234 adjust value: ff37e000
E: Relocs for RVA offset 12000
E: Num relocs in block: 18
E: reloc type a offset f40
E: Unknown reloc type: a
Portion of build output after fix:
..................................
E: file offset: 9218
E: file type = 4
E: file attribs = 0
E: section offset: 9230
E: section type: 12
E: TE image at offset 9234
E: TE Image 0xffed80d4 -> 0xff256234 adjust value: ff37e000
E: Relocs for RVA offset 12000^M
E: Num relocs in block: 18
E: reloc type a offset f40
E: Adjusting 0x7f2e7f377024 ffee9192 -> ff267192
E: reloc type a offset f48
TEST: Integrate FSP blobs built with 64 bit and do boot test.
Signed-off-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Change-Id: I894007ec50378357c00d635ec86d044710892aab
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65383
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
|
|
Include <stddef.h> since we need it for 'size_t'.
Unused <stdlib.h> found using:
diff <(git grep -l '#include <stdlib.h>' -- src/) <(git grep -l 'memalign(\|malloc(\|calloc(\|free(' -- src/)
Change-Id: I3c2668013c16d6771268e8739b1370968c2e120b
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/60620
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <martinroth@google.com>
|
|
Stefan thinks they don't add value.
Command used:
sed -i -e '/file is part of /d' $(git grep "file is part of " |egrep ":( */\*.*\*/\$|#|;#|-- | *\* )" | cut -d: -f1 |grep -v crossgcc |grep -v gcov | grep -v /elf.h |grep -v nvramtool)
The exceptions are for:
- crossgcc (patch file)
- gcov (imported from gcc)
- elf.h (imported from GNU's libc)
- nvramtool (more complicated header)
The removed lines are:
- fmt.Fprintln(f, "/* This file is part of the coreboot project. */")
-# This file is part of a set of unofficial pre-commit hooks available
-/* This file is part of coreboot */
-# This file is part of msrtool.
-/* This file is part of msrtool. */
- * This file is part of ncurses, designed to be appended after curses.h.in
-/* This file is part of pgtblgen. */
- * This file is part of the coreboot project.
- /* This file is part of the coreboot project. */
-# This file is part of the coreboot project.
-# This file is part of the coreboot project.
-## This file is part of the coreboot project.
--- This file is part of the coreboot project.
-/* This file is part of the coreboot project */
-/* This file is part of the coreboot project. */
-;## This file is part of the coreboot project.
-# This file is part of the coreboot project. It originated in the
- * This file is part of the coreinfo project.
-## This file is part of the coreinfo project.
- * This file is part of the depthcharge project.
-/* This file is part of the depthcharge project. */
-/* This file is part of the ectool project. */
- * This file is part of the GNU C Library.
- * This file is part of the libpayload project.
-## This file is part of the libpayload project.
-/* This file is part of the Linux kernel. */
-## This file is part of the superiotool project.
-/* This file is part of the superiotool project */
-/* This file is part of uio_usbdebug */
Change-Id: I82d872b3b337388c93d5f5bf704e9ee9e53ab3a9
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41194
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Done with sed and God Lines. Only done for C-like code for now.
Change-Id: I29e746115e3b0630238176a0f913a3b5340962eb
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40047
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
Change-Id: I9426b88c0936c68d02554b580cc312902b8e5e13
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37810
Reviewed-by: Frans Hendriks <fhendriks@eltan.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
As discussed on the mailing list and voted upon, the coreboot project
is going to move the majority of copyrights out of the headers and into
an AUTHORS file. This will happen a bit at a time, as we'll be unifying
license headers at the same time.
Signed-off-by: Martin Roth <martin@coreboot.org>
Change-Id: I4c9351652d81040cc4e7b85bdd1ba85709a74192
Reviewed-on: https://review.coreboot.org/c/coreboot/+/35178
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Correct typo of 'compilation'
BUG=N/A
TEST=N/A
Change-Id: Iee6b8a8afc4d885d2d4ab9ee5d596e32e5e6d3f1
Signed-off-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-on: https://review.coreboot.org/c/29831
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
|
|
Its spreading copies got out of sync. And as it is not a standard header
but used in commonlib code, it belongs into commonlib. While we are at
it, always include it via GCC's `-include` switch.
Some Windows and BSD quirk handling went into the util copies. We always
guard from redefinitions now to prevent further issues.
Change-Id: I850414e6db1d799dce71ff2dc044e6a000ad2552
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/28927
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Also unify __attribute__ ((..)) to __attribute__((..)) and
handle ((__packed__)) like ((packed))
Change-Id: Ie60a51c3fa92b5009724a5b7c2932e361bf3490c
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: https://review.coreboot.org/15921
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Fix the following errors and warning detected by checkpatch.pl:
ERROR: open brace '{' following struct go on the same line
ERROR: else should follow close brace '}'
WARNING: else is not generally useful after a break or return
False positives are detected for the following checkpatch.pl error.
ERROR: that open brace { should be on the previous line
These false positives are in cbfs.c for two function definitions.
TEST=Build and run Galileo Gen2
Change-Id: Ic679ff3a2e1cfc0ed52073c20165e05bf21d76f3
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://review.coreboot.org/18750
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
|
|
UEFI 2.6 spec casts the return of FFS_FILE2_SIZE to a UINT32
which cannot be read using read_le32(&returnval). Add in a
cast in order to safeguard for any non x86 architecture that may
use this relocate. The proper change will be to get the UEFI
header files changed to not cast this return value.
Change-Id: Ie1b50d99576ac42a0413204bbd599bab9f01828e
Signed-off-by: Brandon Breitenstein <brandon.breitenstein@intel.com>
Reviewed-on: https://review.coreboot.org/16309
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
FSP 2.0 uses the same relocate logic as FSP 1.1. Thus, rename
fsp1_1_relocate to more generic fsp_component_relocate that can be
used by cbfstool to relocate either FSP 1.1 or FSP 2.0
components. Allow FSP1.1 driver to still call fsp1_1_relocate which
acts as a wrapper for fsp_component_relocate.
Change-Id: I14a6efde4d86a340663422aff5ee82175362d1b0
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/14749
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
|
