The ACPI RSDP can only be found in:
- legacy BIOS region
- via UEFI service
On some systems like ARM that legacy BIOS region is not an option, so
to avoid needing UEFI it makes sense to expose the RSDP via a coreboot
table entry.
This also adds the respective unit test.
Change-Id: I591312a2c48f0cbbb03b2787e4b365e9c932afff
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/62573
Reviewed-by: Lance Zhao
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
cb_err_t was meant to be used in place of `enum cb_err` in all
situations, but the choice to use a typedef here seems to be
controversial. We should not be arbitrarily using two different
identifiers for the same thing across the codebase, so since there are
no use cases for serializing enum cb_err at the moment (which would be
the primary reason to typedef a fixed-width integer instead), remove
cb_err_t again for now.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Iaec36210d129db26d51f0a105d3de070c03b686b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/62600
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
This patch aims to make timestamps more consistent in naming,
to follow one pattern. Until now there were many naming patterns:
- TS_START_*/TS_END_*
- TS_BEFORE_*/TS_AFTER_*
- TS_*_START/TS_*_END
This change also aims to indicate, that these timestamps can be used
to create time-ranges, e.g. from TS_BOOTBLOCK_START to TS_BOOTBLOCK_END.
Signed-off-by: Jakub Czapiga <jacz@semihalf.com>
Change-Id: I533e32392224d9b67c37e6a67987b09bf1cf51c6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/62019
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Now that the console system itself will clearly differentiate loglevels,
it is no longer necessary to explicitly add "ERROR: " in front of every
BIOS_ERR message to help it stand out more (and allow automated tooling
to grep for it). Removing all these extra .rodata characters should save
us a nice little amount of binary size.
This patch was created by running
find src/ -type f -exec perl -0777 -pi -e 's/printk\(\s*BIOS_ERR,\s*"ERROR: /printk\(BIOS_ERR, "/gi' '{}' ';'
and doing some cursory review/cleanup on the result. Then doing the same
thing for BIOS_WARN with
's/printk\(\s*BIOS_WARNING,\s*"WARN(ING)?: /printk\(BIOS_WARNING, "/gi'
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I3d0573acb23d2df53db6813cb1a5fc31b5357db8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61309
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Reviewed-by: Lance Zhao
Reviewed-by: Jason Glenesk <jason.glenesk@gmail.com>
In order to provide the same loglevel prefixes and highlighting that
were recently introduced for "interactive" consoles (e.g. UART) to
"stored" consoles (e.g. CBMEM) but minimize the amont of extra storage
space wasted on this info, this patch will write a 1-byte control
character marker indicating the loglevel to the start of every line
logged in those consoles. The `cbmem` utility will then interpret those
markers and translate them back into loglevel prefixes and escape
sequences as needed.
Since coreboot and userspace log readers aren't always in sync,
occasionally an older reader may come across these markers and not know
how to interpret them... but that should usually be fine, as the range
chosen contains non-printable ASCII characters that normally have no
effect on the terminal. At worst the outdated reader would display one
garbled character at the start of every line which isn't that bad.
(Older versions of the `cbmem` utility will translate non-printable
characters into `?` question marks.)
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I86073f48aaf1e0a58e97676fb80e2475ec418ffc
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61308
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
This patch adds ANSI escape sequences to highlight a log line based on
its loglevel to the output of "interactive" consoles that are meant to
be displayed on a terminal (e.g. UART). This should help make errors and
warnings stand out better among the usual spew of debug messages. For
users whose terminal or use case doesn't support these sequences for
some reason (or who simply don't like them), they can be disabled with a
Kconfig.
While ANSI escape sequences can be used to add color, minicom (the
presumably most common terminal emulator for UART endpoints?) doesn't
support color output unless explicitly enabled (via -c command line
flag), and other terminal emulators may have similar restrictions, so in
an effort to make this as widely useful by default as possible I have
chosen not to use color codes and implement this highlighting via
bolding, underlining and inverting alone (which seem to go through in
all cases). If desired, support for separate color highlighting could be
added via Kconfig later.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I868f4026918bc0e967c32e14bcf3ac05816415e8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61307
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
In an attempt to make loglevels more visible (and therefore useful,
hopefully), this patch adds a prefix indicating the log level to every
line sent to an "interactive" console (such as a UART). If the code
contains a `printk(BIOS_DEBUG, "This is a debug message!\n"), it will
now show up as
[DEBUG] This is a debug message!
on the UART output.
"Stored" consoles (such as in CBMEM) will get a similar but more
space-efficient feature in a later CL.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Ic83413475400821f8097ef1819a293ee8926bb0b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61306
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
macOS has never defined the usual endian(3)/byteorder(9) byte-swapping
functions. This change implements these byte-swapping functions using
the OSSwap functions, which provide identical functionality. This was
tested on macOS 10.15.7.
Change-Id: I44d59869a4420030f3ce26118175304c680d57a1
Signed-off-by: Alex James <theracermaster@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/60219
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Libpayload requires cbmem_id.h file to support extracting values from
CBMEM IMD entries of coreboot tables. Libpayload use BSD-3-Clause
license, and all of its files used to compile a static library have to
use it too.
Change-Id: I97c080e34ebdbcdf14fe3a3c9515b1dea8ede179
Signed-off-by: Jakub Czapiga <jacz@semihalf.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59696
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <patrick@coreboot.org>
Add events for Chrome OS diagnostics in eventlog tool:
* ELOG_TYPE_CROS_DIAGNOSTICS(0xb6): diagnostics-related events
* ELOG_CROS_LAUNCH_DIAGNOSTICS(0x01): sub-type for diagnostics boot
These events are not added anywhere currently. They will be added in
another separate commit.
Signed-off-by: Hsuan Ting Chen <roccochen@chromium.org>
Change-Id: I1b67fdb46f64db33f581cfb5635103c9f5bbb302
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58795
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jack Rosenthal <jrosenth@chromium.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
AMD platforms pass in the base address to cbfs tool:
fspm.bin-options: -b $(CONFIG_FSP_M_ADDR)
There is no technical reason not to allow FSP-M to be relocated when
!XIP. By allowing this, we no longer need to pass in the base address
into cbfstool when adding fspm.bin. This enables passing in the
`--alignment` argument to cbfs tool instead. cbfstool currently has a
check that prevents both `-b` and `-a` from being passed in.
BUG=b:179699789
TEST=Boot guybrush to OS
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I797fb319333c53ad0bbf7340924f7d07dfc7de30
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58984
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
elog init requires doing a lot of SPI transactions. This change makes it
clear how long we spend initializing elog.
BUG=b:179699789
TEST=Boot guybrush and see elog init timestamps
114:started elog init 3,029,116 (88)
115:finished elog init 3,071,281 (42,165)
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: Ia92372dd76535e06eb3b8a08b53e80ddb38b7a8f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58957
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
AMD platforms require the destination to be 64 byte aligned in order to
use the SPI DMA controller. This is enforced by the destination address
register because the first 6 bits are marked as reserved.
This change adds an option to the mem_pool so the alignment can be
configured.
BUG=b:179699789
TEST=Boot guybrush to OS
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I8d77ffe4411f86c54450305320c9f52ab41a3075
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56580
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Move the locally declared typec_orientation enum from chip.h to
coreboot_tables.h.
Change enum typec_orientation name to type_c_orientation for consistency
with contents of coreboot_tables.h.
Rename TYPEC_ORIENTATION_FOLLOW_CC to TYPEC_ORIENTATION_NONE.
BUG=b:149830546
TEST="emerge-volteer coreboot" and make sure it compiles successfully.
Change-Id: I24c9177be72b0c9831791aa7d1f7b1236309c9cd
Signed-off-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58084
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Furquan Shaikh <furquan@google.com>
This change adds type-c port information for USB Type-C ports to the
coreboot table. This allows depthcharge to know the usb2 and usb3
port number assignments for each available port, as well as the SBU
and data line orientation for the board.
BUG=b:149830546
TEST='emerge-volteer coreboot chromeos-bootimage' and verify it builds
successfully. Cherry-pick CL to enable this feature for volteer,
flash and boot volteer2 to kernel, log in and check cbmem for type-c
info exported to the payload:
localhost ~ # cbmem -c | grep type-c
added type-c port0 info to cbmem: usb2:9 usb3:1 sbu:0 data:0
added type-c port1 info to cbmem: usb2:4 usb3:2 sbu:1 data:0
Signed-off-by: Nick Vaccaro <nvaccaro@google.com>
Change-Id: Ice732be2fa634dbf31ec620552b383c4a5b41451
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57069
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
This CL uses a 16-bit value (instead of an 8-bit value) for the year.
This is needed because the function internally does a "year % 100", so
the year should not be truncated to 8-bit before applying the modulo.
This fixes a regression introduced in commit e929a75.
BUG=b:200538760
TEST=deployed coreboot. Manually verified that year is correct using
"elogtool list"
TEST=test_that -b $BOARD $DUT firmware_EventLog
Change-Id: I17578ff99af5b31b216ac53c22e53b1b70df5084
Signed-off-by: Ricardo Quesada <ricardoq@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57816
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
This patch fixes a few minor CBFS parsing edge cases that could lead to
unintended behavior: the CBFS attribute parser could have run into an
infinite loop if an attribute's length was (accidentally or maliciously)
invalid. A length of 0 would have caused it to read the same attribute
over and over again without making forward progress, while a very large
length could have caused an overflow that makes it go backwards to find
the next attribute. Also, the filename was not guaranteed to be
null-terminated which could have resulted in out-of-bounds reads on a
few error messages.
Finally, clarify the validity guarantees for CBFS header fields offered
by cbfs_walk() in the comment explaining cbfs_mdata.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Ie569786e5bec355b522f6580f53bdd8b16a4d726
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57569
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jakub Czapiga <jacz@semihalf.com>
CBFS file with lenth of (UINT32_MAX - cbfs_file.offset + 1) causes
overflow, making cbfs_walk() being stuck in an infinite loop, and
checking the same file. This patch makes cbfs_walk() skip file headers
with incorrect data_offset or data_length.
Signed-off-by: Jakub Czapiga <jacz@semihalf.com>
Change-Id: I70020e347087cbd8134a1a60177fa9eef63fb7bd
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57525
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Moves MAX_EVENT_SIZE to commonlib/bsd/include, and renames it
ELOG_MAX_EVENT_SIZE to give it an "scoped" name.
The moving is needed because this defined will be used from
util/cbfstool (see next CL in the chain).
BUG=b:172210863
TEST=compiles Ok
Change-Id: I86b06d257dda5b325a8478a044045b2a63fb1a84
Signed-off-by: Ricardo Quesada <ricardoq@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57394
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jack Rosenthal <jrosenth@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
The new CBFS stack was written to try to isolate cases of single file
corruption as far as possible and still make other files avaialble (at
least as long as verification is disabled and they can still be found at
all). For most cases of header corruption, it will just continue trying
to parse the next file. However, in cases where parts of the file extend
beyond the end of the rdev, we have been relying on the range checking
of the rdev API rather than doing it explicitly.
This is fine in general, but it causes the problem that these errors
cannot be distinguished from I/O errors, and I/O errors always make the
whole cbfs_walk() fail. That means we will not return a successful
result from cbfs_mcache_build(), and leads to an odd discrepancy in how
certain kinds of corrupted CBFSes are treated with and without mcache.
This patch adds an explicit range check to make the behavior consistent.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Ice2b6960284bd0c19be35b0607e5e32791e7a64c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57271
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jakub Czapiga <jacz@semihalf.com>
This CL indroduces the ELOG_RW_REGION_NAME. This constant replaced the
hardcoded "RW_ELOG" value. This constant will be used also by elogtool
(see CL in the commit chain).
BUG=b:172210863
Change-Id: Ie8d31204e65fd67d52b0f8ced7b8c1ffdcf5b539
Signed-off-by: Ricardo Quesada <ricardoq@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56986
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This commit moves some drivers/elog/ functionality to commonlib/bsd
since they will be called from util/cbfstool/.
In particular:
* elog_fill_timestamp(), elog_update_checksum(), elog_checksum_event()
were moved to commonlib/bsd/elog
* elog_fill_timestamp() receives the time parameters and updates the
event based on the "time" arguments.
The original elog_*() functions were written by Duncan Laurie
(see CB:1311) and he gave permission to re-license the code to BSD.
BUG=b:172210863
Change-Id: I67d5ad6e7c4d486b3d4ebb25be77998173cee5a9
Signed-off-by: Ricardo Quesada <ricardoq@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56985
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jack Rosenthal <jrosenth@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Add a new tool that that prints elog events.
The tool, as input, accepts either a file with the RW_ELOG contents, or
if the file is not provided it reads the contents of RW_ELOG by calling
the "flashrom" tool.
The tool is based on "mosys eventlog list"[1]. For the moment it only
supports "list", but future commits will add additional functionality.
This commit also adds missing ELOG defines needed for the tool. These
defines are added with the rest of the ELOG defines, in
include/commonlib/bsd/elog.h
The tool is placed inside util/cbfstool. The rationale behind the
decision, is that this tool shares a lot in common with the other tools
located in cbfstool: vboot dependency, shared files like common.o and
valstr.o, and in spirit is similar to some of the tools located in
cbfstool/.
As an example, you call the tool like the following:
$ elogtool list -f rw_elog_dump.bin
[1]: https://chromium.googlesource.com/chromiumos/platform/mosys/+/refs/heads/main/lib/eventlog/elog.c
BUG=b:172210863
Signed-off-by: Ricardo Quesada <ricardoq@google.com>
Change-Id: Ia1fe1c9ed3c4c6bda846055d4b10943b54463935
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56406
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Jack Rosenthal <jrosenth@chromium.org>
Move ELOG defines and structs from include/elog.h to
include/comonlib/bsd/elog.h.
This is needed because the will be used from util/
(in a future commit).
It also replaces uNN types with uintNN_t types, for the reason described
above.
BUG=b:172210863
Signed-off-by: Ricardo Quesada <ricardoq@google.com>
Change-Id: I4f307f599a311810df2367b7c888f650cff1214a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56405
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jack Rosenthal <jrosenth@chromium.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Move elog_internal.h to commonlib/bsd/include/bsd/.
And rename it from elog_internal.h to elog.h.
Since this file will be included from util/ it also converts the "uNN"
types into "uintNN_t" types.
The two defines that are not used by util/ are moved to
drivers/elog/elog.c, the only file that includes them.
Move also the function elog_verify_header() from drivers/elog/, to
commonlib/bsd/elog.c since this function will be called from util/
as well.
The rationale behind moving elog's defines & structs to
commonlib/bsd/include is to make them available to util/ tools and/or
payloads (should it be needed in the future).
The files that are being relicensed to BSD were coded by Duncan Laurie,
and he is Ok with the relicense.
BUG=b:172210863
Signed-off-by: Ricardo Quesada <ricardoq@google.com>
Change-Id: Ia1aefea705ddd417a1d9e978bb18ab6d9a60cad6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56404
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jack Rosenthal <jrosenth@chromium.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Move post_codes.h from include/console to
commonlib/include/commonlib/console.
This is because post_codes.h is needed by code from util/
(util/ code in different commit).
Also, it sorts the #include statements in the files that were
modified.
BUG=b:172210863
Signed-off-by: Ricardo Quesada <ricardoq@google.com>
Change-Id: Ie48c4b1d01474237d007c47832613cf1d4a86ae1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56403
Reviewed-by: Jack Rosenthal <jrosenth@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The GENMASK is defined in multiple files (with various names such as
MASKBIT), which sets certain consecutive bits to 1 and leaves the others
to 0. To avoid duplicate macros, add GENMASK macro to helpers.h.
GENMASK(high, low) sets bits from `high` to `low` (inclusive) to 1. For
example, GENMASK(39, 21) gives us the 64-bit vector 0x000000ffffe00000.
Remove duplicate macro definitions. Also utilize GENMASK for _BF_MASK in
mmio.h.
BUG=none
TEST=make tests/commonlib/bsd/helpers-test
TEST=emerge-cherry coreboot
BRANCH=none
Change-Id: If2e7c4827d8a7d27688534593b556a72f16f0c2b
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56543
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
TEST=Refer to `cbmem -t` output below:
Without this code changes, timestamp ids 962 and 963 are listed as
`unknown`.
962:<unknown> 1,704,863 (157)
963:<unknown> 1,704,878 (14)
With this code changes, lists the timestamps along with the timestamp
strings.
962:calling FspMultiPhaseSiInit 1,704,863 (157)
963:returning from FspMultiPhaseSiInit 1,704,878 (14)
Change-Id: I528567e4cc630e15dffffd1c7684798fcdde4535
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56641
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Introduce a macro retry(attempts, condition, expr) for retrying a
condition, which is extensively used in coreboot.
Example usage:
if (!retry(3, read32(REG) == 0, mdelay(1))
printk(BIOS_ERR, "Error waiting for REG to be 0\n");
BUG=none
TEST=make tests/commonlib/bsd/helpers-test
TEST=emerge-cherry coreboot
BRANCH=none
Change-Id: I421e4dcab949616bd68b3a14231da744b9f74eeb
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55778
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
CB:51638 separated Chrome OS NVS from global NVS by allocating it
separately in CBMEM. CNVS is used in depthcharge to fill firmware
information at boot time. Thus, location of CNVS needs to be shared in
coreboot tables for depthcharge to use.
This change adds a new coreboot table tag
`CB_TAG_ACPI_CNVS`/`CB_TAG_ACPI_CNVS`(0x41) which provides the
location of CNVS in CBMEM to payload (depthcharge).
Additionally, CB:51639 refactored device nvs(DNVS) and moved it to the
end of GNVS instead of the fixed offset 0x1000. DNVS is used on older
Intel platforms like baytrail, braswell and broadwell and depthcharge
fills this at boot time as well. Since DNVS is no longer used on any
new platforms, this information is not passed in coreboot
tables. Instead depthcharge is being updated to use statically defined
offsets for DNVS.
BUG=b:191324611, b:191324611
TEST=Verified that `crossystem fwid` which reads fwid information from
CNVS is reported correctly on brya.
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: I3815d5ecb5f0b534ead61836c2d275083e397ff0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55665
Reviewed-by: EricR Lai <ericr_lai@compal.corp-partner.google.com>
Reviewed-by: Ivy Jian <ivy_jian@compal.corp-partner.google.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Updating the APOB takes a considerable amount of time. I decided to be
granular and split out the operations so we know when we read vs read +
erase + write.
BUG=b:179092979
TEST=Boot guybrush and dump timestamps
3:after RAM initialization 3,025,425 (44)
920:starting APOB read 3,025,430 (5)
921:starting APOB erase 3,025,478 (48)
922:starting APOB write 3,027,727 (2,249)
923:finished APOB 3,210,965 (183,238)
4:end of romstage 3,210,971 (6)
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I08e371873112e38f623f452af0eb946f5471c399
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55401
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
