This change was promised as a follow-up in
change ID: Ic0302f663cbc931325334d0cce93d3b0bf937cc6
Signed-off-by: Martin Roth <martin@coreboot.org>
Change-Id: I9a41b46cc90684746e2b240c8ee442df1b3d7cf5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52111
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Some of the src/vendorcode/ directories are used to import a whole
codebase from somewhere else which uses a completely different coding
style. For those directories, excluding them from checkpatch makes
sense. However, other directories are simply implementing
vendor-specific extensions that were written by coreboot developers
specifically for coreboot in coreboot's coding style. Those directories
should be covered by checkpatch.
This patch narrows the existing blanket exception of src/vendorcode/ to
the amd, cavium, intel and mediatek directories (which actually include
large amounts of foreign source). The eltan, google and siemens
directories (which seem to contain code specifically written for
coreboot) will now be covered by checkpatch.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I1feaba37c469714217fff4d160e595849e0230b9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51827
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
With the current version method, it's not possible to determine if
a different version is older or newer than the current version without
digging into the repository and finding the dates for the version
numbers.
This change adds the commit date to the start of the toolchain version
which will let us tell at a glance how old or new the toolchain is.
It's not perfect because multiple toolchain commits can go in on the
same day, but adding the time made the string even longer, and really
doesn't help that much.
Signed-off-by: Martin Roth <martin@coreboot.org>
Change-Id: I9c6d27667b922dc15e7a6e132e1beff69eed839c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48901
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The tree is clean at the moment.
Change-Id: I1be3b6c2f3b54b5c10ad3d5c6f0a6fd7e490c6bc
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52066
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add SPD support for Micron DDR4 memory part MT40A1G16RC-062E-B 16Gb
BUG=b:184024142
TEST=none
Change-Id: I438310fb74d96953bc83374df3109e4c56192a5f
Signed-off-by: Kevin Chiu <kevin.chiu@quantatw.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44861
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Rob Barnes <robbarnes@google.com>
- Enable warnings
- Enable warnings as errors
- Remove debug flag -g
- Add targets for all, distclean, and help
- Add dependency of the bincfg file for output targets
- Add all phony targets to .PHONY
BUG=None
TEST=Build all targets
Signed-off-by: Martin Roth <martin@coreboot.org>
Change-Id: Ic0302f663cbc931325334d0cce93d3b0bf937cc6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50654
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The purpose of this is to eventually move the FIT table out of the
bootblock, generate it separately as a cbfs file and then have the FIT
pointer point to that cbfs file.
TESTED: extracted a FIT table using dd, added it as a cbfs file and see
that the FIT pointer correctly points to it. Also test that trying to
add a non valid FIT cbfs file results in an error.
Change-Id: I6e38b7df31e6b30f75b0ae57a5332f386e00f16b
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50925
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Don't use 'is' and 'is not' for comparison with literals. This fixes
warnings like:
.../mbn_tools.py:1097: SyntaxWarning: "is not" with a literal. Did you mean "!="?
if int(off) is not 0:
Change-Id: Idd68acfcbd1a07cbbb9ab41d9581c4850a431445
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51427
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
The CBFS stage header is part of the file data (not the header) from
CBFS's point of view, which is problematic for verification: in pre-RAM
environments, there's usually not enough scratch space in CBFS_CACHE to
load the full stage into memory, so it must be directly loaded into its
final destination. However, that destination is decided from reading the
stage header. There's no way we can verify the stage header without
loading the whole file and we can't load the file without trusting the
information in the stage header.
To solve this problem, this patch changes the CBFS stage format to move
the stage header out of the file contents and into a separate CBFS
attribute. Attributes are part of the metadata, so they have already
been verified before the file is loaded.
Since CBFS stages are generally only meant to be used by coreboot itself
and the coreboot build system builds cbfstool and all stages together in
one go, maintaining backwards-compatibility should not be necessary. An
older version of coreboot will build the old version of cbfstool and a
newer version of coreboot will build the new version of cbfstool before
using it to add stages to the final image, thus cbfstool and coreboot's
stage loader should stay in sync. This only causes problems when someone
stashes away a copy of cbfstool somewhere and later uses it to try to
extract stages from a coreboot image built from a different revision...
a debugging use-case that is hopefully rare enough that affected users
can manually deal with finding a matching version of cbfstool.
The SELF (payload) format, on the other hand, is designed to be used for
binaries outside of coreboot that may use independent build systems and
are more likely to be added with a potentially stale copy of cbfstool,
so it would be more problematic to make a similar change for SELFs. It
is not necessary for verification either, since they're usually only
used in post-RAM environments and selfload() already maps SELFs to
CBFS_CACHE before loading them to their final destination anyway (so
they can be hashed at that time).
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I8471ad7494b07599e24e82b81e507fcafbad808a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46484
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The --alignment flag is currently only handled by cbfstool add, but
there seems little reason to not handle it for all file-adding commands
(the help text actually mentions it for add-stage as well but it doesn't
currently work there). This patch moves the related code (and the
related baseaddress handling) into cbfs_add_component(). As a nice side
effect this allows us to rearrange cbfs_add_component() such that we can
conclusively determine whether we need a hash attribute before trying to
align the file, allowing that code to correctly infer the final header
size even when a hash attribute was implicitly added (for an image built
with CBFS verification enabled).
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Idc6d68b2c7f30e5d136433adb3aec5a87053f992
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47823
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The 'x' option is not set up in the getopt options.
Change-Id: Ib4aa10b0ea2a3f97e8d2439152b708613bcf43db
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50923
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
To support the new CONFIG_CBFS_VERIFICATION feature, cbfstool needs to
update the metadata hash embedded in the bootblock code every time it
adds or removes a CBFS file. This can lead to problems on certain
platforms where the bootblock needs to be specially wrapped in some
platform-specific data structure so that the platform's masked ROM can
recognize it. If that data structure contains any form of hash or
signature of the bootblock code that is checked on every boot, it will
no longer match if cbfstool modifies it after the fact.
In general, we should always try to disable these kinds of features
where possible (they're not super useful anyway). But for platforms
where the hardware simply doesn't allow that, this patch introduces the
concept of "platform fixups" to cbfstool. Whenever cbfstool finds a
metadata hash anchor in a CBFS image, it will run all built-in "fixup
probe" functions on that bootblock to check if it can recognize it as
the wrapper format for a platform known to have such an issue. If so, it
will register a corresponding fixup function that will run whenever it
tries to write back modified data to that bootblock. The function can
then modify any platform-specific headers as necessary.
As first supported platform, this patch adds a fixup for Qualcomm
platforms (specifically the header format used by sc7180), which
recalculates the bootblock body hash originally added by
util/qualcomm/createxbl.py.
(Note that this feature is not intended to support platform-specific
signature schemes like BootGuard directly in cbfstool. For anything that
requires an actual secret key, it should be okay if the user needs to
run a platform-specific signing tool on the final CBFS image before
flashing. This feature is intended for the normal unsigned case (which
on some platforms may be implemented as signing with a well-known key)
so that on a board that is not "locked down" in any way the normal use
case of manipulating an image with cbfstool and then directly flashing
the output file stays working with CONFIG_CBFS_VERIFICATION.)
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I02a83a40f1d0009e6f9561ae5d2d9f37a510549a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41122
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch adds support for the new CONFIG_CBFS_VERIFICATION feature to
cbfstool. When CBFS verification is enabled, cbfstool must automatically
add a hash attribute to every CBFS file it adds (with a handful of
exceptions like bootblock and "header" pseudofiles that are never read
by coreboot code itself). It must also automatically update the metadata
hash that is embedded in the bootblock code. It will automatically find
the metadata hash by scanning the bootblock for its magic number and use
its presence to auto-detect whether CBFS verification is enabled for an
image (and which hash algorithm to use).
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I61a84add8654f60c683ef213b844a11b145a5cb7
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41121
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The `q35-alpine.cfg` adds a lot of PCIe devices to resemble the
topology inside an Intel Alpine Ridge Thunderbolt controller.
By no means could this be detected as such a controller. But
having a real-world example of such a topology can help to
test the allocator and other algorithms on a deeper tree.
It adds two levels of PCIe switches (`alpine-root` and
`alpine-1`), and two endpoints (a `pci-testdev` and an xHCI
controller).
It can be added to the default `q35-base.cfg` config, e.g.
with:
$ make qemu QEMU_EXTRA_CFGS=util/qemu/q35-alpine.cfg
Change-Id: Ieab09c5b67a5aafa986e7d68a6c1a974530408b0
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51329
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add memory part MT53E2G32D4NQ-046 to LP4x global list. Attributes
are derived from data sheets.Also, regenerate the SPD files for ADL
SoC using the newly added parts.
BUG=b:181378727
TEST=Compared generated SPD with data sheets and checked in SPD
Change-Id: Ic06e9d672a2d3db2b4ea12d15b462843c90db8f6
Signed-off-by: Amanda Huang <amanda_hwang@compal.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51167
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: EricR Lai <ericr_lai@compal.corp-partner.google.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
This adds the definitions for MT53E1G32D4NQ-046 WT:E used on Majolica,
and the NT6AP256T32AV-J1 part used on Guybrush.
BUG=b:178715165
TEST=Generate SPDs
Signed-off-by: Martin Roth <martin@coreboot.org>
Change-Id: I7cd729fc72d8f44a449429e97683b2ca1f560f2c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51057
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: EricR Lai <ericr_lai@compal.corp-partner.google.com>
If a previous build failed or the build dir is still around for other
reasons (e.g. buildgcc's `-t`) the symbolic link to our `bin` dir we
create there is also still around and can't be created again without
removing it first. Attempts to use `ln -f` also fail as the existing
destination is treated as directory and a new symbolic link would be
created inside.
Change-Id: I7a2720b0286e33d1ba26ea01f323dbf4f8afaea0
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48776
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
This reverts commit 15e379aaf3.
It triggers on directories that only contain artifacts and no
checked in code. As this happens a lot when switching branches,
it makes it impossible to commit new code.
Change-Id: I38a86c8a5d5dc14ca5f6cba789bcb8c0fcaefb0b
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50354
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
This just reformats these files. go fmt should probably be
run on the check-in of every .go file.
Signed-off-by: Martin Roth <martin@coreboot.org>
Change-Id: I70ced115bad42d123474b18bbff2e4c0a16f3d88
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51019
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: EricR Lai <ericr_lai@compal.corp-partner.google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
To supply memory information for Guybrush, the lpddr4x script for
generating SPDs needs to be updated for Cezanne.
BUG=b:178722935
TEST=Add the part used on Majolica to the global lpddr4x json file
and verify that the output is similar to the actual SPD used for
Majolica.
Signed-off-by: Martin Roth <martin@coreboot.org>
Change-Id: I1f522cb4a92b4fe4c26cad0689437c33ec44befe
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51015
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The codebase currently has only unix line endings, so add a lint tool
to check for windows line endings.
BUG=None
TEST=Verify that line endings are caught both inside and outside a git
repo.
Signed-off-by: Martin Roth <martin@coreboot.org>
Change-Id: I6faf99a3184e4843640fb8965f8124de0bc52ce7
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50851
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
- Add a help target
- Add the -Wshadow and -Werror options
- Add a way to disable -Werror
Signed-off-by: Martin Roth <martin@coreboot.org>
Change-Id: I0d9fe5beb3a2e103a0bf4603712c3a5ed15f93be
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50850
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
- Add a help target
- Add the -Wshadow option
- Add a way to disable -Werror
Signed-off-by: Martin Roth <martin@coreboot.org>
Change-Id: Icd4e5cf51d60254d274c6e5093285cd49ff1607a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50849
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
This fixes the following 2 complaints:
bucts.c: In function ‘main’:
error: unused parameter ‘envp’
error: ‘bucts_state’ may be used uninitialized in this function.
The bucts_state wasn't real, but the compiler couldn't tell, so use
one variable to check for modifications instead of two.
Signed-off-by: Martin Roth <martin@coreboot.org>
Change-Id: Iff1aae3441ec366d272e88b6b6634980d61cb8ea
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50846
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Now that multiple device trees are supported (chipset, base,
override), base_chip_instance parameter for override device needs to
be set to the base chip instance of the corresponding device in
base/primary tree. This can be achieved by using `get_chip_instance()`
instead of using base_dev->chip_instance in `update_device()`.
TEST=Verified that coreboot.rom generated using timeless shows no
change for all boards.
Change-Id: I42e3f4b83c55f3479b95dbbd7a3721558c32b1c8
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50868
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
cbfstool has always had a CBFS_FILENAME_ALIGN that forces the filename
field to be aligned upwards to the next 16-byte boundary. This was
presumably done to align the file contents (which used to come
immediately after the filename field).
However, this hasn't really worked right ever since we introduced CBFS
attributes. Attributes come between the filename and the contents, so
what this code currently does is fill up the filename field with extra
NUL-bytes to the boundary, and then just put the attributes behind it
with whatever size they may be. The file contents don't end up with any
alignment guarantee and the filename field is just wasting space.
This patch removes the old FILENAME_ALIGN, and instead adds a new
alignment of 4 for the attributes. 4 seems like a reasonable alignment
to enforce since all existing attributes (with the exception of weird
edge cases with the padding attribute) already use sizes divisible by 4
anyway, and the common attribute header fields have a natural alignment
of 4. This means file contents will also have a minimum alignment
guarantee of 4 -- files requiring a larger guarantee can still be added
with the --alignment flag as usual.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I43f3906977094df87fdc283221d8971a6df01b53
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47827
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
In a rare placement edge case when adding a file with alignment
requirements, cbfstool may need to generate a CBFS header that's
slightly larger than it needs to be. The way we do this is by just
increasing the data offset field in the CBFS header until the data falls
to the desired value.
This approach works but it may confuse parsing code in the presence of
CBFS attributes. Normally, the whole area between the attribute offset
and the data offset is filled with valid attributes written back to
back, but when this header expansion occurs the attributes are followed
by some garbage data (usually 0xff). Parsers are resilient against this
but may show unexpected error messages.
This patch solves the problem by moving the attribute offset forwards
together with the data offset, so that the total area used for
attributes doesn't change. Instead, the filename field becomes the
expanded area, which is a closer match to how this worked when it was
originally implemented (before attributes existed) and is less confusing
for parsers since filenames are zero-terminated anyway.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I3dd503dd5c9e6c4be437f694a7f8993a57168c2b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47824
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The *location argument to parse_elf_to_stage() is a relic from code all
the way back to 2009 where this function was still used to parse XIP
stages. Nowadays we have a separate parse_elf_to_xip_stage() for that,
so there is no need to heed XIP concerns here. Having a pointer to
represent the location in flash is absolutely irrelevant to a non-XIP
stage, and it is used incorrectly -- we just get lucky that no code path
in cbfstool can currently lead to that value being anything other than
0, otherwise the adjustment of data_start to be no lower than *location
could easily screw things up. This patch removes it.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Ia7f850c0edd7536ed3bef643efaae7271599313d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49369
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Memlayout is a mechanism to define memory areas outside the normal
program segment constructed by the linker. Therefore, it generally
doesn't make sense to relocate memlayout symbols when the program is
relocated. They tend to refer to things that are always in one specific
spot, independent of where the program is loaded.
This hasn't really hurt us in the past because the use case we have for
rmodules (ramstage on x86) just happens to not really need to refer to
any memlayout-defined areas at the moment. But that use case may come up
in the future so it's still worth fixing.
This patch declares all memlayout-defined symbols as ABSOLUTE() in the
linker, which is then reflected in the symbol table of the generated
ELF. We can then use that distinction to have rmodtool skip them when
generating the relocation table for an rmodule. (Also rearrange rmodtool
a little to make the primary string table more easily accessible to the
rest of the code, so we can refer to symbol names in debug output.)
A similar problem can come up with userspace unit tests, but we cannot
modify the userspace relocation toolchain (and for unfortunate
historical reasons, it tries to relocate even absolute symbols). We'll
just disable PIC and make those binaries fully static to avoid that
issue.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Ic51d9add3dc463495282b365c1b6d4a9bf11dbf2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50629
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
To build a CrOS-style zephyr, we need a couple of u-boot tools, so add
them here instead of rebuilding them on every zephyr build (which is
also harder to get right because search paths are no strength of python)
Change-Id: Ib95fcb644ac87c5f35f2228fe081c922452b5213
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50744
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
This fixes the following issues:
bincfg.l: In function ‘parsehex’:
error: declaration of ‘val’ shadows a global declaration
bincfg.y: In function ‘generate_binary_with_gbe_checksum’:
error: comparison of integer expressions of different signedness
bincfg.y: In function ‘yyerror’:
bincfg.y:408:28: error: unused parameter ‘fp’
bincfg.y: In function ‘main’:
bincfg.y:452:15: error: unused variable ‘pos’
bincfg.y:451:16: error: unused variable ‘c’
BUG=None
TEST=Build outputs and make sure they're identical.
Signed-off-by: Martin Roth <martin@coreboot.org>
Change-Id: I60039b741c226a6b6ba53306f6fa293da89e5355
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50653
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Gets rid of these 4 warnings:
archive.c: In function ‘set_file_name’:
warning: comparison of integer expressions of different signedness
archive.c: In function ‘add_file’:
warning: comparison of integer expressions of different signedness
archive.c: In function ‘archive_files’:
warning: comparison of integer expressions of different signedness
archive.c: In function ‘convert_endian’:
warning: comparison of integer expressions of different signedness
BUG=None
TEST=Build and run
Signed-off-by: Martin Roth <martin@coreboot.org>
Change-Id: I57ee8b31bbc9e97168e3b818c4d053eadf8a4f84
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50651
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
- Add method to disable warnings as errors
- Add help target
- Add phony targets to .PHONY
BUG=None
TEST=make all; make help; make all WERROR=""
Signed-off-by: Martin Roth <martin@coreboot.org>
Change-Id: Icd0cfd3e2579c9016ebb616e371d1076a5a171b4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50650
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Fixes these warnings:
warning: alignment 1 of 'struct _psp_directory_table' is less
than 16 [-Wpacked-not-aligned]
warning: alignment 1 of 'struct _psp_combo_directory' is less
than 16 [-Wpacked-not-aligned]
In function 'find_register_fw_filename_bios_dir':
warning: implicit conversion from 'enum _amd_fw_type' to
'amd_bios_type' {aka 'enum _amd_bios_type'} [-Wenum-conversion]
BUG=None
TEST=Build and verify binaries are identical.
Signed-off-by: Martin Roth <martin@coreboot.org>
Change-Id: I761d9893ac6737b42af96c4b2a57c5a4fc61ab05
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50643
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Fix regression from commit 0dcc0662f3 util/cbfstool: Introduce
concept of mmap_window.
Use of region_end() wraps around at 4 GiB, if utility is run in
32bit userspace. The build completes with an invalid coreboot.rom,
while one can find error message in stdout or make.log:
E: Host address(ffc002e4) not in any mmap window!
Change-Id: Ib9b6b60c7b5031122901aabad7b3aa8d59f1bc68
Signed-off-by: Furquan Shaikh <furquan@google.com>
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50618
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
This reverts commit 3ac3c4ebac ("abuild: Allow disabling mainboards").
This mechanism helped getting Chrome OS' coreboot divergence sorted
out in the 2015/2016 timeframe but hasn't been used by anybody since
then. Let's not encourage people to push non-working builds without
good reason and discussion (the result of which could be that we
re-introduce this mechanism).
Change-Id: I8e2f2e1a5d4617baa49cbcb1a640a1ea270007ef
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50518
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Datasheet is not publicly available. Derive which registers to dump from
IT8625E, since there are mainboards that can use either chip depending
on BOM configuration. Default values are taken from an HP 280 G2 running
a coreboot build that does not configure the Super I/O.
Change-Id: Icc8c56e9cd19e940e85176ac51b8ef978275eb71
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50457
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Sometimes boards enable it by default, making the Kconfig option
impossible to disable without messing with the Kconfig files. This
shouldn't happen, so report on such occurrences early.
TEST=Tried building GOOGLE_KOHAKU through abuild with -x, without
-x and both cases after having added a "select CHROMEOS" for testing
and it failed in the "without -x with select" scenario while properly
configuring and passing all other builds.
Change-Id: Ieb6bcbf3e9ca8cd4ced85c7c9ffaa39505f5a9b7
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50494
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
* Add comments to mem_parts_used.txt to point out that the order of
the entries matters when assigning IDs, so always add a new part
to the end of the file.
* Update existing mem_parts_used.txt to add the same comment.
* No updates to Zork variants, because they use an optional ID, so
the order actually doesn't matter there.
BUG=b:175898902
TEST=create a new variant of dalboz, trembyle, volteer, waddledee,
or waddledoo, and observe that mem_parts_used.txt has the new
verbiage.
Signed-off-by: Paul Fagerburg <pfagerburg@google.com>
Change-Id: Iffbd8e69a89b1b7c810c5d25c7a6148d459d8b02
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50449
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Rob Barnes <robbarnes@google.com>
It's not obvious how to set specific byte of a multi-byte field in the
set file. Add an example (and a template) for setting MAC address.
Change-Id: Iea983071682ffebd61757497d43c70cc8214043d
Signed-off-by: Evgeny Zinoviev <me@ch1p.io>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39664
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Swift Geek (Sebastian Grzywna) <swiftgeek@gmail.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Jacob Garber <jgarber1@ualberta.ca>
Martin Roth