Add a function that can be implemented by the SOC to read
and clear the status of a single GPE. This can be used
during firmware to poll for interrupt status.
BUG=chrome-os-partner:53336
Change-Id: I536c2176320fefa4c186dabcdddb55880c47fbad
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Implement postcar stage cbmem console support. The postcar stage
is more like ramstage in that RAM is already up. Therefore, in
order to make the cbmem console reinit flow work one needs the cbmem
init hook infrastructure in place and the cbmem recovery called.
This call is added to x86/postcar.c to achieve that. Additionally,
one needs to provide postcar stage cbmem init hook callbacks for
the cbmem console library to use. A few other places need to
become postcar stage aware so that the code paths are taken.
Lastly, since postcar is backed by ram indicate that to the
cbmem backing store.
BUG=chrome-os-partner:57513
Change-Id: I51db65d8502c456b08f291fd1b59f6ea72059dfd
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16619
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
The console_init(), MTRR printing, and loading ramstage
logic was previously all in assembly. Move that logic
into C code so that future features can more easily be
added into the postcar boot flow.
BUG=chrome-os-partner:57513
Change-Id: I332140f569caf0803570fd635d894295de8c0018
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16618
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
I put in the decimal values for these instead of the hex values.
Instead of running them through a BCD converter, update them to use
the hex values.
Change-Id: I3fa46f055c3db113758f445f947446dd5834c126
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/16567
Tested-by: build bot (Jenkins)
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@googlemail.com>
This change adds armv7-r support for all stages.
armv7-r is an ARM processor based on the Cortex-R series.
Currently, there is support for armv7-a and armv7-m and
armv7-a files has been modfied to accommodate armv7-r by
adding ENV_ARMV7_A, ENV_ARMV7_R and ENV_ARMV7_M constants
to src/include/rules.h.
armv7-r exceptions support will added in a later time.
Change-Id: If94415d07fd6bd96c43d087374f609a2211f1885
Signed-off-by: Hakim Giydan <hgiydan@marvell.com>
Reviewed-on: https://review.coreboot.org/15335
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
In the current implementation of postcar_frame_add_mtrr,
if provided size is bigger than the base address alignment,
the alignment is considered as size and covered by the MTRRs
ignoring the specified size.
In this case the callee has to make sure that the provided
size should be smaller or equal to the base address alignment
boundary.
To simplify this, utilize additonal MTRRs to cover the entire
size specified. We reuse the code from cpu/x86/mtrr/mtrr.c.
Change-Id: Ie2e88b596f43692169c7d4440b18498a72fcba11
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-on: https://review.coreboot.org/16509
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
postcar_loader.c has a useful library of funtions for
setting up stack and MTRRs. Make it available in romstage
irrespective of CONFIG_POSTCAR_STAGE for use in stack setup
after Dram init.
The final step of moving the used and max MTRRs on to stack
is moved to a new function, that can be used outside of
postcar phase.
Change-Id: I322b12577d74268d03fe42a9744648763693cddd
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-on: https://review.coreboot.org/16331
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The field that was previously named 'efr' is actually the iommu feature
info field. The efr field is a 64-bit field that is only present in
type 11h or type 40h headers that follows the iommu feature info field.
Change-Id: I62c158a258d43bf1912fedd63cc31b80321a27c6
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/16508
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The revision field was correct, but the comment was wrong. The revision
1 means that the IVRS table only uses fixed length device entries.
Update the field to use the IVRS revision #define.
Change-Id: I4c030b31e3e3f0a402dac36ab69f43d99e131c22
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/16507
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Avoid the inclusion of a function declaration if the argument type
device_t is not defined.
This was not a problem until now because the
old declaration of device_t and the new one overlapped.
Change-Id: I05a6ef1bf65bf47f3c6933073ae2d26992348813
Signed-off-by: Antonello Dettori <dev@dettori.io>
Reviewed-on: https://review.coreboot.org/16404
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Normally machine-mode code operates completely within physical address
space. When emulating less privileged memory accesses (e.g. when the
hardware doesn't support unaligned read/write), it is useful to access
memory through the MMU (and with virtual addresses); this patch
implements this functionality using the MPRV bit.
Change-Id: Ic3b3301f348769faf3ee3ef2a78935dfbcbd15fd
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/16260
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Not all SBI calls are implemented, but it's enough to see a couple dozen
lines of Linux boot output.
It should also be noted that the SBI is still in flux:
https://groups.google.com/a/groups.riscv.org/forum/#!topic/sw-dev/6oNhlW0OFKM
Change-Id: I80e4fe508336d6428ca7136bc388fbc3cda4f1e4
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/16119
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
A new Kconfig option, DEBUG_PRINT_PAGE_TABLES, is added to control this
behaviour. It is currently only available on RISC-V, but other
architectures can use it, too, should the need arise.
Change-Id: I52a863d8bc814ab3ed3a1f141d0a77edc6e4044d
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/16015
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
In particular:
- Fix the condition of the loop that fills the mid-level page table
- Adhere to the format of sptbr
Change-Id: I575093445edfdf5a8f54b0f8622ff0e89f77ccec
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/16120
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
I copied it from commit e10d2def7d of spike and made sure the copyright
header is still there.
Change-Id: Ie8b56cd2f4855b97d36a112a195866f4ff0feec5
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/15832
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Generate an object to describe the coreboot table region in ACPI
with the HID "CORE0000" so it can be used by kernel drivers.
To keep track of the "CORE" HID usage add them to an enum and add
a function to generate the HID in AML: Name (_HID, "CORExxxx")
BUG=chromium:589817
BRANCH=none
TEST=build and boot on chell, dump SSDT to verify contents:
Device (CTBL)
{
Name (_HID, "CORE0000") // _HID: Hardware ID
Name (_UID, Zero) // _UID: Unique ID
Method (_STA, 0, NotSerialized) // _STA: Status
{
Return (0x0F)
}
Name (_CRS, ResourceTemplate () // _CRS: Current Resource Settings
{
Memory32Fixed (ReadOnly,
0x7AB84000, // Address Base
0x00008000, // Address Length
)
})
}
Change-Id: I2c681c1fee02d52b8df2e72f6f6f0b76fa9592fb
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/16056
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
PCI root ports with "Address Translation Service" capability can be
reported in DMAR table in the ATSR scope to let the OS know how to
handle these devices the right way when VT-d is used.
Add code to create an entry for a PCI root port using the type
"SCOPE_PCI_SUB".
Change-Id: Ie2c46db7292d9f1637ffe2e9cfaf6619372ddf13
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/15912
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
DMAR tables can contain so called "Address Translation Service Reporting"
(ATSR) structure. It is applicable for platforms that support
Device-TLBs and describe PCI root ports that have this ability.
Add code to create this ATSR structure.
In addition, a function to fix up the size of the ATSR
structure is added as this is a new type and using the function
acpi_dmar_drhd_fixup() can lead to confusion.
Change-Id: Idc3f6025f597048151f0fd5ea6be04843041e1ab
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/15911
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
mb() is used in src/arch/riscv/ and src/mainboard/emulation/*-riscv/.
It is currently provided by atomic.h, but I think it fits better into
barrier.h.
The "fence" instruction represents a full memory fence, as opposed to
variants such as "fence r, rw" which represent a partial fence. An
operating system might want to use precisely the right fence, but
coreboot doesn't need this level of performance at the cost of
simplicity.
Change-Id: I8d33ef32ad31e8fda38f6a5183210e7bd6c65815
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/15830
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Add a Kconfig value to enable the console during postcar. Add a call
to console_init at the beginning of the postcar stage in exit_car.S.
TEST=Build and run on Galileo Gen2
Change-Id: I66e2ec83344129ede2c7d6e5627c8062e28f50ad
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/16001
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Display the MTRRs after they have been updated during the postcar stage.
TEST=Build and run on Galileo Gen2
Change-Id: I1532250cacd363c1eeaf72edc6cb9e9268a11375
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/15991
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
A few things are currently missing:
- The trap handler doesn't set the stack pointer, which can easily
result in trap loops or memory corruptions.
- The SBI trampolin page (as described in version 1.9 of the RISC-V
Privileged Architecture Specification), has been removed for now.
Change-Id: Id89c859fab354501c94a0e82d349349c29fa4cc6
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/15591
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
And do the detection just before the initialization.
Change-Id: I9a52430262f799baa298dc4f4ea459880abe250e
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/15831
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
These functions are not used anywhere.
Change-Id: Ica1f4650e8774dd796be0aff00054f3698087816
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/15829
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Quark does not support the rdmsr and wrmsr instructions. Use SOC
specific routines to configure the MTRRs on Quark based platforms.
Add cpu_common.c as a build dependency to provide access to the routine
cpu_phys_address_size.
TEST=Build and run on Galileo Gen2
Change-Id: I43b7067c66c5c55b42097937e862078adf17fb19
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/15846
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Place a map file for the postcar stage and place it into
build/cbfs/fallback.
TEST=Build and run on Galileo Gen2
Change-Id: I349c06e3c610db5b3f2511083208db27110c34d0
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/15845
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Move the ramstage files to the beginning of the section. Eliminate
duplicate conditionals.
TEST=Build and run on Galileo Gen2
Change-Id: I461a5b78a76bd0d2643b85973fd0a70bc5e89581
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/15892
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Move the postcar commands to in between romstage and ramstage. Add the
stage header.
TEST=Build and run on Galileo Gen2
Change-Id: I530da6afd8ccbcea217995ddd27066df6d45de22
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/15844
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This function is unused since coreboot starts payloads in machine mode,
and it uses the obsolete eret instruction.
Change-Id: I98d7d0de5a3959821c21a0ba4319efb610fdefde
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/15729
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Using the opcode directly is necessary for the transition to the GCC
6.1.0 based toolchain, because the old toolchain only supports eret and
the new toolchain only supports mret.
Change-Id: I17e14d4793ae5259f7ce3ce0211cbb27305506cc
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/15290
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The API called to write the name of the child table in the
dp entry (type ACPI_DP_TYPE_CHILD) was not including the
quotes, e.g., it was DAAD and not "DAAD". Thus, the kernel driver
did not get the right information from SSDT.
Change the API to acpigen_write_string() to fix the issue.
Signed-off-by: Harsha Priya <harshapriya.n@intel.com>
Change-Id: Id33ad29e637bf1fe6b02e8a4b0fd9e220e8984e7
Reviewed-on: https://review.coreboot.org/15724
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
In the ACPI specification the PM1 register locations are well
defined, but the sleep type values are hardware specific. That
said, the Intel chipsets have been consistent with the values
they use. Therefore, provide those hardware definitions as well
a helper function for translating the hardware values to the
more high level ACPI sleep values.
BUG=chrome-os-partner:54977
Change-Id: Iaeda082e362de5d440256d05e6885b3388ffbe43
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15666
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins)
Instead of open coding the literal values provide more
semantic symbol to be used. This will allow for aligning
chipset code with this as well to reduce duplication.
BUG=chrome-os-partner:54977
Change-Id: I022bf1eb258f7244f2e5aa2fb72b7b82e1900a5c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15663
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
