Technically, it's not depending on the hardware but on the software
(OS/payload), if the PM Timer is optional. OSes with ACPI >= 5.0A
support disabling of the PM Timer, when the respective FADT flag is
unset. Thus, drop this guard.
For platforms without hardware PM Timer (Apollo Lake, Gemini Lake) the
Kconfig `USE_PM_ACPI_TIMER` depends on `!NO_PM_ACPI_TIMER`.
As of this change, new platforms must either implement code for
disabling the hardware PM timer or select `NO_PM_ACPI_TIMER` if no such
is present.
Change-Id: I973ad418ba43cbd80b023abf94d3548edc53a561
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58017
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Lance Zhao
In the non-XIP world, FSP is normally memmapped and then decompressed.
The AMD SPI DMA controller can actually read faster than mmap. So by
reading the contents into a buffer and then decompressing we reduce boot
time.
BUG=b:179699789
TEST=Boot guybrush and see 30ms reduction in boot time
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I28d7530ae9e50f743e3d6c86a5a29b1fa85cacb6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58987
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
AMD platforms pass in the base address to cbfs tool:
fspm.bin-options: -b $(CONFIG_FSP_M_ADDR)
There is no technical reason not to allow FSP-M to be relocated when
!XIP. By allowing this, we no longer need to pass in the base address
into cbfstool when adding fspm.bin. This enables passing in the
`--alignment` argument to cbfs tool instead. cbfstool currently has a
check that prevents both `-b` and `-a` from being passed in.
BUG=b:179699789
TEST=Boot guybrush to OS
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I797fb319333c53ad0bbf7340924f7d07dfc7de30
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58984
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
The follow up CLs will use CBFS_PRELOAD. The default CBFS_CACHE_SIZE was
derived by examining the `cbfstool print` output and summing the files
we intend to preload.
BUG=b:179699789
TEST=Boot guybrush to OS
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I208067e6ceec6ffb602a87bee3bf99a0a75c822d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58961
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Read fw_config value from VPD.
This new option can be used where chrome EC is not supported like
pre-silicon platform and fw_config can be updated by VPD tool in OS.
TEST= boot to OS and read fw_config from vpd
1. Boot to OS
2. Write "fw_config" in VPD
ex) vpd -i "RW_VPD" -s "fw_config"="1"
3. reboot and check fw_config value from coreboot log
Signed-off-by: Wonkyu Kim <wonkyu.kim@intel.com>
Change-Id: I4df7d5612e18957416a40ab854fa63c8b11b4216
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58839
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Request fw_config values from various sources (as enabled via Kconfig)
until a valid value has been read.
With this change, Chrome EC CBI takes precedence over CBFS fw_config.
TEST=select both configs and check fallback behavior.
1. select both FW_CONFIG_SOURCE_CHROMEEC_CBI and FW_CONFIG_SOURCE_CBFS
2. check log for reading fw_config from CBI and CBFS
Signed-off-by: Wonkyu Kim <wonkyu.kim@intel.com>
Change-Id: I215c13a4fcb9dc3b94f73c770e704d4e353e9cff
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58833
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
elog init requires doing a lot of SPI transactions. This change makes it
clear how long we spend initializing elog.
BUG=b:179699789
TEST=Boot guybrush and see elog init timestamps
114:started elog init 3,029,116 (88)
115:finished elog init 3,071,281 (42,165)
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: Ia92372dd76535e06eb3b8a08b53e80ddb38b7a8f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58957
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This gives us a knob that can be controlled via a .config to
enable/disable file preloading. I left the option disabled because
there is currently a race condition that can cause data corruption when
using the SPI DMA controller. The fix will actually introduce a
boot time regression because the preloads are happening at the same time
as the elog init. I want to keep preloading disabled for now until
I get all the sequencing worked out.
BUG=b:179699789
TEST=Boot guybrush and verify no preloading happens.
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: Ie839e54fa38b81a5d18715f190c0c92467bd9371
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58861
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
SCIMAPS is the total number of SCI to GEVENT mappings. configure_scimap
returns early when the scimap is greater or equal than SCIMAPS, so for
SMITYPE_ACDC_TIMER it returned early without doing what was expected
from it to do despite that being a valid value, so fix this off-by-one.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ibaf8c5618ddbf0b8d4cd612a7f1347d8562bbfcb
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58952
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
EINT event mask register is used to mask EINT wakeup source.
All wakeup sources are masked by default. Since most MediaTek SoCs do
not have this design, we can't modify the kernel EINT upstream driver to
solve the issue 'Can't wake using power button (cros_ec) or touchpad'.
So we add a driver here to unmask all wakeup sources.
TEST=build pass
BUG=b:202871018
Signed-off-by: Rex-BC Chen <rex-bc.chen@mediatek.com>
Change-Id: I84946c2c74dd233419cb94f013a42c734363baf7
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58938
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
The NOR-Flash can be configured on SPI0 or TDM-RX GPIOs so we have to
provide an init function in SoC for the mainboard to select right
configuration.
TEST=boot to romstage
BUG=b:202871018
Signed-off-by: Rex-BC Chen <rex-bc.chen@mediatek.com>
Change-Id: I285ec64ace8b72a48ef1d481d366bd67cb9b0337
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58935
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
The `find_resource` function will never return null (will die instead).
In cases where the existing code already accounts for null pointers, it
is better to use `probe_resource` instead, which returns a null pointer
instead of dying.
Change-Id: I329efcb42a444b097794fde4f40acf5ececaea8c
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58910
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Lance Zhao
The `find_resource` function will never return null (will die instead).
In cases where the existing code already accounts for null pointers, it
is better to use `probe_resource` instead, which returns a null pointer
instead of dying.
Change-Id: Ic6e28add78f686fc9ab4556eddbedf7828fba9ef
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58909
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
The `find_resource` function will never return null (will die instead).
In cases where the existing code already accounts for null pointers, it
is better to use `probe_resource` instead, which returns a null pointer
instead of dying.
Change-Id: Ia9a4b62c857f7362d67aee4f9de3bb2da1838394
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58908
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
The `find_resource` function will never return null (will die instead).
In cases where the existing code already accounts for null pointers, it
is better to use `probe_resource` instead, which returns a null pointer
instead of dying.
Change-Id: I2a57ea1c2f5b156afd0724829e5b1880246f351f
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58907
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
The `find_resource` function will never return null (will die instead).
In cases where the existing code already accounts for null pointers, it
is better to use `probe_resource` instead, which returns a null pointer
instead of dying.
Change-Id: I617fea8a09049e9a87130640835ea6c3e2faec60
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58906
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
The `find_resource` function will never return null (will die instead).
In cases where the existing code already accounts for null pointers, it
is better to use `probe_resource` instead, which returns a null pointer
instead of dying.
Change-Id: I13c7ebeba2e5a896d46231b5e176e5470da97343
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58905
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
This API will hide all the complexity of preloading a CBFS file. It
makes it so the callers simply specify the file to preload and CBFS
takes care of the rest. It will start a new thread to read the file into
the cbfs_cache. When the file is actually required (i.e., cbfs_load,
etc) it will wait for the preload thread to complete (if it hasn't
already) and perform verification/decompression using the preloaded
buffer. This design allows decompression/verification to happen in the
main BSP thread so that timestamps are correctly reflected.
BUG=b:179699789
TEST=Test with whole CL chain, verify VGA bios was preloaded and boot
time was reduced by 12ms.
Logs:
Preloading VGA ROM
CBFS DEBUG: _cbfs_preload(name='pci1002,1638.rom', force_ro=false)
CBFS: Found 'pci1002,1638.rom' @0x20ac40 size 0xd800 in mcache @0xcb7dd0f0
spi_dma_readat_dma: start: dest: 0x021c0000, source: 0x51cc80, size: 55296
took 0 us to acquire mutex
start_spi_dma_transaction: dest: 0x021c0000, source: 0x51cc80, remaining: 55296
...
spi_dma_readat_dma: end: dest: 0x021c0000, source: 0x51cc80, remaining: 0
...
CBFS DEBUG: _cbfs_alloc(name='pci1002,1638.rom', alloc=0x00000000(0x00000000), force_ro=false, type=-1)
CBFS: Found 'pci1002,1638.rom' @0x20ac40 size 0xd800 in mcache @0xcb7dd0f0
waiting for thread
took 0 us
CBFS DEBUG: get_preload_rdev(name='pci1002,1638.rom', force_ro=false) preload successful
In CBFS, ROM address for PCI: 03:00.0 = 0x021c0000
PCI expansion ROM, signature 0xaa55, INIT size 0xd800, data ptr 0x01b0
PCI ROM image, vendor ID 1002, device ID 1638,
PCI ROM image, Class Code 030000, Code Type 00
Copying VGA ROM Image from 0x021c0000 to 0xc0000, 0xd800 bytes
$ cbmem
...
40:device configuration 5,399,404 (8,575)
65:Option ROM initialization 5,403,474 (4,070)
66:Option ROM copy done 5,403,488 (14)
...
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I879fc1316f97417a4b82483d353abdbd02b98a31
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56491
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This cleans up the warning message:
WARNING: Prefer using '"%s...", __func__' to using 'thread_run', this function's name, in a string
BUG=b:179699789
TEST=boot guybrush
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I85bacb7b2d9ebec40b6b05edc2ecf0ca1fc8ceee
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58867
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Rob Barnes <robbarnes@google.com>
