Currently this XHCI driver assumes the PCH XHCI controller, but the TCSS
or North XHCI block has a similar enough PCI MMIO structure to make this
code mostly reusable.
1) Rename everything to drop the `pch_` prefix
2) xhci_update_wake_event() now takes in a pci_devfn_t for the XHCI
controller
3) soc_get_xhci_usb_info() also now takes a pci_devfn_t for the XHCI
controller
BUG=b:172279037
TEST=plug in USB keyboard while in S0, enter S0ix and verify entry via
EC; type on keyboard, verify it wakes up, eventlog contains:
39 | 2020-12-10 09:40:21 | S0ix Enter
40 | 2020-12-10 09:40:42 | S0ix Exit
41 | 2020-12-10 09:40:42 | Wake Source | PME - XHCI (USB 2.0 port) | 1
42 | 2020-12-10 09:40:42 | Wake Source | GPE # | 109
which verifies it still functions for the PCH XHCI controller
Change-Id: I9f28354e031e3eda587f4faf8ef7595dce8b33ea
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47411
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The xeon_sp ACPI NVS and ramstage NVS were out of sync. Since there
isn't anything uncommon with the soc NVS, use the Intel common NVS.
This covers the NVS cases of common code used by xeon_sp. Update
the mainboards for this change.
Change-Id: Icf422f5b75a1ca7a3d8f3d63638b8d86a56fdd7b
Signed-off-by: Marc Jones <marcjones@sysproconsulting.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48491
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Jay Talbott <JayTalbott@sysproconsulting.com>
We need to make most things non-static so that the code builds. Also, we
need to update ibexpeak as well, because it borrows files from bd82x6x.
Tested on Asus P8Z77-V LX2, still boots.
Change-Id: I17e561abf2378632f72d0aa9f0057cb1bee23514
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42019
Reviewed-by: Evgeny Zinoviev <me@ch1p.io>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The register name and the name of one bit are slightly different, but
have the same functionality.
Change-Id: Ie49975bb43868cbb2dc986e66dc5b7291e70222f
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48507
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Copy and paste the i82801gx code onto all newer southbridges. This will
be factored out into common code in a follow-up.
Change-Id: Ic4b7d657865f61703e4310423c565786badf6f40
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48363
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
This is for consistency among the various southbridges.
Change-Id: Id0dcfeef6e220861212ce665201ce8cd31f3b054
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48362
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
SSPM is "Secure System Power Manager" that provides power control in
secure domain. The initialization flow is to load SSPM firmware to
its SRAM space and then enable.
Signed-off-by: TingHan.Shen <tinghan.shen@mediatek.com>
Change-Id: Ia834852af50e9e7e1b1222ed1e2be20e43139c62
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47786
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
DPM is a hardware module for DRAM power management and for better
power saving in low power mode.
BUG=none
TEST=Boots correctly on Asurada
Signed-off-by: Huayang Duan <huayang.duan@mediatek.com>
Change-Id: I16b341ad63940b45b886c4a7fd733c1970624e40
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46393
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Update memory parameters based on memory type supported by
Elkhart Lake CRB:
1. Update spd data for EHL LPDDR4X memory
- DQ byte map
- DQS CPU-DRAM map
- Rcomp resistor
- Rcomp target
2. Add configurations for vref_ca & interleaved memory
3. Add EHL CRB on board LPDDR4X SPD data bin file
4. Update mainboard related FSPM UPDs as part of memory
initialization
Signed-off-by: Tan, Lean Sheng <lean.sheng.tan@intel.com>
Change-Id: Ifd85caa9ac1c9baf443734eb17ad5683ee92ca3b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48127
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Remove JSL specific SMBIOS sku id info as it is not required by
EHL.
Signed-off-by: Tan, Lean Sheng <lean.sheng.tan@intel.com>
Change-Id: Ib672eb456ba62f2eb7f941630c4fbb34823664f5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48123
Reviewed-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
THis patch removes IPU & MIPI related support from EHL CRB as they
are not supported in EHL.
Signed-off-by: Tan, Lean Sheng <lean.sheng.tan@intel.com>
Change-Id: I3eb038009daaabd048f40c7953cb2c111cd4fe63
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48122
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Frans Hendriks <fhendriks@eltan.com>
Since there is no EC support on EHL CRB, this patch removes board
ID detection via EC (board_id.c & board_id.h) and its related
files. Temporarily removes variant_memcfg_config function in
romstage_fsp_param.c, will be added back when updating memory
configs later.
Signed-off-by: Tan, Lean Sheng <lean.sheng.tan@intel.com>
Change-Id: I40d96285dc05ec5faabc123950b6b3728299e99a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48121
Reviewed-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Since EHL CRB does not support ChromeOS, this patch removes
ChromeOS EC related headers (ec.h & gpio.h) and #includes.
Signed-off-by: Tan, Lean Sheng <lean.sheng.tan@intel.com>
Change-Id: I9c0c3722065c041769081f3d564646ce6a565a9b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48119
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Frans Hendriks <fhendriks@eltan.com>
Since there is no ChromeOS support for EHL CRB, drop smihandler.c
which just deals with ChromeOS support.
Signed-off-by: Tan, Lean Sheng <lean.sheng.tan@intel.com>
Change-Id: Id474c3b04a82c03dda6514cc4565b58fb790b9c1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48118
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Frans Hendriks <fhendriks@eltan.com>
Since ChromeOS is not officially supported for EHL CRB, removing
ChromeOS related codes. Here are the change details:
- Remove ChromeOS related kconfig switches, including
SOC_INTEL_CSE_LITE_SKU which has dependency on ChromeOS flag
- Remove chromeos.c file
- Remove ChromeOS dsdt related codes from dsdt.asl & mainboard.c
- Remove ChromeOS GPIO related codes from variants.h & gpio.c
Signed-off-by: Tan, Lean Sheng <lean.sheng.tan@intel.com>
Change-Id: I4aabd40a4b46d4e64534b99e84e0523eaeaff816
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48117
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
This is a initial mainboard code cloned entirely from jasperlake_rvp
aimed to serve as base for further mainboard check-ins.
This patch is based on TGL_upstream series patches:
https://review.coreboot.org/c/coreboot/+/37868
List of changes on top off initial jasperlake_rvp clone:
1. Replace "Jasperlake" with "Elkhartlake"
2. Replace "jsl" with "ehl"
3. Replace "jslrvp" with "ehlcrb"
4. Remove unwanted SPD file, add empty SPD as placeholder
6. Empty romstage_fsp_params.c, to fill it later with SOC specific
config
7. Empty GPIO configurations, to be filled as per board
8. Empty memory.c configurations, to be filled as per board
9. Add board support namely BOARD_INTEL_ELKHARTLAKE_CRB
10. Replace jslrvp variant with ehlcrb variant
Changes to follow on top of this:
1. Add correct memory parameters, add SPDs
2. Clean up devicetree as per tigerlake SOC
3. Add GPIO support
4. Update ehl fmd file to replace 32MB chromeos.fmd
Signed-off-by: Tan, Lean Sheng <lean.sheng.tan@intel.com>
Change-Id: I2cbe9f12468318680b148739edec5222582e42a0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47707
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
When EHL initial mainboard patch is uploaded, there are some build
errors caused by EHL soc codes. Here are the fixes:
1. include gpio_op.asl to resolve undefined variables in scs.asl
2. remove unused variables in fsp_params.c
3. rearrage sequences of #includes to fix build dependency of
soc/gpio_defs.h in intelblocks/gpio.h
4. add the __weak to mainboard_memory_init_params function
5. add the missing _len as per this patch changes
https://review.coreboot.org/c/coreboot/+/45873
Signed-off-by: Tan, Lean Sheng <lean.sheng.tan@intel.com>
Change-Id: Idaa8b0b5301742287665abde065ad72965bc62b3
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47804
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
MCUPM is the MediaTek proprietary firmware for MCU power management.
TEST=1. emerge-asurada coreboot chromeos-bootimage;
2. See following log during booting.
load_blob_file: Load mcupm.bin in 35 msecs, size 115668 bytes
3. Test suspend/resume by:
a. suspend (on DUT): powerd_dbus_suspend
b. resume (on host): dut-control power_state:on
Change-Id: I50bea1942507b4a40df9730b4e1bf98980d74277
Signed-off-by: Yidi Lin <yidi.lin@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46392
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch adds support for loading spm firmware from cbfs to spm sram.
Spm needs its own firmware to enable spm suspend/resume function which
turns off several resources such as DRAM/mainpll/26M clk when linux
system suspend.
BUG=b:159079649
TEST=suspend with command `powerd_dbus_suspend` and
wake up the DUT by powerkey
Signed-off-by: Roger Lu <roger.lu@mediatek.com>
Change-Id: I6478b98f426d2f3e0ee919d37d21d909ae8a6371
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46389
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Use mtk_init_mcu API to load and run sspm firmware.
TEST=emerge-kukui coreboot
Change-Id: I63c4b99342bdebb2a94cbf0c6380b0a6817853e7
Signed-off-by: Yidi Lin <yidi.lin@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48233
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
mtk_init_mcu uses DRAM_DMA section as CBFS buffer.
The change "mediatek/mt8183: Remove DRAM_DMA section" is reverted
for using mtk_init_mcu.
On mt8173 and mt8192, this region is used by DMA hardware and is
marked as non-cacheable resource. On mt8183, this region is reserved
as CBFS buffer, so it is not necessary to be marked as non-cacheable
resource.
Change-Id: I7ce9f68883e2787ee7f3c5066f4c47c5ca315633
Signed-off-by: Yidi Lin <yidi.lin@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48232
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Add mtk_init_mcu to load the firmware to the specified memory address
and run the firmware. This function also measures the load time and the
blob size. For example:
mtk_init_mcu: Loaded (and reset) dpm.pm in 15 msecs (14004 bytes)
Signed-off-by: Yidi Lin <yidi.lin@mediatek.com>
Change-Id: Ie94001bbda25fe015f43172e92a1006e059de223
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46930
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Follow vendor and enable Advanced Error Reporting for PCIe root ports.
This enabled the Linux AER driver, which handles PCIe error conditions.
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Change-Id: I9d9b5afca0ca891e2812445db1d42a46ba16199e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48369
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add the subsystem ids to PCI ports and devices, which were dumped on
vendor firmware using `lspci`.
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Change-Id: Idb36c5c72e1b0b8303439ae5dce772822f551d2d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48368
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Follow vendor and enable LTR on all root ports to optimize for devices'
latency requirements and also optimize power management while preventing
failure due to wrongly guessing idle states, which happens without LTR.
Tested successfully. No errors show up in dmesg.
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Change-Id: I8f72087c71e291d2412dc7b3e16ee7f419e2ca0c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48367
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
All X11 boards currently supported have Intel SPS without support for
S3/S5. Thus, drop it from Kconfig.
Note: not all X11 boards are server boards. When a X11 desktop or
workstation board should be added, this can be selected by the boards,
where S3/S5 work.
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Change-Id: Ie75c9217078d38c42eba2b30c078b8bb1c2ca694
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48366
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Correct unconnected pads that are configured different currently by
copying vendor configuration while porting the board.
Add internal pull resistors to all unconnected pads, that do not have an
external pull resistor, to prevent floating.
The pads have been determined by dissecting a dead board. This commit
only changes pads, that are not connected at all and don't have any via,
so we can be absolutely sure there is no other connection.
Change-Id: I991fe270b42f430f7447712236e0f80b3d5bba2a
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48099
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
(Re)configure various pads found by dissecting a dead board and vendor
firmware, as well as the BMC firmware:
- GPP_B14: input connected to jumper JBR1 - could be used to implement
"BIOS Recovery" ("Top-Block Swap") functionality; external pull-up
- GPP_C20: output to BMC alert CPU_THROTTLED# - can be used to notify
the BMC about a thermal throttling event. Not implemented in vendor
firmware.
- GPP_C23: input connected to the CPU's CATERR# output; external pull-up
Not actively used by vendor firmware.
- GPP_D1: output connected to on-board and front panel power LEDs
- GPP_D18: output connected to PERST# of both CPU PCIe Slots. Can be
used for testing/debugging only, since it resets both slots at once.
Not actively used by vendor firmware.
- GPP_D19: output connected to PERST# of both PCH PCIe Slots. Can be
used for testing/debugging only, since it resets both slots at once.
Not actively used by vendor firmware.
- GPP_D22: input connected to the BMC enable/disable jumper JPB1; Will
be used later in CB:48096 and CB:48097; external pull-up
- GPP_G0 - GPP_G3: dedicated/integrated CPU switching; probably not
useful, since the IGD is not connected to any ports on this board.
External pulls ensure correct function of a dGPU even without driving
the gpios. Not used by vendor firmware.
- GPP_G12 - GPP_G16: inputs for binary SKU_ID; external pulls
- GPP_G20: PWRFAIL# input from JPI2C1 (pin 3); external pull-up; Not
used by vendor firmware.
Also add comments for documentation. While at it, mark ME-owned pads as
reserved.
Change-Id: I9f9328e9ce6f7e291b171f776bb98bc617b64b93
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48098
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
The register name and the name of one bit are slightly different, but
have the same functionality.
Change-Id: I025f1c7b2c7643afe245f2275ae6ef45e64b951a
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48487
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
On Stoneyridge some PCI registers were accessed in this compilation
unit, but on Picasso this is no longer the case.
Change-Id: Ifbf65f9724a14d4847af98930759c865453775b4
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48486
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When passing $(@) to eval command, $(@) is replaced by empty string,
Also, the $(@) in cbfs-files-processor-struct is a temporary file name,
so we should quote it by an extra '$' or use the arg ($1 or $2)
directly.
For example:
cbfs-files-processor-struct= \
$(eval $(2): $(1) $(obj)/build.h $(KCONFIG_AUTOHEADER); \
# ** $(@) is empty string instead of $(2) **
printf " CC+STRIP $(@) \n"; \
# ** $(1) contains the name of source file **
printf " CC+STRIP $(1) \n"; \
......)
Signed-off-by: Xi Chen <xixi.chen@mediatek.com>
Change-Id: Id6a66e25d7dfe8fe6410e517593ed22a438d2f82
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48201
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Since the IOAPIC in the FCH gets set up in the SMBus code, also select
IOAPIC in Kconfig.
Change-Id: I4163e28ca9e68e5fd36421d90aafc20bce43a174
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48474
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch addresses the same problem as CB:48429, but hopefully this
time correctly. Since the mcache is not guaranteed to be available on
the first CBFS lookup for some special cases, we can no longer treat it
as a one-time fire-and-forget initialization. Instead, we test
cbd->mcache_size to check if the mcache has been initialized yet, and
keep trying on every lookup if we don't find it the first time.
Since the mcache is a hard requirement for TOCTOU safety, also make it
more clear in Kconfig that configurations known to do CBFS accesses
before CBMEM init are incompatbile with that, and make sure we die()
rather than do something unsafe if there's a case that Kconfig didn't
catch.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I4e01e9a9905f7dcba14eaf05168495201ed5de60
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48482
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
This reverts commit b652aaef99. It was
dumb and didn't actually fix anything.
Change-Id: I074135dd12face1226105e0706c78ae8ecba18e0
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48481
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The two Socs don't use this functionality and biosram.c in the common
code is the only place where those defines are used, but it doesn't
include soc/iomap.h and has its own definitions instead.
Change-Id: I973df4ab39a94e89ea2ed6ffb639c5a85b8df456
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48470
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
The number at the end actually means the max MiB/s. So 52 MHz clock @ 8x
data width, sampled on each clock edge = 104 MiB/s.
According to JEDEC Standard No. 84-B51A (JESD84-B51A), maximum bandwidth
& clock frequency for various MMC bus speed modes are (at x8 bus width):
MMC_Legacy: 26 MB/s at 26 MHz Single Data Rate (SDR)
MMC_HS: 52 MB/s at 52 MHz SDR
MMC_DDR52: 104 MB/s at 52 MHz Dual Data Rate (DDR)
MMC_HS200: 200 MB/s at 200 MHz SDR
MMC_HS400: 400 MB/s at 200 MHz DDR
BUG=b:159823235
BRANCH=zork
TEST=build zork
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I7818d8cb5ed5974c60a900477a0aa2ecc904db0c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48309
Reviewed-by: Jason Glenesk <jason.glenesk@gmail.com>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Rob Barnes <robbarnes@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Due the location of X86_RESET_VECTOR, the anchor point
for linking the bootblock is at the end, which equals
ROMSTAGE_ADDR.
Change-Id: I2d25911582393c9a10fd3afa1a484eda2604d95a
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48406
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
The architectural requirement is for the address to be
located at the end of bootblock -0x10 bytes, so the
definition was redundant with other Kconfig variables.
Change-Id: Ia014470cfadf0b401a12a2de6dce3b1fc1862137
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48405
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
This change adds support to lock down the DMI configuration
in dmi_lockdown_cfg() by setting Secure Register Lock (SRL)
bit in DMI control register.
BUG=b:171534504
Signed-off-by: Srinidhi N Kaushik <srinidhi.n.kaushik@intel.com>
Change-Id: I98a82ce4a2f73f8a1504e5ddf77ff2e81ae3f53f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48258
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change reorganizes FMAP for volteer to make use of the lower
16MiB of the SPI flash for RW_SECTION_A and RW_MISC in addition to
RW_LEGACY. This is now possible because TGL supports memory mapping of
BIOS region greater than 16MiB.
Following changes are made in chromeos.fmd as part of this:
1. Move RW_SECTION_A and RW_MISC to lower 16MiB.
2. Reduce size of RW_LEGACY to 2MiB since we longer need to use it as
a placeholder in the lower half of the SPI flash.
3. Reduce size of RW_ELOG to 4KiB as coreboot does not support a
larger region for ELOG.
4. Increase WP_RO to 8MiB to allow larger space for firmware
screens. GBB size is thus increased to 448KiB.
BUG=b:171534504
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: I0c3c0af94183a80c23d196422d3c8cf960b9d9f5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48187
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Tim Wawrzynczak