summaryrefslogtreecommitdiff
path: root/src/lib/Kconfig
AgeCommit message (Collapse)Author
2024-02-18ec, lib, security, sb: Add SPDX license headers to Kconfig filesMartin Roth
Change-Id: Ie63499a4b432803a78af1c52d49e34cf1653ba17 Signed-off-by: Martin Roth <gaumless@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/80589 Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-01-11vc/google: Show different logos for different ChromeOS devicesShelley Chen
This commit adds support for showing different logos on the ChromeOS firmware splash screen based on the device model (between Chromebook-Plus and regular ChromeOS devices like Chromebook and Chromebox). This allows OEMs to customize the branding on their devices. This patch also introduces three new Kconfigs: - CHROMEOS_FW_SPLASH_SCREEN - CHROMEOS_LOGO_PATH - CHROMEBOOK_PLUS_LOGO_PATH which allow users to enable the fw splash screen feature in the vendorcode. Previously, we were using the BMP_LOGO Kconfig in drivers/intel/fsp2_0, but we didn't want the top level Kconfigs to be located inside the architecture specific files. BUG=b:317880956 BRANCH=None TEST=emerge-rex coreboot chromeos-bootimage verify that FW splash screen appears Change-Id: I56613d1e7e81e25b31ad034edae0f716c94c4960 Signed-off-by: Shelley Chen <shchen@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/79775 Reviewed-by: Kapil Porwal <kapilporwal@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
2023-12-14lib: ramdetect: Add Kconfig PROBE_RAMNaresh Solanki
Previously ramdetect.c was compiled only for VENDOR_EMULATION. Hence add Kconfig option PROBE_RAM which allows board outside the scope of VENDOR_EMULATION to select and utilize probe_ram function to runtime detect usable RAM in emulation environment. PROBE_RAM is default selected if VENDOR_EMULATION is set so that existing boards under VENDOR_EMULATION scope are not affected. Other boards can explicitly select PROBE_RAM to use probe_ram. TEST=Build mb/arm/rdn2 with PROBE_RAM selected & make sure there is no any error. Also checked qemu-aarch64 build to make sure build is success. Change-Id: Id909ddaee6958cfa8a6c263a11f9a90d94710aa7 Signed-off-by: Naresh Solanki <naresh.solanki@9elements.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/79450 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2022-12-17lib: Hook up libhwbase in romstageJeremy Compostella
It's hidden behind the configuration option `CONFIG_ROMSTAGE_LIBHWBASE'. This also adds some glue code to use the coreboot console for debug output and our monotonic timer framework as timer backend. Running Ada code in romstage and more particular libhwbase brings a few challenges as global initialized variables are not supported in Cache-As-Ram mode. 1. The libhwbase dynamic mmio driver implementation makes the Gnat compiler generate some global initialized variables. For this reason, when compiled for romstage or for romstage and ramstage the static mmio driver is enforced (`HWBASE_STATIC_MMIO'). 2. The Gnat compiler generates elaboration functions to initialize program data at runtime. These elaboration functions are called by the romstage_adainit() function. The data references symbols suffixed by `_E'. Even though these symbols, at compilation time, do not contain any data and are filled with zeros, the Gnat compiler installs them in the .data section. Since these symbols are actually filled with zeros, it is safe to install them in the .bss section. cf. https://docs.adacore.com/gnat_ugn-docs/html/gnat_ugn/gnat_ugn/elaboration_order_handling_in_gnat.html#elaboration-code This patch requires the libhwbase https://review.coreboot.org/c/libhwbase/+/69854 CL. BUG=b:252792591 BRANCH=firmware-brya-14505.B TEST=libhwbae compiles for romstage and loads successfully Change-Id: I670249d33506e886a683e55d1589cb2bf9b16aa3 Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/70275 Reviewed-by: Boris Mittelberg <bmbm@google.com> Reviewed-by: Nick Vaccaro <nvaccaro@google.com> Reviewed-by: Tarun Tuli <taruntuli@google.com> Reviewed-by: Zhixing Ma <zhixing.ma@intel.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2022-12-17Add option to use Ada code in romstageJeremy Compostella
If selected, libgnat is linked into romstage. In addition, a call to romstage_adainit() is added to support Ada program data initialization. BUG=b:252792591 BRANCH=firmware-brya-14505.B TEST=Ada code compiles for romstage and loads successfully Change-Id: I74f0460f6b14fde2b4bd6391e1782b2e5b217707 Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/70274 Reviewed-by: Tarun Tuli <taruntuli@google.com> Reviewed-by: Nick Vaccaro <nvaccaro@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2022-10-12lib/lzma: Build the source for decompression with flag -OfastZheng Bao
The decompression is critical for speed of boot. So we sacrifice some generated code size to optimize for speed. This change speeds up the LZMA decompression between 3% and 6% at a cost of just over 2k of additional code space. BUG=b:223985641 TEST=Majolica The test is done on Majolica and the result is listed below. Time saved: We tested the boot time with each flag for 10 times. The duration of each decompression process is listed as below. Load FSP-M Load ramstage Load payload Ofast Os Ofast Os Ofast Os ------------------------------------------ 62543 62959 20585 22458 9945 10626 62548 62967 20587 22461 9951 10637 62560 62980 20588 22478 9951 10641 62561 62988 20596 22478 9954 10643 62569 62993 20596 22479 9954 10643 62574 63000 20605 22492 9958 10647 62575 63026 20615 22495 9959 10647 62576 63038 20743 22614 9960 10647 62587 63044 20758 22625 9961 10647 62592 63045 20769 22637 9961 10647 ----------------------------------------- average 62568 63004 20644 22521 9955 10642 (unit: microseconds) Size sacrificed: The size of object file with -Os: ./build/ramstage/lib/lzmadecode.o: file format elf32-i386 4 .text.LzmaDecode 00000d84 00000000 00000000 00000076 2**0 CONTENTS, ALLOC, LOAD, READONLY, CODE The size of object file with -Ofast: ./build/ramstage/lib/lzmadecode.o: file format elf32-i386 4 .text.LzmaDecode 00001719 00000000 00000000 00000080 2**4 CONTENTS, ALLOC, LOAD, READONLY, CODE (Output by running "objdump -h ./build/ramstage/lib/lzmadecode.o") We can see that size is increased from 3460 bytes to 5913 bytes, a change of 2453 bytes or 171%. Change-Id: Ie003164e2e93ba8ed3ccd207f3af31c6acf1c5e2 Signed-off-by: Zheng Bao <fishbaozi@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/66392 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
2021-11-16lib/prog_loaders, soc/amd/: Make payload_preload use cbfs_preloadRaul E Rangel
Now that CBFS has this functionality built in, we no longer need to manually code it. payload_preload used to use the payload_preload_cache region to store the raw payload contents. This region was placed outside the firmware reserved region, so it was available for use by the OS. This was possible because the payload isn't loaded again on S3 resume. cbfs_preload only uses the cbfs_cache region. This region must be reserved because it gets used on the S3 resume path. Unfortunately this means that cbfs_cache must be increased to hold the payload. Cezanne is the only platform currently using payload_preload, and the size of cbfs_cache has already been adjusted. In the future we could look into adding an option to cbfs_preload that would allow it to use a different memory pool for the cache allocation. BUG=b:179699789 TEST=Boot guybrush and verify preloading the payload was successful CBFS DEBUG: get_preload_rdev(name='fallback/payload') preload successful Signed-off-by: Raul E Rangel <rrangel@chromium.org> Change-Id: Idc521b238620ff52b8ba481cd3c10e5c4f1394bd Reviewed-on: https://review.coreboot.org/c/coreboot/+/58962 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
2021-11-10Rename ECAM-specific MMCONF KconfigsShelley Chen
Currently, the MMCONF Kconfigs only support the Enhanced Configuration Access mechanism (ECAM) method for accessing the PCI config address space. Some platforms have a different way of mapping the PCI config space to memory. This patch renames the following configs to make it clear that these configs are ECAM-specific: - NO_MMCONF_SUPPORT --> NO_ECAM_MMCONF_SUPPORT - MMCONF_SUPPORT --> ECAM_MMCONF_SUPPORT - MMCONF_BASE_ADDRESS --> ECAM_MMCONF_BASE_ADDRESS - MMCONF_BUS_NUMBER --> ECAM_MMCONF_BUS_NUMBER - MMCONF_LENGTH --> ECAM_MMCONF_LENGTH Please refer to CB:57861 "Proposed coreboot Changes" for more details. BUG=b:181098581 BRANCH=None TEST=./util/abuild/abuild -p none -t GOOGLE_KOHAKU -x -a -c max Make sure Jenkins verifies that builds on other boards Change-Id: I1e196a1ed52d131a71f00cba1d93a23e54aca3e2 Signed-off-by: Shelley Chen <shchen@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/57333 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
2021-11-04lib/cbfs: Add cbfs_preload()Raul E Rangel
This API will hide all the complexity of preloading a CBFS file. It makes it so the callers simply specify the file to preload and CBFS takes care of the rest. It will start a new thread to read the file into the cbfs_cache. When the file is actually required (i.e., cbfs_load, etc) it will wait for the preload thread to complete (if it hasn't already) and perform verification/decompression using the preloaded buffer. This design allows decompression/verification to happen in the main BSP thread so that timestamps are correctly reflected. BUG=b:179699789 TEST=Test with whole CL chain, verify VGA bios was preloaded and boot time was reduced by 12ms. Logs: Preloading VGA ROM CBFS DEBUG: _cbfs_preload(name='pci1002,1638.rom', force_ro=false) CBFS: Found 'pci1002,1638.rom' @0x20ac40 size 0xd800 in mcache @0xcb7dd0f0 spi_dma_readat_dma: start: dest: 0x021c0000, source: 0x51cc80, size: 55296 took 0 us to acquire mutex start_spi_dma_transaction: dest: 0x021c0000, source: 0x51cc80, remaining: 55296 ... spi_dma_readat_dma: end: dest: 0x021c0000, source: 0x51cc80, remaining: 0 ... CBFS DEBUG: _cbfs_alloc(name='pci1002,1638.rom', alloc=0x00000000(0x00000000), force_ro=false, type=-1) CBFS: Found 'pci1002,1638.rom' @0x20ac40 size 0xd800 in mcache @0xcb7dd0f0 waiting for thread took 0 us CBFS DEBUG: get_preload_rdev(name='pci1002,1638.rom', force_ro=false) preload successful In CBFS, ROM address for PCI: 03:00.0 = 0x021c0000 PCI expansion ROM, signature 0xaa55, INIT size 0xd800, data ptr 0x01b0 PCI ROM image, vendor ID 1002, device ID 1638, PCI ROM image, Class Code 030000, Code Type 00 Copying VGA ROM Image from 0x021c0000 to 0xc0000, 0xd800 bytes $ cbmem ... 40:device configuration 5,399,404 (8,575) 65:Option ROM initialization 5,403,474 (4,070) 66:Option ROM copy done 5,403,488 (14) ... Signed-off-by: Raul E Rangel <rrangel@chromium.org> Change-Id: I879fc1316f97417a4b82483d353abdbd02b98a31 Reviewed-on: https://review.coreboot.org/c/coreboot/+/56491 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2021-11-04lib/cbfs: Add CBFS_CACHE_ALIGN Kconfig optionRaul E Rangel
This option will allow platforms to set the alignment of the cbfs_cache buffers. BUG=b:179699789 TEST=gdb -ex 'p cbfs_cache' /tmp/coreboot/guybrush/cbfs/fallback/ramstage.debug $1 = {buf = 0x0, size = 0, alignment = 8, last_alloc = 0x0, second_to_last_alloc = 0x0, free_offset = 0} Signed-off-by: Raul E Rangel <rrangel@chromium.org> Change-Id: I74598d4bcbca9a01cc8c65012d7e4ae341d052b1 Reviewed-on: https://review.coreboot.org/c/coreboot/+/58706 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-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-14 15:16:25 +0000