| Age | Commit message (Collapse) | Author |
|---|
|
On x86 systems there is a concept of cachings the ROM. However,
the typical policy is that the boot cpu is the only one with
it enabled. In order to ensure the MTRRs are the same across cores
the rom cache needs to be disabled prior to OS resume or boot handoff.
Therefore, utilize the boot state callbacks to schedule the disabling
of the ROM cache at the ramstage exit points.
Change-Id: I4da5886d9f1cf4c6af2f09bb909f0d0f0faa4e62
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3138
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Utilize the static boot state callback scheduling to initialize
and tear down the coverage infrastructure at the appropriate points.
The coverage initialization is performed at BS_PRE_DEVICE which is the
earliest point a callback can be called. The tear down occurs at the
2 exit points of ramstage: OS resume and payload boot.
Change-Id: Ie5ee51268e1f473f98fa517710a266e38dc01b6d
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3135
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
It's helpful to provide a distinct state that affirmatively
describes that OS resume will occur. The previous code included
the check and the actual resuming in one function. Because of this
grouping one had to annotate the innards of the ACPI resume
path to perform specific actions before OS resume. By providing
a distinct state in the boot state machine the necessary actions
can be scheduled accordingly without modifying the ACPI code.
Change-Id: I8b00aacaf820cbfbb21cb851c422a143371878bd
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3134
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
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>
|
|
On certain architectures such as x86 the bootstrap processor
does most of the work. When CACHE_ROM is employed it's appropriate
to ensure that the caching enablement of the ROM is disabled so that
the caching settings are symmetric before booting the payload or OS.
Tested this on an x86 machine that turned on ROM caching. Linux did not
complain about asymmetric MTRR settings nor did the ROM show up as
cached in the MTRR settings.
Change-Id: Ia32ff9fdb1608667a0e9a5f23b9c8af27d589047
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2980
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
If a configuration was not using RELOCTABLE_RAMSTAGE, but it
was using HAVE_ACPI_RESUME then the ACPI memory was not being
marked as reserved to the OS. The reason is that memory is marked as
reserved during write_coreboot_table(). These reservations were
being added to cbmem after the call to write_coreboot_table(). In
the non-dynamic cbmem case this sequence is fine because cbmem area
is a fixed size and is already reserved. For the dynamic cbmem case
that no longer holds by the nature of the dynamic cbmem.
Change-Id: I9aa44205205bfef75a9e7d9f02cf5c93d7c457b2
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2897
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 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>
|
|
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>
|
|
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>
|
|
This patch adds an option to build the ramstage as a reloctable binary.
It uses the rmodule library for the relocation. The main changes
consist of the following:
1. The ramstage is loaded just under the cmbem space.
2. Payloads cannot be loaded over where ramstage is loaded. If a payload
is attempted to load where the relocatable ramstage resides the load
is aborted.
3. The memory occupied by the ramstage is reserved from the OS's usage
using the romstage_handoff structure stored in cbmem. This region is
communicated to ramstage by an CBMEM_ID_ROMSTAGE_INFO entry in cbmem.
4. There is no need to reserve cbmem space for the OS controlled memory for
the resume path because the ramsage region has been reserved in #3.
5. Since no memory needs to be preserved in the wake path, the loading
and begin of execution of a elf payload is straight forward.
Change-Id: Ia66cf1be65c29fa25ca7bd9ea6c8f11d7eee05f5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2792
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
|
|
The romstage_handoff structure is intended to be a way for romstage and
ramstage to communicate with one another instead of using sideband
signals such as stuffing magic values in pci config or memory
scratch space. Initially this structure just contains a single region
that indicates to ramstage that it should reserve a memory region used
by the romstage. Ramstage looks for a romstage_handoff structure in cbmem
with an id of CBMEM_ID_ROMSTAGE_INFO. If found, it will honor reserving
the region defined in the romstage_handoff structure.
Change-Id: I9274ea5124e9bd6584f6977d8280b7e9292251f0
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2791
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
The current ramstage code contains uses of symbols that cause issues
when the ramstage is relocatable. There are 2 scenarios resolved by this
patch:
1. Absolute symbols that are actually sizes/limits. The symbols are
problematic when relocating a program because there is no way to
distinguish a symbol that shouldn't be relocated and one that can.
The only way to handle these symbols is to write a program to post
process the relocations and keep a whitelist of ones that shouldn't
be relocated. I don't believe that is a route that should be taken
so fix the users of these sizes/limits encoded as absolute symbols
to calculate the size at runtime or dereference a variable in memory
containing the size/limit.
2. Absoulte symbols that were relocated to a fixed address. These
absolute symbols are generated by assembly files to be placed at a
fixed location. Again, these symbols are problematic because one
can't distinguish a symbol that can't be relocated. The symbols
are again resolved at runtime to allow for proper relocation.
For the symbols defining a size either use 2 symbols and calculate the
difference or provide a variable in memory containing the size.
Change-Id: I1ef2bfe6fd531308218bcaac5dcccabf8edf932c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2789
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
|
|
The Link native graphics commit 49428d84 [1]
Add support for Google's Chromebook Pixel
was missing some of the higher level bits, and hence could not be
used. This is not new code -- it has been working since last
August -- so the effort now is to get it into the tree and structure
it in a way compatible with upstream coreboot.
1. Add options to src/device/Kconfig to enable native graphics.
2. Export the MTRR function for setting variable MTRRs.
3. Clean up some of the comments and white space.
While I realize that the product name is Pixel, the mainboard in the
coreboot tree is called Link, and that name is what we will use
in our commits.
[1] http://review.coreboot.org/2482
Change-Id: Ie4db21f245cf5062fe3a8ee913d05dd79030e3e8
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2531
Tested-by: build bot (Jenkins)
|
|
There are 2 issues in lb_cleanup_memory_ranges(). The first
is that during sort there is a neighbor comparison that initially
starts with the current entry. The second issue is that merging
has an off by one comparison for adjacent entries.
Before:
coreboot memory table:
0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES
1. 0000000000001000-000000000009ffff: RAM
2. 00000000000a0000-00000000000fffff: RESERVED
3. 0000000000100000-0000000000efffff: RAM
4. 0000000000f00000-0000000000ffffff: RESERVED
5. 0000000001000000-00000000acebffff: RAM
6. 00000000acec0000-00000000acffffff: CONFIGURATION TABLES
7. 00000000ad000000-00000000af9fffff: RESERVED
8. 00000000f0000000-00000000f3ffffff: RESERVED
9. 00000000fed10000-00000000fed17fff: RESERVED
10. 00000000fed18000-00000000fed18fff: RESERVED
11. 00000000fed19000-00000000fed19fff: RESERVED
12. 00000000fed84000-00000000fed84fff: RESERVED
13. 0000000100000000-000000018f5fffff: RAM
After:
coreboot memory table:
0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES
1. 0000000000001000-000000000009ffff: RAM
2. 00000000000a0000-00000000000fffff: RESERVED
3. 0000000000100000-0000000000efffff: RAM
4. 0000000000f00000-0000000000ffffff: RESERVED
5. 0000000001000000-00000000acebffff: RAM
6. 00000000acec0000-00000000acffffff: CONFIGURATION TABLES
7. 00000000ad000000-00000000af9fffff: RESERVED
8. 00000000f0000000-00000000f3ffffff: RESERVED
9. 00000000fed10000-00000000fed19fff: RESERVED
10. 00000000fed84000-00000000fed84fff: RESERVED
11. 0000000100000000-000000018f5fffff: RAM
Change-Id: I656aab61b0ed4711c9dceaedb81c290d040ffdec
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2671
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
I've used an operating system for over 10 years now that makes
UTF-8 easy. It's not called Linux or OSX.
When UTF-8 is needed, of course, then we can look again.
I can't think of a single redeeming feature of placing
it in the comment in this manner. It's certainy not
needed.
The inclusion of UTF-8 characters is inconvenient,
especially from a text terminal.
I don't really want to start using compose in
CROSH shell terminals on chromeos.
We might want to incorporate "no UTF-8" as a
commit filter. For now, get rid of these
characters.
Change-Id: If94cc657bae1dbd282bec8de6c5309b1f8da5659
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2604
Reviewed-by: Bernhard Urban <lewurm@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
While reading through the file fix some spotted errors like
indentation, locution(?), capitalization and missing full stops.
Change-Id: Id435b4750e329b06a9b36c1df2c39d2038a09b18
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2484
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
|
|
In the file `COPYING` in the coreboot repository and upstream [1]
just one space is used.
The following command was used to convert all files.
$ git grep -l 'MA 02' | xargs sed -i 's/MA 02/MA 02/'
[1] http://www.gnu.org/licenses/gpl-2.0.txt
Change-Id: Ic956dab2820a9e2ccb7841cab66966ba168f305f
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2490
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
|
|
It's been on for all boards per default since several years now
and the old code path probably doesn't even work anymore. Let's
just have one consistent way of doing things.
Change-Id: I58da7fe9b89a648d9a7165d37e0e35c88c06ac7e
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2547
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
The name lapic_cluster is a bit misleading, since the construct is not local
APIC specific by concept. As implementations and hardware change, be more
generic about our naming. This will allow us to support non-x86 systems without
adding new keywords.
Change-Id: Icd7f5fcf6f54d242eabb5e14ee151eec8d6cceb1
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2377
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
The name pci_domain was a bit misleading, since the construct is only
PCI specific in a particular (northbridge/cpu) implementation, but not
by concept. As implementations and hardware change, be more generic
about our naming. This will allow us to support non-PCI systems without
adding new keywords.
Change-Id: Ide885a1d5e15d37560c79b936a39252150560e85
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2376
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
If somebody makes use of CONFIG_LOCALVERSION show this
user provided config string for DMI bios_version.
As requested I have attached example output.
CONFIG_LOCALVERSION=""
CONFIG_CBFS_PREFIX="fallback"
CONFIG_COMPILER_GCC=y
...
root@OT:~# cat /sys/class/dmi/id/bios_version
4.0-3360-g5be6673-dirty
CONFIG_LOCALVERSION="V1.01.02 Beta"
CONFIG_CBFS_PREFIX="fallback"
CONFIG_COMPILER_GCC=y
...
root@OT:~# cat /sys/class/dmi/id/bios_version
V1.01.02 Beta
Change-Id: I5640b72b56887ddf85113efa9ff23df9d4c7eb86
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Reviewed-on: http://review.coreboot.org/2279
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marcj303@gmail.com>
|
|
Summary:
Isolate CBFS underlying I/O to board/arch-specific implementations as
"media stream", to allow loading and booting romstage on non-x86.
CBFS functions now all take a new "media source" parameter; use
CBFS_DEFAULT_MEDIA if you simply want to load from main firmware.
API Changes:
cbfs_find => cbfs_get_file.
cbfs_find_file => cbfs_get_file_content.
cbfs_get_file => cbfs_get_file_content with correct type.
CBFS used to work only on memory-mapped ROM (all x86). For platforms like ARM,
the ROM may come from USB, UART, or SPI -- any serial devices and not available
for memory mapping.
To support these devices (and allowing CBFS to read from multiple source
at the same time), CBFS operations are now virtual-ized into "cbfs_media". To
simplify porting existing code, every media source must support both "reading
into pre-allocated memory (read)" and "read and return an allocated buffer
(map)". For devices without native memory-mapped ROM, "cbfs_simple_buffer*"
provides simple memory mapping simulation.
Every CBFS function now takes a cbfs_media* as parameter. CBFS_DEFAULT_MEDIA
is defined for CBFS functions to automatically initialize a per-board default
media (CBFS will internally calls init_default_cbfs_media). Also revised CBFS
function names relying on memory mapped backend (ex, "cbfs_find" => actually
loads files). Now we only have two getters:
struct cbfs_file *entry = cbfs_get_file(media, name);
void *data = cbfs_get_file_content(CBFS_DEFAULT_MEDIA, name, type);
Test results:
- Verified to work on x86/qemu.
- Compiles on ARM, and follow up commit will provide working SPI driver.
Change-Id: Iac911ded25a6f2feffbf3101a81364625bb07746
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2182
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
In order to provide some insight on what code is executed during
coreboot's run time and how well our test scenarios work, this
adds code coverage support to coreboot's ram stage. This should
be easily adaptable for payloads, and maybe even romstage.
See http://gcc.gnu.org/onlinedocs/gcc/Gcov.html for
more information.
To instrument coreboot, select CONFIG_COVERAGE ("Code coverage
support") in Kconfig, and recompile coreboot. coreboot will then
store its code coverage information into CBMEM, if possible.
Then, run "cbmem -CV" as root on the target system running the
instrumented coreboot binary. This will create a whole bunch of
.gcda files that contain coverage information. Tar them up, copy
them to your build system machine, and untar them. Then you can
use your favorite coverage utility (gcov, lcov, ...) to visualize
code coverage.
For a sneak peak of what will expect you, please take a look
at http://www.coreboot.org/~stepan/coreboot-coverage/
Change-Id: Ib287d8309878a1f5c4be770c38b1bc0bb3aa6ec7
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2052
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Martin Roth <martin@se-eng.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Since coreboot is compiled into 32bit code, and userspace
might be 32 or 64bit, putting a pointer into the coreboot
table is not viable. Instead, use a uint64_t, which is always
big enough for a pointer, even if we decide to move to a 64bit
coreboot at some point.
Change-Id: Ic974cdcbc9b95126dd1e07125f3e9dce104545f5
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2135
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Initialize the pointer fadt to NULL to prevent a later comparison
(if (fadt == NULL)) when the pointer had the *possibility* of never
having been initialized.
Change-Id: Ib2a544c190b609ab8c23147dc69dca5f4ac7f38c
Signed-off-by: Martin Roth <martin@se-eng.com>
Reviewed-on: http://review.coreboot.org/2037
Reviewed-by: Peter Stuge <peter@stuge.se>
Tested-by: build bot (Jenkins)
|
|
Instead of adding regparm(0) to each assembler function called
by coreboot, add an asmlinkage macro (like the Linux kernel does)
that can be different per architecture (and that is empty on ARM
right now)
Change-Id: I7ad10c463f6c552f1201f77ae24ed354ac48e2d9
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1973
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Change-Id: I120913dac3150a72c2e66c74872ee00074ee0267
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/1936
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
intel_irq_routing_table is a local structure that should not be used
globally, because it might not be there on all mainboards.
Instead, the API has to be corrected to allow passing a PIRQ table in
where needed.
Change-Id: Icf08928b67727a366639b648bf6aac8e1a87e765
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1862
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
The SMM GNVS pointer is normally updated only when the
ACPI tables are created, which does not happen in the
resume path.
In order to restore this pointer it needs to be available
at resume time. The method used to locate it at creation
time cannot be used again as that magic signature is
overwritten with the address itself. So a new CBMEM ID
is added to store the 32bit address so it can be found
again easily.
A new function is defined to save this pointer in CBMEM
which needs to be called when the ACPI tables are created
in each mainboard when write_acpi_tables() is called.
The cpu_index variable had to be renamed due to a conflict
when cpu/cpu.h is added for the smm_setup_structures()
prototype.
Change-Id: Ic764ff54525e12b617c1dd8d6a3e5c4f547c3e6b
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1765
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
At least when CONFIG_CHROMEOS is turned on, it's possible for
CONFIG_FRAMEBUFFER_KEEP_VESA_MODE to be set but for there not to be any valid
information to put into the framebuffer coreboot table. That means that what's
put in there is junk, probably all zeroes from the uninitialized global
variable the mode information is stored in (mode_info).
When a payload uses libpayload and turns on the coreboot framebuffer console,
that console will attempt to scroll at some point and decrease the cursor's y
coordinate until it is less than the number of rows claimed by the console.
The number of rows is computed by taking the vertical resolution of the
framebuffer and dividing it by the height of the font. Because the mode
information was all zeroes, the coreboot table info is all zeroes, and that
means that the number of rows the console claims is zero. You can't get the
unsigned y coordinate of the cursor to be less than zero, so libpayload gets
stuck in an infinite loop.
The solution this change implements is to add a new function,
vbe_mode_info_valid, which simply returns whether or not mode_info has anything
in it. If not, the framebuffer coreboot table is not created, and libpayload
doesn't get stuck.
Change-Id: I08f3ec628e4453f0cfe9e15c4d8dfd40327f91c9
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://review.coreboot.org/1758
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
And move the pre-hardwaremain post code to 0x79
so it comes before hardwaremain at 0x80.
Emit these codes from ACPI OS resume vector as well
as the finalize step in bd82x6x southbridge.
Change-Id: I7f258998a2f6549016e99b67bc21f7c59d2bcf9e
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1702
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Adds lowlevel handling of DMAR tables for use by mainboards'
ACPI code. Not much automagic (yet).
Change-Id: Ia86e950dfcc5b9994202ec0e2f6d9a2912c74ad8
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/1654
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
We only want to add data once per device. Using the one in
chip_operations is not very usable anyway, as different
devices under the same chip directory would need to output
entirely different sets of data.
Change-Id: I96690c4c699667343ebef44a7f3de1f974cf6d6d
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1492
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Tested-by: build bot (Jenkins)
|
|
Change-Id: Ic44915cdb07e0d87962eff0744acefce2a4845a2
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1626
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Peter Stuge <peter@stuge.se>
|
|
HPET's min ticks (minimum time between events to avoid
losing interrupts) is chipset specific, so move it to
Kconfig.
Via also has a special base address, so move it as well.
Apart from these (and the base address was already #defined),
the table is very uniform.
Change-Id: I848a2e2b0b16021c7ee5ba99097fa6a5886c3286
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/1562
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Dave Frodin <dave.frodin@se-eng.com>
|
|
Change-Id: I62b1c497d23ec2241efb963e7834728085824016
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/1565
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
|
|
pirq_routing_irqs assumed that only four links are available for PIRQ
routing, INTA to INTD. Some chipsets provide more, up to INTH.
When pirq_routing_irqs found a link number greater than 4 in the pirq table,
it would not assign that IRQ. This is a shame, as it limits the flexibility
of routing IRQs.
Make the maximum number of links a Kconfig variable, and modify the code to
respect it. This works beatifully on the VX900, which provides 8 routable
interrupts.
While we're at it, also refactor pirq_routing_irqs, and add some much
needed comments.
Rename pirq_routing_irqs to pirq_route_irqs to demistify the role of this
function.
The copyrights added were determined from git log filename.
Change-Id: I4b565315404c65b871406f616474e2cc9e6e013e
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/1482
Tested-by: build bot (Jenkins)
|
|
Don't derive the IRQ pin from the function number. Especially onboard
chipset devices don't follow that rule. Instead check and add all
fixed IRQ entries.
Change-Id: I46c88bad39104c1d9b4154f180f8b3c42df28262
Signed-off-by: Sven Schnelle <svens@stackframe.org>
Reviewed-on: http://review.coreboot.org/1461
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
Remove extra semicolon
Capitalize beginning of printk sentence
Fix detection of multiple ISA-carrying IOAPICs
Fix whitespace issue
Change-Id: I114119b1daf3b472955c0dd00bdc449401789525
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/1474
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
|
|
Change-Id: Ib3dae4f0957a2e0057c0dffb5eb9904af20dcd40
Signed-off-by: Sven Schnelle <svens@stackframe.org>
Reviewed-on: http://review.coreboot.org/1460
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
Adding ranges directly into coreboot memory table raised issues
as those methods bypassed the MTRR setup. Such regions are now
added as resources, so declare the functions again as static.
Change-Id: If78613da40eabc5c99c49dbe2d6047cb22a71b69
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1415
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
|
|
These existed to provide a hook to add reserved memory regions
in the coreboot memory table. Reserved memory are now
added as resources.
Change-Id: I9f83df33845cfa6973b018a51cf9444dbf0f8667
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1414
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Peter Stuge <peter@stuge.se>
|
|
The existing NVS variable for PPCM will be used to
select a dynamic max P-state.
By itself this does not change existing behavior because
the NVS PPCM variable is initialized to zero.
PPCM can be tested by building and booting a modified BIOS
that sets gnvs->ppcm to a value greater than 1 and checking
from the OS that the P-state is limited to that value.
Change-Id: Ia7b3bbc6b84c1aa42349bb236abee5cc92486561
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1341
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
This patch extends the current smbios api to allow changing mainboard
serial and version during coreboot runtime. This is helpful if you
have an EEPROM etc. to access these informations and want to add
some quirks for broken hardware revision for the linux kernel.
This could be done via DMI_MATCH marco.
Change-Id: I1924a56073084e965a23e47873d9f8542070423c
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Reviewed-on: http://review.coreboot.org/1232
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
This standared SMBIOS 0able describes the location and format
of the event log to the OS and applications. In this case the
pointer is a 32bit physical address pointer to the log in
memory mapped flash.
Look for SMBIOS type15 entry with 'dmidecode -t 15'
Handle 0x0004, DMI type 15, 23 bytes
System Event Log
Area Length: 4095 bytes
Header Start Offset: 0x0000
Header Length: 8 bytes
Data Start Offset: 0x0008
Access Method: Memory-mapped physical 32-bit address
Access Address: 0xFFB6F000
Status: Valid, Not Full
Change Token: 0x00000000
Header Format: OEM-specific
Supported Log Type Descriptors: 0
Change-Id: I1e7729e604000f197e26e69991a2867e869197a6
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1314
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
This patch adds support for autogenerating the MPTABLE from
devicetree.cb. This is done by a write_smp_table() declared
weak in mpspec.c. If the mainboard doesn't provide it's own
function, this generic implementation is called.
Syntax in devicetree.cb:
ioapic_irq <APICID> <INTA|INTB|INTC|INTD> <INTPIN>
The ioapic_irq directive can be used in pci and pci_domain
devices. If there's no directive, the autogen code traverses
the tree back to the pci_domain and stops at the first device
which such a directive, and use that information to generate the
entry according to PCI IRQ routing rules.
Change-Id: I4df5b198e8430f939d477c14c798414e398a2027
Signed-off-by: Sven Schnelle <svens@stackframe.org>
Reviewed-on: http://review.coreboot.org/1138
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
With this change it is possible to define serial number
and version of the mainboard. These informations are used
in SMBIOS tables.
Change-Id: I1634882270f6cb94e00aceb7832e7fd14adc186b
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Reviewed-on: http://review.coreboot.org/1163
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
The wrapper for Trinity. Support S3. Parme is a example board.
Change-Id: Ib4f653b7562694177683e1e1ffdb27ea176aeaab
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: zbao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/1156
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
It is just me or does anybody have the same build error without
this patch?
------
src/arch/x86/boot/acpigen.c: In function 'acpigen_write_empty_PTC':
src/arch/x86/boot/acpigen.c:347:3: error: unknown field 'resv'
specified in initializer
src/arch/x86/boot/acpigen.c:347:3: warning: missing braces around
initializer
src/arch/x86/boot/acpigen.c:347:3:warning: (near initialization
for 'addr.<anonymous>')
-------
Anyway, I believe at least this will cause warnings.
"resv" is a member of a union, not of acpi_addr_t. So it should be
wrapped by a brace in the initializer.
Change-Id: I72624386816c987d5bb2d3a3a64c7c58eb9af389
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: zbao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/1056
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Marc Jones <marcj303@gmail.com>
|
|
Replace #if CONFIG_FOO==1 with #if CONFIG_FOO:
find src -name \*.[ch] -exec sed -i "s,#if[[:space:]]*\(CONFIG_[A-Z0-9_]*\)[[:space:]]*==[[:space:]]*1[[:space:]]*\$,#if \1," {} +
Replace #if (CONFIG_FOO==1) with #if CONFIG_FOO:
find src -name \*.[ch] -exec sed -i "s,#if[[:space:]]*(\(CONFIG_[A-Z0-9_]*\)[[:space:]]*==[[:space:]]*1)[[:space:]]*\$,#if \1," {} +
Replace #if CONFIG_FOO==0 with #if !CONFIG_FOO:
find src -name \*.[ch] -exec sed -i "s,#if[[:space:]]*\(CONFIG_[A-Z0-9_]*\)[[:space:]]*==[[:space:]]*0[[:space:]]*\$,#if \!\1," {} +
Replace #if (CONFIG_FOO==0) with #if !CONFIG_FOO:
find src -name \*.[ch] -exec sed -i "s,#if[[:space:]]*(\(CONFIG_[A-Z0-9_]*\)[[:space:]]*==[[:space:]]*0)[[:space:]]*\$,#if \!\1," {} +
(and some manual changes to fix false positives)
Change-Id: Iac6ca7605a5f99885258cf1a9a2473a92de27c42
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/1004
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Martin Roth <martin@se-eng.com>
|
|
Change-Id: I1ec7a7e54513671331ac12f08d5f59161b72b0fd
Example:
PSS: 1900MHz power 35000 control 0x1300 status 0x1300
PSS: 1600MHz power 28468 control 0x1000 status 0x1000
PSS: 1400MHz power 24291 control 0xe00 status 0xe00
PSS: 1200MHz power 20340 control 0xc00 status 0xc00
PSS: 1000MHz power 16569 control 0xa00 status 0xa00
PSS: 800MHz power 12937 control 0x800 status 0x800
PSS: 1900MHz power 35000 control 0x1300 status 0x1300
PSS: 1600MHz power 28468 control 0x1000 status 0x1000
PSS: 1400MHz power 24291 control 0xe00 status 0xe00
PSS: 1200MHz power 20340 control 0xc00 status 0xc00
PSS: 1000MHz power 16569 control 0xa00 status 0xa00
PSS: 800MHz power 12937 control 0x800 status 0x800
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/994
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
The CBMEM_ID_RESUME_SCRATCH area is only used by Agesa code, on one
particular board (AMD Persimmon). Make the creation of that section
depending on Agesa so it does consume space on non-Agesa systems.
Change-Id: I2a1a4f76991ef936ea68cf75928b20b7ed132b84
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/992
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
It's used by Sandybridge specific C state generation code.
Change-Id: Ia6f1e14e748841a9646fd93d0a18f9e8f2a55e29
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/949
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Change-Id: I58050591198bb06de5f0ca58ca3a02f1cfa95069
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/944
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
|
|
... in order to unify the Sandybridge and Lenovo implementations
currently used in the tree.
- use acpi_addr_t in acpigen_write_register()
- use acpi_cstate_t for cstate tables (and fix up
the x60 and t60)
- drop cst_entry from acpigen.h
Change-Id: Icb87418d44d355f607c4a67300107b40f40b3b3f
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/943
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
|
|
since it is used in CPU specific ACPI generation code
Change-Id: I2559658f43c89dc5b4dc8230dea8847d2802990c
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/947
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
If compiling coreboot with ChromeOS support, two
more include files are required.
Change-Id: I7e042e250e4a89e7dd4bab58443824d503c3f709
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/931
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
1. Move the Stack to high memory.
2. Restore the MTRR before Coreboot jump to the wakeup vector.
Change-Id: I9872e02fcd7eed98e7f630aa29ece810ac32d55a
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: zbao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/623
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marcj303@gmail.com>
|
|
HEST feature starts from ACPI 4.0.
HEST is one of four kinds of tables of ACPI Platform Error
Interfaces (APEI). In Windows world, APEI is called Windows Hardware
Error Architecture (WHEA).
APEI consists of four separate tables:
1. Error Record Serialization Table (ERST)
2. BOOT Error Record Table (BERT)
3. Hardware Error Source Table (HEST)
4. Error Injection Table (EINJ)
All these 4 tables have the same header as FADT, MADT, etc. They are
pointed by RSDP.
For the HEST, it contains the error source. The types of them are
defined as
type description
1. Machine Check Exception (MCE)
2. Corrected Machine Check (CMC)
3. NMI Error
6. PCI Express Root Port AER
7. PCI Express Device AER
8. PCI Express Bridge AER
9. Generic Hardware Error Source
Error source types 3, 4, and 5 are reserved for legacy reasons and
must not be used.
Currently AMD board only provide part of "Machine Check
Exception (MCE)" & Corrected Machine Check (CMC)". we need to provide
the header of each error source. Other types of Error Sources is in
TODO list.
Only persimmon is tested. Linux can add HEST feature. The dmesg says,
ACPI: HEST 0000000066fe5010 00198 (v03 CORE COREBOOT 00000000 CORE 00000000)
......
HEST: Table parsing has been initialized.
No more message is got.
Windows can boot with this patch. Havent found a way to test it.
Change-Id: I447e7f57b8e8f0433a145a43d0710910afabf00f
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: zbao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/888
Reviewed-by: Peter Stuge <peter@stuge.se>
Tested-by: build bot (Jenkins)
|
|
In ChromeOS we potentially have different payloads with
different versions. Since the user land tools get information
on which one of them is loaded, leave the string in smbios
empty so we can fill it out in the payload.
Also fill out system version number and serial number with
some constant values.
Change-Id: Id1fed5a54b511c730975fa83347452f1274b8504
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/867
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
|
|
ChromeOS uses two extensions to the coreboot table:
- ChromeOS specific GPIO description for onboard switches
- position of verified boot area in nvram
Change-Id: I8c389feec54c00faf2770aafbfd2223ac9da1362
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/866
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Some mainboards (most likely laptops) will need mainboard specific functions
called upon a resume from suspend.
Change-Id: If1518a4b016bba776643adaef0ae64ff49f57e51
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/852
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
We changed our verified boot initialization to run from romstage,
as that allows faster boot times and does not add as much ChromeOS
specific code to generic files.
Change-Id: Id4164c26d524ea0ffce34467cf91379a19a4b2f6
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/851
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
It's not significantly faster, but easier to read and smaller.
Change-Id: Ibab0b478873912d67bf1f07743f628586353368a
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/755
Reviewed-by: Mathias Krause <minipli@googlemail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Change-Id: I28224867610b947739d940d25c98399d219f10f4
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: http://review.coreboot.org/733
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
and initialize the TPM on S3 resume
This patch integrates the TPM driver and runs TPM resume upon an ACPI S3
resume without including any other parts of vboot.
We could link against vboot_fw.a but it is compiled with u-boot's CFLAGS
(that are incompatible with coreboot's) and it does a lot more than we
want it to do.
Change-Id: I000d4322ef313e931e23c56defaa17e3a4d7f8cf
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/731
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
We need to provide u-boot access to several different CBMEM
sections. To do that, a common coreboot table structure is used,
just different tags match different coreboot table sections.
Also, the code is added to export CBMEM console and MRC cache
addresses through the same mechanism.
Change-Id: I63adb67093b8b50ee61b0deb0b56ebb2c4856895
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/724
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
This change exports the timestamp table pointer through coreboot
table to make it possible for u-boot to add timestamps to the
table.
Inclusion of cbmem.h allows to drop external declarations in
coreboot_table.c.
Change-Id: Ia070198cee7a6ffdaeece03d9d15bd91e033b6d1
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/716
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
class cpu.
Change-Id: Ic7c4452a1b55bae0cefee118003540ec39ef9fd4
Signed-off-by: Rudolf Marek <r.marek@assembler.cz>
Reviewed-on: http://review.coreboot.org/683
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Peter Stuge <peter@stuge.se>
|
|
This way u-boot won't try to use a UART that isn't plugged in.
Change-Id: I9a3a0d074dd03add8afbd4dad836c4c6a05abe6f
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://review.coreboot.org/729
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Tested-by: build bot (Jenkins)
|
|
Packing a device tree into the coreboot table can easily make
the table exceed the current limit of 8KB. However, right now
there is no error handling in place to catch that case.
Increase the maximum memory usable for all tables from 64KB to
128KB and increase the maximum coreboot table size from 8KB
to 32KB.
Change-Id: I2025bf070d0adb276c1cd610aa8402b50bdf2525
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/704
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Change-Id: Id622e4e96b6c8e87b00a96c324a0b4dbfac3391d
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: http://review.coreboot.org/702
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
The code when reporting the coreboot table size did not account
for the last added table record. This change fixes the problem.
. rebuild coreboot, program it on the target, restart it
. look for 'Wrote coreboot table at:' in the console log
. observe the adequate table size reported
$ grep 'Wrote coreboot table:' /tmp/cb.log
Wrote coreboot table at: 00000500, 0x10 bytes, checksum c06f
Wrote coreboot table at: 7f6fc000, 0x1a73 bytes, checksum 3e45
$
Change-Id: Ic55501a4ae06fab2bcda9aea58e362325f2edccf
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/703
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
CONFIG_ variables are used inconsistently within the file
src/arch/x86/boot/coreboot_table.c. #ifdef will do the wrong
thing if the option is disabled. #if (CONFIG_FOO == 1) is
not needed.
Change-Id: Ifcac6ceac5fb34b931281beae500023597b3533b
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/701
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
|
|
We used several names for that same value, and hardcoded the value
at some more places.
They're all LOCAL_APIC_ADDR now (except for lapic specific code
that still uses LAPIC_DEFAULT_BASE).
Change-Id: I1d4be73b1984f22b7e84681edfadf0588a7589b6
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/676
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Also mark the corresponding lint test stable.
Change-Id: Ib7c9ed88c5254bf56e68c01cdbd5ab91cd7bfc2f
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/772
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Linux 2.6.11 seems to require a certain order in CPUs listed in mptable,
so enforce it. This was only done on arima/hdama, but now is generic.
Unfortunately this is somewhat slow.
Change-Id: I85715ebae8a009cb816bc9ffd6372708f246bf66
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/280
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Change-Id: I4e16a0d37717c56a3529f9f9fdb05efec1d93f99
Signed-off-by: Sven Schnelle <svens@stackframe.org>
Reviewed-on: http://review.coreboot.org/312
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
Add information about memory mapped/io mapped base addresses.
and fix up libpayload to use the same structures
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: I5f7b5eda6063261b9acb7a46310172d4a5471dfb
Reviewed-on: http://review.coreboot.org/261
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
If all console types are disabled, coreboot will fail to compile because
static code is unused. This patch fixes the issue.
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: Ie9c8bf2a78e3aeba4c2908b06bc03f0f5af37db2
Reviewed-on: http://review.coreboot.org/260
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marcj303@gmail.com>
|
|
- adds possibility to set a vesa mode without showing a bootsplash
- make bootsplash / mode setting code available in real mode.
Change-Id: I0045c9d75757657f4ce531889593102ea1e39ce5
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/256
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marcj303@gmail.com>
|
|
The last couple of lines of every mptable function were mostly
identical. Refactor into common code, a new function mptable_finalize.
Coccinelle script:
@@
identifier mc;
@@
(
-mc->mpe_checksum = smp_compute_checksum(smp_next_mpc_entry(mc), mc->mpe_length);
-mc->mpc_checksum = smp_compute_checksum(mc, mc->mpc_length);
-printk(BIOS_DEBUG, "Wrote the mp table end at: %p - %p\n", mc, smp_next_mpe_entry(mc));
-return smp_next_mpe_entry(mc);
+return mptable_finalize(mc);
|
-mc->mpe_checksum = smp_compute_checksum(smp_next_mpc_entry(mc), mc->mpe_length);
-mc->mpc_checksum = smp_compute_checksum(mc, mc->mpc_length);
-return smp_next_mpe_entry(mc);
+return mptable_finalize(mc);
)
Change-Id: Ib2270d800bdd486c5eb49b328544d36bd2298c9e
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/246
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marcj303@gmail.com>
|
|
As stated in some code files, fixup_virtual_wire was established
to avoid touching 200 invocations of the mptable code.
Let Coccinelle do it:
@@
type T;
identifier v;
@@
-void fixup_virtual_wire(T v)
-{ ... }
@@
expression A;
identifier v;
@@
-v = smp_write_floating_table(A);
+v = smp_write_floating_table(A, 0);
@@
expression A;
identifier v;
@@
-v = smp_write_floating_table(A, 0);
-fixup_virtual_wire(v);
+v = smp_write_floating_table(A, 1);
Change-Id: Icad8a063380bf4726be7cebb414d13b574112b14
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/245
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marcj303@gmail.com>
|
|
We copied pretty much the same code for generating mptable entries for
local interrupts (with some notable exceptions).
This change moves these lines into a generic function "mptable_lintsrc"
and makes use of it in many places.
The remaining uses of smp_write_lintsrc should be reviewed and replaced
by mptable_lintsrc calls where possible, and smp_write_lintsrc made static.
This patch was generated using Coccinelle:
@@
expression mc;
expression isa_bus;
@@
-smp_write_lintsrc(mc, mp_ExtINT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, isa_bus, 0x0, MP_APIC_ALL, 0x0);
-smp_write_lintsrc(mc, mp_NMI, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, isa_bus, 0x0, MP_APIC_ALL, 0x1);
+mptable_lintsrc(mc, isa_bus);
@@
expression mc;
expression isa_bus;
@@
-smp_write_lintsrc(mc, mp_ExtINT, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH, isa_bus, 0x0, MP_APIC_ALL, 0x0);
-smp_write_lintsrc(mc, mp_NMI, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH, isa_bus, 0x0, MP_APIC_ALL, 0x1);
+mptable_lintsrc(mc, isa_bus);
@m@
identifier mc;
expression BUS;
@@
-#define IO_LOCAL_INT(type, intr, apicid, pin) smp_write_lintsrc(mc, (type), MP_IRQ_TRIGGER_EDGE | MP_IRQ_POLARITY_HIGH, BUS, (intr), (apicid), (pin));
...
-IO_LOCAL_INT(mp_ExtINT, 0x0, MP_APIC_ALL, 0x0);
-IO_LOCAL_INT(mp_NMI, 0x0, MP_APIC_ALL, 0x1);
+mptable_lintsrc(mc, BUS);
Change-Id: I97421f820cd039f5fd753cb0da5c1cca68819bb4
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/244
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marcj303@gmail.com>
|
|
Build fix for src/arch/i386/boot/acpi.c if !CONFIG_SMP
Also check for acpi_slp_type 2 in acpi_is_wakeup, since S2
uses the same acpi wakeup vector as S3.
Add _PTS/_WAK methods to turn off/on the CPU/case fans and blink
the power LED while sleeping.
acpi_get_sleep_type() is in a seperate file i82371eb_wakeup.c because
it is used in both romstage and ramstage after patch 3/3, whereas
i82371eb_early_pm.c is used only in romstage.
I used the name acpi_get_sleep_type instead of acpi_is_wakeup_early
because I think acpi_is_wakeup_early is a bit misleading as a name since it
doesn't return a boolean value.
Other chipsets so far only ever set acpi_slp_type to 0 and 3, so the
added check for acpi_slp_type == 2 (resume from S2) should not
change behaviour of other boards:
northbridge/intel/i945/northbridge.c:256:extern u8 acpi_slp_type;
northbridge/intel/i945/northbridge.c:263: acpi_slp_type=0;
northbridge/intel/i945/northbridge.c:267: acpi_slp_type=3;
northbridge/intel/i945/northbridge.c:271: acpi_slp_type=0;
southbridge/intel/i82801gx/i82801gx_lpc.c:171:extern u8 acpi_slp_type;
southbridge/via/vt8237r/vt8237r_lpc.c:149:extern u8 acpi_slp_type;
southbridge/via/vt8237r/vt8237r_lpc.c:238: acpi_slp_type = ((tmp & (7 << 10)) >> 10) == 1 ? 3 : 0 ;
southbridge/via/vt8237r/vt8237r_lpc.c:239: printk(BIOS_DEBUG, "SLP_TYP type was %x %x\n", tmp, acpi_slp_type);
Change-Id: I13feff0b8f49aa988e5467cdbef02981f0a6be8a
Signed-off-by: Tobias Diedrich <ranma+coreboot@tdiedrich.de>
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/188
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Change-Id: I0ae16dda8969638a8f70fe1d2e29e992aef3a834
Signed-off-by: Sven Schnelle <svens@stackframe.org>
Reviewed-on: http://review.coreboot.org/152
Tested-by: build bot (Jenkins)
|
|
Change-Id: Ibd598813bec0c93d77afbce8aee330498afbe5f6
Signed-off-by: Cristian Măgherușan-Stanciu <cristi.magherusan@gmail.com>
Reviewed-on: http://review.coreboot.org/74
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Tested-by: build bot (Jenkins)
|
|
example.
This newer version reflects the recent changes to further simplify the console
code and partly gets rid of some hacks in the previous version.
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Acked-by: Peter Stuge <peter@stuge.se>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6544 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
|
|
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Acked-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6535 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
|
|
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Acked-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6500 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
|
|
Signed-off-by: Josef Kellermann <Joseph.Kellermann@heitec.de>
Acked-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6295 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
|
|
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Acked-by: Patrick Georgi <patrick.georgi@secunet.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6291 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
|
|
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Acked-by: Patrick Georgi <patrick.georgi@secunet.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6269 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
|
|
to CBFS and adapt coreboot to use it.
Comments by Stefan and Mathias taken into account (except for
the build time failure if the table is missing when it should
exist and the "memory leak" in build_opt_tbl)
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Acked-by: Stefan Reinauer <stepan@coreboot.org>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6268 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
|
|
We currently use "COREBOOT" unconditionally as the "OEM ID" in our
mptable.c files, and hardcode the mainboard name in mptable.c like this:
mptable_init(mc, "DK8-HTX ", LAPIC_ADDR);
However, the spec says
"OEM ID: A string that identifies the manufacturer of the system hardware."
(Table 4-2, page 42)
so "COREBOOT" doesn't match the spec, we should use the hardware vendor name.
Thus, use CONFIG_MAINBOARD_VENDOR which we have already as the "OEM ID"
(truncate/fill it to 8 characters as per spec).
Also, use CONFIG_MAINBOARD_PART_NUMBER (the board name) as "product ID",
and truncate/fill it to 12 characters as per spec, if needed.
Abuild-tested.
Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de>
Acked-by: Stefan Reinauer <stepan@coreboot.org>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6183 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
|
|
src/arch/x86.
Signed-off-by: Stefan Reinauer <stepan@coreboot.org>
Acked-by: Patrick Georgi <patrick@georgi-clan.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6161 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
|
