This reverts commit bd9cec8ae5.
Reason for revert: Enable i2c7 for amp changing to 2 channel
because vell setting amp on i2c0 and i2c7 on next phase
BUG=b:229334701
TEST=emerge-brya coreboot chromeos-bootimage && $powerd_dbus_suspend
&& checks EC log and ensures the DUT could enter s0ix.
Signed-off-by: Shon Wang <shon.wang@quanta.corp-partner.google.com>
Change-Id: I5988cd9926b2c9ced1d111774abaa897bef91537
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64627
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
The description.md file for the intelp2m utility wasn't the description
that was needed - just a subject, and what language it was written in.
It was instead a set of more full documentation, so move it into the
Documentation directory and create a new description file.
Change-Id: Ia180ae41f91f8b8eb408351a9e44e899edc031d3
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64578
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
This fixes the following warnings:
mainboard/starlabs/common/flashing.md::
WARNING: image file not readable:
- mainboard/starlabs/common/fwupdVersion.png
- mainboard/starlabs/common/BiosLock.jpg
- mainboard/starlabs/common/SwitchBranch.png
cbfstool/index.md::
WARNING: document isn't included in any toctree
internals/devicetree_keywords.md::
WARNING: document isn't included in any toctree
mainboard/asus/wifigo_v1.md::
WARNING: document isn't included in any toctree
mainboard/google/index.md::
WARNING: document isn't included in any toctree
mainboard/starlabs/common/flashing.md::
WARNING: document isn't included in any toctree
releases/boards_supported_on_branches.md::
WARNING: document isn't included in any toctree
WARNING: None:any reference target not found:
- releases/coreboot-4.16-relnotes
- releases/coreboot-4.15-relnotes
- releases/coreboot-4.14-relnotes
- releases/coreboot-4.13-relnotes
- releases/coreboot-4.12-relnotes
- releases/coreboot-4.11-relnotes
- releases/coreboot-4.10-relnotes
- releases/coreboot-4.9-relnotes
- releases/coreboot-4.8.1-relnotes
- releases/coreboot-4.7-relnotes
- releases/coreboot-4.6-relnotes
- releases/coreboot-4.5-relnotes
- releases/coreboot-4.4-relnotes
- releases/coreboot-4.3-relnotes
- releases/coreboot-4.2-relnotes
- releases/coreboot-4.1-relnotes
- ../../src/soc/intel/common/block/cse/cse.c
Change-Id: I22273bc1bc34b6297cef4e594c454c2316d4215a
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64576
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
The dGPU used for some Brya projects requests 32 bits of address space
for one of its BARs via the Resizable BAR mechanism. This Kconfig is
currently set at 29 bits for brya, so the allocation currently is
capped at 29 bits. This patch sets the limit to 32 bits for brya
boards, which is enough for the GPU.
BUG=b:214443809
TEST=all of the dGPU PCI BARs on agah can be successfully allocated
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: I61dbe47f1f316967d052bae748ff23babde61ef0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64726
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@tutanota.com>
When a PCI resource is marked as 64-bits, the IORESOURCE_ABOVE_4G flag
needs to be passed to the v4 allocator to ensure that the resource will
be allocated in a range large enough to succeed.
BUG=b:214443809
TEST=agah can successfully allocate all of the Nvidia GN20 BARs
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: I3f16f52f2a64f8728853df263da29871dca533f7
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64725
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@tutanota.com>
While testing the power sequencing code for the GPU, a few mistakes were
found. This patch fixes those errors:
1) FBVDD load-switch enable is active-low
2) NVVDD VR enable is active-high
3) GPU_PERST_L should be driven low during GPIO table programming
4) The BAR saving code missed the top 32 bits of 64-bit BARs
5) sequence_rail() assumed the pwr_en_gpio and pg_gpio were the same
polarity
6) PEG vGPIOs were not programmed to the correct NF
BUG=b:233552225
TEST=dGPU is able to successfully enumerate over PCIe bus
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: I85767d382012a0c7dfdb1f849768e0160f06c273
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64727
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
After commit ae48b42683 (payloads/tianocore: Init submodules),
Tianocore's Makefile no longer detects an unclean working directory and
thus always performs a `git checkout`, overwriting any uncommited
changes made in the cloned sources.
The change of "clean" to "dirty" effectively inverts the logic of the
if-else condition, which would normally swap the two possible code paths
of the branch. However, since `git status` outputs multiple lines, most
of which do not contain "clean", the -v option (select non-matching
lines) causes grep to always match at least 1 line and thus return
success. This causes the if-else branch containing the `git checkout`
to always be taken regardless of the state of the working tree, masking
the issue of the inverted logic. Removing the -v option addresses both
of these issues and restores the intended behavior of the if-else block.
TEST:
1) Build coreboot successfully with the Tianocore UefiPayloadPkg option.
2) Make a change in the cloned Tianocore sources that results in an
unclean working directory and check for the "Working directory not
clean" message when building coreboot.
Change-Id: Icd4952b40c147d0fba676089ced5a8b59b93ad50
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64608
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@tutanota.com>
We need to put USB setting in mux order.
BUG=b:234103724
TEST=Type C mux configuration is correct.
Wrong:
added type-c port0 info to cbmem: usb2:2 usb3:2 sbu:0 data:0
added type-c port1 info to cbmem: usb2:3 usb3:3 sbu:0 data:0
Correct:
added type-c port0 info to cbmem: usb2:3 usb3:3 sbu:0 data:0
added type-c port1 info to cbmem: usb2:2 usb3:2 sbu:0 data:0
Signed-off-by: John Su <john_su@compal.corp-partner.google.com>
Change-Id: I4f8dbee35159960d17107e23fcde825a38c7de4e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64721
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
This adds 2 flags:
* invisible opt-in flag for platforms on which clang seems to work
* visible opt-in flag to allow experimenting
Clang seems to work rather well on x86_32 so it makes sense to start
adding that to Jenkins buildtesting, which this allows.
This allows abuild to differentiate between targets that are known to
build with clang. This makes buildtesting just those targets easier.
Change-Id: I46f1bad59bda94f60f4a141237ede11f6eb93cc2
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63081
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@tutanota.com>
Systems have a lot more cores now and 4KiB is not cutting it. E.g.
for a system with 255 cores more than 16KiB is needed.
We could also make this a Kconfig parameter but it's probably not
worth having such micro optimizations to save a few KiB.
Change-Id: Idd47e55d8d679cc70eae996ee1af3ad7eaa1d0cc
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63484
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
This code was hard to read as it did too much and had a lot of state
to keep track of.
It also looks like the staggered entry points were first copied and
only later the parameters of the first stub were filled in. This
means that only the BSP stub is actually jumping to the permanent
smihandler. On the APs the stub would jump to wherever c_handler
happens to point to, which is likely 0. This effectively means that on
APs it's likely easy to have arbitrary code execution in SMM which is a
security problem.
Change-Id: I42ef9d6a30f3039f25e2cde975086a1365ca4182
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63478
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@tutanota.com>
We don't want to keep track of the real smm size all the time.
As a bonus now ss_start is now really the start of the save state
instead of top - MAX(stub_size, save state size).
Change-Id: I0981022e6c0df110d4a342ff06b1a3332911e2b7
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63477
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@tutanota.com>
This code is much easier to read if one does not have to keep track of
mutable variables.
This also fixes the alignment code on the TSEG smihandler setup code.
It was aligning the code upwards instead of downwards which would cause
it to encroach a part of the save state.
Change-Id: I310a232ced2ab15064bff99a39a26f745239f6b9
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63475
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Martin L Roth <gaumless@tutanota.com>
