diff options
author | Julius Werner <jwerner@chromium.org> | 2021-05-12 15:59:58 -0700 |
---|---|---|
committer | Julius Werner <jwerner@chromium.org> | 2021-05-14 00:35:46 +0000 |
commit | 40acfe7f77304386fa1835faab8d0cd1a132deb6 (patch) | |
tree | efe8ff943d0939e2b466e594e04b5c2282081b94 /src/lib | |
parent | 0d37fcb0040ab27ce8a3ee59224aa3389e5f57b4 (diff) |
cbfs: Increase mcache size defaults
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>
Diffstat (limited to 'src/lib')
-rw-r--r-- | src/lib/Kconfig | 11 |
1 files changed, 0 insertions, 11 deletions
diff --git a/src/lib/Kconfig b/src/lib/Kconfig index e1d56fe26b..239f613470 100644 --- a/src/lib/Kconfig +++ b/src/lib/Kconfig @@ -98,14 +98,3 @@ config NO_CBFS_MCACHE the associated CAR/SRAM size. In that case every single CBFS file lookup must re-read the same CBFS directory entries from flash to find the respective file. - -config CBFS_MCACHE_RW_PERCENTAGE - int - depends on VBOOT && !NO_CBFS_MCACHE - default 25 if CHROMEOS # Chrome OS stores many L10n files in RO only - default 50 - help - The amount of the CBFS_MCACHE area that's used for the RW CBFS, in - percent from 0 to 100. The remaining area will be used for the RO - CBFS. Default is an even 50/50 split. When VBOOT is disabled, this - will automatically be 0 (meaning the whole MCACHE is used for RO). |