summaryrefslogtreecommitdiff
path: root/src/lib/Kconfig
AgeCommit message (Collapse)Author
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-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>
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-02cbfs: Enable CBFS mcache on most chipsetsJulius Werner
This patch flips the default of CONFIG_NO_CBFS_MCACHE so the feature is enabled by default. Some older chipsets with insufficient SRAM/CAR space still have it explicitly disabled. All others get the new section added to their memlayout... 8K seems like a sane default to start with. Change-Id: I0abd1c813aece6e78fb883f292ce6c9319545c44 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/38424 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Furquan Shaikh <furquan@google.com>
2020-11-21cbfs: Add metadata cacheJulius Werner
This patch adds a new CBFS "mcache" (metadata cache) -- a memory buffer that stores the headers of all CBFS files. Similar to the existing FMAP cache, this cache should reduce the amount of SPI accesses we need to do every boot: rather than having to re-read all CBFS headers from SPI flash every time we're looking for a file, we can just walk the same list in this in-memory copy and finally use it to directly access the flash at the right position for the file data. This patch adds the code to support the cache but doesn't enable it on any platform. The next one will turn it on by default. Change-Id: I5b1084bfdad1c6ab0ee1b143ed8dd796827f4c65 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/38423 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2020-09-23treewide: rename GENERIC_SPD_BIN to HAVE_SPD_BIN_IN_CBFSMichael Niewöhner
The name GENERIC_SPD_BIN doesn't reflect anymore what that config is used for, so rename it to HAVE_SPD_BIN_IN_CBFS. Change-Id: I4004c48da205949e05101039abd4cf32666787df Signed-off-by: Michael Niewöhner <foss@mniewoehner.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/45147 Reviewed-by: Felix Singer <felixsinger@posteo.net> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-09-08lib/Kconfig: Drop obsolete help text from GENERIC_SPD_BINMichael Niewöhner
SMBus code is linked unconditionally since commit 0e3c59e. This change drops that obsolete part from the help text. Change-Id: I603ab012760684021be1b5eca5d0ddff69463b79 Signed-off-by: Michael Niewöhner <foss@mniewoehner.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/45145 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2020-05-12espi: Add support for debug helper to print slave capabilitiesFurquan Shaikh
This change adds a Kconfig option to enable eSPI debugging that pulls in a helper function to print slave capabilities. BUG=b:153675913 Signed-off-by: Furquan Shaikh <furquan@google.com> Change-Id: I8ff250fe85dfa9370bf93ce3c7e2de5c069bf9e9 Reviewed-on: https://review.coreboot.org/c/coreboot/+/41254 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Raul Rangel <rrangel@chromium.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2019-11-19lib/fmap: Disable pre-RAM cache for FSP 1.0Julius Werner
Due to the way CAR teardown is handled in FSP 1.0, the results of car_get_var_ptr() aren't always reliable, which can break things when running with FMAP cache. It might be possible to fix this but would make the code rather complicated, so let's just disable the feature on these platforms and hope they die out soon. Also allow this option to be used by platforms that don't have space for the cache and want to save a little more code. Change-Id: I7ffb1b8b08a7ca3fe8d53dc827e2c8521da064c7 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/36937 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Werner Zeh <werner.zeh@siemens.com> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2019-11-10lib/Kconfig: Remove RAMSTAGE_CBMEM_TOP_ARGArthur Heymans
All targets now have the _cbmem_top_ptr symbol populated via calling arguments or in the nvidia/tegra210 case worked around by populating it with cbmem_top_chipset explicitly at the start of ramstage, so the Kconfig guarding this behavior can be removed. Change-Id: Ie7467629e58700e4d29f6e735840c22ed687f880 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/36422 Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Michael Niewöhner Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-11-01lib/cbmem_top: Add a common cbmem_top implementationArthur Heymans
This adds a common cbmem_top implementation to all coreboot target. In romstage a static variable will be used to cache the result of cbmem_top_romstage. In ramstage if CONFIG_RAMSTAGE_CBMEM_TOP_ARG is set a global variable needs to be populated by the stage entry with the value passed via the calling arguments. if CONFIG_RAMSTAGE_CBMEM_TOP_ARG is not set the same implementation as will be used as in romstage. Change-Id: Ie767542ee25483acc9a56785ce20a885e9a63098 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/36273 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2019-05-20src/Kconfig: Move DRAM section to src/lib/KconfigElyes HAOUAS
These Kconfigs are mostly used in src/lib/. Change-Id: I7aa5436c6ff5fef53fde2081e902d793f3581c1e Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/32882 Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2018-10-22reset: Provide new single-function reset APINico Huber
board_reset() replaces the existing common reset API. There is no common distinction between reset types across platforms, hence, common code could never decide which one to call. Currently only hard_reset() is used by common code. We replace these calls and provide a fall-back to the current hard_reset() implemen- tation. The fall-back will be removed along with hard_reset() after the transition of all boards. Change-Id: I274a8cee9cb38226b5a0bdff6a847c74ef0b3128 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/29047 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2018-04-30lib/devicetree: Integrate flattened devicetree supportPatrick Rudolph
* Adapt to coreboot coding style. * Use coreboot's endian conversion functions. * Fix header and header guards. * Get rid of unused functions. * Add Kconfig to build it on ramstage. * Replace size32 with ALIGN_UP and DIV_ROUND_UP. * Add NULL pointer checks * Convert constants to defines Required for Cavium's BDK and uImage FIT support. Change-Id: I6e6cd9f78fb402bd54d684097326d26eb78d552a Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-on: https://review.coreboot.org/25523 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2017-10-28lib: Prepare for libhwbase' generated config fileNico Huber
Add new libhwbase options and add a class for files generated during build. This follows the same pattern as for libgfxinit. Change-Id: Ie5b84992fa687e4e94b6d959a64086c638f66eb8 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/20626 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2017-09-28Kconfig: Move libhwbase related options into lib/KconfigNico Huber
More will follow so better move them where they are used. Also remove defaults and add dependencies to not clutter .config files up that don't have any of these options selected. Change-Id: I3a255c821cc26aeb66e4fd6adf7142d7e856f5ac Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/20625 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2017-05-30lib/edid: Split out fill_lb_framebuffer()Nico Huber
Place it into new edid_fill_fb.c, and invert the logic of the Kconfig guard (NATIVE_VGA_INIT_USE_EDID is now !NO_EDID_FILL_FB). It has to be selected by all drivers that use MAINBOARD_DO_NATIVE_VGA_INIT but pro- vide their own fill_lb_framebuffer() implementation. Change-Id: I90634b835bd8e2d150b1c714328a5b2774d891bd Signed-off-by: Nico Huber <nico.huber@secunet.com> Reviewed-on: https://review.coreboot.org/19764 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-12 04:20:25 +0000