In current versions of spike, the config string is not available
anymore, because RISC-V is moving toward OpenFirmware-derived device
trees (either in FDT or text format). Using query_config_string leads to
a crash in these versions of spike.
With this commit and If0bea4bf52d ("riscv: Update register address"),
coreboot reaches the romstage again, on spike.
Change-Id: Ib1e6565145f0b2252deb1f4658221a4f816e2af4
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/21657
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
I triggered a bug, when I try to debug riscv code by spike.
This bug is caused by an instruction exception[csrwi 0x320,7].
This is operate for mcounteren. This address is error. 0x306
is right. scounteren is not need to be set, because S-mode
code controls it.
Change-Id: If0bea4bf52d8ad2fb2598724d6feb59dc1b3084a
Signed-off-by: wxjstz<wxjstz@126.com>
Reviewed-on: https://review.coreboot.org/20043
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
The deprecation of late (post-romstage) CBMEM initialization was
announced in this blog post:
https://blogs.coreboot.org/blog/2017/05/08/announcing-coreboot-4-6/
There are two warnings:
* In LATE_CBMEM_INIT's help text, I've added a multi-line warning, that
aims to explain the problem.
* In src/mainboard/Kconfig (just below the mainboard selection), there's
a warning which points the user at LATE_CBMEM_INIT, if such a board is
selected.
Also update the function that needs to be implemented, as pointed out by
Keith Hui and Kyösti Mälkki.
Change-Id: I2d21a6ab2fc2811d44fc4febb05841bb2f8d1857
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/21112
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
We now require EARLY_CBMEM_INIT and romstage_handoff to
support HAVE_ACPI_RESUME. Thus acpi_handoff_wakeup() would
never call an externally defined acpi_get_sleep_type().
Name _sleep_type() was also inapproriate here, as it referred
to hardware-dependent SLP_TYP field of PM1CNT but still
returned ACPI_Sx value instead.
Change-Id: I8dc130f1e86dd7e96922d546f0ae9713188336cd
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/21397
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
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>
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>
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>
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>
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>
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>
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>
