Linux upstream's checkpatch.pl has a default max line length of 100.
Since coreboot uses 96, add --max-line-length=96 to the config file.
Change-Id: I7737f3d2e0d016b0f0dd82df2865a6b51b667066
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85435
Reviewed-by: Yidi Lin <yidilin@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The SoC won't be able to boot without dram.elf. Therefore, we should
always expect the file to exist in build time.
BUG=none
TEST=emerge-rauru coreboot
BRANCH=none
Change-Id: Ib902dc4778f34a144dddf847c283fe77d4c776f6
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85441
Reviewed-by: Yidi Lin <yidilin@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This matches the size used in the reference code and required by the
corresponding document #55758 Rev. 2.04. This doesn't seem to make any
difference in runtime behavior, but I'd rather waste a kilobyte of SMM
RAM, than debugging possible problems caused from not following the
corresponding specification.
Change-Id: I2ee30d6d1255317efcd3960016069dfe50885aa7
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85357
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
While gcc didn't seem to care about that mismatch, clang didn't like
that '%ld' was used in the printk format string to print a size_t
variable. Replace the correct '%zu' instead of '%ld' to fix that.
Change-Id: I32bc584abe835c9c1d732c12311881345b8f0cdf
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85251
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
To see if things went wrong in the 'handle_psp_command' function, print
the status code in case it's not MBOX_PSP_SUCCESS.
Change-Id: I8c02e8e29ab5619282e5b864a8cea6f0703f6ef2
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85238
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Extend the 'psp_smi_spi_rpmc_inc_mc' and 'psp_smi_spi_rpmc_req_mc'
function stubs that now implement the actual functionality by calling
'spi_flash_rpmc_increment' and 'spi_flash_rpmc_request' after doing some
sanity checks.
TEST=When selecting both 'SOC_AMD_COMMON_BLOCK_PSP_RPMC' and
'SOC_AMD_COMMON_BLOCK_PSP_SMI' Kconfig options on a board with an RPMC-
capable SPI flash, the PSP SMI handler can successfully service not only
the already working SPI flash write command, but also the increment
monotonic counter RPMC command:
[NOTE ] coreboot-[...] x86_32 smm starting (log level: 8)...
[SPEW ] SMI# #0
[SPEW ] PSP: SPI write request
[DEBUG] FMAP: area PSP_NVRAM found @ f20000 (131072 bytes)
[SPEW ] PSP: SPI write 0x400 bytes at 0x0
[NOTE ] coreboot-[...] x86_32 smm starting (log level: 8)...
[SPEW ] SMI# #0
[SPEW ] PSP: SPI write request
[DEBUG] FMAP: area PSP_NVRAM found @ f20000 (131072 bytes)
[SPEW ] PSP: SPI write 0x400 bytes at 0x400
[NOTE ] coreboot-[...] x86_32 smm starting (log level: 8)...
[SPEW ] SMI# #8
[SPEW ] PSP: SPI write request
[DEBUG] FMAP: area PSP_NVRAM found @ f20000 (131072 bytes)
[SPEW ] PSP: SPI write 0x310 bytes at 0x800
[NOTE ] coreboot-[...] x86_32 smm starting (log level: 8)...
[SPEW ] SMI# #1
[SPEW ] PSP: SPI write request
[DEBUG] FMAP: area PSP_RPMC_NVRAM found @ f40000 (262144 bytes)
[SPEW ] PSP: SPI write 0x70 bytes at 0x100
[NOTE ] coreboot-[...] x86_32 smm starting (log level: 8)...
[SPEW ] SMI# #0
[SPEW ] PSP: SPI RPMC increment monotonic counter request
This requires the PSP_RPMC_NVRAM FMAP section to have the correct size
which in case of Renoir is 256 kByte. Having this large enough size also
makes the PSP report that the PSP RPMC NVRAM is healthy which wasn't the
case in previous tests when the region was too small.
Change-Id: I20e4f60d4e35d33e560fc43212b320e817e13004
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84906
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Commit ee93b35bc3 ("soc/amd/common/psp_smi_flash: add RPMC command-
specific data structures") added the 'psp_spi_rpmc_inc_mc' and
'psp_smi_rpmc_req_mc' structs, but added the counter data as uint32_t
while it should have been an array of 4 uint8_t, since the bytes in that
buffer are already in the order in which they need to be sent over to
the SPI flash which is different than the byte order of a uint32_t. This
was only noticed after getting the code that uses these structs was
tested.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I6c290535a1896c080b74d892cb289e6e122d4525
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85236
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add functions to send the RPMC-related commands to a RPMC-capable SPI
flash to provision the root key, update the HMAC key, increment the
monotonic counter, and request the monotonic counter data. To talk to
the flash chip, the command bytes and polling mechanism described in the
SFDP data structure of the flash are used.
The JESD260 specification was used as a reference.
Some of inspiration was taken from
github.com/teslamotors/coreboot/tree/tesla-4.12-amd
TEST=When used with the later patch that calls some of the functions
added in this patch, sending the RPMC increment monotonic counter
command to the RPMC-capable SPI flash, in this case W74M12JW, is
successful.
Change-Id: Ia9bd69d0105c66bf5ecb6c90e8c782a81912bd40
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84837
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add information about how the symlink target can be used
to develop and test additions to the coreboot tree from
site-local.
Change-Id: I75f9e9575005e9ee2f255848a21c5e57c30e9e72
Signed-off-by: Nicolas Kochlowski <nickkochlowski@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84740
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Ana Carolina Cabral
Reviewed-by: Nicholas Chin <nic.c3.14@gmail.com>
The parentheses are missing in the mtk_scp macro definition.
The only usage is
SET32_BITFIELDS(&mtk_scp->scp_clk_on_ctrl,
SCP_CLK_ON_CTRL, 1);
I guess that bit is already set by default, so there's no ULPOSC clock
issue found so far.
BUG=none
TEST=none
BRANCH=cherry
Change-Id: I2dbb5c465ee60f0c4dce8ff77b8d3a39db42e4f5
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85436
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yidi Lin <yidilin@google.com>
Derive the audio amplifier from FW_CONFIG, and set up I2C and I2S for
TAS2563. Also pass the corresponding GPIO(s) to the payload.
TEST=build pass and driver init ok
BUG=b:357969183
Change-Id: I10cba7964d3847f2a74341b3130ff1e7bfd8d37a
Signed-off-by: Darren Ye <darren.ye@mediatek.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85360
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yidi Lin <yidilin@google.com>
HW TX tracking works by writing a pattern to the designated DRAM buffer
and then reading it back automatically to calculate the appropriate TX
time delay. To avoid writing the pattern to system-used memory, we need
to permanently reserve last 64KB memory on each rank for the HW TX
tracking feature.
BUG=b:317009620
TEST=Reserve memory ok
Firmware shows the following log with 12GB DDR board:
00000001ffff0000-00000001ffffffff: RESERVED
000000037fff0000-000000037fffffff: RESERVED
Change-Id: I042a74c7fbdc0d3dc19dd6bfd2bf021fe1c2b5fc
Signed-off-by: Crystal Guo <crystal.guo@mediatek.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85124
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yidi Lin <yidilin@google.com>
Since commit e633d370 (soc/intel/cometlake: Enable early caching of
RAMTOP region), cmos.layout for Cannon Lake boards must have a ramtop
entry, add it.
Change-Id: I2bf71f2dd79f2e1e2e13f62a3e08103336bbad61
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77670
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Use the DEV_PTR macro to resolve devicetree aliases instead of using the
autogenerated reference names from sconfig directly.
TEST=Timeless build did not change
Change-Id: I4ff06bb3a8256d5fe215cab659f33ec404264e21
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85093
Reviewed-by: Jonathon Hall <jonathon.hall@puri.sm>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Fix the syntax [1] for the footnote about the onboard memory
configuration so that it renders properly in the generated html.
This also fixes a "Unknown target name" error when building with
newer versions of Sphinx (tested with 8.1.3).
[1] https://myst-parser.readthedocs.io/en/latest/syntax/typography.html#footnotes
Change-Id: I07a85b854a181794f82d8e6a739063d66378d2c7
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85412
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Add Micron memory part H58G56CK8BX146 to LP5 global list.
And Regenerate the SPD files for the SoC. The specification
is attached in issue tracker.
BUG=b:367841051
TEST=util/spd_tools/bin/spd_gen spd/lp5/memory_parts.json lp5
Change-Id: I2a003aad32bca9ae5438973ecf0d7872481fee20
Signed-off-by: Roger Wang <roger2.wang@lcfc.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85371
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
These header files do not seem to be used in coreboot. Presumably
they're left over after the code that used them was removed.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: Ide70239c7c2e93fff548d989735450396308c62b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85370
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
The code is simplified by using the mmio.h macros clrsetbits.
Change-Id: Iab71ab4d6e8b6c38e07641dae3b38093690543e8
Signed-off-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85325
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Due to layout restrictions on mc_ehl5, the eMMC interface is limited to
operate in DDR50 mode. The alternative modes SDR104 and SDR50 are not
supported. Limit the capabilities in the eMMC controller to DDR50 mode
only so that the eMMC driver in OS will choose the right mode for
operation even if the attached eMMC card supports higher modes.
BUG=none
TEST=Boot into Linux and check dmesg output for mmc modes
Change-Id: Ie3214bc3e25e7af706a5c96244d0be50f4bb3094
Signed-off-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85314
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
As the functionality is required for other devices, it makes sense to
provide a function for this.
Change-Id: If1f070eebd365de93d4bce13d5201045d3306b17
Signed-off-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85324
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
As the registers for SD-Card and eMMC are identical, the names of the
register defines should also be kept more general. Therefore change the
defines from 'SD_' to 'MMC_'.
Change-Id: I2e0839a00f1b097f92f4f7774d973196d2d0e9a3
Signed-off-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85313
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Uwe Poeche <uwe.poeche@siemens.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
kconfig incorrectly builds fatcat instead of feilino.
Modify the kconfig file to successfully compile felino.
BUG=b:379797598
TEST=1. util/abuild/abuild -p none -t google/fatcat -x -a
make sure the build includes GOOGLE_FELINO
2. Run part_id_gen tool without any errors
Change-Id: Icd76fa97b9879d8f90ae9ee13998b6667f10b39c
Signed-off-by: Tongtong Pan <pantongtong@huaqin.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85315
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Weimin Wu <wuweimin@huaqin.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Pranava Y N <pranavayn@google.com>
The TCSS configuration now relying on the PD<->PMC communication
for the fatcat board.
This removes the need to override the `TcssAuxOri` UPD setting.
TEST=Booted fatcat successfully. Verified USB-C device detection and
functionality on both TCSS#0 and TCSS#1 ports.
Change-Id: I37d5c6fe68ad529b4da46aad460e5c1bf92179a8
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85356
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Pranava Y N <pranavayn@google.com>
Add/update FP enable/disable based on SKU ID. This is meant
to resolve a UMA issue with devices that had the FPMCU populated on
non-fp devices. Since the FPMCU is present, and the firmware enables
the power GPIO's based on variant, not SKU, the devices were reporting
data on fingerprint errantly. Specify the SKUs which should not have a
FP sensor and default to true to maintain the legacy behavior for
undefined devices and limit risk. Variants which do not have FP SKUs
will be unaffected.
BUG=b:354769653
TEST=Flash to zork, test FP.
Disable test SKU, flash on zork, test FP.
To test, run `ectool --name=cros_fp version` in the shell
When enabled, the fpmcu fw version should be displayed.
When disabled, an error should be displayed because the fpmcu
is inaccessible.
Change-Id: Ic6dc71013a1c0d5ee5263109eed87a1b31800232
Signed-off-by: Jon Murphy <jpmurphy@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85294
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Currently only a fixed number of harts/cores can be detected.
This patch adds a Kconfig option which allows to detect the number of
harts at runtime if a SOC or mainboard has a scheme to do so.
As part of that patch SMP logic has been mostly moved to smp_resume,
since it is easier to debug issues at the time smp_resume is called
than it is at smp_pause, since the serial is usually not present at the
time of the first smp_pause call.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: Icc53185991fed4dbed032a52e51ff71d085ad587
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81082
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Alicja Michalska <ahplka19@gmail.com>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
The reasoning is that even though vendors currently tend to open source
their OpenSBI implementation, they often do so in their own repository.
So instead of adding all possible source repositories as submodules, we
shall allow specifying a path to an already compiled OpenSBI ELF file.
This is similar of what we currently do on ARM64 with the BL31 binary.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: I6592ad90a254ca4ac9a6cee89404ad49274f0dea
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83284
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Alicja Michalska <ahplka19@gmail.com>
Reviewed-by: ron minnich <rminnich@gmail.com>
It is unnecessary to look up PMIF controller by mstid in multiple
functions. Just pass `arb` to these functions in order to avoid
redundant calls to get_pmif_controller().
BUG=none
TEST=compiled
Change-Id: I907d6ff029827e4afe4f1d05e39c8dd662c7c45e
Signed-off-by: Yidi Lin <yidilin@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85327
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch refactors the configuration of GPP_E07 (EC_SOC_INT_ODL) to
accommodate the fatcat_ish variant
The GPP_E07 is not connected on google/fatcat variants using the
Microchip EC AIC.
BUG=b:370984186
TEST=Able to build fatcat/fatcat_ish w/o any error.
Change-Id: I88bd76b2110b4c0742569f1ccb2030ea516b3782
Signed-off-by: Jayvik Desai <jayvik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85223
Reviewed-by: Pranava Y N <pranavayn@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Adjusts the EC host command range for the fatcat_ish variant
to 0x800-0x807 & 0x200-0x20f.
This change is necessary because the microchip EC used on the Fatcat
board has a smaller host command range than the ITE/Nuvoton ECs used
on other Fatcat variants.
without this patch:
[SPEW ] LPC: Trying to open IO window from 800 size 8
[ERROR] LPC: Cannot open IO window: 800 size 8
[ERROR] No more IO windows
with this patch:
[SPEW ] LPC: Trying to open IO window from 800 size 8
BUG=b:370984186
TEST=Able to build fatcat/fatcat_ish w/o any error.
Change-Id: I0d726d60d2a15d2dfaff35f570de479fdc6d15aa
Signed-off-by: Jayvik Desai <jayvik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85221
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Pranava Y N <pranavayn@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
This patch adds the "fatcat_ish" board to the fatcat Kconfig.
BUG=b:370984186
TEST=Able to build fatcat/fatcat_ish and verify the correct configs
selected in coreboot.config
Change-Id: I8a49ce54e946dfdfad253ff946da1b37ed50dd0a
Signed-off-by: Jayvik Desai <jayvik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85220
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Pranava Y N <pranavayn@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change corrects the indentation and also does the following to have
the ASL code written in a more canonical style:
- Add space between the operator name and "(".
- Use uppercase for hexadecimal values.
Change-Id: Ib946599f8ab4d68b16867912743f4a7a5bc0307d
Signed-off-by: Nicholas Sudsgaard <devel+coreboot@nsudsgaard.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85281
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Drive Strength BRI Rsp Object provides information from the OEM
platforms if they have replaced the Bluetooth Radio Interface resistor
to overcome the potential STEP errors on their designs. Based on
configuration, CNV firmware shall adjust the BRI Rsp line drive
strength.
The bri_resistor_value is encoded as follow:
| Bit | Val | Description | Default |
|------+-----+---------------------------------------------+---------|
| 0 | 0 | Device FW default values | 1 |
| | 1 | Override device FW default values | |
| 3:1 | 0 | Reserved (shall be set to 0) | 0 |
| 7:4 | 0 | DSBR override values (only if bit 0 is set) | 0xf |
| 31:7 | 0 | Reserved (shall be set to 0) | 0 |
Possible values:
- 0xf1 (default): indicates that the resistor on board is 33 Ohm
- 0x0 or 0xb1: indicates that the resistor on board is 10 Ohm
The implementation follows document 559910 Intel Connectivity
Platforms BIOS Guideline revision 9.2 specification.
BUG=b:346600091
TEST=DSBR methods are added to the wifi device and bluetooth companion
device and they return the data supplied by the SAR binary blob
Change-Id: Iebe95815c944d045f4cf686abcd1874a8a45e300
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85017
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This feature provides ability to provide Wi-Fi PHY filter
Configuration. A well-defined dedicated filter on particular platform
can be used to perform the maximum Wi-Fi performance.
The implementation follows document 559910 Intel Connectivity
Platforms BIOS Guideline revision 9.2 specification.
BUG=b:346600091
TEST=WPFC method is added to the wifi device and return the data
supplied by the SAR binary blob
Change-Id: Iebe95815c944d045f4cf686abcd1874a8a45e270
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84948
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Extended Bluetooth Regulatory Descriptor (EBRD) SAR/RFE are safety
regulations for limiting antenna radiation near human contact. EBRD
provides option to provide up to three sets of TX power limits and
power restrictions.
As the EBRD table is related to the revision 2 of the BRDS, this
commit also adds support for this new revision.
The implementation follows document 559910 Intel Connectivity
Platforms BIOS Guideline revision 9.2 specification.
BUG=b:346600091
TEST=EBRD method is added to the bluetooth companion device and
return the data supplied by the SAR binary blob
Change-Id: Iebe95815c944d045f4cf686abcd1874a8a45e250
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84947
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This feature provides ability to set the Bluetooth Dual Mac Mode
setting.
The implementation follows document 559910 Intel Connectivity
Platforms BIOS Guideline revision 9.2 specification.
BUG=b:346600091
TEST=BDMM method is added to the bluetooth companion device and
return the data supplied by the SAR binary blob
Change-Id: Iebe95815c944d045f4cf686abcd1874a8a45e240
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84946
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
This feature provides ability to set the Bluetooth Ultra High
Band (UHB) settings per country. The bluetooth UHB country selection
is defined as follow (default is 0):
| Bit | Value | |
|-------+-------+---------------------------------------------------|
| 0 | 0 | No override; use BT device settings |
| | 1 | Force disable BT in all countries that are not |
| | | defined in the following bits |
| 1 | 0 | USA 6GHz BT disable |
| | 1 | 6GHz BT allowed in the USA (enabled only if the |
| | | device is certified to the USA) |
| 2 | 0 | Rest of the World 6GHz BT disable |
| | 1 | 6GHz BT allowed in the Rest of the World (enabled |
| | | only if the device is certified to the rest |
| | | of the world) |
| 3 | 0 | EU countries 6GHz BT disable |
| | 1 | 6GHz BT allowed in the EU countries (enabled only |
| | | if the device is certified to the EU countries) |
| 4 | 0 | South Korea 6GHz BT disable |
| | 1 | 6GHz BT allowed in the South Korea (enabled only |
| | | if the device is certified to the South Korea) |
| 5 | 0 | Brazil 6GHz BT disable |
| | 1 | 6GHz BT allowed in the Brazil (enabled only if |
| | | the device is certified to the Brazil) |
| 6 | 0 | Chile 6GHz BT disable |
| | 1 | 6GHz BT allowed in the Chile (enabled only if the |
| | | device is certified to the Chile) |
| 7 | 0 | Japan 6GHz BT disable |
| | 1 | 6GHz BT allowed in Japan (enabled only if the |
| | | device is certified to Japan) |
| 8 | 0 | Canada 6GHz BT disable |
| | 1 | 6GHz BT allowed in Canada (enabled only if the |
| | | device is certified to Canada) |
| 9 | 0 | Morocco 6GHz BT disable |
| | 1 | 6GHz BT allowed in the Morocco (enabled only if |
| | | the device is certified to the Morocco) |
| 10 | 0 | Mongolia 6GHz BT disable |
| | 1 | 6GHz BT allowed in the Mongolia (enabled only if |
| | | the device is certified to the Mongolia) |
| 11 | 0 | Malaysia 6GHz BT disable |
| | 1 | 6GHz BT allowed in the Malaysia (enabled only if |
| | | the device is certified to the Malaysia) |
| 31:12 | 0 | Reserved Should set to zeros |
The implementation follows document 559910 Intel Connectivity
Platforms BIOS Guideline revision 9.2 specification.
BUG=b:346600091
TEST=BUCS method is added to the bluetooth companion device and
return the data supplied by the SAR binary blob
Change-Id: Iebe95815c944d045f4cf686abcd1874a8a45e231
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84945
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
