CBMEM can contain log in different forms (at most one is present):
- coreboot-specific format (CBMEM_ID_TPM_CB_LOG exported as
LB_TAG_TPM_CB_LOG)
- TPM1.2 format (CBMEM_ID_TCPA_TCG_LOG)
- TPM2 format (CBMEM_ID_TPM2_TCG_LOG)
The last two follow specifications by Trusted Computing Group, but until
now cbmem couldn't print them. These formats were added not so long ago
in:
- commit 4191dbf0c9 ("security/tpm: add TPM log format as per 1.2
spec")
- commit 53db677586 ("security/tpm: add TPM log format as per 2.0
spec")
These changes make cbmem utility check for existence of TPM1.2/TPM2 logs
in CBMEM and add code necessary for parsing and printing of their
entries.
TEST=`cbmem -L` for CONFIG_TPM1=y case
TCPA log:
Specification: 1.21
Platform class: PC Client
TCPA log entry 1:
PCR: 2
Event type: Action
Digest: 5622416ea417186aa1ac32b32c527ac09009fb5e
Event data: FMAP: FMAP
TEST=`cbmem -L` for CONFIG_TPM2=y case
TPM2 log:
Specification: 2.00
Platform class: PC Client
TPM2 log entry 1:
PCR: 2
Event type: Action
Digests:
SHA256: 68d27f08cb261463a6d004524333ac5db1a3c2166721785a6061327b6538657c
Event data: FMAP: FMAP
Change-Id: Ib76dc7dec56dd1789a219539a1ac05a958f47a5c
Ticket: https://ticket.coreboot.org/issues/425
Signed-off-by: Krystian Hebel <krystian.hebel@3mdeb.com>
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68749
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Description of POST_EXIT_PCI_SCAN_BUS indicates the opposite of what
its name suggests. Secondly, POST_ENTER_PCI_SCAN_BUS and
POST_EXIT_PCI_SCAN_BUS have identical comments, which appears to be
a copy-paste issue.
Change the description accordingly.
Change-Id: Ifc920651255bacf033cac39f0208d817f9ee84fc
Signed-off-by: lilacious <yuchenhe126@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76047
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The prefix POSTCODE makes it clear that the macro is a post code.
Hence, replace related macros starting with POST to POSTCODE and
also replace every instance the macros are invoked with the new
name.
The files was changed by running the following bash script from the
top level directory.
sed -i'' '30,${s/#define POST/#define POSTCODE/g;}' \
src/commonlib/include/commonlib/console/post_codes.h;
myArray=`grep -e "^#define POSTCODE_" \
src/commonlib/include/commonlib/console/post_codes.h | \
grep -v "POST_CODES_H" | tr '\t' ' ' | cut -d ' ' -f 2`;
for str in ${myArray[@]}; do
splitstr=`echo $str | cut -d '_' -f2-`
grep -r POST_$splitstr src | \
cut -d ':' -f 1 | xargs sed -i'' -e "s/POST_$splitstr/$str/g";
grep -r "POST_$splitstr" util/cbfstool | \
cut -d ':' -f 1 | xargs sed -i'' -e "s/POST_$splitstr/$str/g";
done
Change-Id: I25db79fa15f032c08678f66d86c10c928b7de9b8
Signed-off-by: lilacious <yuchenhe126@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76043
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
This patch introduces CBMEM ID to store the MRC version (similar to
existing implementation that stores the FSP-M version inside CBMEM ID)
inside cbmem so the version information is available across the
different coreboot stages. For example:
* romstage: Use the CBMEM ID version information to check if the MRC
cache is valid and need to erase the MRC cache
* ramstage: Use the CBMEM ID to store the MRC cache into the
non-volatile space.
BUG=b:261689642
TEST=Able to build and boot google/rex and dump the MRC version as
below.
cbmem --list
CBMEM table of contents:
NAME ID START LENGTH
...
21. MRC VERSION 5f43524d 75ffeb60 00000004
...
localhost ~ # cbmem -r 5f43524d | hexdump
00000000 01 12 07 00
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I91f735239b33c6f8ba41c076048903e4b213c6a2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75921
Reviewed-by: Ronak Kanabar <ronak.kanabar@intel.com>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Intel Meteor Lake SOC has a separate I/O Expander (IOE) die.
SRAM from this IOE die contains crashlog records for the IPs
of the IOE die.
This patch adds functions with empty implementation using
__weak attribute for IOE die related crashlog, changes common
data structures while maintaining backwards compatibility,
and support for filling IOE crashlog records, guarded by
SOC_INTEL_IOE_DIE_SUPPORT config and makes cl_get_pmc_sram_data
function as weak because it needs SOC specific implementation.
Bug=b:262501347
TEST=Able to build. With Meteor Lake SOC related patch, able to
capture and decode crashlog
Change-Id: Id90cf0095258c4f7003e4c5f2564bb763e687b75
Signed-off-by: Pratikkumar Prajapati <pratikkumar.v.prajapati@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75475
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The patch implements an API that stores the CSE firmware version in the
CBMEM table. The API will be called from RAMSTAGE based on boot state
machine BS_PRE_DEVICE/BS_ON_EXIT
Additionally, renamed ramstage_cse_fw_sync() to ramstage_cse_misc_ops()
in order to add more CSE related operations at ramstage.
This patch also adds a configuration option,
'SOC_INTEL_STORE_CSE_FPT_PARTITION_VERSION', which enables the storage
of firmware version information in CBMEM memory. This information can be
used to identify the firmware version that is currently installed on the
system. The option depends on the `DRIVERS_INTEL_ISH` config and
platform should be flexible enough to opt out from enabling this
feature.
The cost of sending HECI command to read the CSE FPT is significant
(~200ms) hence, the idea is to read the CSE RW version on every cold
reset (to cover the CSE update scenarios) and store into CBMEM to
avoid the cost of resending the HECI command in all consecutive warm
boots.
Later boot stages can just read the CBMEM ID to retrieve the ISH
version if required.
Finally, ensure this feature is platform specific hence, getting
enabled for the platform that would like to store the ISH version into
the CBMEM and parse to perform some additional work.
BUG=b:273661726
TEST=Able to build and boot google/marasov.
Signed-off-by: Dinesh Gehlot <digehlot@google.com>
Change-Id: I923049d2f1f589f87e1a29e1ac94af7f5fccc2c8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74256
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Fix a typo in an enum's type name, "tmp" ---> "tpm". The enum type is
not used anywhere in the coreboot tree.
Change-Id: Ie7529e7ee80aa9661ec053da8211c2c3295b3942
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74120
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer
Reviewed-by: Benjamin Doron <benjamin.doron00@gmail.com>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Indent with tabs for the sake of consistency with the rest of the code.
Change-Id: Ibd325a7a8348cc1f9023e54dceab40d02a0df233
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74119
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Benjamin Doron <benjamin.doron00@gmail.com>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Used by default for all boards with TPM2 which don't specify log
format explicitly.
Change-Id: I0fac386bebab1b7104378ae3424957c6497e84e1
Ticket: https://ticket.coreboot.org/issues/422
Ticket: https://ticket.coreboot.org/issues/423
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68748
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Used by default for all boards with TPM1 which don't specify log format
explicitly.
Ticket: https://ticket.coreboot.org/issues/423
Change-Id: I89720615a75573d44dd0a39ad3d7faa78f125843
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68747
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
CXL (Compute Express Link) [1] is a cache-coherent interconnect
standard for processors, memory expansion and accelerators.
CXL memory is provided through CXL device which is connected
through CXL/PCIe link, while regular system memory is provided
through DIMMs plugged into DIMM slots which are connected to
memory controllers of processor.
With CXL memory, the server's memory capacity is increased.
CXL memory is in its own NUMA domain, with longer latency
and added bandwidth, comparing to regular system memory.
Host firmware may present CXL memory as specific purpose memory.
Linux kernel dax driver provides direct access to such differentiated
memory. In particular, hmem dax driver provides direct access to
specific purpose memory.
Specific purpose memory needs to be represented in e820 table as
soft reserved, as described in [2].
Add IORESOURCE_SOFT_RESERVE resource property to indicate (memory)
resource that needs to be soft reserved.
Add soft_reserved_ram_resource macro to allow soc/mb code to add
memory resource as soft reserved.
[1] https://www.computeexpresslink.org/
[2] https://web.archive.org/web/20230130233752/https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v5.10.32&id=262b45ae3ab4bf8e2caf1fcfd0d8307897519630
Signed-off-by: Jonathan Zhang <jonzhang@fb.com>
Change-Id: Ie70795bcb8c97e9dd5fb772adc060e1606f9bab0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52585
Reviewed-by: Marc Jones <marc@marcjonesconsulting.com>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <inforichland@gmail.com>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
`stddef.h` should only provide the definitions defined by ISO or Posix.
The included `commonlib/bsd/helpers.h` provide a lot of non standard
definitions that may interfere with definitions from the application.
Change-Id: Ia71edbc3ffe6694ff4b971decf3a41f915264bc8
Signed-off-by: Thomas Heijligen <src@posteo.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70116
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Adding a attach callback function pointer in case a platform needs
to execute anything before the standard initialization of the sdhci
mem controller.
BUG=b:254092907
BRANCH=None
TEST=emerge-herobrine coreboot
Change-Id: I0f37ec09d083922cad5ecd3c47b184cf3311fe2d
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72633
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Add a new set of errors that will be used by the introduced EFI
non-volatile variable store in flash.
Change-Id: I6baea9fb138d1a2755d22a3d587105793adb9c90
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61960
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
This moves the definition for POST_BOOTBLOCK_CAR from the intel-specific
postcodes into the common postcode list, and uses it for the
cache-as-RAM init as needed.
Because POST_BOOTBLOCK_CAR was set to 0x20 in some spots and 0x21 in
most of the others, the values were consolidated into 0x21. This will
change the value on some platforms.
Any conflicts should get sorted out later in the conversion process.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I8527334e679a23006b77a5645f919aea76dd4926
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71596
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Add a new eventLog type of ELOG_TYPE_FW_EARLY_SOL to support logging
when we show early signs of life to the user.
BUG=b:266113626
TEST=event shows in eventlog after CSE sync and/or MRC
Change-Id: I3bd5a250c0be824dbbad0236cee7d61a1ffdbc6c
Signed-off-by: Tarun Tuli <tarun.tuli@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72670
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Now that multiple platforms are trying to initialize eMMC in coreboot
instead of depthcharge, lets move common functionality into commonlib
instead of copying the same functionality between multiple platforms.
Note for consistency, changed name of set_early_mmc_wake_status() to
mmc_set_early_wake_status(). Also adding an mmc_send_cmd1() function
for retrieving the Operating Conditions Register (OCR) contents.
BUG=b:218406702
BRANCH=None
TEST=emerge-herobrine coreboot chromeos-bootimage
flash onto villager device and make sure still boots ChromeOS
Change-Id: Id00535b05bbd379081712601ef10e762c1831747
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71827
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
When pulling in commonlib/storage/pci_sdhci.c into herobrine, am
seeing an "error: cast to pointer from integer of different size
[-Werror=int-to-pointer-cast]", so fixing that.
BUG=b:254092907
BRANCH=None
TEST=emerge-herobrine coreboot
Make sure that we can build without errors
Change-Id: Ib1718f156708a619f7eeb181e19b1a8c620de1f8
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71828
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
TCPA usually refers to log described by TPM 1.2 specification.
Change-Id: I896bd94f18b34d6c4b280f58b011d704df3d4022
Ticket: https://ticket.coreboot.org/issues/423
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69444
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
The CR50 code clears the post code value. Add this as a #define.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: If3b73a3159ac8ac9ab08c6ff705b0ca289ab453c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71592
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jon Murphy <jpmurphy@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
There seem to be some recurring vague concerns about the alignment of
coreboot table entries. While the existing implementation has been
producing tables with a well-defined alignment (4 bytes) for a long
time, the code doesn't always make it very clear. This patch adds an
explicit constant to codify that alignment, assertions to check it after
each entry, and adds explicit padding to the few entry structures that
were relying on compiler padding to return a correct sizeof() value.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Iaeef29ef255047a855066469e03b5481812e5975
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70158
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Jakub Czapiga <jacz@semihalf.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Peter Stuge <peter@stuge.se>
The calculation for mem_chip_info_total_density_bytes() may already
overflow in the intermediate 32-bit calculations before being assigned
to the 64-bit result variable. Fix that.
Fixes Coverity issue: CID 1501510
BRANCH=corsola
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I73da014c953381974c6ede2b17586b68675bde2d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70764
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Add more clamping functions that work with different types.
Change-Id: I14cf335d5a54f769f8fd9184450957e876affd6b
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64175
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The original version of the mem_chip_info structure does not record rank
information and does not allow precise modeling of certain DDR
configurations, so it falls short on its purpose to compile all
available memory information. This patch updates the format to a new
layout that remedies these issues. Since the structure was introduced so
recently that no firmware using it has been finalized and shipped yet,
we should be able to get away with this without accounting for backwards
compatibility.
BRANCH=corsola
Cq-Depend: chromium:3980175
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: If34e6857439b6f6ab225344e5b4dd0ff11d8d42a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68871
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Xixi Chen <xixi.chen@mediatek.corp-partner.google.com>
Currently the MRC cache is updated in romstage, immediately after
returning from FSP-M. Since cbmem is not cached in romstage, the update
is slow (~6 ms on nissa). Specifically, the new MRC data returned by the
FSP is stored in the FSP reserved memory in cbmem, so hashing the new
data is slow.
Move the MRC cache update to ramstage, where cbmem is cached. On nissa,
this saves ~5 ms of boot time.
Before:
552:finished loading ChromeOS VPD (RW) 631,667 (16)
3:after RAM initialization 637,703 (6,036)
4:end of romstage 650,307 (12,603)
After:
552:finished loading ChromeOS VPD (RW) 631,832 (15)
3:after RAM initialization 633,002 (1,169)
4:end of romstage 645,582 (12,580)
In ramstage, save_mrc_data() takes ~138 us.
BUG=b:242667207
TEST=MRC caching still works as expected on nivviks - after clearing the
MRC cache, memory is retrained on the next boot, but cached data is used
on subsequent boots.
Change-Id: Ie6aa2dee83a3ab8913830746593935d36a034b8d
Signed-off-by: Reka Norman <rekanorman@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67669
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
ELOG_CROS_DIAG_RESULT_* codes should be consistent with the enum
definition of enumerated histograms.
Hence add comments based on the requirements of enum histograms in
histogram guidelines.
BUG=b:4047421
TEST=none
Change-Id: I1a1a7c863d5aa9496649f81dc94fd79a6ad482df
Signed-off-by: Hsuan Ting Chen <roccochen@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70145
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
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>
It is no longer necessary to explicitly add "ERROR: " in front of
BIOS_ERR message.
Change-Id: I36e2785ae567d82339212140c1bde0876dfd450d
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69622
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
The function pci_scan_bus had 3 post codes in it:
0x24 - beginning
0x25 - middle
0x55 - end
I got rid of the middle postcode and used 0x25 for the code signifying
the end of the function. I don't think all three are needed.
0x24 & 0x25 postcodes are currently also used in intel cache-as-ram
code. Those postcodes should be adjusted to avoid conflicting.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I19c9d5e256505b64234919a99f73a71efbbfdae3
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69201
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
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>
The 0x9a, 0x9b, and 0x9c postcodes are not used anywhere else in the
coreboot tree other than in arch/x86/tables.c. Add macros to
standardize these postcodes.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I16be65ffa3f0b253fe4a9bb7bfb97597a760ad3f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69200
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Cut and paste error.
Signed-off-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Change-Id: Iae6213ac99bc5c64fd5dcd681c7922eafa011fc0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69165
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Metadata Hash is usually present inside the first segment of BIOS. On
board where vboot starts in bootblock, it is present in bootblock. On
boards where vboot starts before bootblock, it is present in file
containing verstage. Update cbfstool to check for metadata hash in file
containing verstage besides bootblock.
Add a new CBFS file type for the concerned file and exclude it from CBFS
verification.
BUG=b:227809919
TEST=Build and boot to OS in Skyrim with CBFS verification enabled using
x86 and PSP verstages.
Change-Id: Ib4dfba6a9cdbda0ef367b812f671c90e5f90caf8
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66942
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Only edk2 used this to fill in a different struct but even there the
entries go unused, so removing this struct element from coreboot has
no side effects.
Change-Id: Iadd2678c4e01d30471eac43017392d256adda341
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68767
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Bill XIE <persmule@hardenedlinux.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Remove the "_DEPRECATED_" tag from ChromeOS diagnostics event and add a
subtype: "ELOG_CROS_DIAGNOSTICS_LOGS" under it.
The data of "ELOG_CROS_DIAGNOSTICS_LOGS" (0x02) contains:
* An uint8_t of subtype code
* Any number of "ChromeOS diagnostics logs" events
Each "ChromeOS diagnostics log" represents the result of one ChromeOS
diagnostics test run. It is stored within an uint8_t raw[3]:
* [23:19] = ELOG_CROS_DIAG_TYPE_*
* [18:16] = ELOG_CROS_DIAG_RESULT_*
* [15:0] = Running time in seconds
Also add support for parsing this event. The parser will first calculate
the number of runs it contains, and try to parse the result one by one.
BUG=b:226551117
TEST=Build and boot google/tomato to OS,
localhost ~ # elogtool list
0 | 2022-09-26 04:25:32 | Log area cleared | 186
1 | 2022-09-26 04:25:50 | System boot | 0
2 | 2022-09-26 04:25:50 | Firmware vboot info | boot_mode=Manual recovery
| recovery_reason=0x2/0 (Recovery button pressed)
| fw_tried=A | fw_try_count=0 | fw_prev_tried=A
| fw_prev_result=Unknown
3 | 2022-09-26 04:25:50 | EC Event | Keyboard Recovery
4 | 2022-09-26 04:26:01 | Memory Cache Update | Normal | Success
5 | 2022-09-26 04:26:06 | System boot | 0
6 | 2022-09-26 04:26:07 | Firmware vboot info | boot_mode=Diagnostic
| fw_tried=A | fw_try_count=0 | fw_prev_tried=A
| fw_prev_result=Unknown
7 | 2022-09-26 04:26:07 | Diagnostics Mode | Diagnostics Logs
| type=Memory check (quick), result=Aborted, time=0m0s
| type=Memory check (full), result=Aborted, time=0m0s
| type=Storage self-test (extended), result=Aborted, time=0m1s
Change-Id: I02428cd21be2ed797eb7aab45f1ef1d782a9c047
Signed-off-by: Hsuan Ting Chen <roccochen@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67834
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
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>
CL:3825558 changes all vb2_digest and vb2_hash functions to take a new
hwcrypto_allowed argument, to potentially let them try to call the
vb2ex_hwcrypto API for hash calculation. This change will open hardware
crypto acceleration up to all hash calculations in coreboot (most
notably CBFS verification). As part of this change, the
vb2_digest_buffer() function has been removed, so replace existing
instances in coreboot with the newer vb2_hash_calculate() API.
Due to the circular dependency of these changes with vboot, this patch
also needs to update the vboot submodule:
Updating from commit id 18cb85b5:
2load_kernel.c: Expose load kernel as vb2_api
to commit id b827ddb9:
tests: Ensure auxfw sync runs after EC sync
This brings in 15 new commits.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I287d8dac3c49ad7ea3e18a015874ce8d610ec67e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66561
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jakub Czapiga <jacz@semihalf.com>
I added this header in commit a6c8b4becb
(nb/intel/sandybridge: Rewrite get_FRQ). Relicense it as "BSD-3-Clause
OR GPL-2.0-or-later" and move it into the BSD-licensed commonlib part.
Change-Id: I89ebdcdf8d06e78e624e37a443696981b3b17b7d
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66711
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
BUG=b:240624460
TEST=None
Signed-off-by: Reka Norman <rekanorman@chromium.org>
Change-Id: I8542c9bb624a366bc1bb01f6eae66ba97520d19c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66381
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch adds `_DEPRECATED_` tag to ChromeOS boot mode related event
logging types as below:
* ELOG_TYPE_CROS_RECOVERY_MODE <---- to record recovery boot reason
while booting into recovery mode
* ELOG_TYPE_CROS_DEVELOPER_MODE <--- if the platform is booted into
developer mode.
* ELOG_TYPE_CROS_DIAGNOSTICS <---- if the platform is booted into
diagnostic mode.
Drop static structure `cros_deprecated_recovery_reasons` as it has been
replaced by vb2_get_recovery_reason_string() function.
ELOG_TYPE_FW_BOOT_INFO event type is now used to record all those
related fw boot info along with ChromeOS boot mode/reason etc.
BUG=b:215615970
TEST=Build and boot google/kano to ChromeOS.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I932952ce32337e2d54473667ce17582a90882da8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65802
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
This patch adds a function to calculate best rational approximation
for a given fraction and unit tests for it.
Change-Id: I2272d9bb31cde54e65721f95662b80754eee50c2
Signed-off-by: Vinod Polimera <quic_vpolimer@quicinc.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66010
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch calls into vboot API (vb2api_get_fw_boot_info) to retrieve
FW slot boot information like (tries count, current boot slot, previous
boot slot, previous boot status and boot mode).
Upon retrieval of the vboot information, elog callback from ramstage
records the info into the eventlog.
Additionally, this patch refactors the existing event logging mechanism
to add newer APIs to record vboot firmware boot related information.
BUG=b:215615970
TEST=Build and boot google/kano to ChromeOS and run below command to
check the cbmem log:
Scenario 1:
localhost ~ # cbmem -c | grep VB2
[INFO ] VB2:vb2_check_recovery() Recovery reason from previous boot:
0x0 / 0x0
[INFO ] VB2:vb2api_fill_boot_config() boot_mode=`Developer boot`
VB2:vb2api_get_fw_boot_info() fw_tried=`A` fw_try_count=0
fw_prev_tried=`A` fw_prev_result=`Success`.
....
Scenario 2:
localhost ~ # crossystem recovery_request=1
localhost ~ # cbmem -c | grep VB2
[INFO ] VB2:vb2api_fill_boot_config() boot_mode=`Manual recovery boot`
VB2:vb2api_fill_boot_config() recovery_reason=0x13 / 0x00
VB2:vb2api_get_fw_boot_info() fw_tried=`A` fw_try_count=0
fw_prev_tried=`A` fw_prev_result=`Unknown`.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I6882cd1c4dbe5e24f6460388cd1af4e4a05fc4da
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65561
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The concise multi-line comment style is for inside function bodies to
save space. Outside of it, use non-concise style.
Change-Id: I34d9ec6984b598a37c438fa3c395b5478207e31d
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65885
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Sergii Dmytruk