summaryrefslogtreecommitdiff
path: root/src/lib
AgeCommit message (Collapse)Author
2021-10-05src/acpi to src/lib: Fix spelling errorsMartin Roth
These issues were found and fixed by codespell, a useful tool for finding spelling errors. Signed-off-by: Martin Roth <martin@coreboot.org> Change-Id: I5b8ecdfe75d99028fee820a2034466a8ad1c5e63 Reviewed-on: https://review.coreboot.org/c/coreboot/+/58080 Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2021-10-04coreboot tables: Add type-c port info to coreboot tableNick Vaccaro
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>
2021-10-04lib/hardwaremain: change type of "complete" element in boot_state structFelix Held
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>
2021-10-04lib/hardwaremain: add missing types.h includeFelix Held
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>
2021-09-23lib/Makefile.inc: Generate placeholder spd.bin in lib/Makefile.incReka Norman
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>
2021-09-21lib/Makefile.inc: Fail build if SPD file doesn't existReka Norman
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>
2021-08-04Move post_codes.h to commonlib/console/Ricardo Quesada
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>
2021-07-26arch/x86,lib/thread: Enable thread support in romstageRaul E Rangel
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>
2021-07-26lib/thread,lib/hardwaremain: Lazy initialize threadsRaul E Rangel
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>
2021-07-26lib/thread,arch/x86: Move thread stacks into C bssRaul E Rangel
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>
2021-07-26lib/thread: Add asserts around stack size and alignmentRaul E Rangel
`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>
2021-07-26lib/thread: Guard thread_run_until with ENV_RAMSTAGERaul E Rangel
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>
2021-07-20lib/cbfs,device/pci_rom: Move cbfs_boot_map_optionrom and modernizeRaul E Rangel
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>
2021-07-19lib/prog_loaders: Add payload_preloadRaul E Rangel
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>
2021-07-18lib/hardwaremain: Drop boot_state_current_{block,unblock}()Raul E Rangel
There are no more callers. BUG=b:179699789 TEST=Compile guybrush Signed-off-by: Raul E Rangel <rrangel@chromium.org> Change-Id: I522f17c0e450641c0a60496ba07800da7e39889c Reviewed-on: https://review.coreboot.org/c/coreboot/+/56389 Reviewed-by: Karthik Ramasubramanian <kramasub@google.com> Reviewed-by: Furquan Shaikh <furquan@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2021-07-18lib/thread: Make thread_run not block the current stateRaul E Rangel
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>
2021-07-18lib/thread: Add thread_handleRaul E Rangel
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>
2021-07-18lib/thread: Add mutexRaul E Rangel
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>
2021-07-18lib/thread: Rename thread_cooperate and thread_prevent_coopRaul E Rangel
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>
2021-07-18lib/thread: Allow nesting thread_cooperate and thread_prevent_coopRaul E Rangel
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>
2021-07-18lib/thread: Clean up initialization sequenceRaul E Rangel
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>
2021-07-18lib/thread: Add thread_yield helper methodRaul E Rangel
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>
2021-07-15lib/thread: Verify threads are initialized before yieldingRaul E Rangel
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>
2021-07-02selfboot: Add support for selfload in romstageShelley Chen
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>
2021-06-18nvs: Add Chrome OS NVS (CNVS) information to coreboot tablesFurquan Shaikh
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>
2021-06-14ChromeOS: Separate NVS from global GNVSKyösti Mälkki
Allocate chromeos_acpi in CBMEM separately from GNVS. Change-Id: Ide55964ed53ea1d5b3c1c4e3ebd67286b7d568e4 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/51638 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
2021-06-14lib/hardwaremain: Print individual boot state callback durationsRaul E Rangel
This is useful when trying to find which callbacks are taking the longest time. BUG=b:179092979 TEST=See bootstate durations in logs BS: callback (0xcb79d4d8) @ src/security/vboot/bootmode.c:53 (0 ms). BS: callback (0xcb79cf20) @ src/vendorcode/google/chromeos/ramoops.c:30 (0 ms). BS: callback (0xcb79cef0) @ src/vendorcode/google/chromeos/cr50_enable_update.c:160 (18 ms). Signed-off-by: Raul E Rangel <rrangel@chromium.org> Change-Id: Ifb145fea32ad4e0b694bdb7cdcdd43dce4cc0d27 Reviewed-on: https://review.coreboot.org/c/coreboot/+/55374 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Julius Werner <jwerner@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2021-06-14lib/hardwaremain.c: Hide preprocessor guards in headerAngel Pons
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>
2021-05-30drivers/pc80/mc146818rtc: Check date and time for sanityWerner Zeh
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>
2021-05-30lib/rtc: Add sanity check for time and dateWerner Zeh
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>
2021-05-27cbmem: Introduce "early" init hooks for consoleJulius Werner
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>
2021-05-27lib/hexdump: remove hexdump32 and use hexdump insteadFelix Held
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>
2021-05-24fw_config: Add helper function `fw_config_probe_dev`Furquan Shaikh
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>
2021-05-24fw_config: Return false in `fw_config_probe` in unprovisioned caseFurquan Shaikh
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>
2021-05-14cbfs: Increase mcache size defaultsJulius Werner
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>
2021-05-12include/console: Rename and update POST_ENTRY_RAMSTAGE postcodeSubrata Banik
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>
2021-05-10src: Drop "This file is part of the coreboot project" linesAngel Pons
Commit 6b5bc77c9b22c398262ff3f4dae3e14904c57366 (treewide: Remove "this file is part of" lines) removed most of them, but missed some files. Change-Id: Ib8e7ab26a74b52f86d91faeba77df3331531763f Signed-off-by: Angel Pons <th3fanbus@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/53976 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Nico Huber <nico.h@gmx.de>
2021-05-06security/tpm: Add option to init TPM in bootblockArthur Heymans
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>
2021-05-05lib/coreboot_table.c: Remove unnecessary CPP useArthur Heymans
Change-Id: Ib93617867b946e208c31275d55d380aab7e51a50 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/52729 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2021-04-23lib/espi_debug: Add espi_show_slave_peripheral_channel_configurationRaul E Rangel
Prints out the following: eSPI Slave Peripheral configuration: Peripheral Channel Maximum Read Request Size: 64 bytes Peripheral Channel Maximum Payload Size Selected: 64 bytes Peripheral Channel Maximum Payload Size Supported: 64 bytes Bus master: disabled Peripheral Channel: ready Peripheral Channel: enabled BUG=none TEST=boot guybrush Signed-off-by: Raul E Rangel <rrangel@chromium.org> Change-Id: I7d598ee4f0f9d8ec0b37767e6a5a70288be2cb86 Reviewed-on: https://review.coreboot.org/c/coreboot/+/52225 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
2021-04-21commonlib/region: Turn addrspace_32bit into a more official APIJulius Werner
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>
2021-04-19lib/rtc: Fix incomplete leap year macroJakub Czapiga
Signed-off-by: Jakub Czapiga <jacz@semihalf.com> Found-by: Paul Fagerburg <pfagerburg@chromium.org> Change-Id: Ic434c969141c67ce317a5db0c8805de02c84eb08 Reviewed-on: https://review.coreboot.org/c/coreboot/+/52370 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Paul Fagerburg <pfagerburg@chromium.org>
2021-04-15lib/rtc: Remove unnecessary year constraint in rtc_calc_weekdayJakub Czapiga
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>
2021-04-06decompressor: Add CBFS_VERIFICATION supportJulius Werner
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>
2021-04-06cbfs: Add file data hashing for CONFIG_CBFS_VERIFICATIONJulius Werner
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>
2021-04-06cbfs: Simplify cbfs_load_and_decompress() and stop exporting itJulius Werner
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>
2021-04-06lib: Add obvious definition for `calloc`Tim Wawrzynczak
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>
2021-04-05cbfs: Make `mdata` argument to cbfs_allocator_t constJulius Werner
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>
2021-04-02coreboot_tables: Print strapping IDs when adding them to coreboot tableJulius Werner
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>
2021-03-17spd_bin: Replace get_spd_cbfs_rdev() with spd_cbfs_map()Julius Werner
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>
2021-03-17cbfs: Replace more instances of cbfs_boot_locate() with newer APIsJulius Werner
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>
2021-03-17cbfs: Move stage header into a CBFS attributeJulius Werner
The CBFS stage header is part of the file data (not the header) from CBFS's point of view, which is problematic for verification: in pre-RAM environments, there's usually not enough scratch space in CBFS_CACHE to load the full stage into memory, so it must be directly loaded into its final destination. However, that destination is decided from reading the stage header. There's no way we can verify the stage header without loading the whole file and we can't load the file without trusting the information in the stage header. To solve this problem, this patch changes the CBFS stage format to move the stage header out of the file contents and into a separate CBFS attribute. Attributes are part of the metadata, so they have already been verified before the file is loaded. Since CBFS stages are generally only meant to be used by coreboot itself and the coreboot build system builds cbfstool and all stages together in one go, maintaining backwards-compatibility should not be necessary. An older version of coreboot will build the old version of cbfstool and a newer version of coreboot will build the new version of cbfstool before using it to add stages to the final image, thus cbfstool and coreboot's stage loader should stay in sync. This only causes problems when someone stashes away a copy of cbfstool somewhere and later uses it to try to extract stages from a coreboot image built from a different revision... a debugging use-case that is hopefully rare enough that affected users can manually deal with finding a matching version of cbfstool. The SELF (payload) format, on the other hand, is designed to be used for binaries outside of coreboot that may use independent build systems and are more likely to be added with a potentially stale copy of cbfstool, so it would be more problematic to make a similar change for SELFs. It is not necessary for verification either, since they're usually only used in post-RAM environments and selfload() already maps SELFs to CBFS_CACHE before loading them to their final destination anyway (so they can be hashed at that time). Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: I8471ad7494b07599e24e82b81e507fcafbad808a Reviewed-on: https://review.coreboot.org/c/coreboot/+/46484 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2021-03-17prog_loaders: Remove prog_locate()Julius Werner
This patch rewrites the last few users of prog_locate() to access CBFS APIs directly and removes the call. This eliminates the double-meaning of prog_rdev() (referring to both the boot medium where the program is stored before loading, and the memory area where it is loaded after) and makes sure that programs are always located and loaded in a single operation. This makes CBFS verification easier to implement and secure because it avoids leaking a raw rdev of unverified data outside the CBFS core code. Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: I7a5525f66e1d5f3a632e8f6f0ed9e116e3cebfcf Reviewed-on: https://review.coreboot.org/c/coreboot/+/49337 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2021-03-17cbfs: Remove prog_locate() for payloads (SELF and FIT)Julius Werner
This patch removes the prog_locate() call for all instances of loading payload formats (SELF and FIT), as the previous patch did for stages. Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: I582b37f36fe6f9f26975490a823e85b130ba49a2 Reviewed-on: https://review.coreboot.org/c/coreboot/+/49336 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2021-03-16cbfs: Remove prog_locate() for stages and rmodulesJulius Werner
This patch removes the prog_locate() step for stages and rmodules. Instead, the stage and rmodule loading functions will now perform the locate step directly together with the actual loading. The long-term goal of this is to eliminate prog_locate() (and the rdev member in struct prog that it fills) completely in order to make CBFS verification code safer and its security guarantees easier to follow. prog_locate() is the main remaining use case where a raw rdev of CBFS file data "leaks" out of cbfs.c into other code, and that other code needs to manually make sure that the contents of the rdev get verified during loading. By eliminating this step and moving all code that directly deals with file data into cbfs.c, we can concentrate the code that needs to worry about file data hashing (and needs access to cbfs_private.h APIs) into one file, making it easier to keep track of and reason about. This patch is the first step of this move, later patches will do the same for SELFs and other program types. Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: Ia600e55f77c2549a00e2606f09befc1f92594a3a Reviewed-on: https://review.coreboot.org/c/coreboot/+/49335 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2021-03-08cbfs: Add cbfs_alloc() primitive and combine cbfs_load() and cbfs_map()Julius Werner
This patchs adds a new CBFS primitive that allows callers to pass in an allocator function that will be called once the size of the file to load is known, to decide on its final location. This can be useful for loading a CBFS file straight into CBMEM, for example. The new primitive is combined with cbfs_map() and cbfs_load() into a single underlying function that can handle all operations, to reduce the amount of code that needs to be duplicated (especially later when file verification is added). Also add a new variation that allows restraining or querying the CBFS type of a file as it is being loaded, and reorganize the documentation/definition of all these accessors and variations in the header file a little. Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: I5fe0645387c0e9053ad5c15744437940fc904392 Reviewed-on: https://review.coreboot.org/c/coreboot/+/49334 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2021-03-08cbfs: Pull handling of the CBFS_CACHE mem_pool into CBFS coreJulius Werner
This patch pulls control of the memory pool serving allocations from the CBFS_CACHE memlayout area into cbfs.c and makes it a core part of the CBFS API. Previously, platforms would independently instantiate this as part of boot_device_ro() (mostly through cbfs_spi.c). The new cbfs_cache pool is exported as a global so these platforms can still use it to directly back rdev_mmap() on their boot device, but the cbfs_cache can now also use it to directly make allocations itself. This is used to allow transparent decompression support in cbfs_map(). Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: I0d52b6a8f582a81a19fd0fd663bb89eab55a49d9 Reviewed-on: https://review.coreboot.org/c/coreboot/+/49333 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2021-03-08cbfs: Move trivial wrappers to static inlinesJulius Werner
The new CBFS API contains a couple of trivial wrappers that all just call the same base functions with slightly different predetermined arguments, and I'm planning to add several more of them as well. This patch changes these functions to become static inlines, and reorganizes the cbfs.h header a bit for better readability while I'm at it. Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: If0170401b2a70c158691b6eb56c7e312553afad1 Reviewed-on: https://review.coreboot.org/c/coreboot/+/49331 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2021-03-08cbfs: Reflow cbfs.c and cbfs.h to 96-character line lengthsJulius Werner
Doing this all in one go keeps the files consistent and should make future refactoring easier. Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: I4a701d24fc9ccd68dce8789aab15fd21964a55f9 Reviewed-on: https://review.coreboot.org/c/coreboot/+/49330 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2021-03-03lib/cbfs.c: Fix return value of failure to measureArthur Heymans
Returning an error on a failure to measure makes the system not bootable. Change-Id: Ifd20e543d3b30de045c0656eccdcc494c2fb10ce Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/51099 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Christian Walter <christian.walter@9elements.com>
2021-02-19memlayout: Store region sizes as separate symbolsJulius Werner
This patch changes the memlayout macro infrastructure so that the size of a region "xxx" (i.e. the distance between the symbols _xxx and _exxx) is stored in a separate _xxx_size symbol. This has the advantage that region sizes can be used inside static initializers, and also saves an extra subtraction at runtime. Since linker symbols can only be treated as addresses (not as raw integers) by C, retain the REGION_SIZE() accessor macro to hide the necessary typecast. Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: Ifd89708ca9bd3937d0db7308959231106a6aa373 Reviewed-on: https://review.coreboot.org/c/coreboot/+/49332 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2021-02-18lib: Add DDR5 DRAM typeSubrata Banik
TEST=Not seeing default msg "Defaulting to using DDR4 params." with this CL. Change-Id: Ib751396ec74b1491fd08b88b07462b315c4a152d Signed-off-by: Subrata Banik <subrata.banik@intel.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/50745 Reviewed-by: Furquan Shaikh <furquan@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2021-02-11lib/selfboot.c: Fix indentation and drop one newlineAngel Pons
Change-Id: Ica4254297f5d05e75f852d7e9a9e7bb833dfcea7 Signed-off-by: Angel Pons <th3fanbus@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/50397 Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Reviewed-by: Nico Huber <nico.h@gmx.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2021-02-10coreboot_table: Use precision when printing lb_gpio nameJulius Werner
The lb_gpio coreboot table entries use name fields fixed to 16 bytes. GCC will not allow creating a static initializer for such a field with a string of more than 16 characters... but exactly 16 characters is fine, meaning there's no room for the terminating NUL byte. The payloads (at least depthcharge) can deal with this as well because they're checking the size when looking at that table entry, but our printk("%16s") does not and will happily walk over the end until somewhere else in memory we finally find the next NUL byte. We should probably try to avoid strings of exactly 16 characters in this field anyway, just in case -- but since GCC doesn't warn about them they can easily slip back in. So solve this bug by also adding a precision field to the printk, which will make it stop overrunning the string. Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: Ifd7beef00d828f9dc2faa4747eace6ac4ca41899 Reviewed-on: https://review.coreboot.org/c/coreboot/+/49496 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Furquan Shaikh <furquan@google.com>
2021-02-09drivers/intel/fsp1_1,fsp2_0: Refactor logo displayKyösti Mälkki
Hide the detail of allocation from cbmem from the FSP. Loading of a BMP logo file from CBFS is not tied to FSP version and we do not need two copies of the code, move it under lib/. Change-Id: I909f2771af534993cf8ba99ff0acd0bbd2c78f04 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/50359 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2021-02-04src: Remove useless comments in "includes" linesElyes HAOUAS
Change-Id: Ide5673dc99688422c5078c8c28ca5935fd39c854 Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/50186 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2021-02-04coreboot_table: Move VBOOT_VBNV supportKyösti Mälkki
The guard changes from (CHROMEOS && PC80_SYSTEM) to VBOOT_VBNV_CMOS here. Change-Id: I653285c04e864aa6a3494ba1400787fa184ba187 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/50250 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Furquan Shaikh <furquan@google.com>
2021-02-04coreboot_table: Convert some CONFIG(CHROMEOS) preprocessorKyösti Mälkki
Change-Id: I0c42720fdcc3b05337af692ed93a424575defd36 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/48786 Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-by: Furquan Shaikh <furquan@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2021-02-04coreboot_table: Drop <vboot/misc.h> includeKyösti Mälkki
Could have been removed with commit 63b9700b2c already. Change-Id: Ie1083bce1794613c7dc683ae533e42fb5af39adf Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/50249 Reviewed-by: Furquan Shaikh <furquan@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2021-02-03src: Remove unused <cbmem.h>Elyes HAOUAS
Change-Id: I2279e2d7e6255a88953b2485c1f1a3b51a72c65e Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/50182 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2021-02-01lib/asan.c: Update SPDX licenseFrans Hendriks
lint-000-license-headers reports error. The SPDX identifier contains GPL-2.0 Update the identifier to GPL-2.0-only. BUG = N/A TEST = Build Intel Elkhart Lake Change-Id: If49fd014f14b481163bca6cd3131139b6d95c6d8 Signed-off-by: Frans Hendriks <fhendriks@eltan.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/50109 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2021-01-29stage_cache: Add resume_from_stage_cache()Kyösti Mälkki
Factor out the condition when an attempt to load stage from cache can be tried. Change-Id: I936f07bed6fc82f46118d217f1fd233e2e041405 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/50000 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2021-01-28arch/x86: Top-align .init in bootblockKyösti Mälkki
Link .init section near the end of bootblock program. It contains _start16bit, gdtptr and gdt that must be addressable from realmode, thus within top 64 KiB. Change-Id: If7b9737650362ac7cd82685cfdfaf18bd2429238 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/47970 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2021-01-25src/lib/: Remove "this file is part of" lineElyes HAOUAS
Change-Id: I9031dad52581e77aa56014b1fede884f2cdeb6de Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/49882 Reviewed-by: Felix Singer <felixsinger@posteo.net> Reviewed-by: Nico Huber <nico.h@gmx.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2021-01-24ACPI: Clean up GNVS initialisationKyösti Mälkki
With the common <soc/nvs.h> approach platform does not need to implement the common accessors or sizeof() function. Change-Id: I1050a252f765c763c1ae2d1610cbfb0d973ba026 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/49793 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2021-01-24lib/edid_fill_fb: Relax bits_per_pixel constraintRaul E Rangel
The Picasso VBIOS is not setting the reserved_mask_size correctly. This change relaxes the constraint to allow bpp_mask <= bits_per_pixel. This is how the code previously used to work before CB:39002. BUG=b:177094598, b:177422379 TEST=boot zork and see depthcharge working Signed-off-by: Raul E Rangel <rrangel@chromium.org> Change-Id: I2e67532fa949fbd673269d8d7f1c0d8af6124ac9 Reviewed-on: https://review.coreboot.org/c/coreboot/+/49404 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Yu-Ping Wu <yupingso@google.com>
2021-01-23ACPI S3: Replace stashed acpi_slp_typ valueKyösti Mälkki
We currently have a mixture of calls used to determine global ACPI S3 state. Reduce the boilerplate, ultimately acpi_wakeup_is_s3() should be the only to keep. Change-Id: Iff950d2bcf7eacbbdd40865abf62c35a2e8c3c69 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/47694 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2021-01-18lib/device_tree.c: Remove repeated wordElyes HAOUAS
Change-Id: Id5279587231c539bd3ffc75b75b29d88ef30e56a Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/49534 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Jacob Garber <jgarber1@ualberta.ca>
2021-01-18lib/ramtest: Fix ram_check() declarationsKyösti Mälkki
For a long time, second parameter 'stop' has been ignored. The tested range is within 1 MiB above 'start'. Change-Id: Icbf94cd6a651fbf0cd9aab97eb11f9b03f0c3c31 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/48561 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2021-01-18ACPI: Select ACPI_SOC_NVS only where suitableKyösti Mälkki
Having some symmetry with <soc/nvs.h> now allows to reduce the amount of gluelogic to determine the size and cbmc field of struct global_nvs. Since GNVS creation is now controlled by ACPI_SOC_NVS, drivers/amd/agesa/nvs.c becomes obsolete and soc/amd/cezanne cannot have this selected until <soc/nvs.h> exists. Change-Id: Ia9ec853ff7f5e7908f7e8fc179ac27d0da08e19d Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/49344 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Lance Zhao
2021-01-07arch/x86: Move prologue to .init sectionKyösti Mälkki
For arch/x86 the realmode part has to be located within the same 64 KiB as the reset vector. Some older intel platforms also require 4 KiB alignment for _start16bit. To enforce the above, and to separate required parts of .text without matching *(.text.*) rules in linker scripts, tag the pre-C environment assembly code with section .init directive. Description of .init section for ELF: This section holds executable instructions that contribute to the process initialization code. When a program starts to run, the system arranges to execute the code in this section before calling the main program entry point (called main for C programs). Change-Id: If32518b1c19d08935727330314904b52a246af3c Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/47599 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-12-31coreboot_table: Convert some CONFIG(CHROMEOS) preprocessorKyösti Mälkki
Change-Id: I1e63a419db92642df6b7956050c39540c2ae11d6 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/48781 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Patrick Rudolph <siro@das-labor.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-12-25ACPI: Allocate GNVS early in ramstageKyösti Mälkki
We need this to happen prior to SMM module loader. If there is some debugging output it's better they do not appear in the middle of CPU bringup. Change-Id: I45b4b5c0c5bf8bee258a465d1e364bfe98190e44 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/48697 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2020-12-22sb,soc/intel: Drop unnecessary headersKyösti Mälkki
Files under sb/ or soc/ should not have includes that tie those directly to external components like ChromeEC os ChromeOS vendorcode. Change-Id: Ib56eeedaa9d7422e221efa9c8480ed5e12024bca Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/48765 Reviewed-by: Michael Niewöhner <foss@mniewoehner.de> Reviewed-by: Patrick Rudolph <siro@das-labor.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-12-21drivers/tpm: Implement full PPIPatrick Rudolph
Implement the ACPI PPI interface as described in "TCG PC Client Physical Presence Interface Specification" Version 1.3. Add a new Kconfig that allows to use the full PPI instead of the stub version compiled in. This doesn't add code to execute the PPI request, as that's up to the payload with graphical UI support. Tested on GNU/Linux 5.6 using the sysfs interface at: /sys/class/tpm/tpm0/ppi/ Change-Id: Ifffe1d9b715e2c37568e1b009e86c298025c89ac Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/45568 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-12-17arch/arm: Replace .id section with build_info in CBFSKyösti Mälkki
For arch/arm[64], the offsets to board identification strings and CONFIG_ROM_SIZE inside .id were never really used; it was only a convenience to have the strings appear near the start of image. Add the same strings in an uncompressed file in CBFS. Change-Id: I35d3312336e9c66d657d2ca619cf30fd79e18fd4 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/47602 Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Julius Werner <jwerner@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-12-17drivers: Replace set_vbe_mode_info_validPatrick Rudolph
Currently it's not possible to add multiple graphics driver into one coreboot image. This patch series will fix this issue by providing a single API that multiple graphics driver can use. This is required for platforms that have two graphic cards, but different graphic drivers, like Intel+Aspeed on server platforms or Intel+Nvidia on consumer notebooks. The goal is to remove duplicated fill_fb_framebuffer(), the advertisment of multiple indepent framebuffers in coreboot tables, and better runtime/build time graphic configuration options. Replace set_vbe_mode_info_valid with fb_add_framebuffer_info or fb_new_framebuffer_info_from_edid. Change-Id: I95d1d62385a201c68c6c2527c023ad2292a235c5 Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/39004 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Hung-Te Lin <hungte@chromium.org>
2020-12-14src/lib: Add Kconfig option for SPD cache in FMAPMatt DeVillier
Currently, the option to cache DIMM SPD data in an FMAP region is closely coupled to a single board (google/hatch) and requires a custom FMAP to utilize. Loosen this coupling by introducing a Kconfig option which adds a correctly sized and aligned RW_SPD_CACHE region to the default FMAP. Add a Kconfig option for the region name, replacing the existing hard- coded instance in spd_cache.h. Change the inclusion of spd_cache.c to use this new Kconfig, rather than the board-specific one currently used. Lastly, have google/hatch select the new Kconfig when appropriate to ensure no change in current functionality. Test: build/boot WYVERN google/hatch variant with default FMAP, verify FMAP contains RW_SPD_CACHE, verify SPD cache used via cbmem log. Also tested on an out-of-tree Purism board. Change-Id: Iee0e7acb01e238d7ed354e3dbab1207903e3a4fc Signed-off-by: Matt DeVillier <matt.devillier@puri.sm> Reviewed-on: https://review.coreboot.org/c/coreboot/+/48520 Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Reviewed-by: Furquan Shaikh <furquan@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-12-14drivers: Replace multiple fill_lb_framebuffer with single instancePatrick Rudolph
Currently it's not possible to add multiple graphics drivers into one coreboot image. This patch series will fix this issue by providing a single API that multiple graphics drivers can use. This is required for platforms that have two graphic cards, but different graphic drivers, like Intel+Aspeed on server platforms or Intel+Nvidia on consumer notebooks. The goal is to remove duplicated fill_fb_framebuffer(), the advertisment of multiple independent framebuffers in coreboot tables, and better runtime/build time graphic configuration options. Replace all duplications of fill_fb_framebuffer and provide a single one in edid_fill_fb.c. Should not change the current behaviour as still only one graphic driver can be active at time. Change-Id: Ife507f7e7beaf59854e533551b4b87ea6980c1f4 Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/39003 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Frans Hendriks <fhendriks@eltan.com> Reviewed-by: Christian Walter <christian.walter@9elements.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-12-11lib/fmap: Add null parameters handlingJakub Czapiga
Prevent null-pointer access when passed as parameter. Signed-off-by: Jakub Czapiga <jacz@semihalf.com> Change-Id: Ie712d040b1c2383dcc8884e5f779c3591ccf0163 Reviewed-on: https://review.coreboot.org/c/coreboot/+/48531 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Paul Fagerburg <pfagerburg@chromium.org>
2020-12-11fw_config: Use UNDEFINED_FW_CONFIG to mean unprovisionedTim Wawrzynczak
A mainboard might want to configure some things differently when a device is in an unprovisioned state. In the case when fw_config comes from the Chromium EC, an unprovisioned device will not have a FW_CONFIG tag in its CBI. This patch will set the fw_config value to UNDEFINED_FW_CONFIG in the case of an error retrieving the value, as well as adding a function, `fw_config_is_provisioned()` to indicate the provisioning status. BUG=none TEST=remove fw_config from chromium EC CBI, add code to mainboard to print return value of fw_config_is_provisioned() (`0`), add fw_config back to CBI, run same test and see `1`. Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Change-Id: Ib3046233667e97a5f78961fabacbeb3099b3d442 Reviewed-on: https://review.coreboot.org/c/coreboot/+/47956 Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Nick Vaccaro <nvaccaro@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-12-10lib/edid_fill_fb: Support multiple framebuffersPatrick Rudolph
Currently it's not possible to add multiple graphics driver into one coreboot image. This patch series will fix this issue by providing a single API that multiple graphics driver can use. This is required for platforms that have two graphic cards, but different graphic drivers, like Intel and Aspeed on server platforms or Intel and Nvidia on consumer notebooks. The goals are to remove duplicated fill_fb_framebuffer(), to advertise multiple independent framebuffers in coreboot tables, and better runtime/build time graphic configuration options. Add an implementation in edid_fill_fb that supports registering multiple framebuffers, each with its own configuration. As the current code is only compiled for a single graphics driver there's no change in functionality. Change-Id: I7264c2ea2f72f36adfd26f26b00e3ce172133621 Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/39002 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Nico Huber <nico.h@gmx.de>
2020-12-09cbfs: Allow mcache to be found after the first lookupJulius Werner
This patch addresses the same problem as CB:48429, but hopefully this time correctly. Since the mcache is not guaranteed to be available on the first CBFS lookup for some special cases, we can no longer treat it as a one-time fire-and-forget initialization. Instead, we test cbd->mcache_size to check if the mcache has been initialized yet, and keep trying on every lookup if we don't find it the first time. Since the mcache is a hard requirement for TOCTOU safety, also make it more clear in Kconfig that configurations known to do CBFS accesses before CBMEM init are incompatbile with that, and make sure we die() rather than do something unsafe if there's a case that Kconfig didn't catch. Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: I4e01e9a9905f7dcba14eaf05168495201ed5de60 Reviewed-on: https://review.coreboot.org/c/coreboot/+/48482 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Christian Walter <christian.walter@9elements.com> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2020-12-09Revert "cbfs: Skip mcache in post-RAM stages before CBMEM is online"Julius Werner
This reverts commit b652aaef990cc3eb481dea7f8d4cc3eecd92ffa1. It was dumb and didn't actually fix anything. Change-Id: I074135dd12face1226105e0706c78ae8ecba18e0 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/48481 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Christian Walter <christian.walter@9elements.com> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2020-12-08cbfs: Skip mcache in post-RAM stages before CBMEM is onlineJulius Werner
There have been a few issues with the new CBFS mcache code in stages after romstage, where the mcache resides in CBMEM. In a few special cases the stage may be doing a CBFS lookup before calling cbmem_initialize(). To avoid breaking those cases, this patch makes the CBFS code fall back to a lookup from flash if CBMEM hasn't been reinitialized yet in those stages. Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: Icf6d1a1288cb243d0c4c893cc58251687e2873b0 Reviewed-on: https://review.coreboot.org/c/coreboot/+/48429 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2020-12-04cbfs: Add more error messages for lookupJulius Werner
The new CBFS stack will log messages for found files but leaves error messages up to the caller. This patch adds appropriate generic error messages to cbfs_lookup(), matching the behavior of the old CBFS stack for not found files. Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: I8cf44026accc03c466105d06683027caf1693ff0 Reviewed-on: https://review.coreboot.org/c/coreboot/+/48278 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Furquan Shaikh <furquan@google.com>
2020-12-03cbfs: Add verification for RO CBFS metadata hashJulius Werner
This patch adds the first stage of the new CONFIG_CBFS_VERIFICATION feature. It's not useful to end-users in this stage so it cannot be selected in menuconfig (and should not be used other than for development) yet. With this patch coreboot can verify the metadata hash of the RO CBFS when it starts booting, but it does not verify individual files yet. Likewise, verifying RW CBFSes with vboot is not yet supported. Verification is bootstrapped from a "metadata hash anchor" structure that is embedded in the bootblock code and marked by a unique magic number. This anchor contains both the CBFS metadata hash and a separate hash for the FMAP which is required to find the primary CBFS. Both are verified on first use in the bootblock (and halt the system on failure). The CONFIG_TOCTOU_SAFETY option is also added for illustrative purposes to show some paths that need to be different when full protection against TOCTOU (time-of-check vs. time-of-use) attacks is desired. For normal verification it is sufficient to check the FMAP and the CBFS metadata hash only once in the bootblock -- for TOCTOU verification we do the same, but we need to be extra careful that we do not re-read the FMAP or any CBFS metadata in later stages. This is mostly achieved by depending on the CBFS metadata cache and FMAP cache features, but we allow for one edge case in case the RW CBFS metadata cache overflows (which may happen during an RW update and could otherwise no longer be fixed because mcache size is defined by RO code). This code is added to demonstrate design intent but won't really matter until RW CBFS verification can be supported. Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: I8930434de55eb938b042fdada9aa90218c0b5a34 Reviewed-on: https://review.coreboot.org/c/coreboot/+/41120 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2020-12-03cbfs: Introduce cbfs_ro_map() and cbfs_ro_load()Julius Werner
This patch introduces two new CBFS API functions which are equivalent to cbfs_map() and cbfs_load(), respectively, with the difference that they always operate on the read-only CBFS region ("COREBOOT" FMAP section). Use it to replace some of the simple cases that needed to use cbfs_locate_file_in_region(). Change-Id: I9c55b022b6502a333a9805ab0e4891dd7b97ef7f Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/39306 Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Patrick Georgi <pgeorgi@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-12-02lib/trace: Remove TRACE supportKyösti Mälkki
Looks like the option is generally not compatible with garbage collections. Nothing gets inlined, for example is_smp_boot() no longer evaluates to constant false and thus the symbols from secondary.S would need to be present for the build to pass even if we set SMP=n. Also the addresses of relocatable ramstage are currently not normalised on the logs, so util/genprof would be unable dress those. Change-Id: I0b6f310e15e6f4992cd054d288903fea8390e5cf Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/45757 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Nico Huber <nico.h@gmx.de>
2020-12-02cbfs: Port cbfs_load() and cbfs_map() to new APIJulius Werner
This patch adapts cbfs_load() and cbfs_map() to use the new CBFS API directly, rather than through cbfs_boot_locate(). For cbfs_load() this means that attribute metadata does not need to be read twice. Change-Id: I754cc34b1c1471129e15475aa0f1891e02439a02 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/39305 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>