When a ChromeOS device has `SPLASH_SCREEN_FOOTER` Kconfig enabled and
provides a logo path for an OEM-defined boot splash logo in the footer,
it indicates that the device doesn't need to render
`cb_plus_logo.bmp` logo (hence, avoid packing this bitmap for platforms
that select `SPLASH_SCREEN_FOOTER` Kconfig).
In such cases, only the main OEM logo should be displayed at the center
of the splash screen along with custom bitmap at footer of the splash
screen.
BUG=b:423591644
TEST=Able to show OEM splash screen on google/fatcat.
Change-Id: Ie5085babe2f8373058ce1aa18b7071260f2aef7f
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88099
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Use POSTPONE_SPI_ACCESS to handle elog data later boot phase to avoid
flash access delay by other boot controllers.
Intel has pre-CPU boot controllers (e.g. CSE) which load non-CPU
firmwares. Boot-critical firmwares are loaded before CPU reset and
non-boot-critical firmwares are loaded during CPU boot. If another
controller accesses SPI to load firmwares, reading SPI by CPU is ok,
but writing to SPI for saving elog data can take ~32ms sometimes.
Saving elog data usually takes less than 1ms.
There are three elog handling sequences that need to move together
under the Kconfig:
- Soc folder
- Elog driver folder
- ChromeOS folder
Before this change, sometimes it delays like below:
BS: callback (0x7386d428) @ src/soc/intel/pantherlake/elog.c:216 (32 ms)
After this change, the delay is less than 1 ms:
BS: callback (0x7386d3e8) @ src/soc/intel/pantherlake/elog.c:213 (0 ms)
TEST
1. Enable DEBUG_BOOT_STATE
2. Check time
BS: callback (0x7386d3e8) @ src/soc/intel/pantherlake/elog.c:213 (0 ms))
Change-Id: I3f5e7acf5204e213179664d0d77151d415d00896
Signed-off-by: Wonkyu Kim <wonkyu.kim@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87740
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
This change moves pvmfw cbmem implementation to chromeos directory and
under CHROMEOS kconfig. The kconfigs have been renamed accordingly and
with this change CHROMEOS_PVMFW_CBMEM is enabled by default for
CHROMEOS.
BUG=b:410735713
TEST=The build with CONFIG_CHROMEOS=y allocates buffer for pvmfw, the
depthcharge adds the location and size of the buffer to the kernel
command line
Change-Id: I024f21ceee1334ebd7ae9bf1b897ad670ddc9ef9
Signed-off-by: Bartłomiej Grzesik <bgrzesik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87763
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add an allocation of an empty buffer for the Android protected virtual
machine firmware within cbmem. The buffer will be filled by the payload
and the purpose is to just reserve the memory. cbmem is used to make
sure that the region won't overlap with other reserved regions
or device regions.
BUG=b:354045389
BUG=b:359340876
TEST=depthcharge receives the buffer through lib_sysinfo
BRANCH=main
Change-Id: I48efc033ac0f5fbfcf3a52fabf40be016cd4c6f7
Signed-off-by: Bartłomiej Grzesik <bgrzesik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87107
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jakub "Kuba" Czapiga <czapiga@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
This patch refactors low-battery user notification logic (Kconfig,
APIs to check if low-battery rendering is required, low-battery
shutdown is required) outside FSP driver code to ensure in future
non-FSP platforms might still be able to leverage this feature/logics
to render the low-battery indicator icon during boot.
Specifically, it:
- Moves Kconfig options related to low-battery notifications from
drivers/intel/fsp to lib/
- Relocates the low-battery check and shutdown APIs drivers/intel/fsp
to bootsplash.h
* Adjusts the vendor driver to utilize the new APIs for low-battery
rendering decisions.
* Drop the unwanted header file "fsp/api.h" from bmp_logo.c
This change avoids tight coupling of low-battery functionality to FSP,
promoting code reusability across platforms.
BUG=b:400738815
TEST=Able to build and boot google/brox.
Change-Id: Iaa730dac2bb4866183408b6390221f0bb8411a48
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86756
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
This commit implements `platform_is_low_battery_shutdown_needed` and
callback for ChromeOS.
- platform_is_low_battery_shutdown_needed: API to check if low battery
shutdown is needed.
BUG=b:339673254
TEST=Verified low battery boot event logging and controlled shutdown.
Change-Id: I119f80a45c045a6095cae98f179c755a2e948e9c
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86228
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
This commit introduces a new macro, cbfs_add_bmp_file, to the ChromeOS
vendor code Makefile. The macro simplifies the process of adding BMP
files to the CBFS (coreboot Filesystem) by encapsulating the
repetitive tasks of specifying file attributes such as file path,
type, and compression flag.
TEST:Both 'cb_logo.bmp' and 'cb_plus_logo.bmp' files are included with
the same properties, within the coreboot firmware image.
Change-Id: I827451da79931c09768965c3ad071ecdd918d367
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86237
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
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>
This feature provides ability to provide dual chain setting.
The implementation follows document 559910 Intel Connectivity
Platforms BIOS Guideline revision 9.2 specification.
BUG=b:346600091
TEST=BDCM method is added to the bluetooth companion device and
return the data supplied by the SAR binary blob
Change-Id: Iebe95815c944d045f4cf686abcd1874a8a45e220
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84943
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
This feature provides ability to identify non-LTE platform and disable
BiQuad Bypass filter logic in hardware for Bluetooth usecases reducing
device power consumption.
The implementation follows document 559910 Intel Connectivity
Platforms BIOS Guideline revision 9.2 specification.
BUG=b:346600091
TEST=BBFB method is added to the bluetooth companion device and
return the data supplied by the SAR binary blob
Change-Id: Iebe95815c944d045f4cf686abcd1874a8a45e213
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84942
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
The ACPI BPAG method provide information to controls the antenna gain
method to be used per country.
The antenna gain mode is a bit field (0 - disabled, 1 -enabled)
defined as follow:
- Bit 0 - Antenna gain in EU
- Bit 1 - Antenna gain in China Mainland
The implementation follows document 559910 Intel Connectivity
Platforms BIOS Guideline revision 9.2 specification.
BUG=b:346600091
TEST=BPAG method is added to the bluetooth companion device and return
the data supplied by the SAR binary blob
Change-Id: Iebe95815c944d045f4cf686abcd1874a8a45e210
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84941
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Create a new config option to indicate that a board has Google Strauss
keyboard. The scan code for Fn key will be set to 94 if the new config
is selected.
Previously each board was setting the integer config option for Fn key
scan code which was not scalable. The new option is a bool and can be
easily selected by different boards.
BUG=none
TEST=Verify coreboot.config before and after this change.
Change-Id: I2b5d54879d415e4403b2d7948432bb06ab983b86
Signed-off-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85109
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Jayvik Desai <jayvik@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch skips event logging for current boot information at ramstage
if CSE sync is scheduled at payload. Given that CSE sync could initiate
a system reset, resulting in redundant boot information logs, the
payload should handle the logging of boot information following CSE
sync.
BUG=b:360082747
TEST=Verified elog boot info is not logged at ramstage
Change-Id: Ia29ec350facc6850c04bb988027ecb146e648a50
Signed-off-by: Dinesh Gehlot <digehlot@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84120
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch introduces a new early sign-of-life config option when
libgfx or uGOP is enabled for early graphics initialization.
BUG=b:352651132
TEST=Able to build google/rex and google/tivviks
Change-Id: Ic8fe4ca5234de7f8e579f950f6ccbf750f4c7950
Signed-off-by: Jayvik Desai <jayvik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83705
Reviewed-by: Dinesh Gehlot <digehlot@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch enables LZMA or LZ4 compression algorithm for the logo cbfs
file based on BMP_LOGO_COMPRESS_LZMA or BMP_LOGO_COMPRESS_LZ4 Kconfig.
Logo cbfs file is compressed based on CBFS_COMPRESS_FLAG, by default.
Based on logo file content and target platform, enabling LZ4 could
save significant boot time, with increase in file size.
For brox:
cb_logo LZ4 is +1265 bytes than LZMA, saves ~0.760ms in decomp.
cb_plus_logo LZ4 is +2011 bytes than LZMA, saves ~0.880ms in decomp.
BUG=b:337330958
TEST=Able to boot brox and verified firmware splash screen display
with LZMA and LZ4 compression.
Change-Id: I57fbd0d3a39eaba3fb9d61e7a3fb5eeb44e3a839
Signed-off-by: Ashish Kumar Mishra <ashish.k.mishra@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83420
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add support for the configuration of 320MHz Bandwidth per MCC based on
countries. The implementation follows document #559910 Intel
Connectivity Platforms BIOS Guidelines revision 8.3.
BUG=b:333804562
BRANCH=firmware-rex-15709.B
TEST=WBEM method is added to the CNVW device and return the data
supplied by the SAR binary blob
Change-Id: Ie76794825f1a0104d199c078aa4ffc714aa95b17
Signed-off-by: Poornima Tom <poornima.tom@intel.com>
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81790
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Eric Lai <ericllai@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The 'Bluetooth Increased Power Mode - SAR Limitation' feature provides
ability to utilize increased device Transmit power capability for
Bluetooth applications in coordination with Wi-Fi adhering to product
SAR limit when Bluetooth and Wi-Fi run together.
This commit introduces a `bluetooth_companion' field to the generic
Wi-Fi drivers chip data. This field can be set in the board design
device tree to supply the bluetooth device for which the BRDS function
must be created.
This feature is required for Meteor Lake rex karis variant.
The implementation follows document 559910 Intel Connectivity
Platforms BIOS Guideline revision 8.3 specification.
BUG=b:348345301
BRANCH=firmware-rex-15709.B
TEST=BRDS method is added to the CNVW device and return the data
supplied by the SAR binary blob
Change-Id: Iebe95815c944d045f4cf686abcd1874a8a45e209
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83200
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
<stdio.h> header is used for input/output operations (such as printf,
scanf, fopen, etc.). Although some input/output functions can manipulate
strings, they do not need to directly include <string.h> because they
are declared independently.
Change-Id: Ibe2a4ff6f68843a6d99cfdfe182cf2dd922802aa
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82665
Reviewed-by: Yidi Lin <yidilin@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
RAMOOPS memory region was being overwritten by coreboot bmp_load_logo()
function. The CBMEM_ID_FSP_LOGO region created during bmp_load_logo()
was overlapping with RAMOOPS space created earlier. This resulted in
memory corruption of RAMOOPS buffer.
To prevent this, the RAMOOPS region allocation is moved to
BS_DEV_INIT_CHIPS phase from earlier BS_WRITE_TABLES phase of boot.
BUG=b:332910298
TEST=build and boot coreboot image on google/rex HW. Check RAMOOPS
CBMEM region creation using cbmem -l command
Signed-off-by: Anil Kumar <anil.kumar.k@intel.com>
Change-Id: Ibae06362cd80eacb16f6cf0eed8c9aa1fbfb2535
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82042
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Eran Mitrani <mitrani@google.com>
Reviewed-by: Jamie Ryu <jamie.m.ryu@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
This prepares the code for enabling both CONFIG_TPM1 and CONFIG_TPM2
during compilation, in which case actual TPM family in use can be
determined at runtime.
In some places both compile-time and runtime checks are necessary.
Yet in places like probe functions runtime state checks don't make sense
as runtime state is defined by results of probing.
Change-Id: Id9cc25aad8d1d7bfad12b7a92059b1b3641bbfa9
Ticket: https://ticket.coreboot.org/issues/433
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69161
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
No functional changes. Refactor code such that there won't be any
compiler or linker errors if TSS 1.2 and TSS 2.0 were both compiled
in.
One might want to support both TPM families for example if TPM is
pluggable, while currently one has to reflash firmware along with
switching TPM device.
Change-Id: Ia0ea5a917c46ada9fc3274f17240e12bca98db6a
Ticket: https://ticket.coreboot.org/issues/433
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69160
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
* Introduces logic to display context-specific boot splash logos.
* Logo selection considers:
* Chromebook-Plus hardware compliance (using factory_config).
* VPD-based product segmentation (soft-branded vs. regular
chromebook).
* Default Chromebook logo as fallback for regular Chromebook.
This patch fixes the problem where existing logic was unable to pick
correct ChromeOS boot splash logo based on the product segmentation.
Relation between product segment and boot splash screen:
1. Chromebook-Plus Hard-branded device: Renders "cb_plus_logo.bmp" logo
2. Chromebook-Plus Soft-branded device: Renders "cb_plus_logo.bmp" logo
3. Regular Chromebook device: Renders "cb_logo.bmp"
BUG=b:324107408
TEST=Verified logo selection based on compliance and product
requirements.
Change-Id: I9bb1e868764738333977bd8c990bea4253c9d37b
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80738
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Dinesh Gehlot <digehlot@google.com>
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
The .inc suffix is confusing to various tools as it's not specific to
Makefiles. This means that editors don't recognize the files, and don't
open them with highlighting and any other specific editor functionality.
This issue is also seen in the release notes generation script where
Makefiles get renamed before running cloc.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I80559b7c86a8fd2583cb0335279f676e0aa0209e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80067
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-by: Erik van den Bogaert <ebogaert@eltan.com>
This commit adds support for showing different logos on the ChromeOS
firmware splash screen based on the device model (between
Chromebook-Plus and regular ChromeOS devices like Chromebook and
Chromebox). This allows OEMs to customize the branding on their
devices.
This patch also introduces three new Kconfigs:
- CHROMEOS_FW_SPLASH_SCREEN
- CHROMEOS_LOGO_PATH
- CHROMEBOOK_PLUS_LOGO_PATH
which allow users to enable the fw splash screen feature in the
vendorcode. Previously, we were using the BMP_LOGO Kconfig in
drivers/intel/fsp2_0, but we didn't want the top level Kconfigs to be
located inside the architecture specific files.
BUG=b:317880956
BRANCH=None
TEST=emerge-rex coreboot chromeos-bootimage
verify that FW splash screen appears
Change-Id: I56613d1e7e81e25b31ad034edae0f716c94c4960
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79775
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
This patch ensures `chromeos_get_factory_config()` returns an
unsigned integer value because factory config represents
bit-fields to determine the Chromebook Plus branding.
Additionally, introduced safety measures to catch future
"factory_config" bit-field exhaustion.
BUG=b:317880956
TEST=Able to verify that google/screebo is branded as
Chromebook Plus.
Change-Id: I3021b8646de4750b4c8e2a2981f42500894fa2d0
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79769
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
This patch implements an API which relies on the
chromeos_get_factory_config() function to retrieve the factory
config value.
This information is useful to determine whether a ChromeOS device
is branded as a Chromebook Plus based on specific bit flags:
- Bit 4 (0x10): Indicates whether the device chassis has the
"chromebook-plus" branding.
- Bits 3-0 (0x1): Must be 0x1 to signify compliance with
Chromebook Plus hardware specifications.
BUG=b:317880956
TEST=Able to verify that google/screebo is branded as
Chromebook Plus.
Change-Id: Iebaed1c60e34af4cc36316f1f87a89df778b0857
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79763
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
This code leverages the TPM vendor-specific function
tlcl_cr50_get_factory_config() to fetch the device's factory
configuration.
BUG=b:317880956
TEST=Able to retrieve the factory config from google/screebo.
Change-Id: I34f47c9a94972534cda656ef624ef12ed5ddeb06
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79737
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Convert TPM functions to return TPM error codes(referred to as
tpm_result_t) values to match the TCG standard.
BUG=b:296439237
TEST=build and boot to Skyrim
BRANCH=None
Change-Id: Ifdf9ff6c2a1f9b938dbb04d245799391115eb6b1
Signed-off-by: Jon Murphy <jpmurphy@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77666
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Adopt TCG standard naming and definitions for TPM Return codes.
BUG=b:296439237
TEST=Build and boot to OS on skyrim
BRANCH=None
Change-Id: I60755723262ec205a4c134948b0250aac4974d35
Signed-off-by: Jon Murphy <jpmurphy@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77665
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Make naming convention consistent across all functions return values.
BUG=b:296439237
TEST=Boot to OS on Skyrim
BRANCH=None
Change-Id: If86805b39048800276ab90b7687644ec2a0d4bee
Signed-off-by: Jon Murphy <jpmurphy@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77536
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
When CSE jumps between RO and RW, it triggers global reset so the
AP goes down to S5 and back to S0. For Chromebox, when AP goes
down to S5 EC set AP_IDLE flag. This cause an issue to warm reset
the Chromebox device when it is in recovery mode and powered by
USB-C adapter. This patch allows AP to direct EC to clear AP_IDLE
flag before trigger reset.
BUG=b:296173534
BRANCH=firmware-dedede-136-6.B
TEST=Chromebox DUT which is powered by USB-C adapter boots up
after warm reset in recovery mode
Change-Id: Ib0002c1b8313c6f25d2b8767c60639aed8a4f904
Signed-off-by: Derek Huang <derekhuang@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77632
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Reka Norman <rekanorman@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Daisuke Nojiri <dnojiri@google.com>
Previously the clear_ec_ap_idle() is implemented in
cr50_enable_update.c and be called in the file. Move it to
common code so that it can be called in cse_board_reset.c
TEST=emerge-brask coreboot
Change-Id: I2dbe41b01e70f7259f75d967e6df694a3e0fac23
Signed-off-by: Derek Huang <derekhuang@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77631
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Reka Norman <rekanorman@chromium.org>
Use C99 flexible arrays instead of older style of one-element or
zero-length arrays.
It allows the compiler to generate errors when the flexible array does
not occur at the end in the structure.
Change-Id: I81ae8acb0365af102e513b3d7cfa1a824636eb06
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76812
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The prefix POSTCODE makes it clear that the macro is a post code.
Hence, replace related macros starting with POST to POSTCODE and
also replace every instance the macros are invoked with the new
name.
The files was changed by running the following bash script from the
top level directory.
sed -i'' '30,${s/#define POST/#define POSTCODE/g;}' \
src/commonlib/include/commonlib/console/post_codes.h;
myArray=`grep -e "^#define POSTCODE_" \
src/commonlib/include/commonlib/console/post_codes.h | \
grep -v "POST_CODES_H" | tr '\t' ' ' | cut -d ' ' -f 2`;
for str in ${myArray[@]}; do
splitstr=`echo $str | cut -d '_' -f2-`
grep -r POST_$splitstr src | \
cut -d ':' -f 1 | xargs sed -i'' -e "s/POST_$splitstr/$str/g";
grep -r "POST_$splitstr" util/cbfstool | \
cut -d ':' -f 1 | xargs sed -i'' -e "s/POST_$splitstr/$str/g";
done
Change-Id: I25db79fa15f032c08678f66d86c10c928b7de9b8
Signed-off-by: lilacious <yuchenhe126@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76043
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
DSM (Dynamic Speaker Management) uses calibration parameters stored in
a VPD (Vital Product Data) FMAP region to configure the audio output
via an ACPI _DSD table. This has no dependency on a ChromeOS, and can
be used by Linux/Windows drivers if appropriately configured.
Remove the dependency of DSM_CALIB (and the calibration file) on
CHROMEOS and replace it with VPD, so that non-CHROMEOS builds
can utilize this feature as well. Move files from underneath
vc/google/chromeos to underscore the point.
TEST=build/boot google/nightfury, dump ACPI, verify DSM calibraton
parameters present in _DSD table.
Change-Id: I643b3581bcc662befc9e30736dae806f94b055af
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74812
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: CoolStar <coolstarorganization@gmail.com>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
When a mainboard selects ACPI_SOC_NVS and CHROMEOS, CHROMEOS_NVS will be
selected. This causes vc/google/chromeec/acpi/chromeos.asl to be
included in the DSDT and chromeos_acpi_gpio_generate to be called when
generating the coreboot SSDT. When a mainboard also uses
DECLARE_NO_CROS_GPIOS(), this will cause variant_cros_gpio.count to be 0
and variant_cros_gpio.gpios to be NULL. chromeos_acpi_gpio_generate only
checked if the GPIO table was non-NULL, which caused the function to
exit early and not generate the OIPG package which causes the kernel to
complain about referencing the non-existing OIPG package. To avoid this,
only exit in the GPIO table pointer being NULL case if the number of
GPIOs is non-0.
TEST=Error about missing OIPG ACPI object in dmesg disappears on birman.
Before:
[ 0.241339] chromeos_acpi: registering CHSW 0
[ 0.241468] ACPI BIOS Error (bug): Could not resolve symbol [\CRHW.GPIO.OIPG], AE_NOT_FOUND (20220331/psargs-330)
[ 0.241703] ACPI Error: Aborting method \CRHW.GPIO due to previous error (AE_NOT_FOUND) (20220331/psparse-531)
[ 0.241933] chromeos_acpi: failed to retrieve GPIO (5)
[ 0.242011] chromeos_acpi: registering VBNV 0
[ 0.242113] chromeos_acpi: registering VBNV 1
[ 0.242284] chromeos_acpi: truncating buffer from 3072 to 1336
[ 0.242462] chromeos_acpi: installed
With the patch applied:
[ 0.242580] chromeos_acpi: registering CHSW 0
[ 0.242714] chromeos_acpi: registering VBNV 0
[ 0.242817] chromeos_acpi: registering VBNV 1
[ 0.242990] chromeos_acpi: truncating buffer from 3072 to 1336
[ 0.243249] chromeos_acpi: installed
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: Fred Reitberger <reitbergerfred@gmail.com>
Change-Id: Ie340003afb718b1454c2da4a479882b71714c3c7
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74375
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When AP boots up after Cr50 firmware update and reboot, AP finds
that Cr50 reset is required for Cr50 to pick the new firmware so
it trigger Cr50 reset and power off the system, AP expects system
will power on automatically after Cr50 reset. However this is not
the case for Chromebox, Chromebox EC set AP_IDLE flag when system
is shutting down, when AP_IDLE flag is set in EC, the system stays
at S5/G3 and wait for power button presssend. It cause an issue in
factory that the operator needs to press power button to power on
the DUT after Cr50 firmware update.
This patch sends EC command to direct EC to clear AP_IDLE flag
after AP shutdown so AP can boot up when Cr50 reset.
BUG=b:261119366
BRANCH=firmware-brya-14505.B
TEST=DUT boots up after Cr50 firmware update in factory test flow
Change-Id: If97ffbe65f4783f17f4747a87b0bf89a2b021a3b
Signed-off-by: Derek Huang <derekhuang@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70773
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The CR50 code clears the post code value. Add this as a #define.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: If3b73a3159ac8ac9ab08c6ff705b0ca289ab453c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71592
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jon Murphy <jpmurphy@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Use fw_config field to return sar filename instead of fw_config probe.
Return filename unconditionly because the sar_id must be valid in
CBI. If invalid sar_id, the file won't exist in CBFS by design.
Signed-off-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Change-Id: I7b75c5d4fd3c459ad7232bb16c6218a6218f1f77
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70896
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Ivy Jian <ivy.jian@quanta.corp-partner.google.com>
This patch adds `_DEPRECATED_` tag to ChromeOS boot mode related event
logging types as below:
* ELOG_TYPE_CROS_RECOVERY_MODE <---- to record recovery boot reason
while booting into recovery mode
* ELOG_TYPE_CROS_DEVELOPER_MODE <--- if the platform is booted into
developer mode.
* ELOG_TYPE_CROS_DIAGNOSTICS <---- if the platform is booted into
diagnostic mode.
Drop static structure `cros_deprecated_recovery_reasons` as it has been
replaced by vb2_get_recovery_reason_string() function.
ELOG_TYPE_FW_BOOT_INFO event type is now used to record all those
related fw boot info along with ChromeOS boot mode/reason etc.
BUG=b:215615970
TEST=Build and boot google/kano to ChromeOS.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I932952ce32337e2d54473667ce17582a90882da8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65802
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
