It's arch specific, so no need to pollute non-x86 with it.
Change-Id: I99ec76d591789db186e8a33774565e5a04fc4e47
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/21392
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
There is at least one I2C device (being used by Soraka) that has 3
controls -- enable, reset and stop. If the stop gpio is not put into
the right state when turning off the device in suspend mode, then it
causes leakage. Thus, we need control in power resource to be able to
stop the device when entering suspend state.
BUG=b:64987428
TEST=Verified on soraka that touchscreen stop is correctly configured
on suspend.
Change-Id: Iae5ec7eb3972c5c7f80956d60d0d3c321bbefb0f
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/21249
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Provide a new function that will allow adding arbitrary properties
to devicetree entries without needing a custom driver for the device.
This will allow the 'generic i2c' driver to support kernel drivers
that need additional device properties exposed and have those board
specific properties set with values from devicetree.
BUG=b:63413023
TEST=not used yet, compiles cleanly
Change-Id: Id272256639a8525406635e168a3db5ab1ba4df6b
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://review.coreboot.org/21269
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add a Kconfig option to change the \PR.CPxx name string. This
provides some flexibility when working with table not generated
by coreboot.
Change-Id: Ibc0c56783c6da80501e2177de96a414b592cb74f
Signed-off-by: Marc Jones <marcj303@gmail.com>
Reviewed-on: https://review.coreboot.org/21210
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Split `i2c.h` into three pieces to ease reuse of the generic defi-
nitions. No code is changed.
* `i2c.h` - keeps the generic definitions
* `i2c_simple.h` - holds the current, limited to one controller driver
per board, devicetree independent I2C interface
* `i2c_bus.h` - will become the devicetree compatible interface for
native I2C (e.g. non-SMBus) controllers
Change-Id: I382d45c70f9314588663e1284f264f877469c74d
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/20845
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Move the FSP-specific call for tearing down cache-as-RAM out of
postcar.c and replace it with an empty weak function.
This patch omits checking if (IS_ENABLED(CONFIG_FSP_CAR)). The
temp_ram_exit.c file with the real fsp_temp_ram_exit() is only built
when CONFIG_FSP_CAR is true.
Change-Id: I9adbb1f2a7b2ff50d9f36d5a3640f63410c09479
Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-on: https://review.coreboot.org/20965
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
If all strings in SMBIOS table are empty, smbios_string_table_len
function should return 2, cause every table must end with "\0\0".
Also replace "eos" field type in smbios structures
from char to u8.
Change-Id: Ia3178b0030aa71e1ff11a3fd3d102942f0027eb1
Signed-off-by: Konstantin Aladyshev <aladyshev22@gmail.com>
Reviewed-on: https://review.coreboot.org/20840
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Some configurations of AGESA boards fail to boot after commit
61be360 AGESA: Fix UMA calculations
Implementation of cbmem_find() for ENV_ROMSTAGE expects
that CBMEM has already been initialized. In the case of
LATE_CBMEM_INIT boards, this is not the case and cbmem_top()
returned NULL prior to the offending commmit.
By definition LATE_CBMEM_INIT does not have known cbmem_top()
in ENV_ROMSTAGE except for possible ACPI S3 resume path.
Change-Id: Icb8f44661d479e5ad43b123600305dcbc3ce11e1
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/20590
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
These are places that were missed on the first pass.
Change-Id: Ia6511f0325433ab020946078923bf7ad6f0362a3
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/20358
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
At process _start, the stack is expected to be aligned to a
16-byte boundary. Upon entry to any function the stack frame
must have the end of any arguments also aligned. In other words
the value of %esp+4 or %rsp+8 is always a multiple of 16 (1).
Align the stack down and change the method for executing
car_stage_entry from jmp to call which should preserve proper
alignment regardless of a 32- or 64-bit build.
Although 4-byte alignment is the minimum requirement for i386,
some AMD platforms use SSE instructions which expect 16-byte.
1) http://wiki.osdev.org/System_V_ABI
See "Initial Stack and Register State" and "The Stack Frame"
in the supplements.
BUG=chrome-os-partner:62841664
Change-Id: I8a15514f551a8e17e9fe77b8402fe0d2b106972e
Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-on: https://review.coreboot.org/20528
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The current code doesn't work for field with size > 0x3f.
Fix that by using the correct syntax, reverse engineered using iasl.
Refactor to reuse existing code.
Tested on GNU Linux 4.9 and iasl.
Change-Id: Iac3600f184e6bd36a2bcb85753110692fbcbe4b6
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/19435
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com>
- Update all symbols to use IS_ENABLED()
- Update non-romcc usage to use 'if' instead of '#if' where it
makes sense.
Change-Id: I5a84414d2d1631e35ac91efb67a0d4c1f673bf85
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/20005
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Regarding the "System Management BIOS Reference Specification"
Version: 3.1.1, Date: 2017-01-12, Laptop system enclosure is 0x09
and for Notebook it is 0x0a
Change-Id: I5538be0b434eed20d76aef6f26247e46d1225feb
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/20463
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
When the C compiler expects 16-byte alignment of the stack it is
at the call instruction. Correct existing call points from assembly
to ensure the stacks are aligned to 16 bytes at the call instruction.
Change-Id: Icadd7a1f9284e92aecd99c30cb2acb307823682c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/20314
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Fix up for 1b5eda0 (arch/x86/smbios: Fix undefined behavior) which
introduced the variable `tmp` and used it out of scope. Should fix
coverity CID 1376385 (Memory - illegal accesses (RETURN_LOCAL)).
Change-Id: I8d4f664fc54faf6beb432b939dda4ddf93cf5d3e
Found-by: Coverity Scan #1376385
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/20279
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Ryan Salsamendi <rsalsamendi@hotmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
rdrand64() is not clang friendly. Actually it looks like the
function is incorrect on 32bit x86 for all compilers including
gcc, but gcc won't care because the function is never called on
x86:
src/arch/x86/rdrand.c:51:15: error: invalid output size for constraint '=a'
: "=a" (*rand), "=qm" (carry));
^
1 error generated.
Guard the code correctly if ENV_X86_64 is not set.
Change-Id: Ia565897f5e4caaaccfcb02cf1245b150272dff68
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: https://review.coreboot.org/20298
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Fixes report found by undefined behavior sanitizer. Dereferencing a
pointer that's not aligned to the size of access is undefined behavior.
The report triggered for smbios_cpu_vendor(). Also fixes the same issue
in smbios_processor_name() found by inspection.
Change-Id: I1b7d08655edce729e107a5b6e61ee509ebde33b6
Signed-off-by: Ryan Salsamendi <rsalsamendi@hotmail.com>
Reviewed-on: https://review.coreboot.org/20154
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com>
Fixes report found by undefined behavior sanitizer. Dereferencing a
pointer that is not aligned to the size of access is undefined behavior.
Switch to memcpy() for unaligned write to EBDA_LOWMEM. Change other
write16()s in setup_ebda() to memcpy() for consistency.
Change-Id: I79814bd47a14ec59d84068b11d094dc2531995d9
Signed-off-by: Ryan Salsamendi <rsalsamendi@hotmail.com>
Reviewed-on: https://review.coreboot.org/20132
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com>
Add additional ACPI opcodes, that are going to be used in the
following commits.
Change-Id: I20c3aa5a1412e5ef68831027137e9ed9e26ddbc9
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/20087
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com>
The word 'coreboot' should always be written in lowercase, even at the
start of a sentence.
Change-Id: I7945ddb988262e7483da4e623cedf972380e65a2
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/20029
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Move the inline keyword in between the static keyword and the return
type.
Change-Id: Ibacc5ee9fabff7fec2abd5534312cf3ab1bb28cf
Signed-off-by: Logan Carlson <logancarlson@google.com>
Reviewed-on: https://review.coreboot.org/19991
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
Reviewed-by: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com>
Caching is a very architecture-specific thing, but most architectures
have a cache in general. Therefore it can be useful to have a generic
architecture-independent API to perform simple cache management tasks
from common code.
We have already standardized on the dcache_clean/invalidate naming
scheme that originally comes from ARM in libpayload, so let's just do
the same for coreboot. Unlike libpayload, there are other things than
just DMA coherency we may want to achieve with those functions, so
actually implement them for real even on architectures with
cache-snooping DMA like x86. (In the future, we may find applications
like this in libpayload as well and should probably rethink the API
there... maybe move the current functionality to a separate
dma_map/unmap API instead. But that's beyond scope of this patch.)
Change-Id: I2c1723a287f76cd4118ef38a445339840601aeea
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/19788
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com>
This patch adds a simple function that can be used to check if
CAR_GLOBALs are currently being read from CAR or from DRAM.
Change-Id: Ib7ad0896a691ef6e89e622b985417fedc43579c1
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/19787
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com>
coreboot and libpayload currently use completely different code to
perform a full cache flush on ARM64, with even different function names.
The libpayload code is closely inspired by the ARM32 version, so for the
sake of overall consistency let's sync coreboot to that. Also align a
few other cache management details to work the same way as the
corresponding ARM32 parts (such as only flushing but not invalidating
the data cache after loading a new stage, which may have a small
performance benefit).
Change-Id: I9e05b425eeeaa27a447b37f98c0928fed3f74340
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/19785
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The deprecated LATE_CBMEM_INIT function is renamed:
set_top_of_ram -> set_late_cbmem_top
Obscure term top_of_ram is replaced:
backup_top_of_ram -> backup_top_of_low_cacheable
get_top_of_ram -> restore_top_of_low_cacheable
New function that always resolves to CBMEM top boundary, with
or without SMM, is named restore_cbmem_top().
Change-Id: I61d20f94840ad61e9fd55976e5aa8c27040b8fb7
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/19377
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com>
Submodule 3rdparty/arm-trusted-firmware 236c27d21f..3944adca59
This brings in 241 new commits from the upstream arm-trusted-firmware
repository, merged to the upstream tree between December 30, 2016 and
March 18, 2017.
3944adca Merge pull request #861 from soby-mathew/sm/aarch32_fixes
..
e0f083a0 fiptool: Prepare ground for expanding the set of images at
runtime
Also setup ATF builds so that unused functions don't break the build.
They're harmless and they don't filter for these like we do.
Change-Id: Ibf5bede79126bcbb62243808a2624d9517015920
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/18954
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
AGESA and binaryPI boards have no easy way to determine correct
cbmem_top() location early enough when GFXUMA is enabled, so they
will use these functions with EARLY_CBMEM_INIT as well.
At the end of AmdInitPost() the decisions of UMA base and size
have not been written to hardware yet. The decisions are stored
inside AGESA heap object we cannot locate from coreboot proper
until after AmdInitEnv().
Modify code such that weak backup functions are only defined
for LATE_CBMEM_INIT; they are somewhat troublesome to handle.
Change-Id: Ifef4f75b36bc6dee6cd56d1d9164281d9b2a4f2a
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/19306
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
They do 64bit accesses, and gcc does the necessary fix ups to handle
32bit values as zero-padded 64bit values.
clang, however, isn't happy with it.
Change-Id: I9c8b9fe3a1adc521e393c2e2a0216f7f425a2a3e
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/19661
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Move drivers/storage into commonlib/storage to enable access by
libpayload and indirectly by payloads.
* Remove SD/MMC specific include files from include/device
* Remove files from drivers/storage
* Add SD/MMC specific include files to commonlib/include
* Add files to commonlib/storage
* Fix header file references
* Add subdir entry in commonlib/Makefile.inc to build the SD/MMC driver
* Add Kconfig source for commonlib/storage
* Rename *DEVICE* to *COMMONLIB*
* Rename *DRIVERS_STORAGE* to *COMMONLIB_STORAGE*
TEST=Build and run on Galileo Gen2
Change-Id: I4339e4378491db9a0da1f2dc34e1906a5ba31ad6
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://review.coreboot.org/19672
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Define a common area in CAR so that the storage data structures can be
shared between stages.
TEST=Build and run on Reef
Change-Id: I20a01b850a31df9887a428bf07ca476c8410d33e
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://review.coreboot.org/19300
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com>
Create new functions similar to read and write of other sizes.
Change-Id: I35a08c498f25227233604c65c45b73b1c44fae1f
Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-on: https://review.coreboot.org/19394
Tested-by: build bot (Jenkins)
Reviewed-by: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Don't start counting the buffer size amidst the BufferSize field
itself. This should help with a regression introduced in Linux
with [1] which checks the BufferSize field.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=57707a9a778
Change-Id: I7349c8e281c41384491d730dfeac3336f29992f7
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/19284
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Certain devices, such as the northbridge on AMD Opteron systems,
do not require a node in the ACPI device path. Allow such devices
to be passed over by the ACPI path generator if the device-specific
ACPI name function returns a zero-length (non-NULL) string.
Change-Id: Iffffc9a30b395b0bd6d60e411439a437e89f554e
Signed-off-by: Timothy Pearson <tpearson@raptorengineering.com>
Reviewed-on: https://review.coreboot.org/19281
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
When a platform is using postcar stage it's by definition not
tearing down cache-as-ram from within romstage prior to loading
ramstage. Because of this property there's no need to migrate
CAR_GLOBAL variables to cbmem.
Change-Id: I7c683e1937c3397cbbba15f0f5d4be9e624ac27f
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/19215
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Currently only 256 bytes can be written at a time using the
acpigen_write_return_byte_buffer or acpigen_write_byte_buffer API's
and there can be cases where the buffer size can exceed this, hence
increase the number of bytes that can be written.
Change-Id: Ifaf508ae1d5c0eb2629ca112224bfeae1c644e58
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Signed-off-by: Sowmya V <v.sowmya@intel.com>
Reviewed-on: https://review.coreboot.org/18966
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
In builds without CONFIG_VBOOT_SEPARATE_VERSTAGE, verstage files are
linked directly into the bootblock or the romstage. However, they're
still compiled with a separate "libverstage" source file class, linked
into an intermediate library and then linked into the final destination
stage.
There is no obvious benefit to doing it this way and it's unclear why it
was chosen in the first place... there are, however, obvious
disadvantages: it can result in code that is used by both libverstage
and the host stage to occur twice in the output binary. It also means
that libverstage files have their separate compiler flags that are not
necessarily aligned with the host stage, which can lead to weird effects
like <rules.h> macros not being set the way you would expect. In fact,
VBOOT_STARTS_IN_ROMSTAGE configurations are currently broken on x86
because their libverstage code that gets compiled into the romstage sets
ENV_VERSTAGE, but CAR migration code expects all ENV_VERSTAGE code to
run pre-migration.
This patch resolves these problems by removing the separate library.
There is no more difference between the 'verstage' and 'libverstage'
classes, and the source files added to them are just treated the same
way a bootblock or romstage source files in configurations where the
verstage is linked into either of these respective stages (allowing for
the normal object code deduplication and causing those files to be
compiled with the same flags as the host stage's files).
Tested this whole series by booting a Kevin, an Elm (both with and
without SEPARATE_VERSTAGE) and a Falco in normal and recovery mode.
Change-Id: I6bb84a9bf1cd54f2e02ca1f665740a9c88d88df4
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/18302
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch attempts to finish the separation between CONFIG_VBOOT and
CONFIG_CHROMEOS by moving the remaining options and code (including
image generation code for things like FWID and GBB flags, which are
intrinsic to vboot itself) from src/vendorcode/google/chromeos to
src/vboot. Also taking this opportunity to namespace all VBOOT Kconfig
options, and clean up menuconfig visibility for them (i.e. some options
were visible even though they were tied to the hardware while others
were invisible even though it might make sense to change them).
CQ-DEPEND=CL:459088
Change-Id: I3e2e31150ebf5a96b6fe507ebeb53a41ecf88122
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/18984
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
CHIPSET_PROVIDES_VERSTAGE_MAIN_SYMBOL allows the SoC directory to
provide its own main() symbol that can execute code before the generic
verstage code runs. We have now established in other places (e.g. T210
ramstage) a sort of convention that SoCs which need to run code in any
stage before main() should just override stage_entry() instead. This
patch aligns the verstage with that model and gets rid of the extra
Kconfig option. This also removes the need for aliasing between main()
and verstage(). Like other stages the main verstage code is now just in
main() and can be called from stage_entry().
Change-Id: If42c9c4fbab51fbd474e1530023a30b69495d1d6
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/18978
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Due to an unfortunate race between adding verstage support and reverting
an earlier hack that disabled the optimized assembly versions of
memcpy(), memmove() and memset() on ARM64, it seems that we never
enabled the optimized code for the verstage. This should be fixed so
that all stages use the same architecture support code.
Change-Id: I0bf3245e346105492030f4b133729c4d11bdb3ff
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/18976
Tested-by: build bot (Jenkins)
Fix the following errors and warnings detected by checkpatch.pl:
ERROR: do not use assignment in if condition
ERROR: trailing statements should be on next line
ERROR: Macros with complex values should be enclosed in parentheses
ERROR: switch and case should be at the same indent
WARNING: char * array declaration might be better as static const
WARNING: else is not generally useful after a break or return
WARNING: storage class should be at the beginning of the declaration
WARNING: void function return statements are not generally useful
WARNING: break is not useful after a goto or return
WARNING: Single statement macros should not use a do {} while (0) loop
WARNING: sizeof *t should be sizeof(*t)
WARNING: Comparisons should place the constant on the right side of the test
TEST=Build and run on Galileo Gen2
Change-Id: I39d49790c5eaeedec5051e1fab0b1279275f6e7f
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://review.coreboot.org/18865
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Some SSE instructions could take 128bit memory operands from
stack.
AGESA vendorcode was always built with SSE enabled, but until
now stack alignment was not known to cause major issues. Seems
like GCC-6.3 more likely emits instructions that depend on the
16 byte alignment of stack.
Change-Id: Iea3de54f20ff242105bce5a5edbbd76b04c0116c
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/18823
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Fix the following warning detected by checkpatch.pl:
WARNING: line over 80 characters
TEST=Build and run on Galileo Gen2
Change-Id: I3495cd30d1737d9ee728c8a9e72bd426d7a69c37
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://review.coreboot.org/18864
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Fix the following warnings detected by checkpatch.pl:
WARNING: Prefer 'unsigned int' to bare use of 'unsigned'
WARNING: plain inline is preferred over __inline__
TEST=Build and run on Galileo Gen2
Change-Id: I8ba98dfe04481a7ccf4f3b910660178b7e22a4a7
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://review.coreboot.org/18863
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Fix the following errors and warnings detected by checkpatch.pl:
ERROR: space required before the open parenthesis '('
ERROR: space prohibited after that open parenthesis '('
ERROR: space prohibited before that close parenthesis ')'
ERROR: space prohibited after that open square bracket '['
ERROR: space required after that ',' (ctx:VxV)
ERROR: space prohibited before that ',' (ctx:WxW)
ERROR: space required after that ';' (ctx:VxV)
ERROR: spaces required around that ':' (ctx:ExV)
ERROR: spaces required around that ':' (ctx:VxW)
ERROR: spaces required around that ':' (ctx:WxV)
ERROR: spaces required around that '=' (ctx:VxV)
ERROR: spaces required around that '+=' (ctx:VxV)
ERROR: spaces required around that '<=' (ctx:WxV)
ERROR: spaces required around that '||' (ctx:VxW)
ERROR: space prohibited before that '++' (ctx:WxO)
ERROR: need consistent spacing around '+' (ctx:WxV)
ERROR: spaces required around that '<' (ctx:WxV)
ERROR: spaces required around that '<' (ctx:VxV)
ERROR: need consistent spacing around '>>' (ctx:WxV)
ERROR: "(foo*)" should be "(foo *)"
ERROR: "foo* bar" should be "foo *bar"
ERROR: "foo * bar" should be "foo *bar"
ERROR: code indent should use tabs where possible
WARNING: space prohibited between function name and open parenthesis '('
WARNING: unnecessary whitespace before a quoted newline
WARNING: please, no spaces at the start of a line
WARNING: please, no space before tabs
WARNING: Unnecessary space before function pointer arguments
TEST=Build and run on Galileo Gen2
Change-Id: I2d7e1a329c6b2e8ca9633a97b595566544d7fd33
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://review.coreboot.org/18862
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Fix the following errors and warnings detected by checkpatch.pl:
ERROR: open brace '{' following function declarations go on the next line
ERROR: that open brace { should be on the previous line
ERROR: else should follow close brace '}'
WARNING: braces {} are not necessary for any arm of this statement
WARNING: braces {} are not necessary for single statement blocks
TEST=Build and run on Galileo Gen2
Change-Id: I13d1967757e106c8300a15baed25d920c52a1a95
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://review.coreboot.org/18861
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
GPIO edge interrupts can report that they are ActiveBoth and will
generate an interrupt event on both rising and falling edges.
Add a macro so this type of GPIO interrupt can be used.
BUG=b:35581264
BRANCH=none
TEST=successfully use this interrupt type on Eve
Change-Id: I91408386538e442bddcacc9840e0aa14370a446c
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/18834
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Switch some IRQ_* macros to ACPI_IRQ_* instead so they do not
fail at compile time if they are used.
BUG=b:35581264
BRANCH=none
TEST=successfully compile with ACPI_GPIO_IRQ_LEVEL_HIGH
Change-Id: Id4040eca4c7c9d8f7b4f0add411d5d6fe5ed1eb8
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/18833
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins)
Add the missing macro for ACPI_IRQ_LEVEL_HIGH so it can get
used by devicetree when necessary.
BUG=b:35585307
BRANCH=none
TEST=Add rt5514 SPI device with active high level IRQ on Eve board
and check that it is enumerated in the kernel
Change-Id: I25c7b035a198efb218f0f6b4ba3f4a1bf532bcea
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/18815
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Furquan Shaikh <furquan@google.com>
The newly assigned ACPI ID for coreboot is 'BOOT'
http://www.uefi.org/acpi_id_list
Use this new range of ACPI IDs of "BOOTxxxx" for coreboot specific
ACPI objects instead of the placeholder range of "GOOGCBxx".
Change-Id: I10b30b5a35be055c220c85b14a06b88939739a31
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/18521
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Change-Id: Ie0d35c693ed5cc3e890279eda289bd6d4416d9e6
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/18376
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
- Remove warnings about code using deprecated declarations such as:
plat/mediatek/mt8173/bl31_plat_setup.c: In function 'bl31_platform_setup':
plat/mediatek/mt8173/bl31_plat_setup.c:175:2: warning:
'arm_gic_setup' is deprecated [-Wdeprecated-declarations]
include/drivers/arm/arm_gic.h:44:6: note: declared here:
void arm_gic_setup(void) __deprecated;
- Disable pedantic warnings to get rid of these warnings:
In file included from plat/mediatek/mt8173/bl31_plat_setup.c:36:0:
plat/mediatek/mt8173/include/mcucfg.h:134:21: error:
enumerator value for 'MP1_CPUCFG_64BIT' is not an integer constant
expression [-Werror=pedantic]
MP1_CPUCFG_64BIT = 0xf << MP1_CPUCFG_64BIT_SHIFT
Change-Id: Ibf2c4972232b2ad743ba689825cfe8440d63e828
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/17995
Tested-by: build bot (Jenkins)
Reviewed-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Nico Huber <nico.h@gmx.de>
In order to allow GPIOs to be set/clear according to their polarity,
provide helper functions that check for polarity and call set/clear
SoC functions for generating ACPI code.
BUG=None
BRANCH=None
TEST=Verified that the ACPI code generated remains the same as before
for reef.
Change-Id: Ie8bdb9dc18e61a4a658f1447d6f1db0b166d9c12
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/18427
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
This is done to avoid any conflicts with same IRQ enums defined by other
drivers.
BUG=None
BRANCH=None
TEST=Compiles successfully
Change-Id: I539831d853286ca45f6c36c3812a6fa9602df24c
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/18444
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Using x86 RDRAND instruction, two functions are supplied to
generate a 32bit or 64bit number.
One potential usage is the sealing key generation for SGX.
BUG=chrome-os-partner:62438
BRANCH=NONE
TEST=Tested on Eve to generate a 64bit random number.
Change-Id: I50cbeda4de17ccf2fc5efc1fe04f6b1a31ec268c
Signed-off-by: Robbie Zhang <robbie.zhang@intel.com>
Reviewed-on: https://review.coreboot.org/18362
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Coverity is detecting 'sp' as a variable which has not been initialized.
This is obviously not correct, so this patch *TRIES* to mark it as false
I'm not positive that this will work because the annotation needs to go
on the line above the error, but this error is inside of a # define.
Does the whole #define count as one line? Can it go on the line
above the #define in the .h file? Does it have to precede every line
where the #define is used? The documentation doesn't make this clear.
Should suppress coverity issues: 1368525 & 1368527
uninit_use: Using uninitialized value sp.
Change-Id: Ibae5e206c4ff47991ea8a11b6b59972b24b71796
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/18247
Tested-by: build bot (Jenkins)
Reviewed-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Add individual macros for the various interrupt types so
they can be used in devicetree.
BUG=chrome-os-partner:58666
TEST=nothing uses this yet, will be used in an upcoming commit
Change-Id: I2a569f60fcc0815835615656b09670987036b848
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/18392
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Move the function that adds a power resource block from
i2c/generic to the acpi device code at src/arch/x86/acpi_device.c
so it can be used by more drivers.
BUG=chrome-os-partner:61233
TEST=verify SSDT table generation is unchanged
Change-Id: I0ffb61a4f46028cbe912e85c0124d9f5200b9c76
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/18391
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Add a new callback to spi_ctrlr structure - get_config - to obtain
configuration of SPI bus from the controller driver. Also, move common
config definitions from acpi_device.h to spi-generic.h
BUG=chrome-os-partner:59832
BRANCH=None
TEST=Compiles successfully
Change-Id: I412c8c70167d18058a32041c2310bc1c884043ce
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/18337
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
The four options are only used in X86:
- BOOTBLOCK_SIMPLE
- BOOTBLOCK_NORMAL
- BOOTBLOCK_SOURCE
- SKIP_MAX_REBOOT_CNT_CLEAR
Move them all into src/arch/x86/Kconfig - this puts them in the chipset
menu instead of general setup.
Verified that this makes no significant changes to any config file.
Change-Id: I2798ef67a8c6aed5afac34322be15fdf0c794059
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/17909
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Add VFCT table to provide PCI Optiom Rom for
AMD graphic devices.
Useful for GNU Linux payloads and embedded dual GPU systems.
Tested on Lenovo T500 with AMD RV635 as secondary gpu.
Original Change-Id: I3b4a587c71e7165338cad3aca77ed5afa085a63c
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Change-Id: I4dc00005270240c048272b2e4f52ae46ba1c9422
Reviewed-on: https://review.coreboot.org/18192
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
We rely on gnu make, so we can expect the jobserver to be around in
parallel builds, too. Avoids some make warnings and slightly speeds up
the build if those sub-makes are executed (eg for arm-trusted-firmware
and vboot).
Change-Id: I0e6a77f2813f7453d53e88e0214ad8c1b8689042
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/18263
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
This fixes building coreboot with -std=gnu11 on gcc 4.9.x
Also needs fix ups for asus/kcma-d8 and asus/kgpe-d16 due to the missing
type.
Change-Id: I920d492a1422433d7d4b4659b27f5a22914bc438
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/18220
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
The new name and location make more sense:
- The instruction used to call into machine mode isn't called "ecall"
anymore; it's mcall now.
- Having SBI_ in the name is slightly wrong, too: these numbers are not
part of the Supervisor Binary Interface, they are just used to
forward SBI calls (they could be renumbered arbitrarily without
breaking an OS that's run under coreboot).
Also remove mcall_dev_{req,resp} and the corresponding mcall numbers,
which are no longer used.
Change-Id: I76a8cb04e4ace51964b1cb4f67d49cfee9850da7
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/18146
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
SBI calls, as it turned out, were never right.
They did not set the stack correctly on traps.
They were not correctly setting the MIP instead of the SIP
(although this was not really well documented).
On Harvey, we were trying to avoid using them,
and due to a bug in SPIKE, our avoidance worked.
Once SPIKE was fixed, our avoidance broke.
This set of changes is tested and working with Harvey
which, for the first time, is making SBI calls.
It's not pretty and we're going to want to rework
trap_util.S in coming days.
Change-Id: Ibef530adcc58d33e2c44ff758e0b7d2acbdc5e99
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/18097
Tested-by: build bot (Jenkins)
cmos_post_init() is called in src/arch/x86/bootblock_simple.c, and
that function is reponsible for bootstrapping the cmos post register
contents. Without this function being called none of the cmos post
functionality works correctly. Therefore, add a call to lib/bootblock.c
which the C_ENVIRONMENT_BOOTBLOCK SoCs use.
BUG=chrome-os-partner:61546
Change-Id: I2e3519f2f3f2c28e5cba26b5811f1eb0c2a90572
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/18043
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
FSP v2.0 Driver supports TempRamInit & TempRamExit APIs to initialize
& tear down Cache-As-Ram. Add TempRamInit & TempRamExit usage to
ApolloLake SoC when CONFIG_FSP_CAR is enabled.
Verified on Intel Leaf Hill CRB and confirmed that Cache-As-Ram
is correctly set up and torn down using the FSP v2.0 APIs
without coreboot implementation of CAR init/teardown.
Change-Id: Ifd6fe8398ea147a5fb8c60076b93205bb94b1f25
Signed-off-by: Brenton Dong <brenton.m.dong@intel.com>
Reviewed-on: https://review.coreboot.org/17063
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
FSP v2.0 Specification adds APIs TempRamInit & TempRamExit for
Cache-As-Ram initialization and teardown. Add fsp2_0 driver
support for TempRamInit & TempRamExit APIs.
Verified on Intel Leaf Hill CRB and confirmed that Cache-As-Ram
is correctly set up and torn down using the FSP v2.0 APIs
without coreboot implementation of CAR init/teardown.
Change-Id: I482ff580e1b5251a8214fe2e3d2d38bd5f3e3ed2
Signed-off-by: Brenton Dong <brenton.m.dong@intel.com>
Reviewed-on: https://review.coreboot.org/17062
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The user and supervisor counters could not be safely enabled
before as the register numbers were not finalized. Now that
everyone agrees, we can enable them. Until we are sure the
toolchains are caught up, we use the hardcode name with
the register names in comments. As soon as toolchains
settle down we'll do one more pass and convert to
the symbolic names.
Tested on lowrisc bitstream and SPIKE simulator.
Change-Id: I21fe5cac44fafe4b7806e004c179aa27541be4b6
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: https://review.coreboot.org/17920
Tested-by: build bot (Jenkins)
Reviewed-by: Alex Bradbury <asb@lowrisc.org>
Reviewed-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-by: Andrew Waterman <aswaterman@gmail.com>
Just before jumping to OS wakeup vector do the same
tasks to signal coreboot completion that would be done
before entry to payload on normal boot path.
Change-Id: I7514c498f40f2d93a4e83a232ef4665f5c21f062
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17794
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
RISCV requires that timer interrupts be handled in machine
mode and delegated as necessary. Also you can only reset the
timer interrupt by writing to mtimecmp. Further, you must
write a number > mtime, not just != mtime. This rather clumsy
situation requires that we write some value into the future
into mtimecmp lest we never be able to leave machine mode as
the interrupt either is not cleared or instantly reoccurs.
This current code is tested and works for harvey (Plan 9)
timer interrupts.
Change-Id: I8538d5fd8d80d9347773c638f5cbf0da18dc1cae
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: https://review.coreboot.org/17807
Tested-by: build bot (Jenkins)
Reviewed-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
This reverts commit c86da67436.
Alas, I have to disagree with this in every single line. The comment
added to the top of the file only applies to a single function therein
which sits over a hundred lines below. That's not much helpful. More-
over, the link in the comment is already down ofc.
The comment is also irritating as it doesn't state in which way (enco-
ding!) it applies to the code, which presumably led to the wrong in-
terpretation of the IDs.
At last, if anything should have changed it is the strings, the IDs
are resolved to. `smbios_fill_dimm_manufacturer_from_id()` has to
resolve the IDs it gets actually fed and not a random selection from
any spec.
Since I digged into it, here's why the numbers are correct: The func-
tion started with the SPD encoding of DDR3 in mind. There, the lower
byte is the number of a "bank" of IDs with an odd-parity in the upper
most bit. The upper byte is the ID within the bank. The "correction"
was to clear the parity bit for naught. The function was later exten-
ded with IDs in the DDR2-SPD encoding (which is actually 64-bit not
16). There, a byte, starting from the lowest, is either an ID below
127 plus odd-parity, or 127 which means look in the next byte/bank.
Unused bytes seem to be filled with 0xff, I guess from the 0xff2c.
Change-Id: Icdb48e4f2c102f619fbdca856e938e85135cfb18
Reviewed-on: https://review.coreboot.org/17873
Tested-by: build bot (Jenkins)
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
Sometime preram cbmem logs are truncated due to lack of
space (default preram cbmem console size is 0xc00).
Provide Kconfig option to configure preram cbmem console
size so that mainboard can configure it to required value.
Change-Id: I221d9170c547d41d8bd678a3a8b3bca6a76ccd2e
Signed-off-by: Naresh G Solanki <naresh.solanki@intel.com>
Reviewed-on: https://review.coreboot.org/17839
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Create postcar_frame object without placing stack in CBMEM.
This way same cache_as_ram.inc code can be used unmodified.
Change-Id: Ic5ed404ce268ee881e9893dd434534231aa2bc88
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17700
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
There are circumstances where the APs need to run a piece of
code later in the boot flow. The current MP init just parks
the APs after MP init is completed so there's not an opportunity
to target running a piece of code on all the APs at a later time.
Therefore, provide an option, PARALLEL_MP_AP_WORK, that allows
the APs to perform callbacks.
BUG=chrome-os-partner:60657
BRANCH=reef
Change-Id: I849ecfdd6641dd9424943e246317cd1996ef1ba6
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/17745
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Lijian Zhao <lijian.zhao@intel.com>
Doing PCI config operations via MMIO window by default is a
requirement, if supported by the platform. This means chipset
or CPU code must enable MMCONF operations early in bootblock
already, or before platform-specific romstage entry.
Platforms are allowed to have NO_MMCONF_SUPPORT only in the
case it is actually not implemented in the silicon.
Change-Id: Id4d9029dec2fe195f09373320de800fcdf88c15d
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17693
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Resource allocator and 64-bit PCI BARs will need it and
PCI use is not really restricted to x86.
Change-Id: Ie97f0f73380118f43ec6271aed5617d62a4f5532
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17733
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
MMCONF was explicitly used here to avoid races of 0xcf8/0xcfc access
being non-atomic and/or need to access 4kiB of PCI config space.
All these platforms now have MMCONF_SUPPORT_DEFAULT.
I liked the style of code in pci_mmio_cfg.h more, and used those to
replace the ones in io.h.
Change-Id: Ib5e6a451866c95d1edb9060c7f94070830b90e92
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17689
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Linux needs these SBI calls, but so far it seems to work when they don't
do anything.
Change-Id: I2cd0bb3ab91e89805fed84ec87e4a48ce70c3a46
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/17593
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Stash and reload postcar stage in the stage cache for increased
S3 resume speed. It's impact is small (2 ms or so), but there's
no need to go to the boot media on resume to reload something
that was already loaded. This aligns with the same paths we take
on ramstage as well.
Change-Id: I4313794826120853163c7366e81346858747ed0a
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/17649
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Instead of having callers query the romstage handoff resume
status by inspecting the object themselves add
romstage_handoff_is_resume() so that the same information
can be queried easily.
Change-Id: I40f3769b7646bf296ee4bc323a9ab1d5e5691e21
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/17647
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
When running with relocatable ramstage, the gdt loaded from c_start.S
is already in CBMEM (high memory). Thus, there's no need to create
a new copy of the gdt and reload.
Change-Id: I2750d30119fee01baf4748d8001a672d18a13fb0
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/17504
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
o The first 4G of physical address space is now mapped at 0.
o The first 4G of physical address space is now mapped at 1 << 38.
o The first 2G of DRAM (2 - 4 GiB of physical address space)
is now mapped at the top of memory save for the last 4K
i.e. at 0xffffffff80000000, with SBI page at the very top.
Of these, we hope to remove the *most* of the
last one once the gcc toolchain
can handle linking programs that can run at "top 33 bits
of address not all ones (but bit 63 set)". The 4K mapping
of the top of the 64 bit address space will always remain,
however, for SBI calls.
Change-Id: I77b151720001bddad5563b0f8e1279abcea056fa
Reviewed-on: https://review.coreboot.org/17403
Tested-by: build bot (Jenkins)
Reviewed-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
On S3 resume path, CBMEM_ID_GDT already exists but we only printed
the final "ok" string. Always tell GDT is about to be moved.
Change-Id: Ic91c5389cf4d47d28a6c54db152c18541c413bc1
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17500
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
coreboot's build system picks up the BL31 image as an ELF from the ARM
Trusted Firmware submodule and inserts it into CBFS. However, the
generic 'bl31' build target we run in the ARM Trusted Firmware build
system also generates a raw bl31.bin binary file.
We don't need that binary, and with the recently added support for
multiple non-contiguous program segments in BL31 it can grow close to
4GB in size (by having one section mapped near the start and one near
the end of the address space). To avoid clogging up people's hard drives
with 4GB of zeroes, let's only build the target we actually need.
BRANCH=gru
BUG=chrome-os-partner:56314,chromium:661124
TEST=FEATURES=noclean emerge-kevin coreboot, confirm that there's no
giant build/3rdparty/arm-trusted-firmware/bl31.bin file left in the
build artifacts, and that we still generate .d prerequisite files.
Change-Id: I8e7bd50632f7831cc7b8bec69025822aec5bad27
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 31699820f4c36fd441a3e7271871af4e1474129f
Original-Change-Id: Iaa073ec11dabed7265620d370fcd01ea8c0c2056
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/407110
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/17380
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
In function definition of acpigen_write_byte_buffer, buffer size written
using acpigen_emit_byte gives wrong results in generated AML code for
buffer size greater than one.
Write buffer size using acpigen_write_integer as per ACPI spec 5.0
section 20.2.5.4 BufferOp.
Change-Id: I0dcb25b24a1b4b592ad820c95f7c2df67a016594
Signed-off-by: Naresh G Solanki <naresh.solanki@intel.com>
Reviewed-on: https://review.coreboot.org/17444
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
acpigen_write_if_lequal is used to generate ACPI code to check if two
operands are equal, where operand1 is an ACPI op and operand2 is an
integer. Update name of function to reflect this and fix code to write
integer instead of emitting byte for operand2.
TEST=Verified by disassembling SSDT on reef that ACPI code generated for
If with operand2 greater than 1 is correct.
If ((Local1 == 0x02))
{
Return (0x01)
}
Else
{
Return (Buffer (One)
{
0x00 /* . */
})
}
Change-Id: If643c078b06d4e2e5a084b51c458dd612d565acc
Reported-by: Naresh G Solanki <naresh.solanki@intel.com>
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/17421
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This variable can be set in a debugger (e.g. Spike)
to finely control which traps go to coreboot and
which go to the supervisor.
Change-Id: I292264c15f002c41cf8d278354d8f4c0efbd0895
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: https://review.coreboot.org/17404
Tested-by: build bot (Jenkins)
Reviewed-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
The riscv 1.9 standard defines a textual config string to be passed
to kernels and hypervisors. Change the payload function to pass
this string in a0.
Change-Id: I3be7f1712accf2d726704e4c970f22749d3c3f36
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: https://review.coreboot.org/17254
Tested-by: build bot (Jenkins)
Reviewed-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
These functions will allow us to remove hardcodes,
as long as we can verify the qemu and lowrisc targets
implement the configstring correctly. Hence, for the
most part, we'll start with mainboard changes first.
Define a new config variable, CONFIG_RISCV_CONFIGSTRING,
which has a default value that works on all existing
systems but which can be changed
as needed for a new SOC or mainboard.
Change-Id: I7dd3f553d3e61f1c49752fb04402b134fdfdf979
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: https://review.coreboot.org/17256
Tested-by: build bot (Jenkins)
Reviewed-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Add implementation to use actual requirements of ramstage size
for S3 resume backup in CBMEM. The backup covers complete pages of 4 KiB.
Only the required amount of low memory is backed up when ACPI_TINY_LOWMEM_BACKUP
is selected for the platform. Enable this option for AGESA and binaryPI, other
platforms (without RELOCATABLE_RAMSTAGE) currently keep their romstage ramstack
in low memory for s3 resume path.
Change-Id: Ide7ce013f3727c2928cdb00fbcc7e7e84e859ff1
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/15255
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Add acpigen_write_opregion that generates ACPI AML code for OperationRegion,
region name, region space, region length & region size are inputs.
Add acpigen_write_field that generates ACPI AML code for Field.
Operation region name & field list are inputs.
Change-Id: I578834217d39aa3b0d409eb8ba4b5f7a31969fa8
Signed-off-by: Naresh G Solanki <naresh.solanki@intel.com>
Reviewed-on: https://review.coreboot.org/17113
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins)
Note that currently, traps are only handled by the trap handler
installed in the bootblock. The romstage and ramstage don't override it.
TEST=Booted emulation/spike-qemu and lowrisc/nexys4ddr with a linux
payload. It worked as much as before (Linux didn't boot, but it
made some successful SBI calls)
Change-Id: Icce96ab3f41ae0f34bd86e30f9ff17c30317854e
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/17057
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
After I did a new toolchain build, I found the
the mhartid register value is wrong for Spike.
The docs seem to agree with Spike, not the
code the toolchain produces?
Until such time as the bitstreams and toolchain can find
a way to agree, just hardcode it. We've been playing this game
for two years now so this is hardly a new approach.
This is intentionally ugly because we really need the
toolchains and emulators and bitstreams to sync up,
and that's not happening yet. Lowrisc
allegedly implements the v1.9 spec but it's PTEs are clearly
1.7. Once it all settles down we can just use constants
supplied by the toolchain.
I hope the syncup will have happened by the workshop in November.
This gets spike running again.
Change-Id: If259bcb6b6320ef01ed29a20ce3d2dcfd0bc7326
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: https://review.coreboot.org/17183
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Currently, the only supported DSM type is I2C
HID(3CDFF6F7-4267-4555-AD05-B30A3D8938DE). This provides the required
callbacks for generating ACPI AML codes for different function
identifiers for I2C HID.
BUG=chrome-os-partner:57846
Change-Id: Ia403e11f7ce4824956e3c879547ec927478db7b1
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/17091
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add acpigen_write_dsm that generates ACPI AML code for _DSM
method. Caller should provide set of callbacks with callback[i]
corresponding to function index i of DSM method. Local0 and Local1
should not be used in any of the callbacks.
BUG=chrome-os-partner:57846
Change-Id: Ie18cba080424488fe00cc626ea50aa92c1dbb199
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/17090
Tested-by: build bot (Jenkins)
Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This version of coreboot successfully starts a Harvey (Plan 9) kernel as a payload,
entering main() with no supporting assembly code for startup. The Harvey port
is not complete so it just panics but ... it gets started.
We provide a standard payload function that takes a pointer argument
and makes the jump from machine to supervisor mode;
the days of kernels running in machine mode are over.
We do some small tweaks to the virtual memory code. We temporarily
disable two functions that won't work on some targets as register
numbers changed between 1.7 and 1.9. Once lowrisc catches up
we'll reenable them.
We add the PAGETABLES to the memlayout.ld and use _pagetables in the virtual
memory setup code.
We now use the _stack and _estack from memlayout so we know where things are.
As time goes on maybe we can kill all the magic numbers.
Change-Id: I6caadfa9627fa35e31580492be01d4af908d31d9
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: https://review.coreboot.org/17058
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Since reading/toggling of GPIOs is platform-dependent task, provide an
interface with common functions to generate ACPI AML code for
manipulating GPIOs:
1. acpigen_soc_read_rx_gpio
2. acpigen_soc_get_tx_gpio
3. acpigen_soc_set_tx_gpio
4. acpigen_soc_clear_tx_gpio
Provide weak implementations of above functions. These functions are
expected to be implemented by every SoC that uses ACPI. This allows
drivers to easily generate ACPI AML code to interact GPIOs.
BUG=chrome-os-partner:55988
Change-Id: I3564f15a1cb50e6ca6132638447529648589aa0e
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/17080
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add functions to support generation of following AML operations:
1. PowerResource
2. Store
3. Or
4. And
5. Not
6. Debug
7. If
8. Else
9. Serialized method
BUG=chrome-os-partner:55988
Change-Id: I606736b38e6a55ffdc3e814b6ae0fa367ef7595b
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/17079
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
Instead of using hard-coded values for emitting op codes and prefix
codes, define and use enum constants. With this change, it becomes
easier to read the code as well.
BUG=chrome-os-partner:55988
Change-Id: I6671b84c2769a8d9b1f210642f3f8fd3d902cca2
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/17078
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
The stack pointer (SP) is already printed in print_trap_information.
Don't print it again in handle_misaligned_{load,store}.
Change-Id: I156cf5734a16605decc2280e54e6db3089e094a2
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/16996
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
The pointers printed on unaligned memory accesses are now aligned to
those printed at the end of print_trap_information.
Change-Id: Ifec1cb639036ce61b81fe8d0a9b14c00d5b2781a
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/16983
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
TEST=Compiled for and ran on spike; it booted as before.
Change-Id: Id173643a3571962406f9191db248b206235dca35
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/16995
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
spike_util.h:
- (LOG_)REGBYTES and STORE are already defined in
arch/riscv/include/bits.h.
- TOHOST_CMD, FROMHOST_* are helper macros for the deprecated
Host-Target Interface (HTIF).
qemu_util.c:
- mcall_query_memory now uses mprv_write_ulong instead of first
translating the address and then accessing it normally. Thus,
translate_address isn't used anymore.
- Several functions used the deprecated HTIF CSRs mtohost/mfromhost.
They have mostly been replaced by stub implementations.
- htif_interrupt and testPrint were unused and have been deleted.
spike_util.c:
- translate_address and testPrint were unused and have been deleted.
After this commit, spike_util.c and qemu_util.c are exactly the same and
can be moved to a common location.
Change-Id: I1789bad8bbab964c3f2f0480de8d97588c68ceaf
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/16985
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Instead of hard-coding the polarity of the GPIO to active high/low,
accept it as a parameter in devicetree. This polarity can then be used
while calling into acpi_dp_add_gpio to determine the active low status
correctly.
BUG=chrome-os-partner:55988
BRANCH=None
TEST=Verified that correct polarity is set for reset-gpio on reef.
Change-Id: I4aba4bb8bd61799962deaaa11307c0c5be112919
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/16877
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Only acpi_dp of type DP_TYPE_TABLE is allowed to be an array. This
DP_TYPE_TABLE does not have a value which is written. Thus,
acpi_dp_write_array needs to start counting from the next element type
in the array. Fix this by updating the initialization in for loop for
writing array elements.
BUG=chrome-os-partner:55988
BRANCH=None
TEST=Verified that the correct number of elements are passed for
add_gpio in maxim sdmode-gpio.
Change-Id: I8e1e540d66086971de2edf0bb83494d3b1dbd176
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/16871
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Switch the BL31 (ARM Trusted Firmware) format to payload so that it can
have multiple independent segments. This also requires disabling the region
check since SRAM is currently faulted by that check.
This has been tested with Rockchip's pending change:
https://chromium-review.googlesource.com/#/c/368592/3
with the patch mentioned on the bug at #13.
BUG=chrome-os-partner:56314
BRANCH=none
TEST=boot on gru and see that BL31 loads and runs. Im not sure if it is
correct though:
CBFS: Locating 'fallback/payload'
CBFS: Found @ offset 1b440 size 15a75
Loading segment from ROM address 0x0000000000100000
code (compression=1)
New segment dstaddr 0x18104800 memsize 0x117fbe0 srcaddr 0x100038 filesize 0x15a3d
Loading segment from ROM address 0x000000000010001c
Entry Point 0x0000000018104800
Loading Segment: addr: 0x0000000018104800 memsz: 0x000000000117fbe0 filesz: 0x0000000000015a3d
lb: [0x0000000000300000, 0x0000000000320558)
Post relocation: addr: 0x0000000018104800 memsz: 0x000000000117fbe0 filesz: 0x0000000000015a3d
using LZMA
[ 0x18104800, 18137d90, 0x192843e0) <- 00100038
Clearing Segment: addr: 0x0000000018137d90 memsz: 0x000000000114c650
dest 0000000018104800, end 00000000192843e0, bouncebuffer ffffffffffffffff
Loaded segments
BS: BS_PAYLOAD_LOAD times (us): entry 0 run 125150 exit 1
Jumping to boot code at 0000000018104800(00000000f7eda000)
CPU0: stack: 00000000ff8ec000 - 00000000ff8f0000, lowest used address 00000000ff8ef3d0, stack used: 3120 bytes
CBFS: 'VBOOT' located CBFS at [402000:44cc00)
CBFS: Locating 'fallback/bl31'
CBFS: Found @ offset 10ec0 size 8d0c
Loading segment from ROM address 0x0000000000100000
code (compression=1)
New segment dstaddr 0x10000 memsize 0x40000 srcaddr 0x100054 filesize 0x8192
Loading segment from ROM address 0x000000000010001c
code (compression=1)
New segment dstaddr 0xff8d4000 memsize 0x1f50 srcaddr 0x1081e6 filesize 0xb26
Loading segment from ROM address 0x0000000000100038
Entry Point 0x0000000000010000
Loading Segment: addr: 0x0000000000010000 memsz: 0x0000000000040000 filesz: 0x0000000000008192
lb: [0x0000000000300000, 0x0000000000320558)
Post relocation: addr: 0x0000000000010000 memsz: 0x0000000000040000 filesz: 0x0000000000008192
using LZMA
[ 0x00010000, 00035708, 0x00050000) <- 00100054
Clearing Segment: addr: 0x0000000000035708 memsz: 0x000000000001a8f8
dest 0000000000010000, end 0000000000050000, bouncebuffer ffffffffffffffff
Loading Segment: addr: 0x00000000ff8d4000 memsz: 0x0000000000001f50 filesz: 0x0000000000000b26
lb: [0x0000000000300000, 0x0000000000320558)
Post relocation: addr: 0x00000000ff8d4000 memsz: 0x0000000000001f50 filesz: 0x0000000000000b26
using LZMA
[ 0xff8d4000, ff8d5f50, 0xff8d5f50) <- 001081e6
dest 00000000ff8d4000, end 00000000ff8d5f50, bouncebuffer ffffffffffffffff
Loaded segments
INFO: plat_rockchip_pmusram_prepare pmu: code d2bfe625,d2bfe625,80
INFO: plat_rockchip_pmusram_prepare pmu: code 0xff8d4000,0x50000,3364
INFO: plat_rockchip_pmusram_prepare: data 0xff8d4d28,0xff8d4d24,4648
NOTICE: BL31: v1.2(debug):
NOTICE: BL31: Built : Sun Sep 4 22:36:16 UTC 2016
INFO: GICv3 with legacy support detected. ARM GICV3 driver initialized in EL3
INFO: plat_rockchip_pmu_init(1189): pd status 3e
INFO: BL31: Initializing runtime services
INFO: BL31: Preparing for EL3 exit to normal world
INFO: Entry point address = 0x18104800
INFO: SPSR = 0x8
Change-Id: Ie2484d122a603f1c7b7082a1de3f240aa6e6d540
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 8c1d75bff6e810a39776048ad9049ec0a9c5d94e
Original-Change-Id: I2d60e5762f8377e43835558f76a3928156acb26c
Original-Signed-off-by: Simon Glass <sjg@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/376849
Original-Commit-Ready: Simon Glass <sjg@google.com>
Original-Tested-by: Simon Glass <sjg@google.com>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/16706
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Use the GOOG ACPI ID until there is an official ID allocation
for coreboot. Since I administer this range I allocated
0xCB00-0xCBFF for coreboot use.
Change-Id: I38ac0a0267e21f7282c89ef19e8bb72339f13846
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/16724
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
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: I551276f36ff0d2eb5b5ea13f019cdf4a3c749a09
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/16669
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
These values are found in util/cbfstool/cbfs.h.
Change-Id: Iea4807b272c0309ac3283e5a3f5e135da6c5eb66
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/16646
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tidy up a few things which look incorrect in this file.
BUG=chrome-os-partner:56314
BRANCH=none
TEST=build for gru
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: 434e9ceb5fce69b28de577cdc3541a439871f5ed
Original-Change-Id: Ida7a62ced953107c8e1723003bcb470c81de4c2f
Original-Signed-off-by: Simon Glass <sjg@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/376848
Original-Commit-Ready: Simon Glass <sjg@google.com>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Change-Id: If8c283fe8513e6120de2fd52eab539096a4e0c9b
Reviewed-on: https://review.coreboot.org/16584
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
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>
Ron Minnich writes: "we'll change cbfstool to put a header on the
payload to jump to supervisor if that is desired. The principal here is
that payloads are always started in machine mode, but we want to set the
page tables up for them."
Change-Id: I5cbfc90afd3febab33835935f08005136a3f47e9
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/15510
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
There is a second ACPI _DSD document from the UEFI Forum that details
how _DSD style tables can be nested, creating a tree of similarly
formatted tables. This document is linked from acpi_device.h.
In order to support this the device property interface needs to be
more flexible and build up a tree of properties to write all entries
at once instead of writing each entry as it is generated.
In the end this is a more flexible solution that can support drivers
that need child tables like the DA7219 codec, while only requiring
minor changes to the existing drivers that use the device property
interface.
This was tested on reef (apollolake) and chell (skylake) boards to
ensure that there was no change in the generated SSDT AML.
Change-Id: Ia22e3a5fd3982ffa7c324bee1a8d190d49f853dd
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/15537
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Have acpigen_write_package() return a pointer to the package element
counter so it can be used for dynamic package generation where needed.
Change-Id: Id7f6dd03511069211ba3ee3eb29a6ca1742de847
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/15536
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Have the different acpi_device_ path functions use a different static
buffer so they can be called interchangeably.
Change-Id: I270a80f66880861d5847bd586a16a73f8f1e2511
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/15521
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Add a function for an SOC to define that will allow it to map the
SOC-specific gpio_t value into an appropriate ACPI pin. The exact
behavior depends on the GPIO implementation in the SOC, but it can
be used to provide a pin number that is relative to the community or
bank that a GPIO resides in.
Change-Id: Icb97ccf7d6a9034877614d49166bc9e4fe659bcf
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/15512
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The different entry points (0x100, 0x140, ...), which were defined in
the RISC-V Privileged Specification 1.7, aren't used anymore. Instead
the Spike bootrom jumps at the start of our image, and traps are handled
through mtvec.
Change-Id: I865adec5e7a752a25bac93a45654ac06e27d5a8e
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/15283
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Some of the support functions will be built for romstage
once HIGH_MEMORY_SAVE is removed.
Change-Id: I43ed9067cf6b2152a354088c1dcb02d374eb6efe
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/15242
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
No need to make low memory backup unless we are on
S3 resume path.
Hide those details from ACPI.
Change-Id: Ic08b6d70c7895b094afdb3c77e020ff37ad632a1
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/15241
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Without RELOCATABLE_RAMSTAGE have WB cache large enough
to cover the greatest ramstage needs, as there is no benefit
of trying to accurately match the actual need. Choose
this to be bottom 16MiB.
With RELOCATABLE_RAMSTAGE write-back cache of low ram is
only useful for bottom 1MiB of RAM as a small part of this gets used
during SMP initialisation before proper MTRR setup.
Change-Id: Icd5f8461f81ed0e671130f1142641a48d1304f30
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/15249
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This is where the RAM is (now), on RISC-V.
We need to put coreboot.rom in RAM because Spike (at the moment) only
supports loading code into the RAM, not into the boot ROM.
Change-Id: I6c9b7cffe5fa414825491ee4ac0d2dad59a2d75c
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/15149
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Variable name shadows parameter name used on other functions,
and it can be local anyway after function removal.
Change-Id: I3164b15b33d877fef139f48ab2091e60e3124c3b
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/15240
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Add Ramaxel DRAM manufacturer id.
Tested on Lenovo T520 and DDR3-1600 DIMM (RMT3170eb86e9w16).
The manufacturer name shows up in dmidecode.
Change-Id: I14cdc82c09f0f990e2ba18083748d11d79e53874
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/15183
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
This is more of ACPI S3 resume and x86 definition than CBMEM.
Change-Id: Iffbfb2e30ab5ea0b736e5626f51c86c7452f3129
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/15190
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This Kconfig is deprecated, new platforms need to locate
ramstage stack in CBMEM instead.
Change-Id: I20ece297302321337cc2ce17fdef0c55242a4fc3
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/15189
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
In the default (medlow) code model, pointers are loaded with a lui, addi
instruction sequence:
lui a0, 0xNNNNN
addi a0, a0, 0xNNN
Since lui sign-extends bits 32-63 from bit 31 on RV64, lui/addi can't
load pointers just above 0x80000000, where RISC-V's RAM now lives.
The medany code model gets around this restriction by loading pointers
trough auipc and addi:
auipc a0, 0xNNNNN
addi a0, a0, 0xNNN
This way, any pointer within the current pc ±2G can be loaded, which is
by far sufficient for coreboot.
Change-Id: I77350d9218a687284c1337d987765553cf915a22
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/15148
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The uart8250mem driver needs it.
Change-Id: I09e6a17cedf8a4045f008f5a0d225055d745e8db
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/15147
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Not all x86 architectures support the mm register set. The default
routine that saves BIST in mm0 and a "weak" routine that saves the TSC
value in mm2:mm1. Select the Kconfig value
BOOTBLOCK_SAVE_BIST_AND_TIMESTAMP to provide a replacement routine to
save the BIST and timestamp values.
TEST=Build and run on Amenia and Galileo Gen2.
Change-Id: I8119e74664ac3522c011767d424d441cd62545ce
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/15126
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Use Kconfig values to enable debug spinloops in assembly_entry.S. This
makes it easy to debug the assembly code.
TEST=Build and run on Galileo Gen2
Change-Id: Ic56bf2260b8e3181403623961874c9289f3ca945
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://review.coreboot.org/15135
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Conditionally add a debug spinloop to enable easy connection of JTAG
debuggers.
TEST=Build and run on Galileo Gen2 with a JTAG debugger.
Change-Id: I7a21f9e6bfb10912d06ce48447c61202553630d0
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/15127
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Support ROM_SIZE greater than 16 MiB. Work around SMBIOS rom size
limitation of 16 MiB by specifying 16 MiB as the ROM size.
TEST=Build and run on neoncity
Change-Id: I3f464599cd8a1b6482db8b9deab03126c8b92128
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://review.coreboot.org/15108
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Don't write reserved bits in the Quark platform. Follow the previous
boot behavior and just enable SSE.
TEST=Build and run on Galileo Gen2
Change-Id: Ib3143eff02b2610b595bd666c10d70e43103ccda
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/15128
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Leave it for the platform to fill in the string.
Change-Id: I7b4fe585f8d1efc8c9743f0d8b38de1f98124aab
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/14996
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@googlemail.com>
The recent ACPI specification extensions have formally defined a
method for describing device information with a key=value format that
is modeled after the Devicetree/DTS format using a special crafted
object named _DSD with a specific UUID for this format.
There are three defined Device Property types: Integers, Strings, and
References. It is also possible to have arrays of these properties
under one key=value pair. Strings and References are both represented
as character arrays but result in different generated ACPI OpCodes.
Various helpers are provided for writing the Device Property header
(to fill in the object name and UUID) and footer (to fill in the
property count and device length values) as well as for writing the
different Device Property types. A specific helper is provided for
writing the defined GPIO binding Device Property that is used to allow
GPIOs to be referred to by name rather than resource index.
This is all documented in the _DSD Device Properties UUID document:
http://uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf
This will be used by device drivers to provide device properties that
are consumed by the operating system. Devicetree bindings are often
described in the linux kernel at Documentation/devicetree/bindings/
A sample driver here has an input GPIO that it needs to describe to
the kernel driver:
chip.h:
struct drivers_generic_sample_config {
struct acpi_gpio mode_gpio;
};
sample.c:
static void acpi_fill_ssdt_generator(struct device *dev) {
struct drivers_generic_sample_config *config = dev->chip_info;
const char *path = acpi_device_path(dev);
...
acpi_device_write_gpio(&config->mode_gpio);
...
acpi_dp_write_header();
acpi_dp_write_gpio("mode-gpio", path, 0, 0, 0);
acpi_dp_write_footer();
...
}
devicetree.cb:
device pci 1f.0 on
chip drivers/generic/sample
register "mode_gpio" = "ACPI_GPIO_INPUT(GPP_B1)"
device generic 0 on end
end
end
SSDT.dsl:
Name (_CRS, ResourceTemplate () {
GpioIo (Exclusive, PullDefault, 0, 0, IoRestrictionInputOnly,
"\\_SB.PCI0.GPIO", 0, ResourceConsumer) { 25 }
})
Name (_DSD, Package () {
ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () {"mode-gpio", Package () { \_SB.PCI0.LPCB, 0, 0, 1 }}
}
})
Change-Id: I93ffd09e59d05c09e38693e221a87085469be3ad
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/14937
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add required definitions to describe an ACPI SPI bus and a method to
write the SpiSerialBus() descriptor to the SSDT.
This will be used by device drivers to describe their SPI resources to
the OS. SPI devices are not currently enumerated in the devicetree but
can be enumerated by device drivers directly.
generic.c:
void acpi_fill_ssdt_generator(struct device *dev) {
struct acpi_spi spi = {
.device_select = dev->path->generic.device.id,
.device_select_polarity = SPI_POLARITY_LOW,
.spi_wire_mode = SPI_4_WIRE_MODE,
.speed = 1000 * 1000; /* 1 mHz */
.data_bit_length = 8,
.clock_phase = SPI_CLOCK_PHASE_FIRST,
.clock_polarity = SPI_POLARITY_LOW,
.resource = acpi_device_path(dev->bus->dev)
};
...
acpi_device_write_spi(&spi);
...
}
devicetree.cb:
device pci 1e.2 on
chip drivers/spi/generic
device generic 0 on end
end
end
SSDT.dsl:
SpiSerialBus (0, PolarityLow, FourWireMode, 8, ControllerInitiated,
1000000, ClockPolarityLow, ClockPhaseFirst,
"\\_SB.PCI0.SPI0", 0, ResourceConsumer)
Change-Id: I0ef83dc111ac6c19d68872ab64e1e5e3a7756cae
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/14936
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add required definitions to describe an ACPI I2C bus and a method to
write the I2cSerialBus() descriptor to the SSDT.
This will be used by device drivers to describe their I2C resources to
the OS. The devicetree i2c device can supply the address and 7 or 10
bit mode as well as indicate the GPIO controller device, and the bus
speed can be fixed or configured by the driver.
chip.h:
struct drivers_i2c_generic_config {
enum i2c_speed bus_speed;
};
generic.c:
void acpi_fill_ssdt_generator(struct device *dev) {
struct drivers_i2c_generic_config *config = dev->chip_info;
struct acpi_i2c i2c = {
.address = dev->path->i2c.device,
.mode_10bit = dev->path.i2c.mode_10bit,
.speed = config->bus_speed ? : I2C_SPEED_FAST,
.resource = acpi_device_path(dev->bus->dev)
};
...
acpi_device_write_i2c(&i2c);
...
}
devicetree.cb:
device pci 15.0 on
chip drivers/i2c/generic
device i2c 10.0 on end
end
end
SSDT.dsl:
I2cSerialBus (0x10, ControllerInitiated, 400000, AddressingMode7Bit,
"\\_SB.PCI0.I2C0", 0, ResourceConsumer)
Change-Id: I598401ac81a92c72f19da0271af1e218580a6c49
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/14935
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add definitions to describe GPIOs in generated ACPI objects and a
method to write a GpioIo() or GpioInt() descriptor to the SSDT.
ACPI GPIOs have many possible configuration options and a structure
is created to describe it accurately in ACPI terms. There are many
shared descriptor fields between GpioIo() and GpioInt() so the same
function can write both types.
GpioInt shares many properties with ACPI Interrupts and the same types
are re-used here where possible. One addition is that GpioInt can be
configured to trigger on both low and high edge transitions.
One descriptor can describe multiple GPIO pins (limited to 8 in this
implementation) that all share configuration and controller and are
used by the same device scope.
Accurately referring to the GPIO controller that this pin is connected
to requires the SoC/board to implement a function handler for
acpi_gpio_path(), or for the caller to provide this directly as a
string in the acpi_gpio->reference variable.
This will get used by device drivers to describe their resources in
the SSDT. Here is a sample for a Maxim 98357A I2S codec which has a
GPIO for power and channel selection called "sdmode".
chip.h:
struct drivers_generic_max98357a_config {
struct acpi_gpio sdmode_gpio;
};
max98357a.c:
void acpi_fill_ssdt_generator(struct device *dev) {
struct drivers_generic_max98357a_config *config = dev->chip_info;
...
acpi_device_write_gpio(&config->sdmode_gpio);
...
}
devicetree.cb:
device pci 1f.3 on
chip drivers/generic/max98357a
register "sdmode_gpio" = "ACPI_GPIO_OUTPUT(GPP_C5)"
device generic 0 on end
end
end
SSDT.dsl:
GpioIo (Exclusive, PullDefault, 0, 0, IoRestrictionOutputOnly,
"\\_SB.PCI0.GPIO", 0, ResourceConsumer, ,) { 53 }
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Change-Id: Ibf5bab9c4bf6f21252373fb013e78f872550b167
Reviewed-on: https://review.coreboot.org/14934
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add definitions for ACPI device extended interrupts and a method to
write an Interrupt() descriptor to the SSDT output stream.
Interrupts are often tied together with other resources and some
configuration items are shared (though not always compatibly) with
other constructs like GPIOs and GPEs.
These will get used by device drivers to write _CRS sections for
devices into the SSDT. One usage is to include a "struct acpi_irq"
inside a config struct for a device so it can be initialized based
on settings in devicetree.
Example usage:
chip.h:
struct drivers_i2c_generic_config {
struct acpi_irq irq;
};
generic.c:
void acpi_fill_ssdt_generator(struct device *dev) {
struct drivers_i2c_generic_config *config = dev->chip_info;
...
acpi_device_write_interrupt(&config->irq);
...
}
devicetree.cb:
device pci 15.0 on
chip drivers/i2c/generic
register "irq" = "IRQ_EDGE_LOW(GPP_E7_IRQ)"
device i2c 10 on end
end
end
SSDT.dsl:
Interrupt (ResourceConsumer, Edge, ActiveLow, Exclusive,,,) { 31 }
Change-Id: I3b64170cc2ebac178e7a17df479eda7670a42703
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/14933
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
When CONFIG_C_ENVIRONMENT_BOOTBLOCK is employed there's no need for
a chipset specific verstage entry point because cache-as-ram has
already been initialized. Therefore, provide a default entry point
for verstage in that environment.
Change-Id: Idd8f45bd58d3e5b251d1e38cca7ae794b8b77a28
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14971
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
Some exceptions (like from calling a NULL function pointer) are easier
to narrow down with a dump of the call stack. Let's take a page out of
ARM32's book and add that feature to ARM64 as well. Also change the
output format to two register columns, to make it easier to fit a whole
exception dump on one screen.
Applying to both coreboot and libpayload and syncing the output format
between both back up.
Change-Id: I19768d13d8fa8adb84f0edda2af12f20508eb2db
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/14931
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add a function to "struct device_operations" to return the ACPI name
for the device, and helper functions to find this name (either from
the device or its parent) and to build a fully qualified ACPI path
from the root device.
This addition will allow device drivers to generate their ACPI AML in
the SSDT at boot, with customization supplied by devicetree.cb,
instead of needing custom DSDT ASL for every mainboard.
The root device acpi_name is defined as "\\_SB" and is used to start
the path when building a fully qualified name.
This requires SOC support to provide handlers for returning the ACPI
name for devices that it owns, and those names must match the objects
declared in the DSDT. The handler can be done either in each device
driver or with a global handler for the entire SOC.
Simplified example of how this can be used for an i2c device declared
in devicetree.cb with:
chip soc/intel/skylake # "\_SB" (from root device)
device domain 0 on # "PCI0"
device pci 19.2 on # "I2C4"
chip drivers/i2c/test0
device i2c 1a.0 on end # "TST0"
end
end
end
end
And basic SSDT generating code in the device driver:
acpigen_write_scope(acpi_device_scope(dev));
acpigen_write_device(acpi_device_name(dev));
acpigen_write_string("_HID", "TEST0000");
acpigen_write_byte("_UID", 0);
acpigen_pop_len(); /* device */
acpigen_pop_len(); /* scope */
Will produce this ACPI code:
Scope (\_SB.PCI0.I2C4) {
Device (TST0) {
Name (_HID, "TEST0000")
Name (_UID, 0)
}
}
Change-Id: Ie149595aeab96266fa5f006e7934339f0119ac54
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/14840
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
acpigen_write_uuid() will generate a ToUUID() 128-bit buffer object for a
common universally unique identifier that is passed as a string. The
resulting buffer is the UUID in byte format with a specific order of the
bytes as described in the ACPI specification:
ToUUID (uuid)
Compiles to:
Buffer (16) { uuid[3], uuid[2], uuid[1], uuid[0], uuid[5], uuid[4],
uuid[7], uuid[6], uuid[8], uuid[9], uuid[10], uuid[11],
uuid[12], uuid[13], uuid[14], uuid[15] }
Change-Id: Ibbeff926883532dd78477aaa2d26ffffb6ef30c0
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/14838
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
timestamp.c was not included in bootblock and postcar. This means that
these two stages would use the weak implementation in lib/timestamp.c
instead of the arch-specific implementation based on rdtsc.
This resulted in using timer_monotonic_get() which resets the
timestamps from 0. timer_monotonic_get() only provides per-stage
incrementing semantics on x86 because lapic implementation has
counting down values. A globally incrementing counter like rdtsc
provides the semantics like every other non-x86.
On the test configuration, the weak implementation of timestamp_get()
returned zero, resulting in wrong timestamps coming from the bootblock,
while romstage and ramstage used the arch implementation and returned
correct timestamps.
This is a great example of why weak functions are dangerous, and how
easy it is to miss subtle yet strong interactions between subsystems
and the coreboot buildsystem.
Change-Id: I656f9bd58a6fc179d9dbbc496c5b684ea9288eb5
Signed-off-by: Alexandru Gagniuc <alexandrux.gagniuc@intel.com>
Reviewed-on: https://review.coreboot.org/14860
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
strlen(string) was on the "negative" side of the selection operator, the
side where string is NULL.
Change-Id: Ic421a5406ef788c504e30089daeba61a195457ae
Reported-by: Coverity Scan (CID 1355263)
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/14867
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@google.com>
Add helper functions for generating some common objects:
acpigen_write_STA(status) will generate a status method that will
indicate the device status as provided:
Method (_STA) { Return (status) }
Full status byte configuration is possible and macros are provided for
the common status bytes used for generated code:
ACPI_STATUS_DEVICE_ALL_OFF = 0x0
ACPI_STATUS_DEVICE_ALL_ON = 0xF
acpigen_write_PRW() will generate a Power Resoruce for Wake that describes
the GPE that will wake a particular device:
Name (_PRW, Package (2) { wake, level }
Change-Id: I10277f0f3820d272d3975abf34b9a8de577782e5
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/14795
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
In order to produce smaller AML and not rely on the caller to size the
output type appropriately add a helper function that will output an
appropriately sized integer.
To complete this also add helper functions for outputting the single
OpCode for Zero and One and Ones.
And finally add "name" variants of the helpers that will output a
complete sequence like "Name (_UID, Zero)".
Change-Id: I7ee4bc0a6347d15b8d49df357845a8bc2e517407
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/14794
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Add helper function to emit a string into the SSDT AML bytestream with a
NULL terminator. Also add a helper function to emit the string OpCode
followed by the string itself.
acpigen_emit_string(string) /* Raw string output */
acpigen_write_string(string) /* OpCode followed by raw string */
Change-Id: I4a3a8728066e0c41d7ad6429fad983e6ae6962fe
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/14793
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Add helpers for writing word and dword values in acpigen and use them
throughout the file to clean things up:
acpigen_emit_word - write raw word
acpigen_emit_dword - write raw dword
acpigen_write_word - write word opcode and value
Change-Id: Ia758d4dd25d0ae5b31be7d51b33866dddd96a473
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/14792
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
BUG=chrome-os-partner:49249
TEST=None. Initial code not sure if it will even compile
BRANCH=none
Change-Id: Ib0fccfe2d103710c006cb3950c65b11b8d596912
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 9be5f58bb89ec43d4eb264c94c3f745dcade35dd
Original-Change-Id: If50efb55d4974dfcab07d3ae6488c2413b505a1f
Original-Signed-off-by: Varadarajan Narayanan <varada@codeaurora.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/333301
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/14657
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins)
The skylake-based Chromebooks use a separate verstage which runs
just after bootblock and prior to romstage. The normal path for
romstage would be to reload the gdt, however in the previously
described scenario has verstage performing that work. Therefore,
provide that path under those conditions. The only difference
from the C_ENVIRONMENT_BOOTBLOCK scenario is that the stack
should not be reloaded since there's no way to know the top
of the stack.
Change-Id: Ic39ab52a856233d3042ac02a15ae4816ddfe07c7
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14548
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-by: Leroy P Leahy <leroy.p.leahy@intel.com>
The path that just clears CAR_GLOBAL variables and jumps
to the stage entry point needs another condition for
separate verstage just after bootblock. However, the
current conditional is a negative conditional so
swap the logic around to make it easier to extend.
Change-Id: Iab6682498054715a6eaa0476390da6355238b9bc
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14547
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-by: Leroy P Leahy <leroy.p.leahy@intel.com>
Stefan and others have discussed their interest in only
including options in Kconfig that are directly associated
with building a coreboot image. There are variables that
are architecture dependent that are utilized in the
coreboot infrastructure. To meet that goal, introduce
<arch/cbconfig.h> header file which defines variables
for the coreboot infrastructure that are architecture
dependent but utilized in common infrastructure.
Change-Id: Ic4cb9e81bab042797539dce004db0f7ee8526ea6
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14454
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
C_ENVIRONMENT_BOOTBLOCK on x86 is like romstage and uses cache-as-ram
separately. It does not use any data/bss sections.
Change-Id: I8957f467f01e754fa2d95783466a01daa6c4e51a
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/14533
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Leroy P Leahy <leroy.p.leahy@intel.com>
In order to de-duplicate common patterns implement one write_tables()
function. The new write_tables() replaces all the architecture-specific
ones that were largely copied. The callbacks are put in place to
handle any per-architecture requirements.
Change-Id: Id3d7abdce5b30f5557ccfe1dacff3c58c59f5e2b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14436
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Add a architecture specific function, arch_write_tables(), that
allows an architecture to add its required tables for booting.
This callback helps write_tables() to be de-duplicated.
Change-Id: I805c2f166b1e75942ad28b6e7e1982d64d2d5498
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14435
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
A architecture-specific function, named bootmem_arch_add_ranges(),
is added so that each architecture can add entries into the bootmem
memory map. This allows for a common write_tables() implementation
to avoid code duplication.
Change-Id: I834c82eae212869cad8bb02c7abcd9254d120735
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14434
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
In addition to being consistent with all other architectures,
all chipsets support cbmem so the low coreboot table path is
stale and never taken. Also it's important to note the memory
written in to that low area of memory wasn't automatically
reserved unless that path was taken. To that end remove
low coreboot table support for x86.
Change-Id: Ib96338cf3024e3aa34931c53a7318f40185be34c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14432
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
There were quite a number of #if/#endif guards in the
write_tables() code. Clean up that function by splitting
up the subcomponents into their own individual functions.
The same ordering and logic is kept maintained.
The changes also benefit the goal of using a common core
write_tables() logic so that other architectures don't
duplicate large swaths of code.
Change-Id: I93f6775d698500f25f72793cbe3fd4eb9d01a20c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14431
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Each arch was calling cbmem_list() in their own write_tables()
function. Consolidate that call and place it in common code
in write_coreboot_table().
Change-Id: If0d4c84e0f8634e5cef6996b2be4a86cc83c95a9
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14430
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Instead of hard coding a #define in each architecture's
tables.c for the coreboot table size in cbmem use a Kconfig
varible. This aids in aligning on a common write_tables()
implementation instead of duplicating the code for each
architecture.
Change-Id: I09c0f56133606ea62e9a9c4c6b9828bc24dcc668
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14429
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Apparently the memo was missed about the write_tables()
signature. Fix the confusion.
Change-Id: I8ef367345dd54584c57e9d5cd8cc3d81ce109fef
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14421
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Patrick Georgi