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".
BUG=none
BRANCH=none
TEST=none
Change-Id: Ia3bfdec7652d4cf7c8647a7e3b0a1a324666b0af
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 59eddac6ad
Original-Change-Id: I10b30b5a35be055c220c85b14a06b88939739a31
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://review.coreboot.org/18521
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: https://chromium-review.googlesource.com/449826
- 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
BUG=none
BRANCH=none
TEST=none
Change-Id: Ifb355b8d849d119692e0dd3ca11276ddce514089
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 80c314d64a
Original-Change-Id: Ibf2c4972232b2ad743ba689825cfe8440d63e828
Original-Signed-off-by: Martin Roth <martinroth@google.com>
Original-Reviewed-on: https://review.coreboot.org/17995
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Jonathan Neuschfer <j.neuschaefer@gmx.net>
Original-Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Original-Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://chromium-review.googlesource.com/446390
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: I0857d9e5625eca339f6185acea204fcfba901d25
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: bf4845dd3a
Original-Change-Id: Ie8bdb9dc18e61a4a658f1447d6f1db0b166d9c12
Original-Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Original-Reviewed-on: https://review.coreboot.org/18427
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Tested-by: build bot (Jenkins)
Reviewed-on: https://chromium-review.googlesource.com/445821
This is done to avoid any conflicts with same IRQ enums defined by other
drivers.
BUG=None
BRANCH=None
TEST=Compiles successfully
Change-Id: I54701329455709ce023bf363bdacdadf4f7d2639
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 5b9b593f2f
Original-Change-Id: I539831d853286ca45f6c36c3812a6fa9602df24c
Original-Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Original-Reviewed-on: https://review.coreboot.org/18444
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/446382
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: I5e2768ba499f1e008c9b68feae68b368cedaaa39
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 18792314d7
Original-Change-Id: I50cbeda4de17ccf2fc5efc1fe04f6b1a31ec268c
Original-Signed-off-by: Robbie Zhang <robbie.zhang@intel.com>
Original-Reviewed-on: https://review.coreboot.org/18362
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/445138
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: I191f422ec4216ecc70896a3b33ebbb62955053b4
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 4f31d5c2ce
Original-Change-Id: I2a569f60fcc0815835615656b09670987036b848
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://review.coreboot.org/18392
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/445131
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: I20371b7a7f4e270cd1c61a3e8b9b58b10cafc8ed
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: bd73dbbc38
Original-Change-Id: I0ffb61a4f46028cbe912e85c0124d9f5200b9c76
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://review.coreboot.org/18391
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/445130
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.
BUG=none
BRANCH=none
TEST=none
Change-Id: I8fa056af3e829218d8139f3899b7291e62ea6796
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: f797a1ac6a
Original-Change-Id: Ibae5e206c4ff47991ea8a11b6b59972b24b71796
Original-Signed-off-by: Martin Roth <martinroth@google.com>
Original-Reviewed-on: https://review.coreboot.org/18247
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Jonathan Neuschfer <j.neuschaefer@gmx.net>
Reviewed-on: https://chromium-review.googlesource.com/445149
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.
BUG=none
BRANCH=none
TEST=none
Change-Id: If9a61ed8a0b9add3b4f70dfb15ea0213c452f584
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Id: 408fda799a
Original-Change-Id: I2798ef67a8c6aed5afac34322be15fdf0c794059
Original-Signed-off-by: Martin Roth <martinroth@google.com>
Original-Reviewed-on: https://review.coreboot.org/17909
Original-Reviewed-by: Kysti Mlkki <kyosti.malkki@gmail.com>
Original-Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Original-Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Original-Tested-by: build bot (Jenkins)
Reviewed-on: https://chromium-review.googlesource.com/443682
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>
BUG=none
BRANCH=none
TEST=none
Change-Id: Ic5f8c8122003d6f09b0ce2e663e31605daf7db7b
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: a5c2ac6256
Original-Change-Id: I4dc00005270240c048272b2e4f52ae46ba1c9422
Original-Reviewed-on: https://review.coreboot.org/18192
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://chromium-review.googlesource.com/438046
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).
BUG=none
BRANCH=none
TEST=none
Change-Id: I858f72696b7a3f3491ca950b4374735cbb363bb7
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 78a5f22994
Original-Change-Id: I0e6a77f2813f7453d53e88e0214ad8c1b8689042
Original-Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Original-Reviewed-on: https://review.coreboot.org/18263
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Original-Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://chromium-review.googlesource.com/435403
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.
BUG=none
BRANCH=none
TEST=none
Change-Id: I815127db725dd4bc3930e361d79d27a2a63eca80
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 06a629e4b1
Original-Change-Id: I920d492a1422433d7d4b4659b27f5a22914bc438
Original-Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Reviewed-on: https://review.coreboot.org/18220
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Tested-by: build bot (Jenkins)
Reviewed-on: https://chromium-review.googlesource.com/431985
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.
BUG=none
BRANCH=none
TEST=none
Change-Id: I71a96971f46d515a66d5f77497b40d891c1b5fca
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: c5ebb1d005
Original-Change-Id: I76a8cb04e4ace51964b1cb4f67d49cfee9850da7
Original-Signed-off-by: Jonathan Neuschfer <j.neuschaefer@gmx.net>
Original-Reviewed-on: https://review.coreboot.org/18146
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: https://chromium-review.googlesource.com/430174
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
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.
BUG=none
BRANCH=none
TEST=none
Change-Id: I1a4fa2ddec9b556ec2da574e080f9a77ef139203
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 6f3a53b6f6
Original-Change-Id: Ibef530adcc58d33e2c44ff758e0b7d2acbdc5e99
Original-Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Original-Signed-off-by: Jonathan Neuschfer <j.neuschaefer@gmx.net>
Original-Reviewed-on: https://review.coreboot.org/18097
Original-Tested-by: build bot (Jenkins)
Reviewed-on: https://chromium-review.googlesource.com/430170
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
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
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://review.coreboot.org/18043
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Furquan Shaikh <furquan@google.com>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/425979
Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
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.
BUG=None
BRANCH=None
TEST=None
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>
Change-Id: Ifd6fe8398ea147a5fb8c60076b93205bb94b1f25
Reviewed-on: https://chromium-review.googlesource.com/422956
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
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.
BUG=None
BRANCH=None
TEST=None
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>
Change-Id: I482ff580e1b5251a8214fe2e3d2d38bd5f3e3ed2
Reviewed-on: https://chromium-review.googlesource.com/422955
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
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.
BUG=None
BRANCH=None
TEST=None
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 Neuschfer <j.neuschaefer@gmx.net>
Reviewed-by: Andrew Waterman <aswaterman@gmail.com>
Change-Id: I21fe5cac44fafe4b7806e004c179aa27541be4b6
Reviewed-on: https://chromium-review.googlesource.com/422950
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
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.
BUG=None
BRANCH=None
TEST=None
Signed-off-by: Kysti Mlkki <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>
Change-Id: I7514c498f40f2d93a4e83a232ef4665f5c21f062
Reviewed-on: https://chromium-review.googlesource.com/422236
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
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.
BUG=None
BRANCH=None
TEST=None
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: https://review.coreboot.org/17807
Tested-by: build bot (Jenkins)
Reviewed-by: Jonathan Neuschfer <j.neuschaefer@gmx.net>
Change-Id: I8538d5fd8d80d9347773c638f5cbf0da18dc1cae
Reviewed-on: https://chromium-review.googlesource.com/422235
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
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.
BUG=None
BRANCH=None
TEST=None
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>
Change-Id: Icdb48e4f2c102f619fbdca856e938e85135cfb18
Reviewed-on: https://chromium-review.googlesource.com/422234
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
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.
BUG=None
BRANCH=None
TEST=None
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>
Change-Id: I221d9170c547d41d8bd678a3a8b3bca6a76ccd2e
Reviewed-on: https://chromium-review.googlesource.com/422216
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
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
TEST=None
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>
Change-Id: I849ecfdd6641dd9424943e246317cd1996ef1ba6
Reviewed-on: https://chromium-review.googlesource.com/418439
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
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.
BUG=None
BRANCH=None
TEST=None
Signed-off-by: Kysti Mlkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17693
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: Id4d9029dec2fe195f09373320de800fcdf88c15d
Reviewed-on: https://chromium-review.googlesource.com/417953
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
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.
BUG=None
BRANCH=None
TEST=None
Signed-off-by: Kysti Mlkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17689
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: Ib5e6a451866c95d1edb9060c7f94070830b90e92
Reviewed-on: https://chromium-review.googlesource.com/417941
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
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.
BUG=None
BRANCH=None
TEST=None
Signed-off-by: Jonathan Neuschfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/17593
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Change-Id: I2cd0bb3ab91e89805fed84ec87e4a48ce70c3a46
Reviewed-on: https://chromium-review.googlesource.com/417072
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
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.
BUG=None
BRANCH=None
TEST=None
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>
Change-Id: I4313794826120853163c7366e81346858747ed0a
Reviewed-on: https://chromium-review.googlesource.com/416158
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
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.
BUG=None
BRANCH=None
TEST=None
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/17647
Tested-by: build bot (Jenkins)
Reviewed-by: Kysti Mlkki <kyosti.malkki@gmail.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Change-Id: I40f3769b7646bf296ee4bc323a9ab1d5e5691e21
Reviewed-on: https://chromium-review.googlesource.com/416156
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
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.
BUG=None
BRANCH=None
TEST=None
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/17504
Tested-by: build bot (Jenkins)
Reviewed-by: Kysti Mlkki <kyosti.malkki@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Change-Id: I2750d30119fee01baf4748d8001a672d18a13fb0
Reviewed-on: https://chromium-review.googlesource.com/414550
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
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.
BUG=None
BRANCH=None
TEST=None
Reviewed-on: https://review.coreboot.org/17403
Tested-by: build bot (Jenkins)
Reviewed-by: Jonathan Neuschfer <j.neuschaefer@gmx.net>
Change-Id: I77b151720001bddad5563b0f8e1279abcea056fa
Reviewed-on: https://chromium-review.googlesource.com/413259
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
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 /* . */
})
}
BUG=None
BRANCH=None
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>
Change-Id: If643c078b06d4e2e5a084b51c458dd612d565acc
Reviewed-on: https://chromium-review.googlesource.com/412046
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
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.
BUG=None
BRANCH=None
TEST=None
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: https://review.coreboot.org/17404
Tested-by: build bot (Jenkins)
Reviewed-by: Jonathan Neuschfer <j.neuschaefer@gmx.net>
Change-Id: I292264c15f002c41cf8d278354d8f4c0efbd0895
Reviewed-on: https://chromium-review.googlesource.com/411484
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
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.
BUG=None
BRANCH=None
TEST=None
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: https://review.coreboot.org/17254
Tested-by: build bot (Jenkins)
Reviewed-by: Jonathan Neuschfer <j.neuschaefer@gmx.net>
Change-Id: I3be7f1712accf2d726704e4c970f22749d3c3f36
Reviewed-on: https://chromium-review.googlesource.com/411482
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
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.
BUG=None
BRANCH=None
TEST=None
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: https://review.coreboot.org/17256
Tested-by: build bot (Jenkins)
Reviewed-by: Jonathan Neuschfer <j.neuschaefer@gmx.net>
Change-Id: I7dd3f553d3e61f1c49752fb04402b134fdfdf979
Reviewed-on: https://chromium-review.googlesource.com/411480
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
