The ioapic and ioapic_irq keywords are no longer valid tokens as of
commit e84b095d3a (util/sconfig: Remove unused ioapic and irq
keywords), and the associated driver had previously been removed in
commit ca5a793ec3 (drivers/generic/ioapic: Drop poor implementation).
Thus, drop them from autoport. Also, the IOAPICIRQs map that this code
relied on to generate ioapic_irq entries never seems to have been
populated by any code in any previous commit, so this appears to have
been dead code since autoport was created.
The lapic keyword was removed from sconfig in commit 15d5183e4a
(util/sconfig: Remove lapic devices from devicetree parsers) so remove
autoport handling for it as well.
Change-Id: Icf2582594b244cf5f726c722eb3a3c12573a2662
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83358
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
The ucsi_enabled flag is no longer used by the EC. Update coreboot to only use only EC_FEATURE_UCSI_PPM to determine whether UCSI is enabled.
BUG=b:319124515
TEST=emerge-brox coreboot chromeos-bootimage
Cq-Depend: chromium:5664227
Change-Id: Ia9d820c637e56a527fd90f45b1848158a960dee7
Signed-off-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83252
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Forest Mittelberg <bmbm@google.com>
Reviewed-by: Caveh Jalali <caveh@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The test target called make with the `-K` flag, which is not valid.
Change it to `-k` (keep going if some targets fail) which is what was
probably intended.
It also tried to build the `doctest` target from Makefile.sphinx, which
results in an error. Further investigation reveals that this is because
the sphinx doctest extension was not enabled in conf.py. However, from
the documentation of doctest [1], it seems like it is intended to ensure
that documentation containing Python snippets along with the expected
output of the snippet remain in sync, which is something that we
probably don't need. So, remove the call to it.
[1] https://www.sphinx-doc.org/en/master/usage/extensions/doctest.html"
Change-Id: Id514950b4486ed8644d078af222c96ed711fc8f9
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83381
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
This fixes the following MyST Parser warnings:
- Non-consecutive header level increase
- Document headings start at H2, not H1
The header levels (the number of "#" characters before a heading) are
intended to form a logical hierarchy of each section and subsection in a
document. A subsection typically should have a header level one more
than its parent section. Most of these warnings are caused by extra "#"
characters, which were simply removed, or sections missing a "#"
character to make it fall under its parent section.
Notable changes:
getting_started/kconfig.md: Changed the header level of the "Keywords"
section from 2 to 3 to fall under "Kconfig Language" (level 2), and
increased the level of each keyword from 3 to 4 to remain under
"Keywords". This also fixes the warnings of "H3 to H5" increases, since
the Usage/Example/Notes/Restrictions sections for each keyword had a
level of 5.
soc/intel/cse_fw_update/cse_fw_update.md: Changed the first line to a
top level header acting as the title of the document. Without this
soc/intel/index.md displays all the level 2 headers in this document
instead of a single link to cse_fw_update.md.
Change-Id: Ia1f8b52e39b7b6524bef89a95365541235b5b1b9
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83382
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>
This board has a DVI-I connector, which supports both digital and analog
display outputs. The I2C bus to retrieve the EDID is shared between both
outputs, so `select GFX_GMA_ANALOG_I2C_HDMI_B` to describe this.
Can't currently test this due to lack of hardware.
Change-Id: Ib8239917e2f7ee5bb982621752ec406c2d3ca302
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82753
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
With commit 238ff1e9c7 ("payloads/ipxe: Prefix iPXE options with "IPXE"
instead "PXE""), the prefix for iPXE related Kconfig identifiers was
unified to "IPXE". So rename the identifier for the TRUST_CMD option as
well, which was introduced later.
Change-Id: I918358b859003503526ba7849494bb23f8c893fd
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83361
Reviewed-by: Nicholas Chin <nic.c3.14@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The Chrome EC currently supports two ways to read battery strings on
ACPI platforms:
* Read up to 8 bytes from EC shared memory BMFG, BMOD, ...
* Send a EC_CMD_BATTERY_GET_STATIC host command and read strings from
the response. This is assumed to be exclusively controlled by the OS,
because host commands' use of buffers is prone to race conditions.
To support readout of longer strings via ACPI mechanisms, this change
adds support for EC_ACPI_MEM_STRINGS_FIFO (https://crrev.com/c/5581473)
and allows ACPI firmware to read strings of arbitrary length (currently
limited to 64 characters in the implementation) from the EC and to
determine whether this function is supported by the EC (falling back to
shared memory if not).
BUG=b:339171261
TEST=on yaviks, the EC console logs FIFO readout messages when used in
ACPI and correct strings are shown in the OS. If EC support is
removed, correct strings are still shown in the OS.
BRANCH=nissa
Change-Id: Ia29cacb7d86402490f9ac458f0be50e3f2192b04
Signed-off-by: Peter Marheine <pmarheine@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82775
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
bc was added as dependency in commit 229e021110 ("Makefile.inc: Add left shift macro")
bc is not stated as dependency in our docs (e.g. package installation).
If you don't have bc installed you can easily get false positives on
coreboot builds. For example you build a mainboard and coreboot tells
you the build succeeded, even though you don't have bc installed.
This patch is from julius comment on CB:21601.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: I6ab4bc2bd7a45e84b923d4fe7ec473e6c7db2146
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83313
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Autoport determines the mainboard vendor and board names based on DMI
entries, which sometimes doesn't result in the most obvious name. In
addition, newcomers may not be familiar with coreboot's directory
structure and have no idea where to look. Print out the absolute patch
of the generated sources once autoport finishes so that it is easier to
locate the files.
Change-Id: I4ba00484ac57355d7539fa6e36e0e6df62719f8a
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83344
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Intel chipsets from ICH7 through Lynxpoint use the same GPIO register
format and thus mainboards using using these platforms have similar
gpio.c files. Factor out the code to generate gpio.c from bd82x6x.go so
that it other chipsets added to autoport can use it.
This was originally written by Iru Cai in his Haswell autoport patch in
CB:30890; I have simply split out the code to a separate commit as it is
a separate logical change.
TEST=Generated output is identical before and after this patch when run
against logs from a Dell Latitude E6430
Change-Id: If1f506f6ad10144bd6acc42505592426bb7193b7
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83286
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When starting a nested instance Make communicates information on the
number of jobs and how to synchronize difference instances via MAKEFLAGS
variable. Explicitly overwriting it when invoking
payloads/external/iPXE/Makefile ends up forcing serial build of iPXE.
iPXE builds hundreds of files and its dependency generation is done
separately from compilation making the whole process take couple minutes
on a single CPU (which becomes several seconds if large enough number of
CPUs is available).
iPXE seems to have Make-based build system that has no problems with
parallel build and not utilizing that effectively turns it into a
bottleneck when building a coreboot image in parallel.
It's unclear whether MAKEFLAGS= was even added for any particular
purpose. It doesn't prevent child instances from using variables of
parents, nor it prevents child instance from running in parallel
(because it's still passed as an environment variable that's processed
prior of variable assignments on command-line), but it does prevent
grandchild instance from running in parallel (actual iPXE's Makefile).
MFLAGS contains flags from MAKEFLAGS and isn't used implicitly by Make,
so no need to clear it either because iPXE doesn't use it.
Change-Id: Iac00e2f86d160793d3217e00ddc5012202b3196a
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83081
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Krystian Hebel <krystian.hebel@3mdeb.com>
This patch creates a new domika variant which is a Twin Lake platform.
This variant uses Yavilla board mounted with the Twin Lake SOC and hence
the plan is to reuse the existing yavilla code.
BUG=b:350399367
BRANCH=firmware-nissa-15217.B
TEST=build, and boot into OS
Change-Id: I42c56770f8b8d6018592253d2bb16b8166eb5719
Signed-off-by: Wisley Chen <wisley.chen@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83291
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Dinesh Gehlot <digehlot@google.com>
Reviewed-by: Eric Lai <ericllai@google.com>
Domain device objects are created with HID/CID/UID/_OSC/_PXM
Dynamic domain SSDT generation could benefit the support of SoCs with
multiple SKUs, or the case where one set of codes supports multiple
SoCs. One possible side-effect might be the extra performance cost for
generating these tables, which should not bring big impact on high
performance server CPUs.
GNR codes run with dynamic domain SSDT generation to fit for both
GraniteRapids and SierraForest SoCs.
TEST=Build on intel/avenuecity CRB
TEST=Build on intel/beechnutcity CRB
Change-Id: I28bfdf74d8044235f79f67d832860d8b4306670c
Signed-off-by: Shuo Liu <shuo.liu@intel.com>
Signed-off-by: Jincheng Li <jincheng.li@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81374
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Already included <types.h> is supposed to provide <limits.h>. See
`Documentation/contributing/coding_style.md` section `Headers and includes`
Change-Id: I945eeeeccb16851f64d85cf5c67ea6e256082e11
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82724
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jakub Czapiga <czapiga@google.com>
This is a rudimentary port of this board. It was done with Haswell
Autoport, wherein some adjustments for Broadwell were made
(Thanks to Angel Pons!).
The VBT was copied from /sys/kernel/debug/dri/1/i915_vbt on version
2.20 of the vendor firmware.
Working:
- Broadwell MRC.bin
- S3 suspend and resume
- All DIMM slots
- Libgfxinit
- HDMI-Out Port
- DVI-I Port (including passive DVI to VGA adapter)
- USB 2.0 Ports
- USB 3.1 Gen1
- RJ-45 LAN Port
- SATA3 6.0 Gb/s Connectors
- m.2 PCIe SSD
- mPCIe WiFi slot
- x16 PCIe slot
- USB 3.1 Gen1 Header
- Front Panel Audio Connector
- edk2
Not yet tested:
- SATA Express 10 Gb/s Connector
- HDMI-In Port
- DisplayPort 1.2
- Optical SPDIF Out Port
- PS/2 Mouse/Keyboard Port
- USB 2.0 Headers
Not working:
- Broadwell CPUs, see commit f5105313cf (mb/asrock/z97_extreme6:
Add new mainboard)
Special thanks to Angel Pons for guiding me through the process of
porting this board and pushing it to Gerrit!
Change-Id: I3b940e9281814e8360900221714c0dfa3ae39540
Signed-off-by: Jan Philipp Groß <jeangrande@mailbox.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82760
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nicholas Chin <nic.c3.14@gmail.com>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
To publish the Bluetooth Regulator Domain Settings under the right
ACPI device scope, the wifi generic driver requires the bluetooth
companion to be set accordingly.
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: I7f56ab8ac88c1fbc0b223b4286d2a998e424a46e
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83299
Reviewed-by: Subrata Banik <subratabanik@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>
This port was done via autoport and subsequent manual tweaking.
Thanks to Angel Pons for helping me with the misbehaving ASM1061 ASPM!
The board features two socketed DIP-8 SPI flash chips, as well as a
BIOS selection via jumper and onboard Power and Reset switches.
Working:
- Haswell MRC.bin
- All four DDR3/DDR3L DIMM slots
- S3 suspend and resume
- Libgfxinit
- HDMI-Out Port
- both RJ-45 Gigabit LAN Ports
- USB 2.0 Ports
- USB 3.1 Gen1 Ports
- both USB 3.1 Gen1 headers
- HD Audio Jack (audio output)
- all six SATA3 6.0 Gb/s connectors by Intel
- all four SATA3 6.0 Gb/s connectors by ASMedia ASM1061
- all three PCI Express 3.0 x16 slots
- PCI Express 2.0 x1 slot
- half mini-PCI Express slot
Working (board-specific)
- Power Switch with LED (functional, yet no LED)
- Reset Switch with LED (functional, yet no LED)
- BIOS Selection via jumper
not (yet) tested:
- IR header
- COM Port header
- DisplayPort
- eSATA connector
- USB 2.0 headers
- PS/2 Mouse/Keyboard Port
- HDMI-In Port
- PCI slots
not (yet) working:
- Front panel audio connector
- Software fan control: While the Nuvoton chip is correctly discovered,
the numbering of the fan connectors is faulty, resulting in the wrong
fan being controlled.
- Dr. Debug: on vendor firmware, the LEDs turn off after successful
boot. On coreboot, the LED shows two bright zeros after boot.
Change-Id: Iae0b73d8e81be90ec3a2d5463df3ed170f603266
Signed-off-by: Jan Philipp Groß <jeangrande@mailbox.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82913
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nicholas Chin <nic.c3.14@gmail.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Use FW_CONFIG to differentiate MAX98390 and TAS2563. Since config
GERALT_USE_MAX98390 is no longer needed after using FW_CONFIG,
we remove GERALT_USE_MAX98390 from Kconfig.
BUG=b:345629159
BRANCH=none
TEST=emerge-GERALT coreboot
TEST=Verify beep function through deploy in depthcharge successfully.
Change-Id: Ie9f0cbc30dd950b85581fc1924fa351efe1e0aab
Signed-off-by: Rui Zhou <zhourui@huaqin.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83287
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Yidi Lin <yidilin@google.com>
