The allocation is for the OS. Just need to take care
in the firmware that ChromeOS GNVS is allocated first.
Change-Id: I16db41b31751d7b4a8a70e638602f3f537fe392e
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50609
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Both the IO-APIC and PIC mode PCI IRQ tables are incorrect for ADL; the
2nd field in each package is supposed to be pin, not function number,
and some of the IRQ #s differ from what the FSP programs, therefore
align the ACPI table to match what the FSP is currently programming.
BUG=b:180105941
TEST=boot brya, no more `GSI INT` or `failed to derive IRQ routing`
errors seen in dmesg
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: I182be69e8d9ebd854ed74dbb69f4d1f1a539cf2f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50599
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Bilby is the reference board for AMD Raven, Raven2 and Picasso APUs.
Bilby mainboard code is taken from mandolin variant Cereme.
These new files are a renamed copy and subsequent patches will be
applied to create a working bilby implementation.
Change-Id: I426966d782e259a971ec36bac2498bc62b4ce7e2
Signed-off-by: Ritul Guru <ritul.bits@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50315
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
TEST=Boot majolica to linux and see IO-APIC logs
ACPI: Local APIC address 0xfee00000
ACPI: LAPIC_NMI (acpi_id[0xff] high edge lint[0x1])
IOAPIC[0]: apic_id 16, version 33, address 0xfec00000, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level)
ACPI: IRQ0 used by override.
ACPI: IRQ9 used by override.
Using ACPI (MADT) for SMP configuration information
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: Ib8094c3edf401659d9d740e2cc6266ddd5f91da9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50803
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Since all bridges to the internal buses have the same PCI ID, we can
just add this one ID to the pci_driver struct and don't need to use a
list of PCI IDs.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ice024b91f49f03995acbd8dfc8b33d3ae3559dde
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50804
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
These files have windows line endings. Change to unix to match the
rest of the tree.
Signed-off-by: Martin Roth <martin@coreboot.org>
Change-Id: I5bb3338745a6a47b6714aa268d16866aada27790
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50705
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Enforcing the exact match of FSPS UPD block size between FSP and
coreboot mandates simultaneous updates to coreboot and FSP repos. Allow
coreboot to proceed if its UPD structure is smaller than FSP one. This
usually indicates that FSPS has an updated (larger) UPD structure which
should be soon matched/updated on the coreboot side to keep them in
sync.
While this is an undesirable situation that should be corrected
ASAP, it is safe from coreboot perspective. It is safe (as long as
default values in FSP UPD are sane enough to boot) because FSPS UPD
buffer is allocated on the heap with the size specified in FSPS
(larger) and filled with FSPS default values. This allows FSP UPD
changes to be submitted first followed by changes in coreboot repo.
Note that this only applies to the case when entire FSPS UPD structure
grows which should be rare as FSP should allocate enough reserve space,
anticipating future expansion, to keep the structure from growing when
new members are added.
BUG=b:171234996
BRANCH=Zork
TEST=build Trembyle
Change-Id: I557fd3a1f208b5b444ccf76e1552e74ecf4decad
Signed-off-by: Nikolai Vyssotski <nikolai.vyssotski@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50576
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Martin Roth <martinroth@google.com>
Without the cast the left shift is done on a 32 bit variable that gets
extended to 64 bits afterwards which results in missing MSBs. To avoid
this, do the cast to 64 bits before the left shift.
Found-by: Coverity CID 1443793, 1443794
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I7cfa5b9b6ad71f36445ae2fa35140a8713288267
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50778
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
The I2C EEPROM on SMBUS needs to be updated with the current board
layout, so that the BMC knows the actual configuration.
Collect all needed information and update the EEPROM if something
changed. Every byte written add a delay of 5 msec.
Change-Id: Ic8485e6c700eede75b1e829238ee70da65118ace
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48810
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Some (notably older Intel) boards use a tabular description of irq
routing that we want to keep pristine no matter what clang-format
considers correct (as that's ugly).
Change-Id: I259255a9f60208c659b658ecb81535e84a2aaa8c
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50545
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
This only makes sense if relocation via MSR is possible, to relocate
APs in parallel. xeon_sp hardware does not support these MSR.
TESTED: ocp/deltalake boots fine. SMM is relocated on CPU 0 just like
all other cores.
Change-Id: Ic45e6985093b8c9a1cee13c87bc0f09c77aaa0d2
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50722
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Enable Refresh2X to mitigate RAM corruption during long
(> 1hr) periods of S3/suspend, which leads to failure to
successfully resume from S3. Unknown if an issue with all
DRAM types, but tested w/Kingston KVR24S17D8 16GiB DDR4 SODIMMs.
Test: Build/boot Librem Mini v1/v2, put device in suspend,
wait > 1hr, ensure resume from S3 successful 100% of the time.
Change-Id: Ie8e3ebbb1ebdcd98813b5f36f580a235712d2f97
Signed-off-by: Matt DeVillier <matt.devillier@puri.sm>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50756
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The `data->spd_len` option always needs to be initialised. However, it
did not get set when using a mixed memory topology. Correct this bug.
Fixes: commit 859ca18ced
Change-Id: I8a165f000e5d52e49de18d7648d02fe76d2dd296
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50786
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-by: EricR Lai <ericr_lai@compal.corp-partner.google.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This was replaced by APM_CNT defined in src/include/cpu/x86/smm.h, so
remove the now unused definitions.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ibd25dcdb57de14fe42352f01067cedca53712d56
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50777
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
n is the default of bool Kconfig options, so no need to have that added
to each option.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I8775d84caee6fda95eb7749e96090fe05417e764
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50779
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
To build a CrOS-style zephyr, we need a couple of u-boot tools, so add
them here instead of rebuilding them on every zephyr build (which is
also harder to get right because search paths are no strength of python)
Change-Id: Ib95fcb644ac87c5f35f2228fe081c922452b5213
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50744
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
I also removed the unnecessary #include in soc.asl.
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: Ifbd79871fd49b18f45d97f64ccd68fa96eaaebce
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50572
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Mathew King <mathewk@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This fixes the undefined reference for NVB0, NVB1, and NVB2.
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: Ib4ba24b66b9ae7899ccd40f91cdd23074f6afc4b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50614
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Add MMCONF_BUS_NUMBER=256 as this was not defined for
this SoC.
Change-Id: I6ba861d3b7d5ac083c9b16c8f6ad179efd403bcd
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50664
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Move SPD manufacturer ID decoding to device/dram. Will be used by the
following patch outside of SMBIOS scope as well.
Change-Id: Iec175cd6ab1d20761da955785e4bc0e87ae02dbb
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50544
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
* Check and print errors returned from reading from I2C
* Rework offset calculation by using more macros
* Get rid of stage-specific preprocessor code
* Define the EEPROM layout as struct
* Make use of the defined EEPROM layout to calculate offsets
* Read the UPD to disable VT-d from EEPROM
Change-Id: Iad77811318c7dfd3a3a4f8d523cfa0f457f168b6
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48808
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This bit is primarily used to issue RDA commands. There doesn't seem to
be any limitation regarding the number of address bits.
Change-Id: I2804f67319c9bc736f9086af408853056aabedd6
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50473
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Kyösti Mälkki