Add implementation to use actual requirements of ramstage size
for S3 resume backup in CBMEM. The backup covers complete pages of 4 KiB.
Only the required amount of low memory is backed up when ACPI_TINY_LOWMEM_BACKUP
is selected for the platform. Enable this option for AGESA and binaryPI, other
platforms (without RELOCATABLE_RAMSTAGE) currently keep their romstage ramstack
in low memory for s3 resume path.
Change-Id: Ide7ce013f3727c2928cdb00fbcc7e7e84e859ff1
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/15255
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Move old sockets to use romstage_legacy.c, these are ones
using intel/car/cache_as_ram.inc.
These will not be converted to RELOCATABLE_RAMSTAGE as boards
are candidates for getting dropped from the tree anyways.
Change-Id: I2616b4edee53446f1875711291e9dfed2911e2fb
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17280
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
All current implementations of ramstage_cache_invalid() were just
resetting the system based on the RESET_ON_INVALID_RAMSTAGE_CACHE
Kconfig option. Move that behavior to a single implementation
within prog_loaders.c which removes duplication.
Change-Id: I67aae73f9e1305732f90d947fe57c5aaf66ada9e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/17184
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Furquan Shaikh <furquan@google.com>
The CPU_MICROCODE_BLOB_CBFS_LOC should only be specified for COREBOOT CBFS,
not for other CBFS.
BUG=none
BRANCH=none
TEST=Built and boot kunimitsu
Change-Id: I58bb289e6c9add2647876ef817b7920f6e7b427a
Signed-off-by: Barnali Sarkar <barnali.sarkar@intel.com>
Reviewed-on: https://review.coreboot.org/16932
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
An epic battle to fix Nehalem finally ended when we found an odd mask
set in SMRR. This was caused by a wrong calculation of TSEG size. It
was assumed that TSEG spans the whole space between TSEG base
and GTT. This is wrong as TSEG base might have been aligned down.
TEST: On X201, copied 1GiB from usb key to sd-card and verified.
Change-Id: Id8c8a656446f092629fe2517f043e3c6d0f1b6b7
Found-by: Alexander Couzens, Nico Huber
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/16939
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
The datasheets "Intel® Core™ Duo Processor and Intel® Core™ Solo
Processor on 65 nm Process" mentions cpu C-states substates which can
either be attained by adding a substate hint to the MWAIT/P_LVLx request
or automatically by setting some msr bits correctly.
This just sets the same msr bits as model_6fx to enable
dynamic L2 cache, C2E and C4E acpi cpu states.
The result is that when limiting a thinkpad x60 with a yonah T2400
cpu to the acpi cpu C2 state, the idle power usage drops from 18W to
14W. When the lowest C-state is set to C4 the idle power usage seems
to remain similar.
Change-Id: I6c422656ace04659f32082a5944617eda6c79ec3
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/16901
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Replace the use of the old device_t definition inside
cpu/amd/model_fxx.
Change-Id: Iac7571956ed2fb927a6b8cc88514e533f40490d0
Signed-off-by: Antonello Dettori <dev@dettori.io>
Reviewed-on: https://review.coreboot.org/16437
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Replace the use of the old device_t definition inside
cpu/amd/family_10h-family_15h.
Change-Id: Ia1b155eeb7b67d94cf7aaa7789843a3e4ed3497a
Signed-off-by: Antonello Dettori <dev@dettori.io>
Reviewed-on: https://review.coreboot.org/16436
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Move the funtion to find most significant bit set(fms)
and function to find least significant bit set(fls) to a common
place. And remove the duplicates.
Change-Id: Ia821038b622d93e7f719c18e5ee3e8112de66a53
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-on: https://review.coreboot.org/16525
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Hardcoding the microcode filenames into the makefiles is great when
the microcode is in the blobs directory. When the microcode isn't
posted to the blobs directory, we need some method of supplying the
microcode binary into the build. This can of course be done manually
after the build has completed, as can be done with everything that
we're including in the ROM image. Instead of making life hard for
everyone though, let's just add a way to specify where the microcode
rom comes from.
BUG=chrome-os-partner:53013
Change-Id: I7c5127234809e8515906efa56c04af6005eecf0b
Signed-off-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://review.coreboot.org/16386
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Omar Pakker
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Provide a default value of 0 in drivers/spi as there weren't
default values aside from specific mainboards and arch/x86.
Remove any default 0 values while noting to keep the option's
default to 0.
BUG=chrome-os-partner:56151
Change-Id: If9ef585e011a46b5cd152a03e41d545b36355a61
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16192
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Martin Roth <martinroth@google.com>
Almost all boards and chipsets within the codebase assume or
use SPI flash as the boot device. Therefore, provide an option
for the boards/chipsets which don't currently support SPI flash
as the boot device. The default is to assume SPI flash is the
boot device unless otherwise instructed. This falls in line
with the current assumptions, but it also allows one to
differentiate a platform desiring SPI flash support while it not
being the actual boot device.
One thing to note is that while google/daisy does boot with SPI
flash part no SPI API interfaces were ever implemented. Therefore,
mark that board as not having a SPI boot device.
BUG=chrome-os-partner:56151
Change-Id: Id4e0b4ec5e440e41421fbb6d0ca2be4185b62a6e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16191
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
> Overrunning array "am335x_gpio_banks" of 4 4-byte elements at element
> index 4 (byte offset 16) using index "bank" (which evaluates to 4).
As the first index is 0, also error out if the index is equal the array
size.
Change-Id: I6b6b6e010348a58931bd546dfc54f08460e8dbbc
Found-by: Coverity (CID 1354615: Memory - illegal accesses (OVERRUN))
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-on: https://review.coreboot.org/16165
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Quark does not support the rdmsr and wrmsr instructions. In this case
use a SOC specific routine to support the setting of the MTRRs. Migrate
the code from FSP 1.1 to be x86 CPU common.
Since all rdmsr/wrmsr accesses are being converted, fix the build
failure for quark in lib/reg_script.c. Move the soc_msr_x routines and
their depencies from romstage/mtrr.c to reg_access.c.
TEST=Build and run on Galileo Gen2
Change-Id: Ibc68e696d8066fbe2322f446d8c983d3f86052ea
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/15839
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
XIP cachelines contain the executable to run, we never want
that to get modified. With the change such erronous writes
are ignored and next cacheline miss will fetch from boot
media (SPI / FWH flash).
Change-Id: I52b62866b5658e103281ffa1a91e1c64262f3175
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/15778
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
At this state, variable MTRRs are disabled. We overwrite this MTRR entry
before they are re-enabled.
Change-Id: Ieedf90f65514d848905626e75be496e08f710d91
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/15794
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The fixed MTRRs cover the range [0:1MiB). While calculating the
variable MTRR usage the 1MiB boundary is checked such that
an excessive number of MTRRs aren't used because of unnatural
alignment at the low end of the physical address space. Howevever,
those checks weren't inclusive of the 1MiB boundary. As such a
variable MTRR could be used for a range which is actually covered
by the fixed MTRRs when the end address is equal to 1MiB. Likewise,
if the starting address of the range lands on the 1MiB boundary
then more variable MTRRs are calculated in order to meet natural
alignment requirements.
Before:
MTRR: Physical address space:
0x0000000000000000 - 0x00000000000a0000 size 0x000a0000 type 6
0x00000000000a0000 - 0x0000000000100000 size 0x00060000 type 0
0x0000000000100000 - 0x000000007b800000 size 0x7b700000 type 6
0x000000007b800000 - 0x00000000b0000000 size 0x34800000 type 0
0x00000000b0000000 - 0x00000000c0000000 size 0x10000000 type 1
0x00000000c0000000 - 0x0000000100000000 size 0x40000000 type 0
0x0000000100000000 - 0x0000000180000000 size 0x80000000 type 6
CPU physical address size: 39 bits
MTRR: default type WB/UC MTRR counts: 7/17.
MTRR: WB selected as default type.
MTRR: 0 base 0x0000000000000000 mask 0x0000007ffff00000 type 0
MTRR: 1 base 0x000000007b800000 mask 0x0000007fff800000 type 0
MTRR: 2 base 0x000000007c000000 mask 0x0000007ffc000000 type 0
MTRR: 3 base 0x0000000080000000 mask 0x0000007fe0000000 type 0
MTRR: 4 base 0x00000000a0000000 mask 0x0000007ff0000000 type 0
MTRR: 5 base 0x00000000b0000000 mask 0x0000007ff0000000 type 1
MTRR: 6 base 0x00000000c0000000 mask 0x0000007fc0000000 type 0
After:
MTRR: Physical address space:
0x0000000000000000 - 0x00000000000a0000 size 0x000a0000 type 6
0x00000000000a0000 - 0x0000000000100000 size 0x00060000 type 0
0x0000000000100000 - 0x000000007b800000 size 0x7b700000 type 6
0x000000007b800000 - 0x00000000b0000000 size 0x34800000 type 0
0x00000000b0000000 - 0x00000000c0000000 size 0x10000000 type 1
0x00000000c0000000 - 0x0000000100000000 size 0x40000000 type 0
0x0000000100000000 - 0x0000000180000000 size 0x80000000 type 6
CPU physical address size: 39 bits
MTRR: default type WB/UC MTRR counts: 6/8.
MTRR: WB selected as default type.
MTRR: 0 base 0x000000007b800000 mask 0x0000007fff800000 type 0
MTRR: 1 base 0x000000007c000000 mask 0x0000007ffc000000 type 0
MTRR: 2 base 0x0000000080000000 mask 0x0000007fe0000000 type 0
MTRR: 3 base 0x00000000a0000000 mask 0x0000007ff0000000 type 0
MTRR: 4 base 0x00000000b0000000 mask 0x0000007ff0000000 type 1
MTRR: 5 base 0x00000000c0000000 mask 0x0000007fc0000000 type 0
BUG=chrome-os-partner:55504
Change-Id: I7feab38dfe135f5e596c9e67520378a406aa6866
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15780
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Since the socket layer is implemented with this CPU model, there
could potentially be multiple CPU models included. There can be
only one cache_as_ram include, so select it directly within
the socket directory.
Change-Id: Ia52bb152276eddfd1fb33ddb7f5d153ab8e8163c
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/15757
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Zero-filling memory below 1 MiB resets car_migrated variable so
any CAR GLOBALs are not addressed correctly for the remaining
time in romstage. Also there is no actual need to do this as
ramstage loader handles BSS.
This fixes regression with commit 70cd54310 that broke fam10 boards
with romstage spinlocks enabled.
Change-Id: I7418821997a980ae5b818bd57e8a1b6507a543af
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/15754
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
If CAR migration operations unintentionally set the lock,
BSP would have got stuck on printk() calls above already.
Change-Id: I35155ebcb00475a0964fc639ee74ad2755127740
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/15589
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
It is not possible for cbmem_add() to complete succesfully before
cbmem_recovery() is called. Adding more tables on S3 resume path
is also not possible.
Change-Id: Ic14857eeef2932562acee4a36f59c22ff4ca1a84
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/15472
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
