Match PCIe root port allocation and associated comments to
boardview, as follows:
Z77 PCIe ports 1-4: PCIEX16_3 (x4)
Z77 PCIe port 5: PCIEX1_1
Z77 PCIe port 6: RTL8111F LAN
Z77 PCIe port 7: ASM1042 USB3
Z77 PCIe port 8: ASM1061 eSATA
CPU PCIe lanes 1-8: PCIEX16_1
CPU PCIe lanes 9-16: Multiplexed via 4x ASM1480 to PCIEX16_1 lanes 9-16
and PCIEX16_2 lanes 1-8
(CPU PCIe lanes are not covered by overridetree.cb.)
These are not hardware tested.
Change-Id: I472e28add254ea945b401d1ddfd03f29f46d8fd2
Signed-off-by: Keith Hui <buurin@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83607
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
The PSP can send SMIs to the x86 side to have the SMI handler service
requests from the PSP. This commit adds an empty PSP SMI handler; the
actual implementation is added in later patches to keep the patches
relatively small.
This patch is a slightly modified version of parts of CB:65523.
Test=When selecting SOC_AMD_COMMON_BLOCK_PSP_SMI, Mandolin still builds
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Signed-off-by: Ritul Guru <ritul.bits@gmail.com>
Change-Id: I65989ff529d728cd9d2cd60b384295417bef77ad
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83739
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
For Sandy/Ivy Bridge boards, this results in northbridge devices ending
up north of (above) southbridge devices. Which is the convention pretty
much all boards in the tree uses.
Change-Id: I9dc2ff13182ff9d92141b1736796749cea49d23a
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82406
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Running autoport as root has the annoying side effect of making all
generated files owned by root. Prevent this by using sudo to invoke
log-making programs (lspci, dmidecode, acpidump, inteltool, ectool,
superiotool). These programs either need to be run as root or allow
collecting more information if run as root (lspci).
In case there's a valid reason not to use sudo, provide a prompt to
let autoport run the programs directly, as it originally did. There
might be someone trying to run autoport from an OS that lacks sudo.
Change-Id: I4bf4ddf8dd2cb930e9b7303e2ea986d8c072aa7a
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82404
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
The original approach to call external programs was rather convoluted
and would fall back to running executables inside the current working
directory if running them from the location specified in the code did
not succeed, swallowing any errors from the first invocation.
Rewrite the system around the `LogMakingProgram` concept, a struct to
represent a program. Each program has a name, prefixes to try running
it from and the arguments to pass to it (if any). Plus, collect error
information from failed executions, but only show it when none of the
prefixes resulted in a successful invocation.
In addition, look for programs in PATH instead of CWD: it is unlikely
that all utils will be in the CWD, but utils can be in the PATH after
one installs them (`sudo make install`). For coreboot utils, look for
them in the utils folder first as the installed versions might not be
up-to-date.
Furthermore, print out the command about to be executed, as there are
some commands (e.g. `ectool` on boards without an EC) that can take a
very long time to complete.
Change-Id: I144bdf609e0aebd8f6ddebc0eb1216bedebfa313
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82403
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Currently resource allocation starts top down from the default value
0xfe000000. This does not match what ACPI reports, so adapt
CONFIG_DOMAIN_RESOURCE_32BIT_LIMIT to reflect that.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: I2ba0e96a7ab18d65b7fbbb38b1a979ea2ec6d1be
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80207
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Fix potential undefined behaviour in the `get_pkg_power()` function:
- If `rapl_power_unit == 0`, `pkg_power_info / rapl_power_unit` is
invalid
- If `rapl_power_unit > 7`, the result of the shift doesn't fit into a
`uint8_t`
Signed-off-by: Mate Kukri <km@mkukri.xyz>
Change-Id: I48ef59c4fbeb0a55675ac24da31e6e0b194cb58d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83736
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
UART0 is already configured in coreboot, so this change sets SerialIo
config for UART0 to PchSerialIoSkipInit to skip initialization in FSP.
BUG=none
TEST=Able to build and boot google/rex0. Able to see all debug prints
over CPU uart.
Change-Id: I37744f05083eb82ba8ca579b628b69aa976e3d1f
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83750
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Dinesh Gehlot <digehlot@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Currently we use "%p" to print the address, which results in different
string lengths, depending on the value of the address. To improve
readability of the printed addresses in the log, change the format to
"0x%013lx", so that the length of the printed addresses will be
consistent.
In addition, print the level of the translation table when setting up a
new table.
Example log:
Backing address range [0x0000000000000:0x1000000000000) with new L0 ...
Mapping address range [0x0000000000000:0x0000200000000) as ...
Backing address range [0x0000000000000:0x0008000000000) with new L1 ...
Mapping address range [0x0000000100000:0x0000000130000) as ...
Backing address range [0x0000000000000:0x0000040000000) with new L2
Backing address range [0x0000000000000:0x0000000200000) with new L3
Mapping address range [0x0000000107000:0x0000000108000) as ...
Mapping address range [0x0000000200000:0x0000000300000) as ...
Backing address range [0x0000000000000:0x0000000200000) with new L3 ...
BUG=none
TEST=emerge-geralt coreboot
BRANCH=none
Change-Id: Ib29c201e1b096b9c7cd750d2541923616bc858ac
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83652
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Clang does not work that well as a linker for the header as it will
default to other linkers which do not work well here. Instead just use
the linker directly.
Change-Id: Id6ba42b470349a4b138a65b2a037f16a65982ef7
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70161
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
The patch enforces CSE sync when the GBB flag GBB_FLAG_FORCE_CSE_SYNC is
enabled and the system is currently booting from the RO section.
Additionally, it integrates forced CSE sync into eSOL decision-making.
BUG=b:353053317
TEST=Verified forced CSE sync on rex0 with GBB 0x200000
Cq-Depend: chromium:5718196
Change-Id: I228bc8ebf58719776f6c39e0bfbb7ad53d9bfb7f
Signed-off-by: Dinesh Gehlot <digehlot@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83686
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
This patch adds a GBB flag to coreboot, which, when enabled, enforces
CSE sync even if the current CSE version matches the version in CBFS.
The CSME sync GBB and flag are designed to enhance autotest
functionalities and are not intended or recommended for use in
developing any other features.
BUG=b:353053317
TEST=futility gbb --help
Cq-Depend: chromium:5718196
Change-Id: I6352959e1e898a90b4c6e12a22f8d6513f90ded9
Signed-off-by: Dinesh Gehlot <digehlot@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83685
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Updating from commit id 4b12d392e5b1:
scripts: Add a script to convert a vbprivk to a PEM
to commit id f1f70f46dc54:
2lib: Add gbb flag to enforce CSE sync
-Subproject commit 4b12d392e5b12de29c582df4e717b1228e9f1594
+Subproject commit f1f70f46dc5482bb7c654e53ed58d4001e386df2
Change-Id: I2c5b603ce5ea49e6c1aec293960184d84eedd1e7
Signed-off-by: Dinesh Gehlot <digehlot@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83733
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Clang builds (bootblock: 20800 bytes) are slightly larger than GCC
builds (bootblock: 18688 bytes) so increase the size of both bootblock
and romstage.
The technical reference manual mentions no upper limit to the size of
the bootblock in the TI header so increasing the bootblock size is
allowed.
To be able to link the clang bootblock increase it from 20K to 22K.
Change-Id: I8719bc3728d4cc8dba8d939cc154c3fc0884d47b
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70160
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
DC offset of class-D amplifier is 7mV in Brox which is larger than the expected 3mV.
Add a section in the verb table to enable class-D calibration based
on the updated verb table provided by Realtek in b:342506575 comment#6.
This improves the offset to be less than 1mV.
BUG=b:342506575
BRANCH=main
TEST=Verify DC offset of speaker amplier output is less than 1mV with a multimeter when \
playing -100dB sine waves.
Change-Id: I776f5c24ce3c829cbd64840957c1431608cf2b85
Signed-off-by: Terry Cheong <htcheong@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82794
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Shelley Chen <shchen@google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
The PSP can send SMIs to the x86 side of the system. Add helper
functions to configure and to reset the PSP SMI generation. Since
Stoneyridge also selects SOC_AMD_COMMON_BLOCK_SMI, add the SMITRIG0_PSP
define and rename SMITYPE_FCH_FAKE0 to SMITYPE_PSP in its SoC-specific
smi.h to bring it in line with the newer SoCs.
This patch is split out from CB:65523.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Signed-off-by: Ritul Guru <ritul.bits@gmail.com>
Change-Id: I525a447c9a75fdb95b9750e85a02896056315edf
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83702
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
In order to detect more issues in our code, make GCC more picky by
enabling -Wextra. Disable a couple of warnings turned on by -Wextra
temporarily in order to keep everything compiling and working for now.
The warnings may be enabled step by step later.
Since xcompiles applies to coreboot and libpayload, add Wextra here
instead of the top-level Makefile.mk.
Change-Id: I60915cb66581dc2c9b6807335fd0e214b45e76d6
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83347
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
acpigen_write_pci_root_port writes SSDT device objects for PCIe
root port, _ADR and _BBN are provided. SSDT objects for direct
subordinate devices will also be created (if detected), _ADR and
_SUN are provided.
TEST=Build and boot on intel/archercity CRB
Change-Id: I434fea7880a463c2027abfa22ba2b3bb985815c0
Signed-off-by: Lu, Pen-ChunX <pen-chunx.lu@intel.com>
Signed-off-by: Jincheng Li <jincheng.li@intel.com>
Signed-off-by: Shuo Liu <shuo.liu@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82252
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
To avoid having constructs like 'dev->path.domain.domain' in the SoC
code, create the 'dev_get_domain_id' helper function that returns the
domain ID of either that device if it's a domain device or the
corresponding domain device's domain ID, and use it in the code.
If this function is called with a device other than PCI or domain type,
it won't have a domain number. In order to not need to call 'die',
'dev_get_domain_id' will print an error and return 0 which is a valid
domain number. In that case, the calling code should be fixed.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I3d79f19846cea49609f848a4c42747ac1052c288
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83644
Reviewed-by: Shuo Liu <shuo.liu@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Some chips (fintek [1,2]) have registers with specific selector-fields
that can affect the address space of the device (for example, switch the
register bank). At the same time, these registers contain fields that
should not change after they are configured in BIOS (for example, set
the port to 2E/2F or 4E/4F). In this case, the selector should take into
account the mask of the register fields and there is no convenient and
easy way to add this in the code in the utility. The selector-fields
should be set manually before the dump and this action is done several
times.
This patch adds an extra-selector mechanism that allows superiotool to
make a correct dump in automatic mode.
Just add a structure with an index, mask, and value for the selector
inside the superio_registers chip for the corresponding LDN to switch
the register bank:
{FINTEK_F81966_DID, "F81962/F81964/F81966/F81967", {
* * *
{NOLDN, "Global",
{0x28,0x2a,0x2b,0x2c,EOT},
{0x00,0x00,0x00,0x00,EOT},
{.idx = 0x27, .mask = 0xd, .val = 0x1} /* update extra selector */
},
{0x03, "LPT",
{0x30,0x60,0x61,0x70,0x74,0xf0,EOT},
{NANA,0x03,0x78,0x07,0x03,0xc2,EOT} /* without extra selector */
},
* * *
Tested with Fintek F81966 on Asrock IMB-1222:
- run superiotool on Ubuntu and dump the registers for the board with
the vendor's firmware;
- add the superio chip initialization code to the board configuration
in coreboot and build the project;
- boot Ubuntu on the board with coreboot and re-dump the registers;
- the register values from the board configuration code are the same
in both dumps.
Found Fintek F81962/F81964/F81966/F81967 (vid=0x3419, id=0x0215) at 0x2e
(Global) -- ESEL[27h] 0x00 (Port Select Register) --
idx 02 07 20 21 23 24 25 26 27 28 29 2a 2b 2c 2d
val 00 0b 15 02 19 34 5a 23 80 a0 f0 45 02 e3 2e
def NA 00 15 02 19 34 00 23 02 a0 00 00 02 0c 28
* * *
The changes do not affect the configuration of existing chips, which
was tested on the Asrock H110-STX motherboard with Nuvoton NCT5539D
(the dump before and after the changes are the same).
[1] CB:83004
[2] CB:83019
Change-Id: If56af9f977381e637245bdd26563f5ba7e6cbead
Signed-off-by: Maxim Polyakov <max.senia.poliak@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83196
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
During the stages which use Cache-as-RAM (CAR), coreboot needs more than
1 KiB as configured in DCACHE_BSP_STACK_SIZE. After studying the UPDs
for various SoCs(ADL-P, ADL-N, RPL), coreboot stack requirement is
estimated to be 32 KiB. Update DCACHE_BSP_STACK_SIZE accordingly.
BUG=None
TEST=Build Brox BIOS image and boot to OS.
Change-Id: I723ba1f4289c393fe7376f989d760b26e75b33da
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83680
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
