| Age | Commit message (Collapse) | Author |
|---|
|
The ACPI NVS region was setup in place and there was a CBMEM
table that pointed to it. In order to be able to use NVS
earlier the CBMEM region is allocated for NVS itself during
the LPC device init and the ACPI tables point to it in CBMEM.
The current cbmem region is renamed to ACPI_GNVS_PTR to
indicate that it is really a pointer to the GNVS and does
not actually contain the GNVS.
Change-Id: I31ace432411c7f825d86ca75c63dd79cd658e891
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/2970
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
This enables the TPM device in ACPI tables so the OS is able
to probe for the TPM without needing it be force loaded.
Change-Id: I21e660ac1c12e3e1341cf266cf8f0bf03763df5a
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/2968
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
There is a wildcard rule to include mainboard/fadt.c.
Change-Id: I7f59d6b241c683b62c2c41c5795e45184882635e
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/2940
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)
|
|
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>
|
|
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>
|
|
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 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>
|
|
This commit pulls in all the common logic for romstage into
the Haswell cpu directory. The bits specific to the mainboard
still reside under their respective directories. The calling
sequence bounces from the cpu directory to mainboard then back
to the cpu directory. The reasoning is that Haswell systems use
cache-as-ram for backing memory in romstage. The stack is used to
allocate structures. However, now changes can be made to the
romstage for Haswell and apply to all boards.
Change-Id: I2bf08013c46a99235ffe4bde88a935c3378eb341
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2754
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
It was found that the Haswell reference code was smashing through the
stack into the reference code's heap implementation. The reason for this
is because our current CAR allocation is too small. Moreover there are
quite a few things to coordinate between 2 code bases to get correct.
This commit separates the CAR into 2 parts:
1. MRC CAR usage.
2. Coreboot CAR usage.
Pointers from one region can be passed between the 2 modules, but one
should not be able to affect the others as checking has been put into
place in both modules.
The CAR size has effectively been doubled from 0x20000 (128 KiB) to
0x40000 (256KiB). Not all of that increase was needed, but enforcing
a power of 2 size only utilizes 1 MTRR.
Old CAR layout with a single contiguous stack with the region starting
at CONFIG_DCACHE_RAM_BASE:
+---------------------------------------+ Offset CONFIG_DCACHE_RAM_SIZE
| MRC global variables |
| CONFIG_DCACHE_RAM_MRC_VAR_SIZE bytes |
+---------------------------------------+
| ROM stage stack |
| |
| |
+---------------------------------------+
| MRC Heap 30000 bytes |
+---------------------------------------+
| ROM stage console |
| CONFIG_CONSOLE_CAR_BUFFER_SIZE bytes |
+---------------------------------------+
| ROM stage CAR_GLOBAL variables |
+---------------------------------------+ Offset 0
There was some hard coded offsets in the reference code wrapper to start
the heap past the console buffer. Even with this commit the console
can smash into the following region depending on what size
CONFIG_CONSOLE_CAR_BUFFER_SIZE is.
As noted above This change splits the CAR region into 2 parts starting
at CONFIG_DCACHE_RAM_BASE:
+---------------------------------------+
| MRC Region |
| CONFIG_DCACHE_RAM_MRC_VAR_SIZE bytes |
+---------------------------------------+ Offset CONFIG_DCACHE_RAM_SIZE
| ROM stage stack |
| |
| |
+---------------------------------------+
| ROM stage console |
| CONFIG_CONSOLE_CAR_BUFFER_SIZE bytes |
+---------------------------------------+
| ROM stage CAR_GLOBAL variables |
+---------------------------------------+ Offset 0
Another variable was add, CONFIG_DCACHE_RAM_ROMSTAGE_STACK_SIZE,
which represents the expected stack usage for the romstage. A marker
is checked at the base of the stack to determine if either the stack
was smashed or the console encroached on the stack.
Change-Id: Id76f2fe4a5cf1c776c8f0019f406593f68e443a7
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2752
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Lots of things are still placeholder and need work.
Due to the useful GPIOs being run to either the EC or the SIO1007
I have hard coded developer mode on and recovery mode off.
Change-Id: I4c308bd90db03ac5bffdfde566e5adbbaabac632
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/2724
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
