diff options
| author | Subrata Banik <subratabanik@google.com> | 2023-03-22 00:35:42 +0530 |
|---|---|---|
| committer | Subrata Banik <subratabanik@google.com> | 2023-03-23 05:54:28 +0000 |
| commit | 30a011417fb227d8e1e78a6a47abd9ea332c00c7 (patch) | |
| tree | 7128644516e689030e23c97a5a35e50d2f5616c1 /src/soc/intel/common/basecode/ramtop/Kconfig | |
| parent | 3f57a783c0844c326e7c3567e837b4456c02f8d9 (diff) | |
soc/intel: Rename IA common code module from `TOM` to `RAMTOP`
This patch renames all references of `top_of_ram` (TOM) in IA common
`basecode` module (for example: functions, variables, Kconfig,
Makefile and comments) with `ramtop` aka top_of_ram to make it more
meaningful and to avoid conflicts with Intel SA chipset TOM registers.
BUG=Able to build and boot google/rex with the same ~49ms savings
in place.
Change-Id: Icfe6300a8e4c5761064537fb256cfecbe2afb2d8
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73881
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Diffstat (limited to 'src/soc/intel/common/basecode/ramtop/Kconfig')
| -rw-r--r-- | src/soc/intel/common/basecode/ramtop/Kconfig | 15 |
1 files changed, 15 insertions, 0 deletions
diff --git a/src/soc/intel/common/basecode/ramtop/Kconfig b/src/soc/intel/common/basecode/ramtop/Kconfig new file mode 100644 index 0000000000..2b600e7464 --- /dev/null +++ b/src/soc/intel/common/basecode/ramtop/Kconfig @@ -0,0 +1,15 @@ +config SOC_INTEL_COMMON_BASECODE_RAMTOP + bool + default n + help + Driver code to store the top_of_ram (RAMTOP) address into + non-volatile space (CMOS) during the first boot and use + it across all consecutive boot. + + Purpose of this driver code is to cache the RAMTOP (with a + fixed size) for all consecutive boots even before calling + into the FSP. Otherwise, this range remains un-cached until postcar + boot stage updates the MTRR programming. FSP-M and late romstage + uses this uncached RAMTOP range for various purposes and having the + ability to cache this range beforehand would help to optimize the boot + time (more than 50ms). |