| Age | Commit message (Collapse) | Author |
|---|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
* 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>
|
|
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>
|
|
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>
|
|
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>
|
