summaryrefslogtreecommitdiffstats
path: root/src/lib
Commit message (Collapse)AuthorAgeFilesLines
* Move post_codes.h to commonlib/console/Ricardo Quesada2021-08-041-9/+9
| | | | | | | | | | | | | | | | | | | | | 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>
* arch/x86,lib/thread: Enable thread support in romstageRaul E Rangel2021-07-261-2/+6
| | | | | | | | | | | | | | | | | | | | 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>
* lib/thread,lib/hardwaremain: Lazy initialize threadsRaul E Rangel2021-07-262-2/+10
| | | | | | | | | | | | | | | 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>
* lib/thread,arch/x86: Move thread stacks into C bssRaul E Rangel2021-07-261-3/+6
| | | | | | | | | | | | | | | | 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>
* lib/thread: Add asserts around stack size and alignmentRaul E Rangel2021-07-261-0/+7
| | | | | | | | | | | | | `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>
* lib/thread: Guard thread_run_until with ENV_RAMSTAGERaul E Rangel2021-07-261-0/+4
| | | | | | | | | | | | | | | | 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>
* lib/cbfs,device/pci_rom: Move cbfs_boot_map_optionrom and modernizeRaul E Rangel2021-07-201-40/+0
| | | | | | | | | | | | | | | 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>
* lib/prog_loaders: Add payload_preloadRaul E Rangel2021-07-192-6/+63
| | | | | | | | | | | | | | 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>
* lib/hardwaremain: Drop boot_state_current_{block,unblock}()Raul E Rangel2021-07-181-10/+0
| | | | | | | | | | | | | | 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>
* lib/thread: Make thread_run not block the current stateRaul E Rangel2021-07-181-13/+1
| | | | | | | | | | | | | | | | | | | 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>
* lib/thread: Add thread_handleRaul E Rangel2021-07-181-16/+57
| | | | | | | | | | | | | | | | | 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>
* lib/thread: Add mutexRaul E Rangel2021-07-181-0/+20
| | | | | | | | | | | | | | | | 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>
* lib/thread: Rename thread_cooperate and thread_prevent_coopRaul E Rangel2021-07-181-3/+3
| | | | | | | | | | | | | | | | | 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>
* lib/thread: Allow nesting thread_cooperate and thread_prevent_coopRaul E Rangel2021-07-181-5/+11
| | | | | | | | | | | | | | | | 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>
* lib/thread: Clean up initialization sequenceRaul E Rangel2021-07-181-4/+3
| | | | | | | | | | | | | | | | | 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>
* lib/thread: Add thread_yield helper methodRaul E Rangel2021-07-181-0/+5
| | | | | | | | | | | | | | | | | | 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>
* lib/thread: Verify threads are initialized before yieldingRaul E Rangel2021-07-151-0/+7
| | | | | | | | | | | | | | | | | | | | | 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>
* selfboot: Add support for selfload in romstageShelley Chen2021-07-021-0/+8
| | | | | | | | | | | | | | | | | | | 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>
* nvs: Add Chrome OS NVS (CNVS) information to coreboot tablesFurquan Shaikh2021-06-181-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* ChromeOS: Separate NVS from global GNVSKyösti Mälkki2021-06-141-0/+4
| | | | | | | | | | 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>
* lib/hardwaremain: Print individual boot state callback durationsRaul E Rangel2021-06-141-0/+9
| | | | | | | | | | | | | | | | | | 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>
* lib/hardwaremain.c: Hide preprocessor guards in headerAngel Pons2021-06-141-4/+4
| | | | | | | | | | | | | | | | | | | | | | 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>
* drivers/pc80/mc146818rtc: Check date and time for sanityWerner Zeh2021-05-301-0/+1
| | | | | | | | | | | | | | | | | | | 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>
* lib/rtc: Add sanity check for time and dateWerner Zeh2021-05-301-0/+16
| | | | | | | | | | | | | 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>
* cbmem: Introduce "early" init hooks for consoleJulius Werner2021-05-272-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* lib/hexdump: remove hexdump32 and use hexdump insteadFelix Held2021-05-271-18/+0
| | | | | | | | | | | | | | | | 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>
* fw_config: Add helper function `fw_config_probe_dev`Furquan Shaikh2021-05-241-13/+28
| | | | | | | | | | | | | | | | | | 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: Return false in `fw_config_probe` in unprovisioned caseFurquan Shaikh2021-05-241-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* cbfs: Increase mcache size defaultsJulius Werner2021-05-141-11/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* include/console: Rename and update POST_ENTRY_RAMSTAGE postcodeSubrata Banik2021-05-121-1/+1
| | | | | | | | | | | | 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>
* src: Drop "This file is part of the coreboot project" linesAngel Pons2021-05-101-1/+0
| | | | | | | | | | | | 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>
* security/tpm: Add option to init TPM in bootblockArthur Heymans2021-05-061-0/+7
| | | | | | | | | | | | | 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>
* lib/coreboot_table.c: Remove unnecessary CPP useArthur Heymans2021-05-051-6/+5
| | | | | | | | 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>
* lib/espi_debug: Add espi_show_slave_peripheral_channel_configurationRaul E Rangel2021-04-231-0/+86
| | | | | | | | | | | | | | | | | | | | 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>
* commonlib/region: Turn addrspace_32bit into a more official APIJulius Werner2021-04-213-13/+9
| | | | | | | | | | | | | | | | | | | 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>
* lib/rtc: Fix incomplete leap year macroJakub Czapiga2021-04-191-1/+1
| | | | | | | | | 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>
* lib/rtc: Remove unnecessary year constraint in rtc_calc_weekdayJakub Czapiga2021-04-151-3/+0
| | | | | | | | | | | 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>
* decompressor: Add CBFS_VERIFICATION supportJulius Werner2021-04-065-4/+36
| | | | | | | | | | | | | | | | | | | | 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>
* cbfs: Add file data hashing for CONFIG_CBFS_VERIFICATIONJulius Werner2021-04-061-13/+48
| | | | | | | | | | | | | | 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>
* cbfs: Simplify cbfs_load_and_decompress() and stop exporting itJulius Werner2021-04-061-38/+21
| | | | | | | | | | | | | | | 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>
* lib: Add obvious definition for `calloc`Tim Wawrzynczak2021-04-061-1/+11
| | | | | | | | | | | 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>
* cbfs: Make `mdata` argument to cbfs_allocator_t constJulius Werner2021-04-052-3/+3
| | | | | | | | | | | | | | | | 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>
* coreboot_tables: Print strapping IDs when adding them to coreboot tableJulius Werner2021-04-021-1/+12
| | | | | | | | | | | | | 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>
* spd_bin: Replace get_spd_cbfs_rdev() with spd_cbfs_map()Julius Werner2021-03-171-8/+7
| | | | | | | | | | | | | | | | | | | 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>
* cbfs: Replace more instances of cbfs_boot_locate() with newer APIsJulius Werner2021-03-171-14/+6
| | | | | | | | | | | | | | 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>
* cbfs: Move stage header into a CBFS attributeJulius Werner2021-03-172-85/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* prog_loaders: Remove prog_locate()Julius Werner2021-03-171-17/+0
| | | | | | | | | | | | | | | | | 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>
* cbfs: Remove prog_locate() for payloads (SELF and FIT)Julius Werner2021-03-173-46/+35
| | | | | | | | | | | 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>
* cbfs: Remove prog_locate() for stages and rmodulesJulius Werner2021-03-163-25/+39
| | | | | | | | | | | | | | | | | | | | | | | | | 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>
* cbfs: Add cbfs_alloc() primitive and combine cbfs_load() and cbfs_map()Julius Werner2021-03-081-52/+65
| | | | | | | | | | | | | | | | | | | | 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>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-11 20:48:12 +0000