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>
A signed bitfield with a length of 1 bit can only have the values 0 and
-1. Assigning a 1 ends up behaving as expected, but it's not the
semantically correct thing to do there. Changing the type of the element
to an unsigned bitfield with a length of 1 would fix that, but since
this is used as a boolean value, just change it to bool type.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I230804335e7a15a8a9489859b20846988ba6c5cd
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58076
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The u8 type is used in the file, but neither stdint.h not types.h was
included in the file.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ifd67aff9eba01f9618004c869f1473217b3aeae4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58075
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
When a new variant is created, it needs to have a path to its SPD binary
defined. Currently, this is done by setting SPD_SOURCES to a placeholder
SPD file, which just contains zero bytes.
To remove the need for a placeholder file, automatically generate a
single-byte spd.bin in lib/Makefile.inc when SPD_SOURCES is set to the
marker value 'placeholder'.
BUG=b:191776301
TEST=Change cappy/memory/Makefile to `SPD_SOURCES = placeholder`. Build
and check that spd.bin contains a single zero byte.
Signed-off-by: Reka Norman <rekanorman@google.com>
Change-Id: I11f8f9b7ea3bc32aa5c7a617558572a5c1c74c72
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57795
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Currently, if LIB_SPD_DEPS contains an SPD file which doesn't exist, the
file is silently skipped when creating spd.bin. Instead, fail the build.
BUG=b:191776301
TEST=Build test on brya. Build fails if a non-existent file is included
in LIB_SPD_DEPS.
Change-Id: I1bdadb72e087c2ee7a88fbab2f3607bd400fa2e4
Signed-off-by: Reka Norman <rekanorman@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57697
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
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>
This change does the following:
* Pushes the cpu_info struct into the top of the stack (just like
c_start.S). This is required so the cpu_info function works correctly.
* Adds the thread.c to the romstage build.
I only enabled this for romstage since I haven't done any tests in other
stages, but in theory it should work for other stages.
BUG=b:179699789
TEST=Boot guybrush with threads enabled in romstage
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I8e32e1c54dea0d0c85dd6d6753147099aa54b9b5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56494
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
By lazy initializing the threads, if a stage doesn't use them, they will
be garbage collected.
BUG=b:179699789
TEST=Boot guybrush to the OS and verify threads worked
Suggested-by: Julius Werner <jwerner@chromium.org>
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I7208ffb5dcda63d916bc6cfdea28d92a62435da6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56532
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
There is no reason this needs to be done in asm. It also allows
different stages to use threads. If threads are no used in a specific
stage, the compiler will garbage collect the space.
BUG=b:179699789
TEST=Boot guybrush to the OS
Suggested-by: Julius Werner <jwerner@chromium.org>
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: Ib5a84a62fdc75db8ef0358ae16ff69c20cbafd5f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56531
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
`cpu_info()` requires that stacks be STACK_SIZE aligned and a power of 2.
BUG=b:179699789
TEST=Boot guybrush to the OS
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I615623f05bfbe2861dcefe5cae66899aec306ba2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56530
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
thread_run_until is a ramstage specific API. This change guards the API
by checking ENV_RAMSTAGE.
BUG=b:179699789
TEST=Boot guybrush to the OS
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I4784942070fd352a48c349f3b65f5a299abf2800
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56529
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
These methods are oprom specific. Move them out of CBFS. I also deleted
the tohex methods and replaced them with snprintf.
BUG=b:179699789
TEST=Boot guybrush and see oprom still loads
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I03791f19c93fabfe62d9ecd4f9b4fad0e6a6146e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56393
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
This method will allow the SoC code to start loading the payload before
it is required.
BUG=b:177909625
TEST=Boot guybrush and see read/decompress drop by 23 ms.
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: Ifa8f30a0f4f931ece803c2e8e022e4d33d3fe581
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56051
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
If a thread wants to block a state transition it can use
thread_run_until. Otherwise just let the thread run. `thread_join` can
be used to block on the thread. Boot states are also a ramstage concept.
If we want to use this API in any other stage, we need a way of starting
a thread without talking about stages.
BUG=b:179699789
TEST=verify thread_run no longer blocks the current state
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I3e5b0aed70385ddcd23ffcf7b063f8ccb547fc05
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56351
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The thread_handle can be used to wait for a thread to exit. I also added
a return value to the thread function that will be stored on the handle
after it completes. This makes it easy for the callers to check if the
thread completed successfully or had an error. The thread_join
method uses the handle to block until the thread completes.
BUG=b:179699789
TEST=See thread_handle state update and see error code set correctly.
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: Ie6f64d0c5a5acad4431a605f0b0b5100dc5358ff
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56229
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
We need a way to protect shared resources. Since we are using
cooperative multitasking the mutex implementation is pretty trivial.
BUG=b:179699789
TEST=Verify thread lock and unlock.
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: Ife1ac95ec064ebcdd00fcaacec37a06ac52885ff
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56230
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Renaming them to thread_coop_disable()/thread_coop_enable() makes them
sound like a pair.
BUG=b:179699789
TEST=Boot guybrush to OS
Suggested-by: Julius Werner <jwerner@chromium.org>
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I1d70c18965f53e733e871ca03107270612efa4fc
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56357
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change allows nesting critical sections, and frees the caller from
having to keep track of whether the thread has coop enabled.
BUG=b:179699789
TEST=Boot guybrush with SPI DMA
Suggested-by: Julius Werner <jwerner@chromium.org>
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I325ab6181b17c5c084ca1e2c181b4df235020557
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56350
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
idle_thread_init was actually configuring the BSP thread at the end.
We can instead do this in threads_initialize. This now lets us set
initialized after the idle thread has been set up.
BUG=b:179699789
TEST=Boot guybrush to OS
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I7f1d6afac3b0622612565b37c61fbd2cd2481552
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56356
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This helper method is just a shorthand for
`thread_yield_microseconds(0)`. I think it makes it clear that we want
to yield a thread without delaying.
BUG=b:179699789
TEST=build test
Suggested-by: Julius Werner <jwerner@chromium.org>
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: Id8b60c35b183cff6871d7ba70b36eb33b136c735
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56349
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
In hardwaremain.c we call console_init before threads_initialize. Part
of setting up the uart requires calling udelay which then calls
thread_yield_microseconds. Since threads have not been set up, trying to
yield will result in bad things happening. This change guards the thread
methods by making current_thread return NULL if the structures have not
been initialized.
BUG=b:179699789
TEST=Ramstage no longer hangs with serial enabled
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: If9e1eedfaebe584901d2937c8aa24e158706fa43
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56318
Reviewed-by: Krystian Hebel <krystian.hebel@3mdeb.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Since bootmem is not available in romstage, calls to bootmem APIs need
to be compile-time eliminated in order to avoid linker error:
undefined reference to `bootmem_region_targets_type
BUG=None
BRANCH=None
TEST=./util/abuild/abuild -p none -t GOOGLE_HEROBRINE -x -a -B
cherry-picked on top of CB:49392 and verified successful
compilation.
Change-Id: I8dfa2f2079a9a2859114c53c22bf7ef466ac2ad9
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55865
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.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>
The `location` member of `struct boot_state_callback` is conditionally
guarded depending on `CONFIG(DEBUG_BOOT_STATE)` using preprocessor. It
is probably intended to save some space when the `location` strings do
not get printed. However, directly using the `location` member without
any guards will cause a compile-time error. Plus, preprocessor-guarded
code gets nasty really quickly.
In order to minimise preprocessor usage, introduce the `bscb_location`
inline helper function, which transforms the compile-time error into a
link-time error. It is then possible to substitute preprocessor guards
with an ordinary C `if` statement.
Change-Id: I40b7f29f96ea96a5977b55760f0fcebf3a0df733
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55386
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
There are cases where the RTC_VRT bit in register D stays set after a
power failure while the real date and time registers can contain rubbish
values (can happen when RTC is not buffered). If we do not detect this
invalid date and/or time here and keep it, Linux will use these bad
values for the initial timekeeper init. This in turn can lead to dates
before 1970 in user land which can break a lot assumptions.
To fix this, check date and time sanity when the RTC is initialized and
reset the values if needed.
Change-Id: I5bc600c78bab50c70372600347f63156df127012
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54914
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add a function to check sanity of a given RTC date and time.
Invalid values in terms of overrun ranges of the registers can lead to
strange issues in the OS.
Change-Id: I0a381d445c894eee4f82b50fe86dad22cc587605
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54913
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Over the last couple of years we have continuously added more and more
CBMEM init hooks related to different independent components. One
disadvantage of the API is that it can not model any dependencies
between the different hooks, and their order is essentially undefined
(based on link order). For most hooks this is not a problem, and in fact
it's probably not a bad thing to discourage implicit dependencies
between unrelated components like this... but one resource the
components obviously all share is CBMEM, and since many CBMEM init hooks
are used to create new CBMEM areas, the arbitrary order means that the
order of these areas becomes unpredictable.
Generally code using CBMEM should not care where exactly an area is
allocated, but one exception is the persistent CBMEM console which
relies (on a best effort basis) on always getting allocated at the same
address on every boot. This is, technically, a hack, but it's a pretty
harmless hack that has served us reasonably well so far and would be
difficult to realize in a more robust way (without adding a lot of new
infrastructure). Most of the time, coreboot will allocate the same CBMEM
areas in the same order with the same sizes on every boot, and this all
kinda works out (and since it's only a debug console, we don't need to
be afraid of the odd one-in-a-million edge case breaking it).
But one reproducible difference we can have between boots is the vboot
boot mode (e.g. normal vs. recovery boot), and we had just kinda gotten
lucky in the past that we didn't have differences in CBMEM allocations
in different boot modes. With the recent addition of the RW_MCACHE
(which does not get allocated in recovery mode), this is no longer true,
and as a result CBMEM consoles can no longer persist between normal and
recovery modes.
The somewhat kludgy but simple solution is to just create a new class of
specifically "early" CBMEM init hooks that will always run before all
the others. While arbitrarily partitioning hooks into "early" and "not
early" without any precise definition of what these things mean may seem
a bit haphazard, I think it will be good enough in practice for the very
few cases where this matters and beats building anything much more
complicated (FWIW Linux has been doing something similar for years with
device suspend/resume ordering). Since the current use case only relates
to CBMEM allocation ordering and you can only really be "first" if you
allocate in romstage, the "early" hook is only available in romstage for
now (could be expanded later if we find a use case for it).
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: If2c849a89f07a87d448ec1edbad4ce404afb0746
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54737
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
hexdump and hexdump32 do similar things, but hexdump32 is mostly a
reimplementation that has additional support to configure the console
log level, but has a very unexpected len parameter that isn't in bytes,
but in DWORDs.
With the move to hexdump() the console log level for the hexdump is
changed to BIOS_DEBUG.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I6138d17f0ce8e4a14f22d132bf5c64d0c343b80d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54925
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change adds a helper function `fw_config_probe_dev()` that allows
the caller to check if any of the probe conditions are true for any
given device. If device has no probe conditions or a matching probe
condition, then it returns true and provides the matching probe
condition back to caller (if provided with a valid pointer). Else, it
returns false. When fw_config support is disabled, this function
always returns true.
Change-Id: Ic2dae338e6fbd7755feb23ca86c50c42103f349b
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54751
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: EricR Lai <ericr_lai@compal.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
fw_config is unprovisioned in the factory for the first boot. This is
the only case where fw_config is left unprovisioned. On first boot in
factory, fw_config gets correctly provisioned by the factory
toolkit. When fw_config is unprovisioned, it is not always possible to
make a guess which device to enable/disable since there can be certain
conflicting devices which can never be enabled at the same time. That
is the reason the original implementation of fw_config library kept
fw_config as 0 when it was unprovisioned.
CB:47956 ("fw_config: Use UNDEFINED_FW_CONFIG to mean unprovisioned")
added support for a special unprovisioned value to allow any callers
to identify this factory boot condition and take any appropriate
action required for this boot (Ideally, this would just involve
configuring any boot devices essential to getting to OS. All other
non-essential devices can be kept disabled until fw_config is properly
provisioned). However, CB:47956 missed handling the
`fw_config_probe()` function and resulted in silent change in behavior.
This change fixes the regression introduced by CB:47956 and returns
`false` in `fw_config_probe()` if fw_config is not provisioned yet.
Change-Id: Ic22cd650d3eb3a6016fa2e2775ea8272405ee23b
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54750
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: EricR Lai <ericr_lai@compal.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The CBFS mcache size default was eyeballed to what should be "hopefully
enough" for most users, but some recent Chrome OS devices have already
hit the limit. Since most current (and probably all future) x86 chipsets
likely have the CAR space to spare, let's just double the size default
for all supporting chipsets right now so that we hopefully won't run
into these issues again any time soon.
The CBFS_MCACHE_RW_PERCENTAGE default for CHROMEOS was set to 25 under
the assumption that Chrome OS images have historically always had a lot
more files in their RO CBFS than the RW (because l10n assets were only
in RO). Unfortunately, this has recently changed with the introduction
of updateable assets. While hopefully not that many boards will need
these, the whole idea is that you won't know whether you need them yet
at the time the RO image is frozen, and mcache layout parameters cannot
be changed in an RW update. So better to use the normal 50/50 split on
Chrome OS devices going forward so we are prepared for the eventuality
of needing RW assets again.
The RW percentage should really also be menuconfig-controllable, because
this is something the user may want to change on the fly depending on
their payload requirements. Move the option to the vboot Kconfigs
because it also kinda belongs there anyway and this makes it fit in
better in menuconfig. (I haven't made the mcache size
menuconfig-controllable because if anyone needs to increase this, they
can just override the default in the chipset Kconfig for everyone using
that chipset, under the assumption that all boards of that chipset have
the same amount of available CAR space and there's no reason not to use
up the available space. This seems more in line with how this would work
on non-x86 platforms that define this directly in their memlayout.ld.)
Also add explicit warnings to both options that they mustn't be changed
in an RW update to an older RO image.
BUG=b:187561710
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I046ae18c9db9a5d682384edde303c07e0be9d790
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54146
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Rename and update POST_ENTRY_RAMSTAGE postcode value from 0x80 to 0x6f
to make the ramstage postcodes appear in an incremental order.
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Change-Id: I60f4bd8b2e6b2b887dee7c4991a14ce5d644fdba
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52947
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
When using a hardware assisted root of trust measurement, like Intel
TXT/CBnT, the TPM init needs to happen inside the bootblock to form a
proper chain of trust.
Change-Id: Ifacba5d9ab19b47968b4f2ed5731ded4aac55022
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51923
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
We had the addrspace_32bit rdev in prog_loaders.c for a while to help
represent memory ranges as an rdev, and we've found it useful for a
couple of things that have nothing to do with program loading. This
patch moves the concept straight into commonlib/region.c so it is no
longer anchored in such a weird place, and easier to use in unit tests.
Also expand the concept to the whole address space (there's no real need
to restrict it to 32 bits in 64-bit environments) and introduce an
rdev_chain_mem() helper function to make it a bit easier to use. Replace
some direct uses of struct mem_region_device with this new API where it
seems to make sense.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Ie4c763b77f77d227768556a9528681d771a08dca
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52533
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Algorithm used to calculate weekday is now based on Zeller's rule, so it
does not need if statement constraining year to 1971 and later.
Signed-off-by: Jakub Czapiga <jacz@semihalf.com>
Change-Id: I25e2e6a1c9b2fb1ac2576e028b580db0ea474d37
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52347
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Fagerburg <pfagerburg@chromium.org>
CBFS_VERIFICATION requires the CBFS metadata hash anchor to be linked
into an uncompressed stage, but for platforms using COMPRESS_BOOTBLOCK,
this is only the decompressor stage. The first CBFS accesses are made in
the bootblock stage after decompression, so if we want to make
CBFS_VERIFICATION work on those platforms, we have to pass the metadata
hash anchor from the decompressor into the bootblock. This patch does
just that. (Note that this relies on the decompressor data remaining
valid in memory for as long as the metadata hash anchor is needed. This
is always true even for OVERLAP_DECOMPRESSOR_ROMSTAGE() situations
because the FMAP and CBFS metadata necessarily need to have finished
verification before a new stage could be loaded.)
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I2e6d7384cfb8339a24369eb6c01fc12f911c974e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52085
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch adds file data hashing for CONFIG_CBFS_VERIFICATION. With
this, all CBFS accesses using the new CBFS APIs (cbfs_load/_map/_alloc
and variants) will be fully verified when verification is enabled. (Note
that some use of legacy APIs remains and thus the CBFS_VERIFICATION
feature is not fully finished.)
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Ic9fff279f69cf3b7c38a0dc2ff3c970eaa756aa8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52084
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
With the last external user to cbfs_load_and_decompress() gone, we can
stop exporting this function to the rest of coreboot and make it local
to cbfs.c. Also remove a couple of arguments that no longer really make
a difference and fold the stage-specific code for in-place LZ4
decompression into cbfs_prog_stage_load().
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I4b459650a28e020c4342a66090f55264fbd26363
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52083
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
The calloc() function is useful in addition to malloc and friends, so
add the obvious definition.
Change-Id: I57a568e323344a97b35014b7b8bec16adc2fd720
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51949
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Right before CB:49334 was submitted, I changed the signature of
cbfs_allocator_t function pointers to include another argument passing
in the already loaded CBFS metadata (to allow for the rare edge case of
allocators needing to read CBFS attributes). This interface is not meant
to be able to modify the passed-in metadata, so to clarify that and
prevent potential errors, we should declare the argument const.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I7e3756490b9ad7ded91268c61797cef36c4118ee
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52081
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
These used to be printed before CB:46605. Having them in the logs can be
a huge timesaver when debugging logs sent to you by other people
(especially from systems that don't boot all the way). Let's add them
back.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Ifdbfdd29d25a0937c27113ace776f7aec231a57d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52011
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
In pursuit of the goal of eliminating the proliferation of raw region
devices to represent CBFS files outside of the CBFS core code, this
patch removes the get_spd_cbfs_rdev() API and instead replaces it with
spd_cbfs_map() which will find and map the SPD file in one go and return
a pointer to the relevant section. (This makes it impossible to unmap
the mapping again, which all but one of the users didn't bother to do
anyway since the API is only used on platforms with memory-mapped
flash. Presumably this will stay that way in the future so this is not
something worth worrying about.)
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Iec7571bec809f2f0712e7a97b4c853b8b40702d1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50350
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Wim Vervoorn <wvervoorn@eltan.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
In pursuit of the eventual goal of removing cbfs_boot_locate() (and
direct rdev access) from CBFS APIs, this patch replaces all remaining
"simple" uses of the function call that can easily be replaced by the
newer APIs (like cbfs_load() or cbfs_map()). Some cases of
cbfs_boot_locate() remain that will be more complicated to solve.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Icd0f21e2fa49c7cc834523578b7b45b5482cb1a8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50348
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
