Setting up postcar MTRRs is done when invd is already called so there
is no reason to do this in assembly anymore.
This also drops the custom code for Quark to set up MTRRs.
TESTED on foxconn/g41m and hermes/prodrive that MTRR are properly set
in postcar & ramstage.
Change-Id: I5ec10e84118197a04de0a5194336ef8bb049bba4
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54299
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The commentary was wrong, write_protect_state() is only called
in ramstage at the moment, and only if MRC_SETTINGS_PROTECT is
selected.
Implementation of get_gpio() eventually does the MMIO read, so
BOARD_GOOGLE_CYAN was not a special case.
Change-Id: I96ca871110bcf2fc1485bd042ed137d51b822a20
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59014
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
For some reason, the '\s' syntax is causing an error for me under
freebsd. It's entirely possible that I'm doing something wrong, but
this change should be fine regardless.
Freebsd's grep, GNU grep, and git grep all handle posix regex classes,
so this change should be transparent.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I489ec13b4ea2e9c17692888e42b8741763b1a2c5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63532
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
There were 3 different functions in gpio.c file which used to
get gpio group and pin information separately through function
calls.
Since these are static function, we can modify argument to
pass group and pin information from parent/calling function.
This will reduce redundant work of getting information 3 times
separately.
BUG=None
BRANCH=None
TEST=code compiles and correct information is passed to functions.
Check by using pin information on Brya.
Change-Id: Ie92be8c22838ebc5e831be58545e2023eecfff24
Signed-off-by: Maulik V Vaghela <maulik.v.vaghela@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64231
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Enable either eMMC, NVMe or UFS based on fw_config. NVMe and UFS are
only supported on nirwen, an additional nissa variant based on nivviks
and sharing the nivviks coreboot target.
BUG=b:218929856
TEST=Boot to OS on nivviks to check that eMMC still works. NVMe and UFS
will be tested once nirwen boards are available.
Change-Id: Ibdb122ef35920c962d7bd9f3f238a5d548112282
Signed-off-by: Reka Norman <rekanorman@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64211
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Nirwen is an additional nissa reference board which is almost identical
to nivviks, so is reusing the nivviks coreboot variant. However, there
are two GPIO changes, so update the GPIO tables to handle these based on
board_id.
nivviks:
GPP_D6 -> WWAN_EN
GPP_E13 -> NC
nirwen:
GPP_D6 -> SSD_CLKREQ_ODL
GPP_E13 -> WWAN_EN
BUG=b:218929856
TEST=Boot to OS on nivviks
Change-Id: I494ed127714069a8f36d16d11ca4e8a1f3d37827
Signed-off-by: Reka Norman <rekanorman@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64210
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kangheui Won <khwon@chromium.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Since coreboot locks GPIO registers after GPIO configuration, OS is not
able to program GPE_EN register to program wake events. This causes
the issue of event not getting logged into event log (since GPE_EN bit
is not set).
GPE_EN register programming is required for the GPIO pins which are
capable of generating SCI for the system wake. Elog mechanism relies
on GPE_EN and GPE_STS bit to log correct wake signal.
This patch add supports to program GPE_EN register before coreboot locks
the GPIO registers. Note that coreboot will only program GPE_EN bits for
GPIO capable of generating SCI.
This will help resolve issue where we don't see wake event GPIO in event
log.
BUG=b:222375516
BRANCH=firmware-brya-14505.B
TEST=Compile code for Brya and see GPE_EN bits set from the kernel console
Change-Id: I27e525f50c374c2cc9675e77eaa7774683a6e7c2
Signed-off-by: Maulik V Vaghela <maulik.v.vaghela@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64089
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Frank Wu <frank_wu@compal.corp-partner.google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
coreboot needs to set GPE_EN bit for the GPIOs which are wake capable
from s0ix/sleep. Due to GPIO locking mechanism, coreboot/OS will not
be able to write GPE_EN register post GPIO has been locked.
This patch adds support in SoC code to provide correct offset for
GPE_EN and GPE_STS registers to the common code.
Plan is to use this offsets to set GPE_EN bits before GPIO locking
in coreboot which will be part of subsequent CL.
BUG=b:222375516
BRANCH=firmware-brya-14505.B
TEST=Check if code compiles for Brya and correct offset values are printed.
Change-Id: I6b813b30b8b360f8eccbf539b57387310e380560
Signed-off-by: Maulik V Vaghela <maulik.v.vaghela@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64088
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Frank Wu <frank_wu@compal.corp-partner.google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Ti50 firmware versions below 0.0.15 don't support the firmware_version
register and trying to access it causes I2C errors. Some nissa boards
are still using Ti50 0.0.12, so add a workaround Kconfig to skip reading
the firmware version and select it for nissa. The firmware version is
only read to print it to the console, so it's fine to skip this. This
workaround will be removed once all ODM stocks are updated to 0.0.15 or
higher.
A similar workaround Kconfig was added in CB:63011 then removed in
CB:63158 which added support for separate handling of Cr50 and Ti50.
But we actually still need this workaround until all Ti50 stocks are
upgraded to 0.0.15 or higher.
BUG=b:224650720
TEST=Boot to OS on nereid with Ti50 0.0.14
Change-Id: Ia30d44ac231c42eba3ffb1cb1e6d83bb6593f926
Signed-off-by: Reka Norman <rekanorman@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64202
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
With GPIO_DRIVER_LOCK kernel driver can't change to IRQ. Thus, we need
to set it as INT in coreboot to make the IRQ work.
BUG=b:223476974
TEST=evtest work as expected.
Input driver version is 1.0.1
Input device ID: bus 0x19 vendor 0x1 product 0x1 version 0x100
Input device name: "PRP0001:00"
Supported events:
Event type 0 (EV_SYN)
Event type 5 (EV_SW)
Event code 15 (SW_PEN_INSERTED) state 0
Properties:
Testing ... (interrupt to exit)
Event: type 5 (EV_SW), code 15 (SW_PEN_INSERTED), value 1
Event: -------------- SYN_REPORT ------------
Event: type 5 (EV_SW), code 15 (SW_PEN_INSERTED), value 0
Signed-off-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Change-Id: I5f9fdfb2622b4b955da216119e74c6f7d5795d36
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64091
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kangheui Won <khwon@chromium.org>
Reviewed-by: Reka Norman <rekanorman@chromium.org>
By using mp_run_on_all_cpus_synchronously to run APs MTRR init, it
gurantees the BSP will run post_cpus_add_romcache until all APs finishes
_x86_setup_mtrrs task.
BUG=b:225766934
TEST=Test on redrix and found the MTRR race condition on AP/BSP is gone.
Change-Id: I1fd889f880a0c605e6c739423a434d2adbc12d26
Signed-off-by: Kane Chen <kane.chen@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63567
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
MTRR is a core level register which means 2 threads in one core share
same MTRR. There is a race condition could happen that AP overrides
BSP MTRR unintentionally.
In order to prevent such race condition between BSP and APs, this
patch provides a function to let BSP assign tasks to all APs and wait
them to complete the assigned tasks.
BUG=b:225766934
Change-Id: I8d1d49bca410c821a3ad0347548afc42eb860594
Signed-off-by: Kane Chen <kane.chen@intel.corp-partner.google.com>
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63566
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change matches what we already do for cezanne. It will allow the
GPIO controller to work correctly in windows.
BUG=b:175146875
TEST=Boot windows and verify GPIO controller binds correctly and touch
screen works. Also boot linux and verify touchpad still works.
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I998e286de18d3e3f8b2fe610d17aef94a6cf5477
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64227
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Rob Barnes <robbarnes@google.com>
With this patch, the ThinkLight on the ThinkPad T60 can be controlled
through the OS. This was initially done for the X201 in f63fbdb6:
mb/lenovo/x201: Add support for ThinkLight.
After applying this patch, the light can be controlled like this:
echo on >/proc/acpi/ibm/light
echo off >/proc/acpi/ibm/light
Or through sysfs at /sys/class/leds/tpacpi::thinklight
Change-Id: I47f878533d36857d002d2e2605cc8bc7e1d960c9
Signed-off-by: Stefan Ott <stefan@ott.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40678
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
