Move the setup of the base address to a separate function and explicitly
set the SMBUS and ASF I/O port decode even though it is expected to
already be set after reset.
Change-Id: I8072ab78985021d19b6528100c674ecdd777e62e
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48434
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
ACPIMMIO_DECODE_REGISTER_04 is the definition in the common ACPIMMIO
code block that actually gets used. Also fix the indentation of the
ACPIMMIO register decode defines in the common code.
Change-Id: Ib2c460541be768fe05d8cc3d19a14dbd9c114a45
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48432
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
sb_disable_4dw_burst is only used in the same compilation unit, so no
need to make it externally visible.
Change-Id: I6c7c96f67b98fb8ed808f45a7685c4d72a10d32c
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48431
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
This change restricts RW_DIAG region to lower 16MiB to ensure that the
extended BIOS checker for FMAP does not complain about 16MiB boundary
crossing.
I haven't updated any other regions to occupy the newly freed space
but it is fine since this board is dead and should be dropped from
coreboot soon.
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: I19ab204fbe3e020e42baf68bfa350dcff32066a3
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48190
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
This change restricts SI_ME region to live below the 16MiB boundary to
ensure that no regions cross the 16MiB boundary as the extended BIOS
window checker for FMAP complains about it.
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: Ib0838ff4c63b06b8dc169b40d3022965b2f2f8f9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48189
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Srinidhi N Kaushik <srinidhi.n.kaushik@intel.com>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
This change adds support to Lock down the configuration of
extended BIOS region. This is done as part of
fast_spi_lockdown_cfg() so that it is consistent with the
other lockdown.
Change includes:
1. New helper function fast_spi_lock_ext_bios_cfg() added that
will basically set EXT_BIOS_LOCK.
BUG=b:171534504
Signed-off-by: Srinidhi N Kaushik <srinidhi.n.kaushik@intel.com>
Change-Id: I730fc12a9c5ca8bb4a1f946cad45944dda8e0518
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48068
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change enables caching for extended BIOS region.
Currently, caching is enabled for the standard BIOS region
upto a maximum of 16MiB using fast_spi_cache_bios_region,
used the same function to add the support for caching for
extended BIOS region as well.
Changes include:
1. Add a new helper function fast_spi_cache_ext_bios_window()
which calls fast_spi_ext_bios_cache_range() which calls
fast_spi_get_ext_bios_window() to get details about the
extended BIOS window from the boot media map and checks for
allignment and set mtrr.
2. Make a call to fast_spi_cache_ext_bios_region() from
fast_spi_cache_bios_region ().
3. Add new helper function fast_spi_cache_ext_bios_postcar()
which does caching ext BIOS region in postcar similar to 1.
4. If the extended window is used, then it enables caching
for this window similar to how it is done for the standard
window.
BUG=b:171534504
Signed-off-by: Srinidhi N Kaushik <srinidhi.n.kaushik@intel.com>
Change-Id: I9711f110a35a167efe3a4c912cf46c63c0812779
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47991
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change adds the SPI-DMI Destination ID for tigerlake
soc. This is needed for enabling support for extended
BIOS region. Also, implements a SOC helper function
soc_get_spi_dmi_destination_id() which returns SPI-DMI
Destination id.
BUG=b:171534504
Signed-off-by: Srinidhi N Kaushik <srinidhi.n.kaushik@intel.com>
Change-Id: I0b6a8af0c1e79fa668ef2f84b93f3bbece59eb6a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47989
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
This change enables support for configuration of extended BIOS
region decode window. This configuration needs to be performed
as early as possible in the boot flow. This is required to
ensure that any access to the SPI flash region below 16MiB in
coreboot is decoded correctly. The configuration for the extended
BIOS window if required is done as part of fast_spi_early_init().
Changes include:
1. Make a call to fast_spi_enable_ext_bios() before the bus master
and memory space is enabled for the fast SPI controller.
2. Added a helper function fast_spi_enable_ext_bios() which calls
fast_spi_get_ext_bios_window() to get details about the extended
BIOS window from the boot media map.
3. Depending upon the SPI flash device used by the mainboard and
the size of the BIOS region in the flashmap, this function will
have to perform this additional configuration only if the BIOS
region is greater than 16MiB
4. Adddditionally, set up the general purpose memory range
registers in DMI.
BUG=b:171534504
Signed-off-by: Srinidhi N Kaushik <srinidhi.n.kaushik@intel.com>
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: Idafd8be0261892122d0b5a95d9ce9d5604a10cf2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47990
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change allows configuring the General Purpose
Memory Range(GPMR) register in BIOS to set up the decoding in DMI.
This driver provides the following functionality:
1. Add a helper function dmi_enable_gpmr which takes as input base,
limit and destination ID to configure in general purpose memory range
registers and then set the GPMR registers in the next available
free GMPR and enable the decoding.
2. Add helper function get_available_gpmr which returns available free
GPMR.
3. This helper function can be utilized by the fast SPI driver to
configure the window for the extended BIOS region.
BUG=b:171534504
Signed-off-by: Srinidhi N Kaushik <srinidhi.n.kaushik@intel.com>
Change-Id: I34a894e295ecb98fbc4a81282361e851c436a403
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47988
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change adds details about the memory map windows to translate
addresses between SPI flash space and host address space to coreboot
tables. This is useful for payloads to setup the translation using the
decode windows already known to coreboot. Until now, there was a
single decode window at the top of 4G used by all x86
platforms. However, going forward, platforms might support more decode
windows and hence in order to avoid duplication in payloads this
information is filled in coreboot tables.
`lb_spi_flash()` is updated to fill in the details about these windows
by making a call to `spi_flash_get_mmap_windows()` which is
implemented by the driver providing the boot media mapping device.
BUG=b:171534504
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: I00ae33d9b53fecd0a8eadd22531fdff8bde9ee94
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48185
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change reserves the window used for extended BIOS decoding as a
fixed MMIO resource using read_resources callback in systemagent
driver. This ensures that the resource allocator does not allocate
from this window.
Additionally, this window is also marked as fixed memory region in
_CRS for PNP0C02 device.
BUG=b:171534504
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: I42b5a0ebda2627f72b825551c566cd22dbc5cca7
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48184
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
This change enables support for a custom boot media device in fast SPI
controller driver if the platform supports additional decode window
for mapping BIOS regions greater than 16MiB. Following new Kconfigs
are added:
1. FAST_SPI_SUPPORTS_EXT_BIOS_WINDOW: SoC can select this to indicate
support for extended BIOS window.
2. EXT_BIOS_WIN_BASE: If FAST_SPI_SUPPORTS_EXT_BIOS_WINDOW is
selected, this provides the base address of the host space that is
reserved for mapping the extended window.
3. EXT_BIOS_WIN_SIZE: If FAST_SPI_SUPPORTS_EXT_BIOS_WINDOW is
selected, this provides the size of the host space reserved for
mapping extended window.
If platform indicates support for extended BIOS decode window,
cbfstool add command is provided additional parameters for the decode
window using --ext-win-base and --ext-win-size.
It is the responsibility of the mainboard fmap author to ensure that
the sections in the BIOS region do not cross 16MiB boundary as the
host space windows are not contiguous. This change adds a build time
check to ensure no sections in FMAP cross the 16MiB boundary.
Even though the platform supports extended window, it depends upon the
size of BIOS region (which in turn depends on SPI flash size) whether
and how much of the additional window is utilized at runtime. This
change also provides helper functions for rest of the coreboot
components to query how much of the extended window is actually
utilized.
BUG=b:171534504
Change-Id: I1b564aed9809cf14b40a3b8e907622266fc782e2
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47659
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
There have been a few issues with the new CBFS mcache code in stages
after romstage, where the mcache resides in CBMEM. In a few special
cases the stage may be doing a CBFS lookup before calling
cbmem_initialize(). To avoid breaking those cases, this patch makes the
CBFS code fall back to a lookup from flash if CBMEM hasn't been
reinitialized yet in those stages.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Icf6d1a1288cb243d0c4c893cc58251687e2873b0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48429
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
cbmem_online() always returns 1 in stages after romstage. However, CBMEM
isn't actually immediately available in those stages -- instead, it will
only become available when cbmem_initialize() is called. That usually
happens very early in the stage, but there are still small amounts of
code running beforehand, so it is useful to reflect this distinction.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I623c0606a4f49ea98c4c7559436bf32ebb83b456
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48428
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
This patch adds the PMC MUX and CONx devices for lindar. Device
specific method contains the port and orientation details used
to configure the mux.
BUG=b:172533907
BRANCH=firmware-volteer-13521.B
TEST=Built and booted into OS.
Signed-off-by: Stanley Wu <stanley1.wu@lcfc.corp-partner.google.com>
Change-Id: Id5ee78b7ece8421144086af9b95f5f0d849be56c
Signed-off-by: Kevin Chang <kevin.chang@lcfc.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47434
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Zhuohao Lee <zhuohao@google.com>
Reviewed-by: Caveh Jalali <caveh@chromium.org>
SATA_AHCI is already the default mode for CNL based mainboards.
Therefore, remove its configuration from all related devicetrees.
Built clevo/l140cu with BUILD_TIMELESS=1, coreboot.rom remains
identical.
Change-Id: I814e191243224a4b021cd7d4c1b611316f1fd1a4
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48391
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Align the SATA mode names with soc/skl providing a consistent API.
Built clevo/l140cu with BUILD_TIMELESS=1, coreboot.rom remains
identical.
Change-Id: I54b48462852d7fe0230dde0c272da3d12365d987
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48390
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
The PCI devices P2SB and PMC are hidden by the FSP and cannot be
unhidden, because the FSP locks their configuration. Thus, setting them
to `on` is not correct. Therefore, set their state to hidden.
Change-Id: Ib7c019cd7f389b2e487829e5550cc236ee5645b7
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48388
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change adds optional CBFSTOOL_ADD_CMD_OPTIONS that can be used by
arch/SoC/mainboard Makefiles to supply any additional arguments that
need to be passed into cbfstool when using cbfstool add command.
This is useful when platform wants to add these parameters depending
upon some arch/SoC/mainboard specific configs. Immediate use case is
the fast SPI controller on Intel platforms adding arguments for
extended window base and size.
BUG=b:171534504
Change-Id: I2f48bc3f494d9a5da7e99b530a39d6078b4a881c
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47884
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
SATA_AHCI is already the default mode for SKL/KBL based mainboards.
Therefore, remove its configuration from all related devicetrees.
Built clevo/n130wu with BUILD_TIMELESS=1, coreboot.rom remains
identical.
Change-Id: Ib5222c1b0314365b634f8585e8a97e0054127fe9
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48378
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The Skylake FSP isn't used by coreboot anymore. Therefore, drop the
misleading comment and the "KBLFSP" extension from the names of these
enums.
Also, drop the "MODE" extension to make their names shorter in general,
since it doesn't add any more value.
Built clevo/n130wu with BUILD_TIMELESS=1, coreboot.rom remains
identical.
Change-Id: If37d40e4e1dfd11e9315039acde7cafee0ac60f0
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48377
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Use proper indents in the devicetree and align `end` keywords.
Change-Id: Id6e6f4ad648a9bed35305b7a446744c6ed06a150
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48372
Reviewed-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The PCI devices P2SB and PMC are hidden by the FSP. So instead turning
them off, set their state to hidden being able to allocate ressources
for them.
Change-Id: Ie6e12f99b0a7ffb1c4831b3aa8705e911b677e88
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48371
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Update lindar gpio settings for Synaptics trackpad no function issue.
Update I2C5 bus freq to 400kHz.
Improve Goodix Touchscreen power on sequence.
BUG=b:160013582
BRANCH=firmware-volteer-13521.B
TEST=emerge-volteer coreboot and check system dmesg and evtest can get
device. Verify trackpad function workable.
Signed-off-by: Stanley Wu <stanley1.wu@lcfc.corp-partner.google.com>
Change-Id: I8c1ab6bab1f9de187e2a78ead7b5bbaf758f5fcf
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48150
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com>
This change updates the translated region device (xlate_region_dev) to
support multiple translation windows from the 1st address space to
2nd address space. The address spaces described by the translation
windows can be non-contiguous in both spaces. This is required so that
newer x86 platforms can describe memory mapping of SPI flash into
multiple decode windows in order to support greater than 16MiB of
memory mapped space.
Since the windows can be non-contiguous, it introduces new
restrictions on the region device ops - any operation performed on the
translated region device is limited to only 1 window at a time. This
restriction is primarily because of the mmap operation. The caller
expects that the memory mapped space is contiguous, however, that is
not true anymore. Thus, even though the other operations (readat,
writeat, eraseat) can be updated to translate into multiple operations
one for each access device, all operations across multiple windows are
prohibited for the sake of consistency.
It is the responsibility of the platform to ensure that any section
that is operated on using the translated region device does not span
multiple windows in the fmap description.
One additional difference in behavior is xlate_region_device does not
perform any action in munmap call. This is because it does not keep
track of the access device that was used to service the mmap
request. Currently, xlate_region_device is used only by memory mapped
boot media on the backend. So, not doing unmap is fine. If this needs
to be changed in the future, xlate_region_device will have to accept a
pre-allocated space from the caller to keep track of all mapping
requests.
BUG=b:171534504
Change-Id: Id5b21ffca2c8d6a9dfc37a878429aed4a8301651
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47658
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change adds support in fmaptool to generate a macro in C header
file that provides a list of section names that do not have any
subsections. This is useful for performing build time tests on these
sections.
BUG=b:171534504
Change-Id: Ie32bb8af4a722d329f9d4729722b131ca352d47a
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47883
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
All x86 platforms until now have memory mapped up to a maximum of
16MiB of SPI flash just below 4G boundary in host address space. For
newer platforms, cbfstool needs to be able to accommodate additional
windows in the host address space for mapping SPI flash size greater
than 16MiB.
This change adds two input parameters to cbfstool ext-win-base and
ext-win-size which a platform can use to provide the details of the
extended window in host address space. The extended window does not
necessarily have to be contiguous with the standard decode window
below 4G. But, it is left upto the platform to ensure that the fmap
sections are defined such that they do not cross the window boundary.
create_mmap_windows() uses the input parameters from the platform for
the extended window and the flash size to determine if extended mmap
window is used. If the entire window in host address space is not
covered by the SPI flash region below the top 16MiB, then mapping is
assumed to be done at the top of the extended window in host space.
BUG=b:171534504
Change-Id: Ie8f95993e9c690e34b0e8e792f9881c81459c6b6
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47882
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change adds the concept of mmap_window to describe how the SPI
flash address space is mapped to host address space on x86
platforms. It gets rid of the assumption that the SPI flash address
space is mapped only below the 4G boundary in host space. This is
required in follow up changes to be able to add more decode windows
for the SPI flash into the host address space.
Currently, a single mmap window is added i.e. the default x86 decode
window of maximum 16MiB size living just below the 4G boundary. If the
window is smaller than 16MiB, then it is mapped at the top of the host
window.
BUG=b:171534504
TEST=Verified using abuild with timeless option for all coreboot
boards that there is no change in the resultant coreboot.rom file.
Change-Id: I8dd3d1c922cc834c1e67f279ffce8fa438d8209c
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47831
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
This change renames the macro `IS_TOP_ALIGNED_ADDRESS` to
`IS_HOST_SPACE_ADDRESS` to make it clear that the macro checks if
given address is an address in the host space as opposed to the SPI
flash space.
BUG=b:171534504
Change-Id: I84bb505df62ac41f1d364a662be145603c0bd5fa
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47830
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
cbfstool overloads baseaddress to represent multiple things:
1. Address in SPI flash space
2. Address in host space (for x86 platforms)
3. Offset from end of region (accepted as negative number)
This was done so that the different functions that use these
addresses/offsets don't need to be aware of what the value represents
and can use the helper functions convert_to_from* to get the required
values.
Thus, even if the user provides a negative value to represent offset
from end of region, it was stored as an unsigned integer. There are
special checks in convert_to_from_top_aligned which guesses if the
value provided is really an offset from the end of region and converts
it to an offset from start of region.
This has worked okay until now for x86 platforms because there is a
single fixed decode window mapping the SPI flash to host address
space. However, going forward new platforms might need to support more
decode windows that are not contiguous in the host space. Thus, it is
important to distinguish between offsets from end of region and
addresses in host/SPI flash space and treat them separately.
As a first step towards supporting this requirement for multiple
decode windows on new platforms, this change handles the negative
offset provided as input in dispatch_command before the requested cbfs
operation is performed.
This change adds baseaddress_input, headeroffset_input and
cbfsoffset_input to struct param and converts them to offsets from
start of region before storing into baseaddress, headeroffset and
cbfsoffset if the inputs are negative.
In follow up changes, cbfstool will be extended to add support
for multiple decode windows.
BUG=b:171534504
TEST=Verified using abuild with timeless option for all coreboot
boards that there is no change in the resultant coreboot.rom file.
Change-Id: Ib74a7e6ed9e88fbc5489640d73bedac14872953f
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47829
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Unique among the Volteer devices, the volteer2_ti50 variant connects to
the TPM via I2C. This CL introduces the proper devicestree declarations
for the Linux kernel to recognize that.
overridetree.cb is shared between "sub"-variants volteer2 and
volteer2_ti50, so both will have two TPM nodes, the I2C being disabled
by default. The odd _ti50 variant then has code in variant.c to enable
the I2C node and disable the SPI node.
BUG=b:173461736
TEST=abuild -t GOOGLE_VOLTEER2{_TI50,} -c max -x
Change-Id: I5576a595bbabc34c62b768f8b3439e35ff6bcf7b
Signed-off-by: Jes Bodi Klinke <jbk@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48223
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Update Power Limit2 (PL2) minimum value to the same as maximum value for
volteer variants like baseboard, delbin, eldrid, terrador and todor.
All other variants uses the DTT entries from baseboard devicetree since
there is no override present for those variants. DTT does not throttle PL2,
so this minimum value change here does not impact any existing behavior on
the system.
BUG=None
BRANCH=volteer
TEST=Build and test on volteer system
Change-Id: I568e87c87ef517e96eaab3ff144b1674d26ae1e6
Signed-off-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48292
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Probabilistic interrupt storm is observed while kernel is configuring
the GPIO for SD card CD pin. The root cause is that the macro
PAD_CFG_GPI_GPIO_DRIVER isn't configuring trigger as PAD_TRIG(OFF).
The way GPIO interrupts are handled is:
1. Pad is configured as input in coreboot.
2. Pad IRQ information is passed in ACPI tables to kernel.
3. Kernel configures the required pad trigger.
Therefore, PAD_TRIG(OFF) should be added in PAD_CFG_GPI_GPIO_DRIVER
to turn off the trigger while pad is configured as input in coreboot
and then let kernel to configure the required pad trigger.
BUG=b:174336541
TEST=Run 1500 reboot iterations successfully without any interrupts
storm.
Signed-off-by: Kaiyen Chang <kaiyen.chang@intel.corp-partner.google.com>
Change-Id: Icc805f5cfe45e5cc991fb0561f669907ac454a03
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48302
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: EricR Lai <ericr_lai@compal.corp-partner.google.com>
DRIVER_I2C_TPM_ACPI is used to enable the "driver" needed for coreboot
to present a TPM node in the devicetree. It would usually only do so,
if coreboot itself is communicating with the TPM via I2C (I2C_TPM).
However, technically, there is no dependency.
In order to not show the ACPI option in menuconfig if the board is not
using I2C, a dependency was declared in Kconfig. However, the same can
be achieved without making it an error to manually declare
DRIVER_I2C_TPM_ACPI without I2C_TPM.
For Volteer, we have just such a need, since it has two "sub-variants"
sharing the same overridetree.cb, one having SPI TPM and another having
I2C TPM. The former will have a disabled ACPI node representing the I2C
TPM, while its Kconfig is such that coreboot itself does not have I2C
TPM support.
In order to export even a disabled ACPI node representing the I2C
connected TPM, coreboot needs DRIVER_I2C_TPM_ACPI. Hence, that will
have to be enabled in a case where coreboot does not have I2C_TPM (for
one of the two sub-variants, namely volteer2).
BUG=b:173461736
TEST=Tested as part of next CL in chain
Change-Id: I9717f6b68afd90fbc294fbbd2a5b8d0c6ee9ae55
Signed-off-by: Jes Bodi Klinke <jbk@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48222
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Move all memory map definitions into a separate header.
Tested with BUILD_TIMELESS=1, Packard Bell MS2290 remains identical.
Change-Id: I1f37ad9cae39041f98871c613b308b5ac5da01b3
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45379
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
There's no need to wrap these macros with casts. Removing them allows
dropping more casts in `early_init.c`.
To avoid binary changes the casts are put into the
{MCH,DMI,EP}BAR{8,16,32} macros instead where they are needed to reach
the right memory locations.
Change-Id: Icff7919f7321a08338db2f0a765ebd605fd00ae2
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45378
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Inspired by Idca25b2e4bf65abcb and Ib275f9ad8ca9ff move all memory map
definitions into a header with a common name.
Change-Id: I32a99f70f4d2eb52367c9edfc0aa6d5da2fec03f
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48234
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Setting PegXEnable to 1, statically enables the PEG ports, which blocks
the SoC from going to deeper PC states. Instead, set the state to "auto"
(2), so the port gets disabled, when no device was detected.
Note: Currently, this only works with the AST PCI bridge disabled or the
VGA jumper set to disabled on coreboot, while it works on vendor
in any case. The reason for this is still unclear.
Test: powertop on X11SSM-F shows SoC in PC8 like on vendor firmware
instead of just PC3
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Change-Id: I3933a219b77d7234af273217df031cf627b4071f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48304
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Furquan Shaikh <furquan@google.com>
The patch modifies KConfig behaviour if CSE Lite SKU is integrated into
the coreboot. When the CSE Lite SKU is integrated, the KConfig prevents
writing to ME region but keeps read access enabled. Since CSE Lite driver
checks the signature of RW partition to identify the interrupted CSE
firmware update, so host must have read access to the ME region. Also, the
patch modifies the KConfig's help text to reflect the change.
When CSE Lite SKU is integrated, master access permissions:
FLMSTR1: 0x002007ff (Host CPU/BIOS)
EC Region Write Access: disabled
Platform Data Region Write Access: disabled
GbE Region Write Access: disabled
Intel ME Region Write Access: disabled
Host CPU/BIOS Region Write Access: enabled
Flash Descriptor Write Access: disabled
EC Region Read Access: disabled
Platform Data Region Read Access: disabled
GbE Region Read Access: disabled
Intel ME Region Read Access: enabled
Host CPU/BIOS Region Read Access: enabled
Flash Descriptor Read Access: enabled
BUG=b:174118018
TEST=Built and verified the access permissions.
Signed-off-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Change-Id: I2f6677ab7b59ddce827d3fcaae61508a30dc1b28
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48267
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Jamie Ryu <jamie.m.ryu@intel.com>
Felix Held