Each stage performs some basic initialization (stack, HLS etc) and then
call smp_pause to enter the single-threaded state. The main work of each
stage is executed in a single-threaded state, and the multi-threaded
state is restored by call smp_resume while booting the next stage.
Change-Id: I8d508c3d0f65a022010e74f8edad7ad2cfdc7dee
Signed-off-by: Xiang Wang <wxjstz@126.com>
Reviewed-on: https://review.coreboot.org/29024
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-by: Philipp Hug <philipp@hug.cx>
See https://doc.coreboot.org/arch/riscv/ we know that we need to execute
smp_pause at the start of each stage and smp_resume at the end of each
stage.
Change-Id: I6f8159637bfb15f54f0abeb335de2ba6e9cf82fb
Signed-off-by: Xiang Wang <wxjstz@126.com>
Reviewed-on: https://review.coreboot.org/29023
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-by: Philipp Hug <philipp@hug.cx>
After a {break,return}, "else" is generally not needed.
Change-Id: I6145424ef8ffe6854c18c1d885f579d37853a70c
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/29267
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
After a {break,return}, "else" is generally not needed.
Change-Id: Id55af179f63316f7218e93978628cbe05e94e0aa
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/29266
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Using a conditional statement to return 0 or 1 depending on a logic
value is unnecessarily complex.
Change-Id: I449ce2b71b72374de5ec4986f9cc9f91a67856ee
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/29265
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
There are some small mistakes in these recently-added mainboards:
- board_info.txt: Lists board socket incorrectly.
- cmos.default: Loglevel was decreased some time ago.
- devicetree.cb: Spelling mistake.
- Kconfig: Mainboard name does not have a hyphen.
Change-Id: I08d9b06e79683acd3994b84647bce401ed6741e2
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/29446
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Get board id from AUXIN4 and RAM code from AUXIN3.
BUG=b:80501386
BRANCH=none
TEST=AUXIN4 is 0.074v and AUXIN3 is 0.212v on P0.
AUXIN4 is 0.212v and AUXIN3 is 0.212v on P1.
Change-Id: I50533e851d2fae66ae8c5e4e1aa36708d9058e94
Signed-off-by: Tristan Shieh <tristan.shieh@mediatek.com>
Reviewed-on: https://review.coreboot.org/29062
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
We plan to get board id and RAM code from AUXADC on Kukui. Add AUXADC
driver to support it.
BUG=b:80501386
BRANCH=none
TEST=Boots correctly on Kukui
Change-Id: I121a6a0240f9c517c0cbc07e0c18b09167849ff1
Signed-off-by: Po Xu <jg_poxu@mediatek.com>
Reviewed-on: https://review.coreboot.org/29061
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
The Sarien mainboard uses the newly added Wilco EC.
- enable CONFIG_EC_GOOGLE_WILCO
- add the device and host command ranges to the devicetree
- have the mainboard SMI handlers call the EC handlers
- add EC and SuperIO devices to the ACPI DSDT
- call the early init hook for serial setup
Change-Id: Idfc4a4af52a613de910ec313d657167918aa2619
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://review.coreboot.org/29411
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add a variant of the Sarien board called Arcada. This is currently
very similar to Sarien with differences in PCIe, USB, and GPIO usage.
Change-Id: I432d2ba99558e960d4e775c809cc8bf6aa1a56bf
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://review.coreboot.org/29410
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Sarien is a new board using Intel Whiskey Lake SOC. It also uses
the newly added Wilco EC, enabled in a separate commit.
Sarien is not a true reference board, it is just one variant of
a very similar design. For that reason it is not considered the
baseboard but rather a standalone variant.
Change-Id: I2e38f617694ed2c2ef746ff8083f2bfd58cbc775
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://review.coreboot.org/29409
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Add a way for the mainboard to provide a wake pin that the EC
will use to wake the system. This defines a _PRW object.
Change-Id: I94954104bbb8226683c37abc8c0465fe3c62a693
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://review.coreboot.org/29408
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Download the linux kernel tarball with curl.
Curl is already a dependency for coreboot.
Change-Id: I2e0bee3286593bd8e93b4d645242898eb9a14015
Signed-off-by: Marcello Sylvester Bauer <info@marcellobauer.com>
Reviewed-on: https://review.coreboot.org/29426
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
The function `acpi_fill_madt()` is identical among all the Lynx Point
boards and sb/intel/bd82x6x, so share a common function between them.
Earlier Intel platforms have similar implementations of this function.
The common implementation might only need minor alterations to support
them.
Tested on an ASRock H81M-HDS and Google Peppy (variant of Slippy). No
issues arose from this patch.
Change-Id: Ife9e3917febf43d8a92cac66b502e2dee8527556
Signed-off-by: Tristan Corrick <tristan@corrick.kiwi>
Reviewed-on: https://review.coreboot.org/29388
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
If the file `southbridge/intel/lynxpoint/nvs.h` is included in a file
that does not already include <stdint.h>, compilation errors result.
Adding the necessary <stdint.h> inclusions fixes compilation for an
ASRock H81M-HDS.
Change-Id: Id0d14705282cc959146e00dd47754ee8a2e8e825
Signed-off-by: Tristan Corrick <tristan@corrick.kiwi>
Reviewed-on: https://review.coreboot.org/29389
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
The platform.asl file is copied from sb/intel/bd82x6x, and also matches
the contents deleted from each mainboard's platform.asl.
Tested on an ASRock H81M-HDS and a Google Peppy board (variant of
Slippy). No issues arose from this patch.
Change-Id: I539e401ce9af83070f69147526ca3b1c122f042c
Signed-off-by: Tristan Corrick <tristan@corrick.kiwi>
Reviewed-on: https://review.coreboot.org/29386
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
On an ASRock H81M-HDS neither libgfxinit, nor Linux, is able to
initialise the display when lanes are not configured to be shared
between DDI A and DDI E.
Intel's reference manual [1] states that the decision to share lanes
between DDI A and DDI E is "based on board configuration". Hence, add a
new field to the devicetree that boards can set. All existing Haswell
boards have this unset, thus taking a value of 0, so there is no change
to existing behaviour.
[1]: Intel Open Source Graphics Programmer's Reference Manual (PRM)
Volume 2c: Command Reference: Registers (Haswell)
https://01.org/linuxgraphics/documentation/hardware-specification-prms/2013-intel-core-processor-family
Change-Id: I6f7832293215d2b53e31b0a5c985e6098eb72f1b
Signed-off-by: Tristan Corrick <tristan@corrick.kiwi>
Reviewed-on: https://review.coreboot.org/29385
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
On my system (Pentium G3258, ASRock H81M-HDS), changing the the slow
ramp rate during `initialize_vr_config()` results in the following
exception, causing the system to hang.
CPU Index 0 - APIC 0 Unexpected Exception:13 @ 10:7f7a3736 - Halting
Code: 0 eflags: 00010006 cr2: 00000000
eax: 00262626 ebx: 00140000 ecx: 00000603 edx: 00360000
edi: 00000007 esi: 00262626 ebp: 7f7c0fd8 esp: 7f7c0e90
So, only change this setting for Haswell ULT CPUs, as suggested by the
BIOS Writer's guide.
Change-Id: I79b10139295741d298ac6c77c4f7272ac151ad90
Signed-off-by: Tristan Corrick <tristan@corrick.kiwi>
Reviewed-on: https://review.coreboot.org/29384
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When the Haswell-specific monotonic timer is used on an ASRock H81M-HDS
with a Pentium G3258, the following exception is generated, causing the
system to hang.
CPU Index 0 - APIC 0 Unexpected Exception:13 @ 10:7f7a3736 - Halting
Code: 0 eflags: 00010006 cr2: 00000000
eax: 00262626 ebx: 00140000 ecx: 00000603 edx: 00360000
edi: 00000007 esi: 00262626 ebp: 7f7c0fd8 esp: 7f7c0e90
The exception occurs when trying to read `MSR_COUNTER_24_MHz`, located
at 0x637. This MSR only exists on Haswell-ULT CPUs.
So, allow boards to use the TSC monotonic timer instead. They can do
this by placing `select TSC_MONOTONIC_TIMER` in the mainboard Kconfig.
Change-Id: I31d0e801b8cc85330dcb70c3fc03670f2e677e8f
Signed-off-by: Tristan Corrick <tristan@corrick.kiwi>
Reviewed-on: https://review.coreboot.org/29383
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The super I/O setup needs to be done after the LPC is enabled. For
Lynx Point, configuring the super I/O in `mainboard_romstage_entry()`
is too early to get a serial console output. To remedy this, add a
function `mainboard_config_superio()` that will be called at the
appropriate time, and can be overridden by mainboard code.
Change-Id: Iaf4188a17533c636e7b0c7efa220bc6a25876dda
Signed-off-by: Tristan Corrick <tristan@corrick.kiwi>
Reviewed-on: https://review.coreboot.org/29382
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
The PCI ID was taken from the output of `lspci` on an ASRock H81M-HDS.
Change-Id: I3679d1ab0ae08726bff04c5985d6d93437b2fb81
Signed-off-by: Tristan Corrick <tristan@corrick.kiwi>
Reviewed-on: https://review.coreboot.org/29379
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
The PCI ID was taken from the output of `lspci` on an ASRock H81M-HDS.
Change-Id: Ie162cb7a27e313ffe612659e8444657a3772d3c9
Signed-off-by: Tristan Corrick <tristan@corrick.kiwi>
Reviewed-on: https://review.coreboot.org/29378
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Romstage is where DRAM comes online. Therefore, allow
raw CAR_GLOBAL object access in all cache-as-ram stages
that are not romstage. In practice, this should be a nop.
However, the explicit check for romstage is clearer.
Change-Id: I31454c05029140a946ef663b8fa1b2fa6a788154
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/29401
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Furquan Shaikh <furquan@google.com>
For platforms utilizing CONFIG_NO_CAR_GLOBAL_MIGRATION there's
no need to automatically migrate globals. Because of this it's
possible to automatically allow for uninitialized global variables
which reside in the .bss section without needing to decorate those
objects with CAR_GLOBAL.
Change-Id: Icae806fecd936ed2ebf0c13d30ffa07c77a95150
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/29359
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The PCI ID was taken from the output of `lspci` on an ASRock H81M-HDS.
Change-Id: Idc222392a0973f9ea62b943d18dd762b48c76d17
Signed-off-by: Tristan Corrick <tristan@corrick.kiwi>
Reviewed-on: https://review.coreboot.org/29377
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Change the variant name from kalista to karma.
According to the CL:1298319, the baseboard name is kalista
and the board name is karma.
BUG=none
BRANCH=master
TEST=emerge-kalista coreboot chromeos-bootimage
Change-Id: Idea295cc14249721a6dc0fc4e2ef6470d43e16eb
Signed-off-by: David Wu <David_Wu@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/29314
Reviewed-by: Zhuohao Lee <zhuohao@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: David Wu <david_wu@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
In commit 41baf0c3ff (soc/amd/stoneyridge: Remove dev_find_slot where
possible), the register being read was changed accidentally from
HT_DEV (Device 18h, Func 0) to NB_DEV (Device 18h, Func 5)
This doesn't return the correct value, and causes Grunt to reboot.
BUG=b:118721473
TEST=Boot grunt
Change-Id: I7b73358a074dd27639aafead7c8b39f0fad5685f
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/29367
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Daniel Kurtz <djkurtz@google.com>
Reviewed-by: Richard Spiegel <richard.spiegel@silverbackltd.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
The function domain_read_resources() didn't have any code to actually
reserve any resources - it was just creating an empty resource entry.
I looked at fixing it to actually reserve the space, but the values in
the registers at the point when this runs aren't the final values that
we want to reserve anyway, they're temp values with a range much larger
than we want to reserve.
I next looked at moving the amd_initcpuio() function earlier so that we
could get the correct values for the registers, but even that doesn't
give us what we really want.
Ultimately removing this whole function seems to be the right thing.
BUG=None
TEST=Verify that the only resource that changes is the empty resource:
PCI: 00:18.0 resource base 0 size 0 align 0 gran 0 limit 0 flags 1 index 1080
Change-Id: I83bd3ea8db141416632c12fc883386070363f2f1
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/29345
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Richard Spiegel <richard.spiegel@silverbackltd.com>
The speakers start up muted, and the EC must be told by the BIOS
to unmute it. This helps prevent popping noises on boot/resume.
Change-Id: I693f1d01e46e19362ef8fd0d5b3f4930967b5a12
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://review.coreboot.org/29203
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add ACPI devices for the basic SuperIO functionality provided by the EC
for PS/2 keyboard, PS/2 mouse (trackpad emulation), and legacy UART.
The specific defines to enable these devices should be declared by the
mainboard before including this ASL, the same as the Chrome EC behavior.
Change-Id: I910940ebf26b8758ab12d695e1eba9c668c640c6
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://review.coreboot.org/29125
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Lijian Zhao