The {get,set}_option() functions are not type-safe: they take a pointer
to void, without an associated length/size. Moreover, cmos_get_option()
does not always fully initialise the destination value (it has no means
to know how large it is), which can cause issues if the caller does not
initialise the value beforehand.
The idea behind this patch series is to replace the current type-unsafe
API with a type-safe equivalent, and ultimately decouple the option API
from CMOS. This would allow using different storage mechanisms with the
same option system, maximising flexibility.
Most, if not all users of get_option() have a value to fall back to, in
case the option could not be read. Thus, get_int_option() takes a value
to fall back to, which avoids repeating the same logic on call-sites.
These new functions will be put to use in subsequent commits.
Change-Id: I6bbc51135216f34518cfd05c3dc90fb68404c1cc
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47107
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
The eint driver can be shared by multiple platforms so
we want to move it to common/.
BRANCH=asurada
TEST=emerge-asurada coreboot
Signed-off-by: Yidi Lin <yidi.lin@mediatek.com>
Change-Id: Id8e0b631d5079e51213831ed17aa540e0afadd4b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52506
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
The name of the and_mask parameter was a bit misleading, due to the
function inverting the value. Renaming this into clear and set makes it
more obvious what those parameters will actually do.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: If307ab4858541861e22f8ff24ed178d47ba70fe5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52524
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
We had the addrspace_32bit rdev in prog_loaders.c for a while to help
represent memory ranges as an rdev, and we've found it useful for a
couple of things that have nothing to do with program loading. This
patch moves the concept straight into commonlib/region.c so it is no
longer anchored in such a weird place, and easier to use in unit tests.
Also expand the concept to the whole address space (there's no real need
to restrict it to 32 bits in 64-bit environments) and introduce an
rdev_chain_mem() helper function to make it a bit easier to use. Replace
some direct uses of struct mem_region_device with this new API where it
seems to make sense.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Ie4c763b77f77d227768556a9528681d771a08dca
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52533
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Move the function declaration of parse_devicetree() out of the if-else
preprocessor condition.
Change-Id: I6974554711e4cc2bb944bff14fc057ef6945c888
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52502
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
parse_devicetree() just calls parse_devicetree_param(). To be aligned
with other platforms, remove it and rename parse_devicetree_param() to
parse_devicetree().
Change-Id: I1128ab709cfdb02bbdb505c3f22f5433a30cb3c1
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52488
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
`devicetree.cb` is the default value for the Kconfig DEVICETREE
setting. Drop redundant configurations.
Change-Id: I5eded3d5e38ca80986da2fda95050815c2702f82
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52504
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The `chipset_lockdown` option defaults to `CHIPSET_LOCKDOWN_FSP` if
omitted. As most of the mainboards use `CHIPSET_LOCKDOWN_COREBOOT`,
choose it here as well for consistency.
Change-Id: I5ef61f3d931abdb740411d8c58048cf21185802c
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52094
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Maxim Polyakov <max.senia.poliak@gmail.com>
Fix board ID (HSI) read from BMC:
* R02 and R03 have an HSI of 2.
* R04 has an HSI of 3.
Change-Id: I987b2dd848c48e3562bcc07270c958cde3c5a962
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51920
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
There was a bug in the UPDs for STAPM settings that required one UPD
field to be extended from 8 to 32 bits, so this patch is a breaking
change to the binary layout, but since the UPD struct fields for the SMU
SoC power and performance tuning parameters aren't populated by the
coreboot code yet and we added some padding after each logical section
in the UPD, this isn't expected to cause too much trouble; the only
thing that is required is that a very recent build of the FSP binaries
need to be used in combination with the new coreboot code that will
populate the struct fields in follow-up patches.
BUG=b:182297189
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: If39aaf64e8e1b4c0426f22ce8ed07707c2a31e61
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52452
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
This option is not mainboard-specific, and should be user-visible.
Change-Id: I9ff2ca984cd238a112af4efd7685f142cc6e5459
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52099
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
The uPEP device is required to support S0i3. The device has been written
in ASL to make it easier to read and maintain. The device constraints
are purely informational. We use a dummy constraint like the Intel
platforms to keep both linux and Windows functional.
In order for this device to be used by the linux kernel the
ACPI_FADT_LOW_PWR_IDLE_S0 flag must be set. So including it
unconditionally doesn't cause any problems.
The AMD Modern Standby BIOS Implementation Guide defines two UUIDs,
one for getting the device constraints, and one for handling
notifications. This differs from the Intel specification and the linux
driver implementation. For this reason I haven't implemented any of the
notification callbacks yet.
BUG=b:178728116
TEST=Boot OS and verify _DSM is called:
[ 0.226701] lps0_device_attach: ACPI: \_SB_.PEP_: _DSM function mask: 0x3
[ 0.226722] lpi_device_get_constraints_amd: ACPI: \_SB_.PEP_: _DSM function 1 eval successful
[ 0.226723] lpi_device_get_constraints_amd: ACPI: \_SB_.PEP_: LPI: constraints list begin:
[ 0.226724] lpi_device_get_constraints_amd: ACPI: \_SB_.PEP_: LPI: constraints list end
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I2deef47eabe702efe1a0f3747c9f27bcec37464b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52445
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
On Intel 6-series PCHs, the GCAP register is R/WO (Read / Write Once),
and needs to be written to after the HD Audio controller is taken out
of reset. Add a Kconfig option to read and write back GCAP in order to
lock it down. Follow-up commits will select this option when switching
platforms to use common Azalia code, to preserve original behaviour.
Change-Id: I70bab20816fb6c0bf7bff35c3d2f5828cd96172d
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50794
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
This comment is most likely a copy-paste leftover from Braswell.
Change-Id: I49bfa3cc56539df0b47d2e2bd74b2bfc45421034
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52500
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
To make the L140CU able to be selected by other OEMs, use
BOARD_CLEVO_L140CU_BASE for OEM independent options.
BOARD_CLEVO_L140CU represents the standard Clevo mainboard without any
OEM modifications, while BOARD_CLEVO_L140CU_BASE is used for the
baseboard.
Change-Id: Iee82eadebfc851619dbb64de09283c5ee55a499f
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52241
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The macro definitions depend on __SIMPLE_DEVICE__ and are only used in
the get_gpio_base() or lpc_get_pmbase() functions, which already guard
PCH_LPC_DEV usage using __SIMPLE_DEVICE__ in preprocessor.
Change-Id: I5d3681debe29471dfa143ba100eb9060f6364c93
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52461
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Rename `BOARD_CLEVO_L140CU_OPTIONS` to `BOARD_CLEVO_L140CU_BASE` to
make clear that this option represents the baseboard.
Change-Id: I76690626fddafc8e3c37ef760aeb4f064fb6b591
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52480
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Memory init config is board specific. Thus, move it to variant level and
hook up variant romstage.c.
Change-Id: Id78788815ad9c4ed64f0172fb746ff6e50d608ef
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49132
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Hook up FSP-M configuration on mainboard level instead of variant level
being able to do common configuration there.
Also, hook up variant romstage.c on mainboard level for variant
specific configurations.
Change-Id: Ic161f83cb629b1e70ca670e10975a25bc0949656
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49077
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Add a new configuration low_power_probe to avoid camera privacy LED
blink during the boot.
Change-Id: I27d5c66fb380ae6cd76d04ee82b7736407dac1b0
Signed-off-by: Pandya, Varshit B <varshit.b.pandya@intel.com>
Signed-off-by: Sugnan Prabhu S <sugnan.prabhu.s@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52189
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Maulik V Vaghela <maulik.v.vaghela@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
PARALLEL_MP_AP_WORK is set in the xeon_sp Kconfig. No need to
set it here.
Change-Id: I66d59fd7cbc3617eb739fdf2f3750f20ee701fbd
Signed-off-by: Marc Jones <marcjones@sysproconsulting.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52448
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Use the same stack location during relocation as for the permanent
handler.
When the number of CPUs is too large the stacks during relocation
don't fit inside the default SMRAM segment at 0x30000. Currently the
code would just let the CPU stack base grow downwards outside of the
default SMM segment which would corrupt lower memory if S3 is
implemented.
Also update the comment on smm_module_setup_stub().
Change-Id: I6a0a890e8b1c2408301564c22772032cfee4d296
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51186
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
This reverts commit ad7c33abd2. With EFS2
already enabled in EC, enabling early EC sync is not required. Also a
workaround has been added in payload to address any boot issues.
BUG=b:185277224
TEST=Build and boot to OS in Guybrush in both normal and recovery mode.
Cq-Depend: chromium:2832032
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Change-Id: I34f8433739754365c8e5a10fdf7e58e3d1e7e797
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52419
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This reverts commit 1e36dc078e. With EFS2
already enabled in EC, enabling early EC sync is not required. Also a
workaround has been added in payload to address any boot issues.
BUG=b:185277224
TEST=Build and boot to OS in Guybrush in both normal and recovery mode.
Cq-Depend: chromium:2832032
Change-Id: I921dc5c814e5187dce283eeff43075b59885723a
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52418
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
If we select scancode set #1 and keep that, it can confuse Linux
with keyboards that don't return to set #2 when asked to load the
defaults. This happens for instance with various integrated Think-
Pad keyboards but was also seen with an external PS/2 one.
The chosen configuration, scancode set #2 without translation, seems
to be the default for many systems. So we can expect other payloads
and kernels to work with it.
Change-Id: I28d74590e9f04d32bb2bbd461b67f15014f927ec
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47594
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Instead of ignoring keyboards indefinitely when they failed to
initialize, we wait 5s and then start over with the hotplug
detection. As we always assume a present keyboard at first,
we'd otherwise never have a chance to hot plug a device after
the initial 30s timer ran out.
Change-Id: I8dec4921b2e932442d52b5118cdcf27090633498
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48774
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
While we assume a keyboard is attached, we send an echo command every
500ms. If there is no data coming from the keyboard within 200ms, we
assume it was detached.
Correspondingly, if we assume no keyboard is attached, we run an echo
command once per second.
Change-Id: I2c75182761729bf30711305f3d8b9d43eafad675
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47593
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Angel Pons