Rename different spd_raw_data[] for DDR3 and DDR4.
This is to solve the conflict when we include both "ddr3.h" and ddr4.h"
for example here: src/device/dram/spd.c.
Otherwise, it won't compile as DDR3 and DDR4 have different
spd_raw_data[] size.
Change-Id: I46597fe82790410fbb53d60e04b7fdffb7b0094a
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82171
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The only implementations of `mb_post_raminit_setup()` in the tree are
found in Lenovo ThinkPads. These boards use this function to toggle a
SMBus mux, which makes the DIMM SPDs inaccessible. Given that the SPD
data is needed in `setup_sdram_meminfo()` and that there are no other
side-effects, simply move the call to `mb_post_raminit_setup()` after
the call to `setup_sdram_meminfo()`.
TEST=Verify SMBIOS Type 17 information for lenovo/x200 is correct.
Change-Id: I46abffa48e7e0848f9346ce9c6498860e4ece2da
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81946
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Fill in memory info so that coreboot can generate SMBIOS Type 17 tables.
The S/N, P/N and module ID fields are only populated for DDR3.
Change-Id: I92060ce05bdf0ca617a3383a2db1fdbd43df6fe4
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81861
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jean Lucas
Clang complains that the two enumerations are incompatible. However, the
values themselves are the same (0: mobile, 1: desktop, 5: ULT). So, cast
the function's return value to silence the warning.
Change-Id: If7b5e22e893e9f3f17a15197c65448fb782590f6
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81862
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Integer division in C truncates toward zero. When the dividend and the
divisor are positive, one can add half of the divisor to the dividend to
round the division result towards the closest integer. We already have a
macro in commonlib to do just that, so put it to good use.
Tested with BUILD_TIMELESS=1, coreboot images for the Asus P8Z77-V LX2
and the Asrock B85M Pro4 do not change.
Change-Id: I251af82da15049a3a2aa6ea712ae8c9fe859caf6
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52651
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Benjamin Doron <benjamin.doron00@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
tCPDED is always 1, except for steppings earlier than Sandy Bridge D0.
Reduces the differences to MRC.bin.
Tested on Lenovo X220: Still boots and runs fine.
Change-Id: I5294173c02f06c601fdb13ed785ee33d7a4e3eca
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79762
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Only write register WMM_READ_CONFIG on Ivy Bridge as it's
reserved on Sandy Bridge.
Tested on Lenovo X220: Still boots and runs fine.
Change-Id: Ie14ea06d744b1a8368d32803c6c1ccfb1262532e
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79761
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
MRC.bin doesn't write BANDTIMERS_SNB register, so drop the
write. The bits written were targeting a reserved range,
so assume it didn't do anything useful.
Tested on Lenovo X220: Still boots and runs fine.
Change-Id: I920aabd60831c791188af976914553787cc0ff18
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79760
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
A register dump between native and MRC.bin raminit showed a difference
in the PM_DLL_CONFIG register. Use the same value as MRC.bin uses.
Tested on Lenovo X220: Still boots and works fine.
Change-Id: Iaf6334814c5748e5a3691a572213f433c79f382d
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79759
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
With SMM holding page tables itself, we can consider SMM support stable
and safe enough for general use.
Also update the respective documentation.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: Ifcf0a1a5097a2d7c064bb709ec0b09ebee13a47d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80338
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
This is usually is handled by Haswell mrc.bin, disabling VGA
decode on the iGPU when a dGPU is installed. However, Broadwell
mrc.bin does not, so the iGPU and dGPU are both enabled.
This patch disables legacy VGA cycles for iGPU, under such
conditions. It has been tested on Broadwell mrc.bin when
using a graphics card on Dell OptiPlex 9020 SFF (currently
under review at this time of writing, submitted by Mate
Kukri).
This patch has also been tested when Haswell mrc.bin is used,
and there are seemingly no breaking changes caused by it.
Change-Id: I1df0a3aa42f8475b7741007bf3e28c2e089d916b
Signed-off-by: Leah Rowe <info@minifree.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80717
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
It seems that we have some applications where we need to calculate a GCD
in 64 bits. Now, we could instantiate the algorithm multiple times for
different bit width combinations to be able to use the most efficient
one for each problem... but considering that the function usually only
gets called once per callsite per stage, and that software emulation of
64-bit division on 32-bit systems doesn't take *that* long either, we
would probably usually be paying more time loading the second instance
of the function than we save with faster divisions. So let's just make
things easy and always do it in 64-bit and then nobody has to spend time
thinking on which version to call.
Change-Id: I028361444c4048a0d76ba4f80c7334a9d9983c87
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80319
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yidi Lin <yidilin@google.com>
This patch moves the IP checksum algorithm into commonlib to prepare for
it being shared with libpayload. The current implementation is ancient
and pretty hard to read (and does some unnecessary questionable things
like the type-punning stuff which leads to suboptimal code generation),
so this reimplements it from scratch (that also helps with the
licensing).
This algorithm is prepared to take in a pre-calculated "wide" checksum
in a machine-register-sized data type which is then narrowed down to 16
bits (see RFC 1071 for why that's valid). This isn't used yet (and the
code will get optimized out), but will be used later in this patch
series for architecture-specific optimization.
Change-Id: Ic04c714c00439a17fc04a8a6e730cc2aa19b8e68
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80251
Reviewed-by: Yidi Lin <yidilin@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jakub Czapiga <czapiga@google.com>
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>
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>
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: Iddac15cc42532f44dda44032be0f8525f6347abd
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80070
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Built roda/rk9 with BUILD_TIMELESS=1 and the resulting coreboot.rom
remains identical.
Change-Id: Ib1e7144eebf8148c4eb5cc0e7bc03ae3d7281092
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77971
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Enable x86_64 support for MRC.bin:
- Add a wrapper function for console printing that calls into
long mode to call native do_putchar
- Remove Kconfig guard for x86_64 when MRC is being used
Tested: Booted Lenovo X220 using mrc.bin under x86_64 and
MRC is able to print to the console.
Change-Id: I21ffcb5f5d4bf155593e8111531bdf0ed7071dfc
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79754
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
In DDR3 DLL-Off mode is an optional feature advertised by SPD.
Honor the SPD and only use DLL-Off mode when all DIMMs on the
same channel indicate support for it.
The same is done on MRC.bin.
Tested on Lenovo X220: Still boots fine.
Change-Id: Ief4bfb9e045cad7ff9953f6fda248586ea951a52
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79758
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
- Remove pointers in argument list passed to MRC to make sure the struct
has the same size on x86_64 as on x86_32.
- Add assembly wrapper to call the MRC with argument in EAX.
- Wrap calling MRC in protected_mode_call_2arg, which is a stub on x86_32
Tested: Boots on Lenovo X220 using MRC in x86_32 and x86_64 mode.
Change-Id: Id755e7381c5a94360e3511c53432d68b7687df67
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79751
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Use same indent levels for switch/case in order to comply with the
linter.
Change-Id: I64361262e5b16419351fa139c8fdf04c5c07662d
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79444
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Since the EHCI controllers in the PCH are always on the same device
functions, the device operations can be statically assigned in the
devicetree and there's no need to bind the EHCI device operations to the
PCI devices during runtime via a list of PCI IDs.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I92ecc3607216fb2f31639db9628898c9ce81770d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79171
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Since the XHCI controller in the PCH is always on the same device
function, the device operations can be statically assigned in the
devicetree and there's no need to bind the XHCI device operations to the
PCI device during runtime via a list of PCI IDs.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I8685bec734415346a53330c9bd1aa82986995f1a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79170
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Since the PCI bridge in the PCH is always on the same device function,
the device operations can be statically assigned in the devicetree and
there's no need to bind the PCI bridge device operations to the PCI
device during runtime via a list of PCI IDs.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ic9ca925a12e64c9a5b3bf295653bf032572ff29a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79169
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Since the SMBus controller in the PCH is always on the same device
function, the device operations can be statically assigned in the
devicetree and there's no need to bind the SMBus device operations to
the PCI device during runtime via a list of PCI IDs.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I3d3745ba5aefa30efbe705155d216aa7eadd26a7
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79168
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Since the LPC bridge in the PCH is always on the same device function,
the device operations can be statically assigned in the devicetree and
there's no need to bind the LPC bridge device operations to the PCI
device during runtime via a list of PCI IDs.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I366226be4aba75b98e45e4832bfe129fac14dbfa
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79167
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Instead of using MSR IA32_PLATFORM_ID read the SystemAgent device id
to figure out the PC type. This follows the BWG which suggest to not
use MSR IA32_PLATFORM_ID for system identification.
Tested: Lenovo X220 still boots.
Change-Id: Ibddf6c75d15ca7a99758c377ed956d483abe7ec1
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78826
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Since the HD audio controller in the PCH are always on the same device
functions, the device operations can be statically assigned in the
devicetree and there's no need to bind the host bridge device operations
to the PCI device during runtime via a list of PCI IDs.
TEST=Lenovo X220 still boots to Linux and audio still works
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Change-Id: I9bbbe9f4490dc6fb21174d63d1c8906d69ea3ee0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79118
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Since the PCIe root ports in the PCH are always on the same device
functions, the device operations can be statically assigned in the
devicetree and there's no need to bind the host bridge device operations
to the PCI device during runtime via a list of PCI IDs.
TEST=Lenovo X220 still boots to Linux and all PCIe devices on PCH are
visible and working.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Change-Id: I05bfe8db88fd54415f320f32ea147636ca4e0df8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79117
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Since the integrated GPU is always function 0 of device 2 on bus 0, the
device operations can be statically assigned in the devicetree and
there's no need to bind the host bridge device operations to the PCI
device during runtime via a list of PCI IDs.
TEST=Lenovo X220 still boots to Linux and graphics works in UEFI
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Change-Id: I20e387e626e19dc441aceda18451186d1e86cd5f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79114
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Since the host bridge is always function 0 of device 0 on bus 0, the
device operations can be statically assigned in the devicetree and
there's no need to bind the host bridge device operations to the PCI
device during runtime via a list of PCI IDs.
TEST=Lenovo X220 still boots to Linux
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Change-Id: Icf3d9f8cd2be2f8ef71fd9fdb5f005f3b683332e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79113
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
After commit adaeb11021 (nb/intel/sandybridge: Clean up post Haswell SPD mapping API migration), no boards use this header anymore and it
no longer offers original content.
Adjust northbridge code #includes as needed and drop it.
Change-Id: I2785e920bd6188dbfc1a6157351083ec4a2526d0
Signed-off-by: Keith Hui <buurin@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78785
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
With migration to Haswell SPD mapping interface complete:
1. Remove weak stubs meant to ensure smooth transition and
internalizes mainboard_get_spd() within raminit.c.
2. Remove post-mainboard SPD data sanitization code in raminit_mrc.c,
now that it fills its own SPD data.
3. Remove old prototypes from raminit_native.h
4a. Drops raminit_native.h from raminit.c, as individual headers
therein are already included.
4b. Drop another header from raminit.c IWYU identified as unneeded.
asus/p8z77-m still builds afterwards.
(sandybridge to receive a full IWYU cleanup later.)
Change-Id: Ie073c1386cd0a645069f0e1416263b4fa359b74b
Signed-off-by: Keith Hui <buurin@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76991
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Changes both MRC and native raminit code path to get SPD mapping
from one place.
Boards with all memory socketed specify their mappings in a
devicetree setting introduced in commit 5709e03613
("nb/intel/sandybridge: Migrate MRC settings to devicetree") back in
May 2019 but remains unused as of this patch. This setting
will now hold raw SMBus addresses, and MRC raminit gets code to
translate them into a representation MRC expects.
Boards with soldered down memory (specifically with HAVE_SPD_IN_CBFS
in their board Kconfig), with or without socketed memory, specify
their layouts in mb_get_spd_map() as used by Haswell boards, where
they access hardware GPIO straps to select which SPD data to use.
This harmonizes the way boards specify their SPD layouts across
Haswell/SNB/IVB boards whether using MRC or native raminit. Going
forward they only need to specify the layout in one place. (Going
forward the devicetree setting should be backported to Haswell,
once we get native raminit working there.)
With this, northbridge code is now fully responsible for loading
all SPD data, be it from CBFS or SMBus.
To avoid breakage, transition will happen in stages:
1. This patch gets all the code in, and implements weak stubs that
maintain existing code and data flow (i.e. mainboards still populate
final SPD layout data). At this point devicetree already uses new
representation, but is still unused meaning no breakage.
2. Follow-up patch(es) remove mainboard_get_spd() from mainboards, and
replace it with mb_get_spd_map() or devicetree values (as appropriate)
with converted SPD info. The "weak" mainboard_get_spd() with new logic
takes over. Boards go Haswell Style at this point. Boards with MRC
raminit also lose code to fill in SPD data, allowing new data to take
hold.
3. Clean-up patch removes the weak functions and public prototypes re
mainboard_get_spd(), making it internal to northbridge. Changeover is
complete.
Change-Id: I1a75279d981e46505930a9ce1aae894ccc4e1f24
Signed-off-by: Keith Hui <buurin@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76965
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Change-Id: I30e4b02a9ca6a15c9bc4edcf4143ffa13a21a732
Signed-off-by: Yidi Lin <yidilin@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78799
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
Having a CBFS cache scratchpad offers a generic way to decompress CBFS
files through the cbfs_map() function without having to reserve a
per-file specific memory region.
This commit introduces the x86 `PRERAM_CBFS_CACHE_SIZE' Kconfig to set
the pre-memory stages CBFS cache size. A cache size of zero disables
the CBFS cache feature. The default value is 16 KB which seems a
reasonable minimal value enough to satisfy basic needs such as the
decompression of a small configuration file. This setting can be
adjusted depending on the platform needs and capabilities.
We have set this size to zero for all the platforms without enough
space in Cache-As-RAM to accommodate the default size.
TEST=Decompression of vbt.bin in romstage on rex using cbfs_map()
Change-Id: Iee493f9947fddcc57576f04c3d6a2d58c7368e09
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77290
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
On all targets the domain works as a host bridge. Xeon-sp code intends
to feature multiple host bridges below a domain, hence rename the
function to pci_host_bridge_scan_bus.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: I4e65fdbaf0b42c5f4f62297a60d818d299d76f73
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78326
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Yidi Lin <yidilin@google.com>
Collect SPD data from DIMMs and memory-down, and find the common
supported settings.
Original-Change-Id: I4e6a1408a638a463ecae37a447cfed1d6556e44a
Original-Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Signed-off-by: Bill XIE <persmule@hardenedlinux.org>
Change-Id: I7948554eb02113bdca380222a11cfb322f9615f8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77049
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
CPU replacement check should only be done on cold boots.
Original-Change-Id: I98efa105f4df755b23febe12dd7b356787847852
Original-Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Signed-off-by: Bill XIE <persmule@hardenedlinux.org>
Change-Id: I3c79f4e55e23c0b98da7661988e3ff8b50d6300d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77048
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
To help identify the licenses of the various files contained in the
coreboot source, we've added SPDX headers to the top of all of the
.c and .h files. This extends that practice to Makefiles.
Any file in the coreboot project without a specific license is bound
to the license of the overall coreboot project, GPL Version 2.
This patch adds the GPL V2 license identifier to the top of all
makefiles in the commonlib, console, northbridge, security, and
southbridge directories that don't already have an SPDX license line
at the top.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I02804a10d0b0355e41271a035613d9f3dfb122f8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68985
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Rewrite them to more accurately describe what they are about.
Change-Id: Icb0ac1e592b662bbb81da431ff97af1a00f952c0
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47429
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
