94b761c8e (util/board_status: run dmesg with sudo) attempted to
fetch the console as root locally but instead sudo was put in front
of the remote path which runs as root anyways.
Also unless quotation marks are used the cmd function will see 'sudo'
and 'dmesg' as separate aruguments.
Change-Id: Ib9e9e4b443f4e3ad04c5fda2c2ce626255a190f2
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/30264
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Bobba would prefer to use different SAR values per sku-id for regulatory
compliance. This commit uses the newly added interface for custom wifi
SAR CBFS filenames.
CQ-DEPEND=CL:*729429
BUG=b:120958726
BRANCH=octopus
TEST=build
Signed-off-by: Justin TerAvest <teravest@chromium.org>
Change-Id: I354382d651d65d533459f0ca460ca6fd6de547fd
Reviewed-on: https://review.coreboot.org/c/30223
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Using a fixed filename only allows for one SAR configuration to be
checked into CBFS. However, we have devices with shared firmware that
would desire separate SAR configurations. This change allows boards to
define a function to select one of multiple files stored in CBFS to be
used.
BUG=b:120958726
BRANCH=octopus
TEST=build
Signed-off-by: Justin TerAvest <teravest@chromium.org>
Change-Id: Ib852aaaff39f1e9149fa43bf8dc25b2400737ea5
Reviewed-on: https://review.coreboot.org/c/30222
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
It seems they are not included anywhere, Jenkins?
Change-Id: I629cdeb337fce381c69bd1ba0520e524ccdd90dd
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/26756
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
According to bard/ekko cpu types, PL2 need to set the values
1. KBL_U PL2 is 25w.
2. KBL_R PL2 is 29w.
BUG=b:120874861
TEST=power on and check the DUT can boot up well
Change-Id: I5f9d672c4244c363a7cfb362653663a065259fc0
Signed-off-by: Ren Kuo <ren.kuo@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/30178
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Enaebl the RTC driver to be used on mc_apl4.
Change-Id: Ib8d2a9f6b8cea47cd10db4dfcc59eec1b21c7993
Signed-off-by: Uwe Poeche <uwe.poeche@siemens.com>
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/c/30205
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Mario Scheithauer <mario.scheithauer@siemens.com>
This function returns APIC id for respective cpu core.
BUG=b:74436746
BRANCH=none
TEST=mp_get_apic_id() can be accessed in other files now.
Change-Id: I5c5eda8325f941ab84d8a3fe0dae64be71c44855
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/25620
Reviewed-by: Aamir Bohra <aamir.bohra@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch implements board reset on the Cheza board. The real board
reset used by the operating system uses the PMIC, but unfortunately the
PMIC needs to be configured right for that to work. The PMIC
configuration currently happens in the Qualcomm blob (QcLib) that is run
from romstage, but vboot needs to be able to reboot during verstage
already. Porting all the PMIC initialization code to run in the
bootblock seems excessive (and at odds with the goal of doing as little
as possible before verification), so we'll just do a little hack and ask
the EC to perform a cold reset instead. For vboot purposes, this should
work just as well.
BUG=b:118501305
TEST=Hacked vboot code to call vboot_reboot(), confirmed that board
reset and came back up as expected.
Change-Id: I3858d95f481884a87c243d4fa3d6369c1e8a5a2c
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/29849
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The GPIO pin map for CNL-H does not match with the OS expected
pin numbers. This has been updated to match what is used by the
Linux kernel pinctrl driver and the pad base has been set for
the GPIO groups to match the sparse GPIO map used by the kernel.
I do not have CNL-H hardware to test this so it is verified against
the kernel driver at drivers/pinctrl/intel/pinctrl-cannonlake.c
Change-Id: Ife7d3090d654b0b88c6911befa08bf6abd4f2ff9
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://review.coreboot.org/c/30134
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The GPIO drivers in Windows and Linux for the Cannonlake CPU
have a sparse GPIO map and do not allocate pins contiguously.
Each GPIO group is allocated as 32 pads regardless of whether
the hardware actually has that many in the group.
It appears this originated with a bug in Windows/UEFI and was
carried over to Linux in order to work with existing firmware:
https://lore.kernel.org/patchwork/patch/855244/
In order to support using ACPI GPIOs it is necessary for coreboot
to be compatible with this implementation. The GPIO groups that
are usable by the OS are declared with a pad base which is then
used to compute the number for ACPI GPIOs.
BUG=b:120686247
TEST=tested with write protect GPIO on sarien board. Before this
change the ACPI pin number was 220 which did not correspond to the
pin number in Linux. After this change the ACPI number is 303,
which maps to the correct GPIO in Linux. Now the GPIO value reported
by the kernel changes when the WP pin is toggled in hardware.
Change-Id: I4f1a9e118d7e48f2445ccbb62a12a22e9a832c51
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://review.coreboot.org/c/30133
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
If the generic GPIO library is enabled the code that generates the
GPIO table in ACPI should attempt to get the GPIO pin value from
the gpio_acpi_pin() function.
BUG=b:120686247
TEST=Tested on Sarien board to ensure that GPIO pin exported by
Chrome OS for the Write Protect signal is correct.
Change-Id: I267694b576009f79bacac6eda5f32bbf51742d78
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://review.coreboot.org/c/30132
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
In some situations the GPIO pad numbers used by the OS are not
contiguous and coreboot must provide a way for ACPI to provide
the expected GPIO number to the OS.
To do this each GPIO group can now have a pad base value, which
will be used as the starting pin number for this group and it
is added to the relative pin number of this GPIO to compute the
ACPI pin number for a particular GPIO.
By default this change has no effect because the existing uses
of INTEL_GPP() will set the pad base to PAD_BASE_NONE and the
GPIO number is used as the ACPI pin number without translation.
BUG=b:120686247
TEST=tested on a sarien(cannonlake) board
Change-Id: I25f73df45ffae18c5721a00ca230a6b07c250bab
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://review.coreboot.org/c/30131
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Correct Ram_ID=0b0000 SPD Module Part Number mismatch last alphabet 'C'
to "H5AN8G6NAFR-UHC".
BUG=b:120000816
BRANCH=master
TEST=mosys memory spd print all
Change-Id: I4f4b83589ad6b53c0a24f2637f0fe8b92a1168e3
Signed-off-by: Lucas Chen <lucas.chen@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/30208
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Daniel Kurtz <djkurtz@google.com>
Reviewed-by: Justin TerAvest <teravest@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Correct to add Ram_ID=0b0001 SPD Module Part Number mismatch last alphabet 'C'
to "H5ANAG6NAMR-UHC".
BUG=b:120000816
BRANCH=master
TEST=mosys memory spd print all
Change-Id: I4d320b2e10c4865456a9a9ccb400db5dd9256b3e
Signed-off-by: Lucas Chen <lucas.chen@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/30177
Reviewed-by: Daniel Kurtz <djkurtz@google.com>
Reviewed-by: Justin TerAvest <teravest@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch introduces 3 helper function for cpuid(1) :
1. cpu_get_cpuid() -> to get processor id (from cpuid.eax)
2. cpu_get_feature_flags_ecx -> to get processor feature flag (from cpuid.ecx)
3. cpu_get_feature_flags_edx -> to get processor feature flag (from cpuid.edx)
Above 3 helper functions are targeted to replace majority of cpuid(1)
references.
Change-Id: Ib96a7c79dadb1feff0b8d58aa408b355fbb3bc50
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/30123
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Creating skeleton files and directories in mainboard for the new Hatch
board. This is to facilitate development for different parties
involved.
BUG=None
BRANCH=None
TEST=./util/abuild/abuild -p none -t google/hatch -x -a
Change-Id: I5fc60c178f83034abe5d846d0f4169072b66f448
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/30169
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aamir Bohra <aamir.bohra@intel.com>
Change-Id: I64e79904c7ad95091ea29d9f80444c4e3b493471
Signed-off-by: T Michael Turney <mturney@codeaurora.org>
Reviewed-on: https://review.coreboot.org/c/29298
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Update the TRACKPAD_INT1_1V8_ODL GPIO configuration so that it acts as a
wakeup source
BUG=b:119598593
BRANCH=octopus
TEST=Ensure that the system wakes up on trackpad events. Ensure that the
suspend_stress_test runs successfully for 25 iterations.
Change-Id: I28292682cf9c8037abb87d265e49a60139550db2
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@codeaurora.org>
Reviewed-on: https://review.coreboot.org/c/30171
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Justin TerAvest <teravest@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Change-Id: I15cfbbab15b940641c3952f2cfb4b11c37574816
Signed-off-by: T Michael Turney <mturney@codeaurora.org>
Reviewed-on: https://review.coreboot.org/c/29299
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
When building coreboot from scratch with 'make -j4', I sometimes see
this error:
CREATE build/mainboard/emulation/qemu-riscv/cbfs-file.wblRgZ.out (from /.../coreboot/.config)
HOSTCC cbfstool/cbfstool (link)
make[1]: execvp: build/util/kconfig/conf: Permission denied
make[1]: *** [/.../coreboot/util/kconfig/Makefile:92: savedefconfig] Error 127
It happens, I think, because the rule generated by
cbfs-files-processor-defconfig runs 'make savedefconfig', which builds
build/util/kconfig/conf, and something also builds it, at the same time.
Fix this case, by making this rule depend on $(objutil)/kconfig/conf.
The same fix is also precautiously applied to the rule for
$(KCONFIG_AUTOHEADER) in Makefile.
Change-Id: Ie93eda567f88ca08c97df7e70cdff5b07442747d
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/c/29984
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Disable SATA port 0 and port 1 as that's not used as SATA on platform.
BUG=N/A
TEST=Build and boot up fine on google arcada board.
Change-Id: I1b8801f7a0f9b7847b85d7c315fa0a2093b32f70
Signed-off-by: Lijian Zhao <lijian.zhao@intel.com>
Reviewed-on: https://review.coreboot.org/c/30091
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Roy Mingi Park <roy.mingi.park@intel.com>
Reviewed-by: Bora Guvendik <bora.guvendik@intel.com>
There are 2 vendor BIOS's for the Lenovo X200 with the difference being the
settings in the VBT blob to accommodate different backlight frequencies.
Linux however sticks with the setting set by the firmware.
Tested on Lenovo X200 with CCFL backlight.
Change-Id: I4c4a7011ce03cdd511fa2e2160c2f006ba2707ba
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/29904
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
It's not just for the mailing lists, tools and IRC channel.
Change-Id: I23883cfd8200496f4281d73b6e75fac0d3448a3c
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/30104
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
It's not very helpful to tell somebody who feels wronged "that their
mail was probably lost" (in just as many words).
State why we don't go for a mailing list or ticket system for grievances
and encourage contact multiple people from the outset.
Change-Id: Idac4bcdf8b596a7325e463036c580b17a8b2f27b
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/30086
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
I reordered the contacts by current activity and added a link to the
CC-BY-SA license, otherwise it's the original text.
Change-Id: I6f41611db8d9a2f60b24d95abdf30f4fd47cd6f2
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/30085
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
It's originally written by Martin who graciously allowed to me rework it
a bit and push it into coreboot's documentation.
Change-Id: I14938d678e4620abec7ed5f0d35dddaf00edda6d
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/30082
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
PEN_EJECT GPIOs are active high and also require an internal pull-up.
Update the GPIO configuration appropriately.
BRANCH=octopus
BUG=b:117953118
TEST=Ensure that the system boots to ChromeOS. Ensure that the stylus
tools open on pen eject. Ensure that the system can enter S0ix and S3
states successfully when the pen is inserted. Ensure that the system
wakes on Pen Eject. Ensure that the system does not enter S0ix and S3
states when the pen is placed in its holder. Ensure that the
suspend_stress_test runs successfully for 25 iterations with the pen
placed in its holder.
Change-Id: Ibf9cb214a8ce7561efbb77a7e99d1e386cf064c3
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/30107
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Add mechanism to configure GPE wake event which in turn can be used as ACPI
Power Resources for Wake
BRANCH=octopus
BUG=b:117953118
TEST=Ensure that the wake GPE event is added to ACPI Power Resource for
Wake.
Change-Id: Iacc12b8636aaac98a8689a211cbe1dcfe306f342
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/30106
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Update the GPIOs for the next board build. Mostly minor changes but
the polarity change on GPP_E8/RECOVERY on sarien will result in it
booting to recovery every time unless using new hardware.
For this reason the recovery mode GPIO that is passed to vboot is
commented out for sarien. It is only used for testing and currently
it is useful to have an image that works on both board versions.
Change-Id: I32d84f3010cb4d3968370a03f7e191b1710a50e8
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://review.coreboot.org/c/30062
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Currently CoffeeLake FSP is incorrectly modifying GPIO pad configuration
if specific UPD variables are not set as it expects.
This affects the display-related SOC pads with the following UPD variables:
UINT8 DdiPortBHpd; // GPP_E13
UINT8 DdiPortCHpd; // GPP_E14
UINT8 DdiPortDHpd; // GPP_E15
UINT8 DdiPortFHpd; // GPP_E16
UINT8 DdiPortBDdc; // GPP_E18/GPP_E19
UINT8 DdiPortCDdc; // GPP_E20/GPP_E21
UINT8 DdiPortDDdc; // GPP_E22/GPP_E23
UINT8 DdiPortFDdc; // GPP_H16/GPP_H17
Until FSP is fixed to not touch the pad configuration this workaround
will reprogram the GPIO settings after FSP-S step so they are correct
when the OS attempts to use them.
This was found in CoffeLake FSP Gold release:
https://github.com/IntelFsp/FSP/tree/master/CoffeeLakeFspBinPkg
As well as the current top-of-tree for the FSP sources.
BUG=b:120686247,chromium:913216
TEST=verify correct GPIO configuration for GPP_E group in the kernel
Change-Id: I19550c4347cf65d409de6a8638619270372c4d0a
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://review.coreboot.org/c/30113
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lijian Zhao <lijian.zhao@intel.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
The kernel GPIO driver only expects some GPIO communities to be exported
in the _CRS and it will not work correctly if the other communities are
exported.
CNL-LP: GPIO communities 0, 1, 4
CNL-H: GPIO communities 0, 1, 3, 4
Additionally one of the pin offset values was incorrect in GPIO
community 1 for CNL-LP. This doesn't have any specific failure mode but
it was found when auditing the GPIO code.
Details of the kernel expected map can be found in the linux kernel at
drivers/pinctrl/intel/pinctrl-cannonlake.c
BUG=b:120686247
TEST=check /sys/kernel/debug/pinctrl/INT34BB:00/pins to ensure that
pins >= 198 are not reading all zeros for the pin config registers.
Change-Id: Ie1a2f3b9f9f4b24a9fc57e468dee50e99753912f
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://review.coreboot.org/c/30112
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Synaptics Trackpad wake event is incorrectly routed to GPE0_DW2_02. The
concerned GPIO is not connected and hence wont trigger a wakeup. Fix the
GPE wake configuration for synaptics trackpad.
BUG=b:120666158
BRANCH=octopus
TEST=Ensure that the wake on trackpad works with Synaptics touch pad.
Ensure that the system can enter S0ix successfully(run
suspend_stress_test -c 25).
Change-Id: I87b8c266266280f61700839d428e6f8938b0f72f
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/30105
Reviewed-by: Justin TerAvest <teravest@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Jonathan Neuschäfer