This renames bus to upstream and link_list to downstream.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: I80a81b6b8606e450ff180add9439481ec28c2420
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78330
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
GPP_E08 and GPP_E22 were set incorrectly previously.
This CL corrects these settings according to schematics.
BUG=b:305793886
TEST=Built FW image correctly.
Signed-off-by: Eran Mitrani <mitrani@google.com>
Change-Id: I8e427350e1ee564f9d6566bdfe1f42c92c87a711
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80238
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Macros can be confusing on their own; hiding commas make things worse.
This can sometimes be downright misleading. A "good" example would be
the code in soc/intel/xeon_sp/spr/chip.c:
CHIP_NAME("Intel SapphireRapids-SP").enable_dev = chip_enable_dev,
This appears as CHIP_NAME() being some struct when in fact these are
defining 2 separate members of the same struct.
It was decided to remove this macro altogether, as it does not do
anything special and incurs a maintenance burden.
Change-Id: Iaed6dfb144bddcf5c43634b0c955c19afce388f0
Signed-off-by: Nicholas Sudsgaard <devel+coreboot@nsudsgaard.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80239
Reviewed-by: Yidi Lin <yidilin@google.com>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Jakub Czapiga <czapiga@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
With Cr50, the GPIO EC_IN_RW is used to determine whether EC is trusted. However, With the switch to Ti50, it is determined by Ti50's boot mode. If the boot mode is TRUSTED_RO, the VB2_CONTEXT_EC_TRUSTED flag will be set in check_boot_mode(). Therefore in the Ti50 case get_ec_is_trusted() can just return 0.
The current code of get_ec_is_trusted() only checks the GPIO, which
causes the EC to be always considered "trusted". Therefore, correct the return value to 0 for TPM_GOOGLE_TI50.
BUG=b:321172119
TEST=emerge-nissa coreboot chromeos-bootimage
TEST=firmware_DevMode passed in FAFT test
Change-Id: I308f8b36411030911c4421d80827fc49ff325a1b
Signed-off-by: Qinghong Zeng <zengqinghong@huaqin.corp- partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80158
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Tyler Wang <tyler.wang@quanta.corp-partner.google.com>
Reviewed-by: Ian Feng <ian_feng@compal.corp-partner.google.com>
Reviewed-by: Weimin Wu <wuweimin@huaqin.corp-partner.google.com>
Reviewed-by: Eric Lai <ericllai@google.com>
Check MTL EDS2, SOC_TCHSCR_RST(GPP_C01) default setting is NF1.
Set SOC_TCHSCR_RST to output low in early_gpio_table.
BUG=none
TEST=Build and test on karis, touchscreen function works
Change-Id: Ieebd3cf3c320bc895d036c372f792ec7b5d7ebf9
Signed-off-by: Tyler Wang <tyler.wang@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80000
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Eric Lai <ericllai@google.com>
Move the definition of the TCO registers used in most boards to a
separate file and use it consistently. Do not unify TCO for older
incompatible platforms.
BUG=b:314260167
TEST=none
Change-Id: Id64a635d106cea879ab08aa7beca101de14b1ee6
Signed-off-by: Marek Maslanka <mmaslanka@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80005
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Jakub Czapiga <czapiga@google.com>
Follow reference design rex0, toggles NVMe PWR pin as soon as
in early stage to make NVMe ready sooner.
BUG=none
TEST=Build karis and try warm reboot from OS console. Check the DUT
with WD SSD boots to OS again.
Change-Id: I24a702f02278355c4f2137f0d05c8a9da7cb3c1c
Signed-off-by: Tyler Wang <tyler.wang@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80213
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The current panel voltage measured at mainboard side is 1.79V and the
voltage at panel side is 1.74V. Since the panel requires 1.8V or more,
increase the circuit voltage to 1.9V to meet the panel requirement.
After adjustment mainboard side voltage is 1.89V and panel side is
1.84V.
BUG=b:322080023
TEST=Check ciri vm18 ldo voltage
BRANCH=None
Change-Id: I6d6193d45409f53c0b656890c44ddaef253c5e01
Signed-off-by: Cong Yang <yangcong5@huaqin.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80198
Reviewed-by: Ruihai Zhou <zhouruihai@huaqin.corp-partner.google.com>
Reviewed-by: Yidi Lin <yidilin@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
GCC_OPTIONS is only used for target specific options right now,
so rename to TARGET_GCC_OPTIONS and only use them in the
non-bootstrap build.
Adapt BINUTILS_OPTIONS for consistency, even though it doesn't
have the same problem.
Change-Id: I5e4f54b758dd7daf4e69101c19dfa1212fa64cf6
Signed-off-by: Patrick Georgi <patrick@georgi.software>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80229
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
It's what this function family is defined to do, we currently don't
usually run into the case (see: not too many die() instances going
around), it's more useful to try to recover, and the JPEG parser can run
into it if the work buffer size exceeds the remaining heap, whereas its
sole user (the bootsplash code) knows what to do when seeing a NULL.
Use xmalloc() if you want an allocation that either works or dies.
tl;dr: That code path isn't usually taken. Right now it crashes. With
this patch it _might_ survive. There is a use-case for doing it like
that now.
Change-Id: I262fbad7daae0ca3aab583fda00665a2592deaa8
Signed-off-by: Patrick Georgi <patrick@coreboot.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80226
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Reviewed-by: Eric Lai <ericllai@google.com>
Multiple links are unused throughout the tree and make the code more
confusing as an iteration over all busses is needed to get downstream
devices. This also not done consistently e.g. the allocator does not
care about multiple links on busses. A better way of dealing multiple
links below a device is to feature dummy devices with each their
respective bus.
This drops the sconfig capability to declare the same device multiple
times which was previously used to declare multiple links.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: Iab6fe269faef46ae77ed1ea425440cf5c7dbd49b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78328
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jincheng Li <jincheng.li@intel.com>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
CXL IIO stacks
When an IIO stack is connected with CXL cards, its bus range
will be divided by a PCI host bridge object and a CXL host
bridge object, otherwise, all its range will be owned by the
PCI host bridge object. Accordingly, CXL ACPI resources should
be only created when the IIO stack is connected with a CXL
card.
TEST=intel/archercity CRB
Change-Id: I6c1b1343991bc73d90a433d959f6618bbf59532f
Signed-off-by: Shuo Liu <shuo.liu@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80087
Reviewed-by: Felix Held <felix-coreboot@felixheld.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.
Change-Id: I32d08ffd5bbd856b17f7ca2775c5923957d92c85
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80190
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Adding downstream busses at runtime is a common pattern so add a helper
function.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: Ic898189b92997b93304fcbf47c73e2bb5ec09023
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80210
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
The CRAT (Component Resource Attribute Table) isn't used on the APUs
from Renoir on and has also been marked as deprecated in version 6.5 of
the ACPI specification. So remove the 'TODO: look into adding CRAT'
comment from all SoCs from Renoir/Cezanne on.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I3ea1e3678608b0ace2a1ff7fc104594e90c91476
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80227
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Since the acpi_add_fsp_tables implementation is identical for all SoCs,
factor it out and move it to the common AMD FSP code. Also guard the
acpi_add_fsp_tables call in soc_acpi_write_tables with
if (CONFIG(PLATFORM_USES_FSP2_0)) to properly handle the FSP dependency.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I8917a346f586e77b3b3278c73aed8cf61f3c9e6a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80225
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Factor out acpi_add_fsp_tables from the soc_acpi_write_tables function
and move the remaining parts of the soc_acpi_write_tables function to
the SoC's acpi.c. This aligns the other family 17h/19h SoCs more with
Genoa and only leaves the FSP-specific code in agesa_acpi.c which will
be made common in a following patch. I decided against also renaming
agesa_acpi.c to acpi_fsp.c, since that would have made the diff less
readable and the files get deleted in a following patch anyway.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ia87ac0e77c5e673e694703b85a4bab85a34b980e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80224
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Factor out the code to add the CRAT ACPI table into a separate file and
add the acpi_add_crat_table function that can then be called from
soc_acpi_write_tables to better isolate all code specific to the CRAT
table.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I4a7853748512811d3d4e124224fcd459e527522c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80223
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
ACPI_SCI_IRQ is defined as 9 for all AMD SoCs, so move the definition to
the common amdblocks/acpi.h. Since all but Stoneyridge's soc/acpi.h are
now empty, delete those files too.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I8210c98dc4cf2c6001d5273d132053278ff7fea5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80222
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Since the definition is the same for all SoCs, move it to the common
amdblock/acpi.h header. Since the Stoneyridge northbridge.c file also
includes this prototype, remove the static attribute of the function
there.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ib9aa215f2b4ba58f43fed2c751d989f1719e0a17
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80221
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The southbridge_write_acpi_tables function uses a struct device type
parameter, but device/device.h that provides the definition wasn't
included.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I5245fa132ec9b84bbc483a31788bcd6fac0736e1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80220
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
add_agesa_fsp_acpi_table should use the same type for the 'current'
parameter and return value as the calling soc_acpi_write_tables does.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ie9f770b1d847ea28e4dbd96298a723d794b91a02
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80219
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
A pointer to soc_acpi_write_tables gets assigned to the
write_acpi_tables element of the device_operations struct, so make sure
that the function has the expected function signature which in this case
means using unsigned long as type for both the 'current' parameter and
the return value.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Iee45badb904fa20c6db146edbc00c40ca09361d1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80218
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
It's not the AGESA code that generates most of the ACPI tables, so
rename the function. This also aligns the other SoCs more with Genoa.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I6b2e6c4cb7139c8bde01b4440ab2e923a1086827
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80217
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
As a result of hardware changes on this board, the PHY previously
routed to the PSE GbE 1 is now routed to PSE GbE 0 on the Elkhart Lake
SoC.
This patch changes the device PCI ID in the board's devicetree and
accordingly, the GPIO configuration.
BUG=none
TEST=Boot into Linux and observe whether both PSE GbE 0 and PCH GbE
are working, while PSE GbE 1 remains inactive (not listed by 'ip link')
.
Change-Id: I322371f944d15134e6f48ecd84a4026c2fced27b
Signed-off-by: Jan Samek <jan.samek@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80186
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Mario Scheithauer <mario.scheithauer@siemens.com>
The currently used panel type could work with 500 ms but increasing
the value to 1 second allows to use a wider range of LVDS LCD panels,
as many of them specify the delay of 1 s as minimum.
The patch has already been made for mc_ehl3 and serves the purpose of
standardization.
commit c0221aa980 ("mb/siemens/mc_ehl3/lcd_panel.c: Set LVDS re-power
delay to 1 s")
Change-Id: Ife26ff27b41298ceeed7d9aed0c1ae5553ab5ff8
Signed-off-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80214
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jan Samek <jan.samek@siemens.com>
This patch refactors GPR0 unlock function to add few important
logic as below
1. Perform GPR0 unlock if GPR0 is locked.
2. While unlocking dump the GPRD PCH strap details
3. Additionally, print the GPR start and end range if GPR0
protection is enabled.
TEST=Able to test GPR0 protection on google/rex and google/yahiko.
Exp 1: Trying to unlock GPR0 protection for a locked image
> ifdtool -p mtl -g image.bin -O image.bin_unlock
File image.bin is 33554432 bytes
Value at GPRD offset (64) is 0x83220004
--------- GPR0 Protected Range --------------
Start address = 0x00004000
End address = 0x00322fff
Writing new image to image.bin_unlock
Exp 2: Trying to unlock GPR0 protection for a unlocked image
> ifdtool -p mtl -g image.bin_unlock -O image.bin_unlock
File image.bin_unlock is 33554432 bytes
GPR0 protection is already disabled
Change-Id: Id35ebdefe83182ad7a3e735bdd2998baa0ec3ed7
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80216
Reviewed-by: YH Lin <yueherngl@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
This patch ensures the baseboard and variant configs (inside Kconfig
and Kconfig.name) are organized in alphabetic order.
TEST=execute make menuconfig and verify the google/rex variants
order are alphabetically correct.
Change-Id: I0acc2cec21b4607856127b04c400ec416f0c0dd2
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80206
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Jakub Czapiga <czapiga@google.com>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
BUG=b:300690448,b:319393777
BRANCH=None
TEST=tested on a device with i2cdetect
Also tested with evtest and make sure Wacom is listed
Change-Id: I4f528b0d778c8c4a4e83774d5c167ccb2d6afd9a
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79895
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This is causing an assertion error on the devices that don't have CNVi
enabled because CNVi is hidden behind a FW_CONFIG flag in the
overridetree now.
BUG=b:319188820
BRANCH=None
TEST=emerge-brox coreboot chromeos-bootimage
make sure we can boot to kernel on device.
Change-Id: Ifcfbc04825d4d4e7f2874a4c52f9c5cf3e657856
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80211
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This adds the ability to add a flat-binary using menuconfig.
Test: boot hifive-unmatched mainboard with the following config:
CONFIG_PAYLOAD_NONE=n
CONFIG_PAYLOAD_ELF=y
CONFIG_PAYLOAD_FILE="~/repos/linux-riscv/arch/riscv/boot/Image"
CONFIG_PAYLOAD_IS_FLAT_BINARY=y
CONFIG_PAYLOAD_OPTIONS="-l 0x82000000 -e 0x82000000"
CONFIG_COMPRESSED_PAYLOAD_LZMA=y
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: I48c6b53a0c9f5b173c89f1a294a0c37fa1a58f31
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79950
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Move the verstage on PSP files in vendorcode from the fsp subdirectory
to a new psp_verstage subdirectory, since those files aren't specific to
the case of the FSP being used for the silicon initialization.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ic47f8b18bc515600add7838f4c7afcb4fff7c004
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80209
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
This patch adds APCB blobs to the mainboard directory and it replaces
CB:76445 Also this brings onyx_poc mainboard inline with how APCB are
included in other AMD mainboard: commit 95d05d8301 ("mb/google/zork:
Add and use APCB configuration data"), commit I352f58e0d39 ("mb/google/
skyrim: Add and use APCB configuration data") and commit I1c34528fa0f
("mb/amd/onyx_poc: Add and use APCB configuration data").
BUG=none
TEST=build/boot onyx_poc
Change-Id: I1c34528fa0fd15b847c22c995713078c60ac3873
Signed-off-by: Varshit Pandya <pandyavarshit@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80204
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Instead of open-coding this functionality in all AMD SoCs, factor it out
into a common implementation.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Idb65c398b747e70ec67107e0a1d4bd6551501347
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80208
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
As with other devices with only an external display, the Librem mini/
mini-v2 need a few extra seconds (vs an internal panel) for display init in order for the edk2 boot splash to be visible before the
default boot target is booted.
TEST=build/boot Librem Mini v2 w/edk2 payload, verify splash screen
shown / user has time to enter setup menu.
Change-Id: I9d2d514719a9918ee58cc63969b3adae44ac1632
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80182
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jonathon Hall <jonathon.hall@puri.sm>
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: I2a6a4d1eb7e0d0cd32c8690caf3eff340cdb0d8c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80124
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
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: I434940ebb46853980596f7ad55d27a62c90280fa
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80123
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
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: Id09eafd293a54198aab87281f529749325df8b07
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80122
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
If the smbios table is not below 4G there is no need to have a 32 bit
entry point. Even worse it could cause the payload to try to use the
entry point.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: I4cb426bb0c45282ed03ff4c65d15004b7f985dab
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76911
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Arthur Heymans