We are going to expose ths tool to end users, and want to take
care that the presented information can be consumed by them.
The current code simply prints below warnings if we use release
binary available for end-user to download:
No firmware volume header present
No valid firmware volume was found
It will be concerning and not clear to end users, they might not
understant why it happens, what are the implications, and whether
it is something that they should worry about.
This commit tries to explain what actually happens here.
Change-Id: Iaa2678f5ae7c243811484c0567ced97ae0b3fc0a
Signed-off-by: Maciej Pijanowski <maciej.pijanowski@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82692
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
If the EC doesn't know a value, it will report it as 0xffff. In these
cases, calculate a value to used based on others. For example, if the
EC doesn't know the last full charge capacity, report the design
capacity to the OS.
Change-Id: I310555ff913c2e492bbaec4d77281ac32c0de7a3
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81408
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add wifi sar table support for xol. Bit 31 in CBI/FW_CONFIG
is used to select different sar table (index 0 or 1) but only
0 is in used at the moment.
BUG=b:344274789
BRANCH=firmware-brya-14505.B
TEST=emerge-brya coreboot chromeos-bootimage
Change-Id: Id4dc74c4f2a807d2e531b419ecb7b590d4c32ac2
Signed-off-by: YH Lin <yueherngl@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82945
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Current existing temperature thresholds of TSR1 sensor are set at 60C
to start fan. Due to this CPU gets hot and temperature goes over 80C.
In this situation, fan does not even start to lower down CPU temperature.
With updated new settings based on tuning from thermal team, start fan
early at 40C for TSR0 and TSR1 so the CPU temperature stays below 80C.
BUG=b:339493551
TEST=Built and tested on google/brox board
Signed-off-by: Sumeet Pawnikar <sumeet.r.pawnikar@intel.com>
Change-Id: I4765c13c10e436733d8c9d017085968daa561ccc
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82784
Reviewed-by: Eric Lai <ericllai@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
This change restores the EN_PP3300_SSD GPIO configuration in the
ramstage for the Rex0 variant. This is necessary to enable testing
of RO lockdown scenarios on FSI'ed Screbo devices, where bootblock
changes are not applicable.
Additionally, ensures locking the GPIO PAD from getting misconfigured
after booting to OS.
BUG=b/337971452
BRANCH=firmware-rex-15709.B
TEST=Able to boot google/rex with RO locked to an older version without
SSD GPIO refactored, and RW is with the latest revision.
Change-Id: Ia7564b14a20d00e9bb2c9466b7a737dd97f01351
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82909
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
It is now possible to hook up device ops directly to devices in
devicetree which removes the need for a fake chip.
This also fixes Hermes booting as the PCI ops were incorrectly hooked up
to a dummy device. The intel uart driver was requesting a resource from
the generic device and died since it does not exist:
[EMERG] GENERIC: 0.0 missing resource: 10
This was broken in commit b9165199c3 (mb/prodrive/hermes: Rework UART
devicetree entry).
Change-Id: I3b32d1cc52afaed2a321eea5815f2957fe730f79
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82940
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Currently, the 3rdparty/fsp submodule contains only the IoT FSP for
ADL-N. However, coreboot's Kconfig is incorrectly applying the IoT
FSP for both Client and IoT configurations, despite the Client FSP
requiring distinct headers.
The CWWK CW-ADL-4L-V1.0 board relies on the FSP provided by the
3rdparty/fsp submodule, which means it has been using the IoT FSP by
default. To ensure the board continues to use the correct FSP as we
plan to introduce Client FSP headers into vendorcode, we are now
explicitly select FSP_TYPE_IOT for the CWWK CW-ADL-4L-V1.0 board.
Change-Id: Ie3844cb24740e4d95ee835a44e55b4d5cb6854e5
Signed-off-by: Ronak Kanabar <ronak.kanabar@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82915
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Brandon Weeks <bweeks@google.com>
Currently, the 3rdparty/fsp submodule contains only the IoT FSP for
ADL-N. However, coreboot's Kconfig is incorrectly applying the IoT
FSP for both Client and IoT configurations, despite the Client FSP
requiring distinct headers.
The aoostar/wtr_r1 board relies on the FSP provided by the 3rdparty/fsp
submodule, which means it has been using the IoT FSP by default. To
ensure the board continues to use the correct FSP as we plan to
introduce Client FSP headers into vendorcode, we are now explicitly
select FSP_TYPE_IOT for the aoostar/wtr_r1 board.
Change-Id: I68feeaaffd825013ae1012694047b067535e7341
Signed-off-by: Ronak Kanabar <ronak.kanabar@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82914
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The QEMU Bochs display driver and the QEMU Firmware Configuration
interface code (in the qemu-i440fx mainboard dir) were written for x86.
These devices are available in QEMU VMs of other architectures as well,
so we want to port them to be independent from x86.
The main problem is that the drivers use x86 port I/O functions to
communicate with devices over PCI I/O space. These are currently not
available for ARM* and RISC-V, although it is often still possible to
access PCI I/O ports over MMIO through a translator.
Add implementations of port I/O functions that work with PCI I/O space
on these architectures as well, assuming there is such a translator at a
known address configured at build-time.
Change-Id: If7d9177283e8c692088ba8e30d6dfe52623c8cb9
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80372
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
This was done using Haswell autoport, with manual fixes to get the
output to build against current main. I do not physically have this
board; I was sent the output of autoport with some fixes on top of
which I added additional changes. The VBT was copied from
/sys/kernel/debug/dri/0/i915_vbt on version 2.70 of the vendor firmware.
The flash chip is 8MiB in a socketed DIP8 package, making it easy to
externally flash to recover from a brick.
Working:
- Haswell MRC.bin
- S3 suspend and resume
- Libgfxinit
- HDMI
- DVI-I (including passive DVI to VGA adapter)
- DisplayPort
- SATA ports
- mSATA SSD
- mPCIe WiFi slot
- Rear USB ports
- USB 3.0 header
- Audio header
- Ethernet
- x16 PCIe slot
- EHCI debug with the CH347 (top USB 2.0 port by the PS/2 connector)
- edk2 (MrChromebox uefipayload_202309)
Not Tested:
- PS/2 keyboard/mouse
- eSATA
- USB 2.0 header
Change-Id: I56c22d8f5505f9a4da25f8b4406b00978af1a586
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81022
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch flips the polarity of CONFIG_USE_1G_PAGES_TLB into
CONFIG_NEED_SMALL_2MB_PAGE_TABLES which is off by default, meaning
CPUs added in the future will automatically build the smaller 1GB pages.
We can expect support for this feature to be available on all future CPU
generations (with the possible exception of embedded edge cases), so
this default setting should make mistakes less likely and keep
maintenance effort lower. (Besides, enabling the support where it
doesn't work fails fast, whereas keeping it disabled where it could work
is an inefficiency that can easily go overlooked for a long time.)
While this is technically a CPU feature, not a northbridge feature, we
support a lot more individual CPUs than northbridges in the pre-SoC era,
and they tend to be closely coupled anyway. So select the option at the
northbridge level for older CPUs to keep things simpler.
Change-Id: I2cf1237a7fb63b8904c2a3d57fead162c66bacde
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82792
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
ARM SoC supports FEAT_CCIDX after ARMv8.3. The register field
description of CCSIDR_EL1 is different when FEAT_CCIDX is implemented.
If numsets and associativity from CCSIDR_EL1 are not correct, the system
would hang during mmu_disable().
Rather than assuming that FEAT_CCIDX is not implemented, this patch
adds a check to dcache_apply_all to use the right register format.
Reference:
- https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/12770
BUG=b:317015456
TEST=mmu_disable works on the FEAT_CCIDX supported SoC.
Change-Id: I892009890f6ae889e87c877ffffd76a33d1dc789
Signed-off-by: Yidi Lin <yidilin@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82636
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
ARM SoC supports FEAT_CCIDX after ARMv8.3. The register field
description of CCSIDR_EL1 is different when FEAT_CCIDX is implemented.
If numsets and associativity from CCSIDR_EL1 are not correct, the system
would hang during mmu_disable().
Rather than assuming that FEAT_CCIDX is not implemented, this patch
adds a check to dcache_apply_all to use the right register format.
Reference:
- https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/12770
BUG=b:317015456
TEST=mmu_disable works on the FEAT_CCIDX supported SoC.
TEST=manually add mmu_disable to emulation/qemu-aarch64/bootblock.c and
verify with the command
qemu-system-aarch64 -bios \
./coreboot-builds/EMULATION_QEMU_AARCH64/coreboot.rom -M \
virt,secure=on,virtualization=on -cpu max -cpu cortex-a710 \
-nographic -m 8192M
Change-Id: Ieadd0d9dfb8911039b3d36c9419af4ae04ed814c
Signed-off-by: Yidi Lin <yidilin@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82635
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
There's two copies of the `get_cxl_mode()` function to map the OCP VPD
value to the values expected by platform code. As this is unnecessary,
have a single copy of this function in the OCP VPD driver code. As the
`get_cxl_mode()` function is Xeon-SP only, keep it in a separate file.
This change simplifies things for boards using OCP VPD for CXL and has
no impact for boards *not* using OCP VPD:
- Boards not using OCP VPD can still define get_cxl_mode() in mainboard
code as needed, just like they were able to do before.
- Boards using OCP VPD but without CXL (`SOC_INTEL_HAS_CXL` is not
enabled), this code won't get compiled in at all (see `Makefile.mk`).
- Boards using OCP VPD and CXL will automatically make use of this
`get_cxl_mode()` definition, which should be the same for all boards.
It is possible that this may need to be expanded/adapted in the future,
which is easy to handle in a follow-up commit when the need arises.
TEST=Build and boot on intel/archercity CRB
Change-Id: I935c4eb5b2392e2d0dc01b9f66d46c79b8141ea7
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82224
Reviewed-by: Shuo Liu <shuo.liu@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
