Age | Commit message (Collapse) | Author |
|
Change-Id: I252a1cd77bf647477edb7dddadb7e527de872439
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/29582
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
|
|
Change-Id: I6c77f4289b46646872731ef9c20dc115f0cf876d
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/29161
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
In romstage malloc is not available, so use CAR_GLOBAL
variable instead.
BUG=b:78106689
TEST=Boot to OS
Change-Id: If9438d0b707c6ffaa61db80bd1d385112bc91cfc
Signed-off-by: Bora Guvendik <bora.guvendik@intel.com>
Reviewed-on: https://review.coreboot.org/25067
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
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>
|
|
Add a __always_inline macro that wraps __attribute__((always_inline))
and replace current users with the macro, excluding files under
src/vendorcode.
Change-Id: Ic57e474c1d2ca7cc0405ac677869f78a28d3e529
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/28587
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@google.com>
|
|
Since we can derive chromeos_acpi's location from that of
ACPI GNVS, remove chromeos_acpi entry from cbtable and
instead use acpi_gnvs + GVNS_CHROMEOS_ACPI_OFFSET.
BUG=b:112288216
TEST=None
CQ-DEPEND=CL:1179725
Change-Id: I74d8a9965a0ed7874ff03884e7a921fd725eace9
Signed-off-by: Joel Kitching <kitching@google.com>
Reviewed-on: https://review.coreboot.org/28190
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Since we can retrieve the address of ACPI GNVS directly
from CBMEM_ID_ACPI_GNVS, there is no need to store and
update a pointer separately.
TEST=Compile and run on Eve
Signed-off-by: Joel Kitching <kitching@google.com>
Change-Id: I59f3d0547a4a724e66617c791ad82c9f504cadea
Reviewed-on: https://review.coreboot.org/28189
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Change-Id: If7650ac4d9be2614a9665c7f2aba9ac5cc413efe
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/28097
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
There is a confusingly named section in cbmem called vdat.
This section holds a data structure called chromeos_acpi_t,
which exposes some system information to the Chrome OS
userland utility crossystem.
Within the chromeos_acpi_t structure, there is a member
called vdat. This (currently) holds a VbSharedDataHeader.
Rename the outer vdat to chromeos_acpi to make its purpose
clear, and prevent the bizarreness of being able to access
vdat->vdat.
Additionally, disallow external references to the
chromeos_acpi data structure in gnvs.c.
BUG=b:112288216
TEST=emerge-eve coreboot, run on eve
CQ-DEPEND=CL:1164722
Change-Id: Ia74e58cde21678f24b0bb6c1ca15048677116b2e
Signed-off-by: Joel Kitching <kitching@google.com>
Reviewed-on: https://review.coreboot.org/27888
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
* Make tcpa_log_init static and move init code into
the tcpa_log_add_table_entry routine.
* Add more checks for log initialization.
* Fix minor issues
Change-Id: I215d79eed7ad17c6ab87f0c4b14a282e519ef07d
Signed-off-by: Philipp Deppenwiese <zaolin@das-labor.org>
Reviewed-on: https://review.coreboot.org/27769
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Fix regression introduced in commit f18dc5c7
"Add TCPA logging functionality":
Introduced TCPA log got overwritten in acpi.c of x86/arch, due to
CBMEM name collision. Use a different cbmem name to have two independent
TCPA logs.
Change-Id: Iac63ac26989080a401aac2273265a263a3fdec56
Signed-off-by: Philipp Deppenwiese <zaolin@das-labor.org>
Reviewed-on: https://review.coreboot.org/27726
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
|
|
* Read and print the TCPA ACPI log.
Change-Id: Ie2253d86cfc675d45b0a728794cc784215401f4a
Signed-off-by: Philipp Deppenwiese <zaolin@das-labor.org>
Reviewed-on: https://review.coreboot.org/26244
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
|
|
* TCG spec only applies to BIOS or UEFI.
* Therefore implement coreboot TCPA compliant log
in CBMEM.
* Write CBMEM log into the coreboot table for CBMEM tool access
Change-Id: I0a52494f647d21e2587231af26ed13d62b3a72f5
Signed-off-by: Philipp Deppenwiese <zaolin@das-labor.org>
Reviewed-on: https://review.coreboot.org/22867
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
|
|
Change-Id: I8e4118c5c5d70719ad7dc5f9ff9f86d93fa498ac
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/26942
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
|
|
change sd_mmc_go_idle to be accessible from other files
so that we have an api to send CMD0 and reset the card.
BUG=b:78106689
TEST=Boot to OS
Change-Id: I064a9bded347be5d500047df92d1c448c3392016
Signed-off-by: Bora Guvendik <bora.guvendik@intel.com>
Reviewed-on: https://review.coreboot.org/25066
Reviewed-by: Justin TerAvest <teravest@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
In order to support booting a GNU/Linux payload on non x86, the FIT format
should be used, as it is the defacto standard on ARM.
Due to greater complexity of FIT it is not converted to simple ELF format.
Add support for autodecting FIT payloads and add them as new CBFS_TYPE 'fit'.
The payload is included as is, with no special header.
The code can determine the type at runtime using the CBFS_TYPE field.
Support for parsing FIT payloads in coreboot is added in a follow on
commit.
Compression of FIT payloads is not supported, as the FIT sections might be
compressed itself.
Starting at this point a CBFS payload/ can be either of type FIT or SELF.
Tested on Cavium SoC.
Change-Id: Ic5fc30cd5419eb76c4eb50cca3449caea60270de
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/25860
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
Non of the .c files is using a function from console.h directly.
Include console.h is moved to sd_mmc.h, where sdhc_error("msg..") is
defined.
Change-Id: Ic9283f227a37785056b9fac216fabcac054066a0
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/26752
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Masked ROMs are the silent killers of boot speed on devices without
memory-mapped SPI flash. They often contain awfully slow SPI drivers
(presumably bit-banged) that take hundreds of milliseconds to load our
bootblock, and every extra kilobyte of bootblock size has a hugely
disproportionate impact on boot speed. The coreboot timestamps can never
show that component, but it impacts our users all the same.
This patch tries to alleviate that issue a bit by allowing us to
compress the bootblock with LZ4, which can cut its size down to nearly
half. Of course, masked ROMs usually don't come with decompression
algorithms built in, so we need to introduce a little decompression stub
that can decompress the rest of the bootblock. This is done by creating
a new "decompressor" stage which runs before the bootblock, but includes
the compressed bootblock code in its data section. It needs to be as
small as possible to get a real benefit from this approach, which means
no device drivers, no console output, no exception handling, etc.
Besides the decompression algorithm itself we only include the timer
driver so that we can measure the boot speed impact of decompression. On
ARM and ARM64 systems, we also need to give SoC code a chance to
initialize the MMU, since running decompression without MMU is
prohibitively slow on these architectures.
This feature is implemented for ARM and ARM64 architectures for now,
although most of it is architecture-independent and it should be
relatively simple to port to other platforms where a masked ROM loads
the bootblock into SRAM. It is also supposed to be a clean starting
point from which later optimizations can hopefully cut down the
decompression stub size (currently ~4K on RK3399) a bit more.
NOTE: Bootblock compression is not for everyone. Possible side effects
include trying to run LZ4 on CPUs that come out of reset extremely
underclocked or enabling this too early in SoC bring-up and getting
frustrated trying to find issues in an undebuggable environment. Ask
your SoC vendor if bootblock compression is right for you.
Change-Id: I0dc1cad9ae7508892e477739e743cd1afb5945e8
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/26340
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Make cbfsf_file_type public to support detecting the payload type at
runtime. To be used by the following commits.
Possible payload types are:
* simple ELF
* FIT
Change-Id: I37e9fb06f926dc71b001722a6c3b6205a2f20462
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/25859
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
In some cases callers want to know if a file
exists and, if so, what its type is.
Modify cbfs_locate so that if the pointer is non-NULL,
but has the value 0, the type of the file that
matches the name will be returned.
Change-Id: Ic1349d358c3054207ccbccf3825db56784327ad0
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: https://review.coreboot.org/26279
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
On grunt these operations combined take a little over 37ms.
BUG=b:64549506
TEST=built on grunt
511:starting TPM PCR extend 301,268 (598)
512:finished TPM PCR extend 326,710 (25,442)
513:starting locking TPM 326,716 (6)
514:finished locking TPM 339,517 (12,801)
Change-Id: I05cfb3d0f8463f073e329a035484a340546649e1
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Reviewed-on: https://review.coreboot.org/26218
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
In preparation of having FIT payloads, which aren't converted to simple ELF,
rename the CBFS type payload to actually show the format the payload is
encoded in.
Another type CBFS_TYPE_FIT will be added to have two different payload
formats. For now this is only a cosmetic change.
Change-Id: I39ee590d063b3e90f6153fe655aa50e58d45e8b0
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/25986
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
When the latest AGESA timestamp values were added, the descriptions
weren't added along with them. Because of this, the cbmem tool just
shows them as "<unknown>".
Bug=b:79153552
TEST=None
Change-Id: Iad7bcd53bc6136b74d4d933d1a290feac6a0de56
Signed-off-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://review.coreboot.org/26001
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Instead of writing out '__attribute__((weak))' use a shorter form.
Change-Id: If418a1d55052780077febd2d8f2089021f414b91
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/25767
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Justin TerAvest <teravest@chromium.org>
|
|
Add timestamps before and after the vBIOS load and after the vBIOS
run. This lets us see exactly how long it took to load it from the
ROM chip, and how long it takes to run.
BUG=b:64549506
TEST=Build & boot Grunt, see vBIOS load & initialization times.
Change-Id: I878ba653eb086ad6c6614aa08a6d3fe216a9323e
Signed-off-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://review.coreboot.org/25018
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Leverage the stage_cache mechanism to store a non-specific type
of data. This is not interesting when the location for the cache
is in cbmem. However it will be more useful when an external
location is used, e.g. when the cache is in TSEG, locked from user
modification.
Change-Id: Iaf0b25ebe14c176bbd24fc8942f902f627ca8e6f
Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-on: https://review.coreboot.org/23518
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
This patch stores the correct capabilities for EMMC media which in turn
sets the correct timing data for HS400 mode.
Without this code change, EMMC CMD13 is failing at the end of HS400 mode
switching.
BUG=none
BRANCH=none
TEST=Build and boot Soraka
Change-Id: I3f00c9eace7cc136d86a1e07f040fbfc09e0e02e
Signed-off-by: Barnali Sarkar <barnali.sarkar@intel.com>
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/23541
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
A discussion around the `bytes_per_line` field (it was ignored in
CorebootPayloadPkg for some reason) made the lack of documentation
obvious.
Change-Id: I5e1343b5fe37ac106e61e6907fbcc1737ac56f8b
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/23466
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
|
|
Extend the values reserved for AGESA to include the Entry Points used
for S3 Resume.
BUG=b:69614064
Change-Id: I6b50e76a0c49c1f317f9294c5f95735e7aa5d95c
Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-on: https://review.coreboot.org/23439
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Write _ROM method and store PCI Option ROM in CBMEM.
Allows an EFI compatible OS to retrieve the Option ROM without the need
to access the PCI BAR. As the Option ROM is no longer present in the
legacy VGA area it's required for mobile platforms. On hybrid devices,
like Lenovo Thinkpads supporting NVIDIA Optimus it's the only way to
retrieve the Option ROM, even with legacy BIOS, as there's no PCI BAR to
map.
Tested on:
* Lenovo T530
* Linux Kernel 4.13.7
* nouveau
Change-Id: I548b730fb64833083cc05af5b21dd6959804224b
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/20548
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Export region_is_subregion() for determinig if a region is a child of
a parent region.
BUG=b:69614064
Change-Id: I6363fe4fdb33342f9d025a726ec7e17e87adf7e0
Signed-off-by: Aaron Durbn <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/22878
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
BUG=b:70432544
TEST=Build & boot kahlee. Look at timestamps.
Change-Id: I3bf691a0fb1f5c09e7b6c9965c9e506393ec31f6
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/22797
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
On many recent Chrome OS boards, the desire to unite more configurations
under the same image has led to the need of a "SKU ID" that identifies
different configurations of the same board (e.g. with certain optional
components stuffed or not stuffed, or replaced with a comparable
component). This is markedly different from the existing "board ID",
because that is reserved to count "revisions" -- changes made to the
same configuration over time during the development process. This patch
adds support to have a mainboard define this SKU ID and pass it through
the coreboot table like we already have for board IDs.
Change-Id: I8aabffe8e1003b0d6fb70d689ae513ca4b46aeda
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/22696
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Merge the different coreboot table strapping ID structures into one
because they're really just all the same, and I want to add more. Make
the signature of the board_id() function return a uint32_t because
that's also what goes in the coreboot table. Add a printk to the generic
code handling strapping IDs in ramstage so that not every individual
mainboard implementation needs its own print. (In turn, remove one such
print from fsp1_1 code because it's in the way of my next patch.)
Change-Id: Ib9563edf07b623a586a4dc168fe357564c5e68b5
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/22741
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
The code dealing with the old config string isn't needed anymore,
because the config string has been deprecated in favor of
OpenFirmware-derived devicetrees.
Change-Id: I71398fb4861dbaf7eefc6e6f222bb7159798fafa
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/22594
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
The definition of offsetof() uses size_t, which is declared in stddef.h,
according to POSIX. Include stddef.h directly to avoid relying on
implicit inclusion.
Change-Id: I221be02c332de55c9fcf7d86673709ed43dd5c3c
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/22230
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Maximilian Schander <coreboot@mimoja.de>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
When building the Go version of cbmem I found that
LB_TAG_MAC_ADDRS has the same value as LB_TAG_VERSION_TIMESTAMP.
I am guessing that this tag was little used. In any event, move it
forward to 0x33.
Change-Id: I038ad68e787e56903a2ed9cb530809a55821c313
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: https://review.coreboot.org/22218
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
In commit c06a3f72 (arch/x86: initialize EBDA in S3 and S0/S5 path)
the BDA and EBDA are wiped in the resume path. However, the coreboot
table forwarding entry wasn't taken into account so that was wiped
which resulted in cbmem not working on the resume path. Fix this
by stashing the forwarding table in cbmem and restoring it on
the resume path.
Change-Id: I142503535a78635fbb1c698fc7d032c1a2921813
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/22078
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
Make the spelling of *romstage* consistent without a space. Choose this
version, as *ramstage* is also spelled without a space, since commit
a7d924412a (timestamps: You can never have enough of them!).
Fixes: 0db924d74c (cbmem: print timestamp names)
Change-Id: I1b1c10393f0afb9a20ac916ff9dc140a51c716cd
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: https://review.coreboot.org/21706
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
Add a timestamp before and after waiting for the ME to acknowledge the
DRAM being ready.
This allows easier debugging during use of me_cleaner and/or alternate
ME images.
Change-Id: Ie228e12a75d373b4f406b3595e1fb1aab41aa5df
Signed-off-by: Nathaniel Roach <nroach44@gmail.com>
Reviewed-on: https://review.coreboot.org/21465
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
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>
|
|
The architecture is determined by __riscv__ in the LZ4_copy8 function
(located in src / commonlib / lz4_wrapper.c). __riscv exists in gcc7.1.1.
But __riscv__ does not exist.
Change-Id: I38fd41da9afd76c254f0c3d6984579c3790e5792
Signed-off-by: XiangWang <wxjstz@126.com>
Reviewed-on: https://review.coreboot.org/20125
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Andrew Waterman <aswaterman@gmail.com>
Reviewed-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
|
|
Fix CID 1376472 detected by coverity. Zero extend the capacity instead
of sign extending it.
TEST=Build and run on reef
Change-Id: I6aac422fb1dacb75e0cc44a94ff1f467ce9f529e
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://review.coreboot.org/20392
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
|
|
Change memcpy()s and memset()s to endian.h wrappers for consistency
and safety. Add zero_n() wrapper to safely clear memory.
Change-Id: If155d82608c81992f05eae4d2223de6f506e98c5
Signed-off-by: Ryan Salsamendi <rsalsamendi@hotmail.com>
Reviewed-on: https://review.coreboot.org/20240
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Add missing includes to build mmc.c.
TEST=Build and run on Galileo Gen2
Change-Id: I0dea597272e5ece97843704a159aa546a8d77ff0
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://review.coreboot.org/20271
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Move drivers/storage into commonlib/storage to enable access by
libpayload and indirectly by payloads.
* Remove SD/MMC specific include files from include/device
* Remove files from drivers/storage
* Add SD/MMC specific include files to commonlib/include
* Add files to commonlib/storage
* Fix header file references
* Add subdir entry in commonlib/Makefile.inc to build the SD/MMC driver
* Add Kconfig source for commonlib/storage
* Rename *DEVICE* to *COMMONLIB*
* Rename *DRIVERS_STORAGE* to *COMMONLIB_STORAGE*
TEST=Build and run on Galileo Gen2
Change-Id: I4339e4378491db9a0da1f2dc34e1906a5ba31ad6
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://review.coreboot.org/19672
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
TEST=Build and run on Reef
Change-Id: I2f04a01e5e266422e3ef0d90541dc9d39471260c
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://review.coreboot.org/19301
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Add a Kconfig value to indicate coreboot builds.
Add prototypes and definitions for:
* dma_coherent
* dma_malloc
* xmalloc
* xzmalloc
Move prototype for memset into stdlib.h from string.h to eliminate build
breaks.
TEST=Build and test on Galileo Gen2
Change-Id: Ib2eb2ca143b0538bdd1863e628af4c1948bc0f8c
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/19207
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
member_size macro provides the size of a structure member.
Change-Id: I53e9c9bf70b3ebed0d15e8258111b17e50667a74
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/19384
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
Introduce ibuf and obuf structures for helping manage memory buffers.
The ibuf, an input buffer, can be read from and the obuf, an output
buffer, can be written to. Helper functions are provided for serializing
values in different endian formats. This library is provided to for
common buffer management routines such that the same code doesn't
have to re-written in different and less consistent forms.
BUG=b:36598499
Change-Id: I5247237f68b658906ec6916bbbb286d57d6df5ee
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/19062
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com>
|