The haswell patches that verified correctly were not yet submitted,
but verified correctly. However they still used romcc_io.h which was
dropped in another patch earlier today.
With a lot of development happening in parallel, this is
unfortunately nothing that the gerrit 2.6 Rebase If Necessary submit
type could have fixed.
Change-Id: Ifef9ae05b22c408e78d6cff37defd68e4ed91ed9
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2876
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
Changes:
- Get rid of the E350M1 mainboard specific code and use the
platform generic function wrapper that was added in change
http://review.coreboot.org/#/c/2497/
AMD f14: Add SPD read functions to wrapper code
- Move DIMM addresses into devicetree.cb
- Add the ASF init that used to be in the SPD read code into
mainboard_enable()
Notes:
- The DIMM reads only happen in romstage, so the function is not
available in ramstage. Point the read-SPD callback to a generic
function in ramstage.
Change-Id: I08c2aebc62facc14f94400ee1ad188901ba73f19
Signed-off-by: Jens Rottmann <JRottmann@LiPPERTembedded.de>
Reviewed-on: http://review.coreboot.org/2875
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Changes:
- Get rid of the LiPPERT FrontRunner-AF and Toucan-AF mainboard
specific code and use the platform generic function wrapper that
was added in change
http://review.coreboot.org/#/c/2497/
AMD f14: Add SPD read functions to wrapper code
- Move DIMM addresses into devicetree.cb
- Add the ASF init that used to be in the SPD read code into
mainboard_enable()
Notes:
- The DIMM reads only happen in romstage, so the function is not
available in ramstage. Point the read-SPD callback to a generic
function in ramstage.
Change-Id: I4ee5e1bc34f4caee20615c48248d4f7605c09377
Signed-off-by: Jens Rottmann <JRottmann@LiPPERTembedded.de>
Reviewed-on: http://review.coreboot.org/2874
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
This adds a test case for using CBFS images that reside in RAM
and a Makefile to run it (and maybe other tests in the future).
The test concerns an issue in libcbfs when using x86 style CBFS
images in non-canonical locations (eg. when loading CBFS images
for processing).
Use with "make run" inside the tests directory.
Change-Id: I1af3792a1451728ff9594ba7f0410027cdecb59d
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/2623
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
When calculating initial CBFS empty entry space, the size of header itself must
be not included (with the reserved space for entry name). This is a regression
of the old cbfstool size bug.
Before this fix, in build process we see:
OBJCOPY cbfs/fallback/romstage_null.bin
W: CBFS image was created with old cbfstool with size bug.
Fixing size in last entry...
And checking the output binary:
cbfstool build/coreboot.pre1 print -v -v
DEBUG: read_cbfs_image: build/coreboot.pre1 (262144 bytes)
DEBUG: x86sig: 0xfffffd30, offset: 0x3fd30
W: CBFS image was created with old cbfstool with size bug.
Fixing size in last entry...
DEBUG: Last entry has been changed from 0x3fd40 to 0x3fd00.
coreboot.pre1: 256 kB, bootblksz 688, romsize 262144, offset 0x0 align: 64
Name Offset Type Size
(empty) 0x0 null 261296
DEBUG: cbfs_file=0x0, offset=0x28, content_address=0x28+0x3fcb0
After this fix, no more alerts in build process.
Verified to build successfully on x86/qemu and arm/snow configurations.
Change-Id: I35c96f4c10a41bae671148a0e08988fa3bf6b7d3
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2731
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
coreboot tables are, unlike general system tables, a platform
independent concept. Hence, use the same code for coreboot table
generation on all platforms. lib/coreboot_tables.c is based
on the x86 version of the file, because some important fixes
were missed on the ARMv7 version lately.
Change-Id: Icc38baf609f10536a320d21ac64408bef44bb77d
Signed-off-by: Stefan Reinauer <reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/2863
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
It's helpful to switch back and forth for developer and
recovery settings while testing boards. The wtm2 board
currently doesn't have gpios which dynamically seelect that.
Might as well make it easy to change the value for each
setting with one define. The original defaults are kept.
Change-Id: I7b928c592fd20a1b847e4733f4cdef09d6ddad4c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2861
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The coreboot include were not being passed correctly when
building vboot_reference. The paths being included were of the
src/<dir> form. However, vboot_reference lives in
src/../vboot_reference. That coupled with the recursive make
call made vboot_reference not see coreboot's header files.
Fix this by appending ../ to coreboot's default include paths.
Change-Id: I73949c6f854ecfce77ac36bb995918d51f91445e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2860
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The vboot_handoff structure contians the VbInitParams as well as the
shared vboot data. In order for the boot loader to find it, the
structure address and size needs to be obtained from the coreboot
tables.
Change-Id: I6573d479009ccbf373a7325f861bebe8dc9f5cf8
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2857
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Take the vboot path in romstage. This will complete the haswell
support for vboot firmware selection.
Built and booted. Noted firmware select worked on an image with
RW firmware support. Also checked that recovery mode worked as
well by choosing the RO path.
Change-Id: Ie2b0a34e6c5c45e6f0d25f77a5fdbaef0324cb09
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2856
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The get_write_protect_state() function was added to the
chromeos API that needs to be supported by the boards.
Implement this support.
Built and booted. Noted firmware select worked on an image with
RW firmware support. Also checked that recovery mode worked as
well by choosing the RO path.
Change-Id: Ifd213be25304163fc61d153feac4f5a875a40902
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2855
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This patch implements support for vboot firmware selection. The vboot
support is comprised of the following pieces:
1. vboot_loader.c - this file contains the entry point,
vboot_verify_firmware(), for romstage to call in order to perform
vboot selection. The loader sets up all the data for the wrapper
to use.
2. vboot_wrapper.c - this file contains the implementation calling the vboot
API. It calls VbInit() and VbSelectFirmware() with the data supplied
by the loader.
The vboot wrapper is compiled and linked as an rmodule and placed in
cbfs as 'fallback/vboot'. It's loaded into memory and relocated just
like the way ramstage would be. After being loaded the loader calls into
wrapper. When the wrapper sees that a given piece of firmware has been
selected it parses firmware component information for a predetermined
number of components.
Vboot result information is passed to downstream users by way of the
vboot_handoff structure. This structure lives in cbmem and contains
the shared data, selected firmware, VbInitParams, and parsed firwmare
components.
During ramstage there are only 2 changes:
1. Copy the shared vboot data from vboot_handoff to the chromeos acpi
table.
2. If a firmware selection was made in romstage the boot loader
component is used for the payload.
Noteable Information:
- no vboot path for S3.
- assumes that all RW firmware contains a book keeping header for the
components that comprise the signed firmware area.
- As sanity check there is a limit to the number of firmware components
contained in a signed firmware area. That's so that an errant value
doesn't cause the size calculation to erroneously read memory it
shouldn't.
- RO normal path isn't supported. It's assumed that firmware will always
load the verified RW on all boots but recovery.
- If vboot requests memory to be cleared it is assumed that the boot
loader will take care of that by looking at the out flags in
VbInitParams.
Built and booted. Noted firmware select worked on an image with
RW firmware support. Also checked that recovery mode worked as well
by choosing the RO path.
Change-Id: I45de725c44ee5b766f866692a20881c42ee11fa8
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2854
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
For completeness add a vboot rmodule type since vboot will be
built as an rmodule.
Change-Id: I4b9b1e6f6077f811cafbb81effd4d082c91d4300
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2853
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The vboot firmware selection from romstage will need to
pass the resulting vboot data to other consumers. This will
be done using a cbmem entry.
Change-Id: I497caba53f9f3944513382f3929d21b04bf3ba9e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2851
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Convert the existing haswell code to support reloctable ramstage
to use dynamic cbmem. This patch always selects DYNAMIC_CBMEM as
this option is a hard requirement for relocatable ramstage.
Aside from converting a few new API calls, a cbmem_top()
implementation is added which is defined to be at the begining of the
TSEG region. Also, use the dynamic cbmem library for allocating a
stack in ram for romstage after CAR is torn down.
Utilizing dynamic cbmem does mean that the cmem field in the gnvs
chromeos acpi table is now 0. Also, the memconsole driver in the kernel
won't be able to find the memconsole because the cbmem structure
changed.
Change-Id: I7cf98d15b97ad82abacfb36ec37b004ce4605c38
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2850
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Dynamic cbmem is now a requirement for relocatable ramstage.
This patch replaces the reserve_* fields in the romstage_handoff
structure by using the dynamic cbmem library.
The haswell code is not moved over in this commit, but it should be
safe because there is a hard requirement for DYNAMIC_CBMEM when using
a reloctable ramstage.
Change-Id: I59ab4552c3ae8c2c3982df458cd81a4a9b712cc2
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2849
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Here's the great news: From now on you don't have to worry about
hitting the right io.h include anymore. Just forget about romcc_io.h
and use io.h instead. This cleanup has a number of advantages, like
you don't have to guard device/ includes for SMM and pre RAM
anymore. This allows to get rid of a number of ifdefs and will
generally make the code more readable and understandable.
Potentially in the future some of the code in the io.h __PRE_RAM__
path should move to device.h or other device/ includes instead,
but that's another incremental change.
Change-Id: I356f06110e2e355e9a5b4b08c132591f36fec7d9
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2872
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This patch fixes an issue for rmodules which are copied into memory
at the final load/link location. If the bss section is cleared for
that rmodule the relocation could not take place properly since the
relocation information was wiped by act of clearing the bss. The
reason is that the relocation information resides at the same
address as the bss section. Correct this issue by performing the
relocation before clearing the bss.
Change-Id: I01a124a8201321a9eaf6144c743fa818c0f004b4
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2822
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
This patch adds a parallel implementation of cbmem that supports
dynamic sizing. The original implementation relied on reserving
a fixed-size block of memory for adding cbmem entries. In order to
allow for more flexibility for adding cbmem allocations the dynamic
cbmem infrastructure was developed as an alternative to the fixed block
approach. Also, the amount of memory to reserve for cbmem allocations
does not need to be known prior to the first allocation.
The dynamic cbmem code implements the same API as the existing cbmem
code except for cbmem_init() and cbmem_reinit(). The add and find
routines behave the same way. The dynamic cbmem infrastructure
uses a top down allocator that starts allocating from a board/chipset
defined function cbmem_top(). A root pointer lives just below
cbmem_top(). In turn that pointer points to the root block which
contains the entries for all the large alloctations. The corresponding
block for each large allocation falls just below the previous entry.
It should be noted that this implementation rounds all allocations
up to a 4096 byte granularity. Though a packing allocator could
be written for small allocations it was deemed OK to just fragment
the memory as there shouldn't be that many small allocations. The
result is less code with a tradeoff of some wasted memory.
+----------------------+ <- cbmem_top()
| +----| root pointer |
| | +----------------------+
| | | |--------+
| +--->| root block |-----+ |
| +----------------------+ | |
| | | | |
| | | | |
| | alloc N |<----+ |
| +----------------------+ |
| | | |
| | | |
\|/ | alloc N + 1 |<-------+
v +----------------------+
In addition to preserving the previous cbmem API, the dynamic
cbmem API allows for removing blocks from cbmem. This allows for
the boot process to allocate memory that can be discarded after
it's been used for performing more complex boot tasks in romstage.
In order to plumb this support in there were some issues to work
around regarding writing of coreboot tables. There were a few
assumptions to how cbmem was layed out which dictated some ifdef
guarding and other runtime checks so as not to incorrectly
tag the e820 and coreboot memory tables.
The example shown below is using dynamic cbmem infrastructure.
The reserved memory for cbmem is less than 512KiB.
coreboot memory table:
0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES
1. 0000000000001000-000000000002ffff: RAM
2. 0000000000030000-000000000003ffff: RESERVED
3. 0000000000040000-000000000009ffff: RAM
4. 00000000000a0000-00000000000fffff: RESERVED
5. 0000000000100000-0000000000efffff: RAM
6. 0000000000f00000-0000000000ffffff: RESERVED
7. 0000000001000000-000000007bf80fff: RAM
8. 000000007bf81000-000000007bffffff: CONFIGURATION TABLES
9. 000000007c000000-000000007e9fffff: RESERVED
10. 00000000f0000000-00000000f3ffffff: RESERVED
11. 00000000fed10000-00000000fed19fff: RESERVED
12. 00000000fed84000-00000000fed84fff: RESERVED
13. 0000000100000000-00000001005fffff: RAM
Wrote coreboot table at: 7bf81000, 0x39c bytes, checksum f5bf
coreboot table: 948 bytes.
CBMEM ROOT 0. 7bfff000 00001000
MRC DATA 1. 7bffe000 00001000
ROMSTAGE 2. 7bffd000 00001000
TIME STAMP 3. 7bffc000 00001000
ROMSTG STCK 4. 7bff7000 00005000
CONSOLE 5. 7bfe7000 00010000
VBOOT 6. 7bfe6000 00001000
RAMSTAGE 7. 7bf98000 0004e000
GDT 8. 7bf97000 00001000
ACPI 9. 7bf8b000 0000c000
ACPI GNVS 10. 7bf8a000 00001000
SMBIOS 11. 7bf89000 00001000
COREBOOT 12. 7bf81000 00008000
And the corresponding e820 entries:
BIOS-e820: [mem 0x0000000000000000-0x0000000000000fff] type 16
BIOS-e820: [mem 0x0000000000001000-0x000000000002ffff] usable
BIOS-e820: [mem 0x0000000000030000-0x000000000003ffff] reserved
BIOS-e820: [mem 0x0000000000040000-0x000000000009ffff] usable
BIOS-e820: [mem 0x00000000000a0000-0x00000000000fffff] reserved
BIOS-e820: [mem 0x0000000000100000-0x0000000000efffff] usable
BIOS-e820: [mem 0x0000000000f00000-0x0000000000ffffff] reserved
BIOS-e820: [mem 0x0000000001000000-0x000000007bf80fff] usable
BIOS-e820: [mem 0x000000007bf81000-0x000000007bffffff] type 16
BIOS-e820: [mem 0x000000007c000000-0x000000007e9fffff] reserved
BIOS-e820: [mem 0x00000000f0000000-0x00000000f3ffffff] reserved
BIOS-e820: [mem 0x00000000fed10000-0x00000000fed19fff] reserved
BIOS-e820: [mem 0x00000000fed84000-0x00000000fed84fff] reserved
BIOS-e820: [mem 0x0000000100000000-0x00000001005fffff] usable
Change-Id: Ie3bca52211800a8652a77ca684140cfc9b3b9a6b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2848
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Change "ERROR" to "WARNING" -- not finding the indicated file is usually
not a fatal error.
Change-Id: I0600964360ee27484c393125823e833f29aaa7e7
Signed-off-by: Shawn Nematbakhsh <shawnn@google.com>
Reviewed-on: http://review.coreboot.org/2833
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Using the CPU microcode update script and
Intel's Linux* Processor Microcode Data File
from 2013-02-22
Change-Id: I9bb60bdc46f69db85487ba923e62315f6e5352f9
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2845
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Using the CPU microcode update script and
Intel's Linux* Processor Microcode Data File
from 2013-02-22
Change-Id: Icaf0e39978daa9308cc2f0c4856d99fb6b7fdffa
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2844
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
for latest URL of their microcode tar ball
Change-Id: I3da2bdac4b2ca7d3f48b20ed389f6a47275d24fe
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2842
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Force link speed on these platforms to 3 Gbps to defeat buggy SATA
drives.
Change-Id: Ia38a7c486fb1f4469cd67ca5244bbf61f877d556
Signed-off-by: Shawn Nematbakhsh <shawnn@google.com>
Reviewed-on: http://review.coreboot.org/2823
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The standard string functions memcmp(), memset(), and memcpy()
are needed by most programs. The rmodules class provides a way to
build objects for the rmodules class. Those programs most likely need
the string functions. Therefore provide those standard functions to
be used by any generic rmodule program.
Change-Id: I2737633f03894d54229c7fa7250c818bf78ee4b7
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2821
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This configures power management registers according to
the 1.2.0 reference code drop. There are many inconsistencies
with the documentation and I tried to note those with ?.
This does not do the same for LynxPoint-H yet.
Change-Id: I9b8f5c24a8b0931075a44398571c9b0d54cce6a6
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/2819
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This uses the new helper function added earlier.
Change-Id: Icdb5d5c51f70eeb7e39e11062276ceb3eb3d9473
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/2818
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This is updated to handle LynxPoint-H and LynxPoint-LP
and a new wake event is added for the power button.
Boot, suspend/resume, reboot, etc on WTM2
and then check the event log to see if expected events
have been added.
Change-Id: I15cbc3901d81f4fd77cc04de37ff5fa048f9d3e8
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/2817
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This makes use of the new functions from pmutil.c that take
care of the differences between -H and -LP chipsets.
It also adds support for the LynxPoint-LP GPE0 register block
and the SMI/SCI routing differences.
The FADT is updated to report the new 256 byte GPE0 block on
wtm2/wtm2 boards which is too big for the 64bit X_GPE0 address
block so that part is zeroed to prevent IASL and the kernel
from complaining about a mismatch.
This was tested on WTM2. Unfortunately I am still unable to get an
SCI delivered from the EC but I suspect that is due to a magic
command needed to put the EC in ACPI mode. Instead I verified that
all of the power management and GPIO registers were set to expected
values.
I also tested transitions into S3 and S5 from both the kernel and
by pressing the power button at the developer mode screen and they
all function as expected.
Change-Id: Ice9e798ea5144db228349ce90540745c0780b20a
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/2816
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The kernel ACPI was not happy with the Add inside a
ResourceTemplate (or perhaps within the IO declaration)
Instead make a buffer of IO reservations and turn _CRS
into a method that updates the buffer depending on the
chipset type.
This adds an \ISLP() method that checks the chipset LPC
device ID to see if it is -LP or -H.
It also increases the PM base reservation to 256 bytes
and moves both GPIO and PM base to above 0x1000 on -LP
chipsets.
Change-Id: I747b658588a4d8ed15a0134009a7c0d74b3916ba
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/2815
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This was put in for debugging and experimentation on i945
and has been copied around since. Drop it from lynxpoint.
Change-Id: I0b53f4e1362cd3ce703625ef2b4988139c48b989
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/2814
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
There are subtle yet significant differences in some of the
registers in the power management region between LynxPoint-H
and LynxPoint-LP.
In order to reduce code that is accessing these registers and
would need special cases this adds a number of helper functions
that can be used in both ramstage and SMM.
This commit just adds the new functions, subsequent commits will
start to use them.
Change-Id: I411da75da519f5b3198a408078cbf3114e426992
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/2813
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
These base addresses are used in several places and it
is helpful to have one location that is reading it.
Change-Id: Ibf589247f37771f06c18e3e58f92aaf3f0d11271
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/2812
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Add a helper function pch_is_lp() that will return 1 if
the current chipset is of the new "low power" variant used
with Haswell ULT.
Additionally these functions are added to SMM so it can
be used there.
Change-Id: I9acdea2c56076cd8d9627aba66cf0844c56a38fb
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/2811
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
In order to be able to talk to an EC via standard path.
Change-Id: I3fe76882dec9a0596cbc1c844afa2ddb03ed771c
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/2810
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
I'm not sure if I screwed this up originally or the Intel docs changed
(I didn't bother to go back and check). According to ME BWG 1.1.0 the give
up bit is in the host general status #2 register.
Change-Id: Ieaaf524b93e9eb9806173121dda63d0133278c2d
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2808
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The RESET_ON_INVALID_RAMSTAGE_CACHE option indicates what to do
when the ramstage cache is found to be invalid on a S3 wake. If
selected the system will perform a system reset on S3 wake when the
ramstage cache is invalid. Otherwise it will signal to load the
ramstage from cbfs.
Change-Id: I8f21fcfc7f95fb3377ed2932868aa49a68904803
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2807
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Cache the relocated ramstage into the SMM region. There is
a reserved region within the final SMM region (TSEG). Use that
space to cache the relocated ramstage program. That way, on S3 resume
there is a copy that can be loaded quickly instead of accessing the
flash. Caching the ramstage in the SMM space is also helpful in that
it prevents the OS from tampering with the ramstage program.
Change-Id: Ifa695ad1c350d5b504b14cc29d3e83c79b317a62
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2806
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Instead of hard coding the policy for how a relocated ramstage
image is saved add an interface. The interface consists of two
functions. cache_loaded_ramstage() and load_cached_ramstage()
are the functions to cache and load the relocated ramstage,
respectively. There are default implementations which cache and
load the relocated ramstage just below where the ramstage runs.
Change-Id: I4346e873d8543e7eee4c1cd484847d846f297bb0
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2805
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The SMM region is available for multipurpose use before the SMM
handler is relocated. Provide a configurable sized region in the
TSEG for use before the SMM handler is relocated. This feature is
implemented by making the reserved size a Kconfig option. Also
make the IED region a Kconfig option as well. Lastly add some sanity
checking on the Kconfig options.
Change-Id: Idd7fccf925a8787146906ac766b7878845c75935
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2804
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The TSEG region is accessible until the SMM handler is relocated
to that region. Set the region as cacheable in romstage so that it
can be used for other purposes with fast access.
Change-Id: I92b83896e40bc26a54c2930e05c02492918e0874
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2803
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
So it can get used in both romstage and ramstage.
Change-Id: Ief9eaafdd91df2a7b668de1a9b83aea3af3ff894
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/2802
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The haswell processors support the ability to save their SMM state
into MSR space instead of the memory. This feaure allows for parallel
SMM relocation handlers as well as setting the same SMBASE for each
CPU since the save state memory area is not used.
The catch is that in order determine if this feature is available the
CPU needs to be in SMM context. In order to implement parallel SMM
relocation the BSP enters the relocation handler twice. The first time
is to determine if that feature is available. If it is, then that
feature is enabled the BSP exits the relocation handler without
relocating SMBASE. It then releases the APs to run the SMM relocation
handler. After the APs have completed the relocation the BSP will
re-enter the SMM relocation handler to relocate its own SMBASE to the
final location. If the parallel SMM feature is not available the BSP
relocates its SMBASE as it did before.
This change also introduces the BSP waiting for the APs to relocate
their SMBASE before proceeding with the remainder of the boot process.
Ensured both the parallel path and the serial path still continue
to work on cold, warm, and S3 resume paths.
Change-Id: Iea24fd8f9561f1b194393cdb77c79adb48039ea2
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2801
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Accessing the flash part where the ramstage resides can be slow
when loading it. In order to save time in the S3 resume path a copy
of the relocated ramstage is saved just below the location the ramstage
was loaded. Then on S3 resume the cached version of the relocated
ramstage is copied back to the loaded address.
This is achieved by saving the ramstage entry point in the
romstage_handoff structure as reserving double the amount of memory
required for ramstage. This approach saves the engineering time to make
the ramstage reentrant.
The fast path in this change will only be taken when the chipset's
romstage code properly initializes the s3_resume field in the
romstage_handoff structure. If that is never set up properly then the
fast path will never be taken.
e820 entries from Linux:
BIOS-e820: [mem 0x000000007bf21000-0x000000007bfbafff] reserved
BIOS-e820: [mem 0x000000007bfbb000-0x000000007bffffff] type 16
The type 16 is the cbmem table and the reserved section contains the two
copies of the ramstage; one has been executed already and one is
the cached relocated program.
With this change the S3 resume path on the basking ridge CRB shows
to be ~200ms to hand off to the kernel:
13 entries total:
1:95,965
2:97,191 (1,225)
3:131,755 (34,564)
4:132,890 (1,135)
8:135,165 (2,274)
9:135,840 (675)
10:135,973 (132)
30:136,016 (43)
40:136,581 (564)
50:138,280 (1,699)
60:138,381 (100)
70:204,538 (66,157)
98:204,615 (77)
Change-Id: I9c7a6d173afc758eef560e09d2aef5f90a25187a
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2800
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Now that there is a way to disseminate the presence of s3 wake more
formally use that instead of hard coded pointers in memory and stashing
magic values in device registers. The northbridge code picks up the
field's presence in the romstage_handoff structure and sets up the
acpi_slp_type variable accordingly.
Change-Id: Ida786728ce2950bd64610a99b7ad4f1ca6917a99
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2799
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Provide the implemenation of cbmem_get_table_location() so that
cbmem can be initialized early in ramstage when CONFIG_EARLY_CBMEM_INIT
is enabled. The cbmem tables are located just below the TSEG region.
Change-Id: Ia160ac6aff583fc52bf403d047529aaa07088085
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2798
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
When CONFIG_EARLY_CBMEM_INIT is selected romstage is supposed to have
initialized cbmem. Therefore provide a weak function for the chipset
to implement named cbmem_get_table_location(). When
CONFIG_EARLY_CBMEM_INIT is selected cbmem_get_table_location() will be
called to get the cbmem location and size. After that cbmem_initialize()
is called.
Change-Id: Idc45a95f9d4b1d83eb3c6d4977f7a8c80c1ffe76
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2797
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Stefan Reinauer