| Age | Commit message (Collapse) | Author |
|---|
|
Instead of having a magic entry in the CPU device ID table list to tell
find_cpu_driver that it has reached the end of the list, introduce and
use CPU_TABLE_END. Since the vendor entry in the CPU device ID struct is
compared against X86_VENDOR_INVALID which is 0, use X86_VENDOR_INVALID
instead of the 0 in the CPU_TABLE_END definition.
TEST=Timeless build for Mandolin results in identical image.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Suggested-by: Angel Pons <th3fanbus@gmail.com>
Change-Id: I0cae6d65b2265cf5ebf90fe1a9d885d0c489eb92
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72888
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
Use CPUID_ALL_STEPPINGS_MASK as CPUID match mask to support all
Mendocino steppings that might be available in the future. Right now it
shouldn't change any behavior.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I77ea8c6162667e0a318176e62078b1f57726c10c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72850
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Instead of always doing exact matches between the CPUID read in
identify_cpu and the device entries of the CPU device ID table,
offer the possibility to use a bit mask in the CPUID matching. This
allows covering all steppings of a CPU family/model with one entry and
avoids that case of a missing new stepping causing the CPUs not being
properly initialized.
Some of the CPU device ID tables can now be deduplicated using the
CPUID_ALL_STEPPINGS_MASK define, but that's outside of the scope of this
patch.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I0540b514ca42591c0d3468307a82b5612585f614
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72847
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
Remove TODO comment after reviewing against mendocino ppr #57243, rev
3.00
BUG=b:263563246
Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com>
Change-Id: I9a89751df71eb32b2c8d99c568341dd669b5f065
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72073
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: I7c457ab69581f8c29f2d79c054ca3bc7e58a896e
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64870
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Only 16 MByte of the SPI flash can be mapped right below the 4 GB
boundary.
In case of a larger SPI flash size, still only the 16 MByte region
starting at 0xff000000 can be configured as WRPROT and be reserved for
the MMIO mapped SPI flash region. The next 16 MByte MMIO region starting
at address 0xfe000000 contain for example the LAPIC MMIO region, the
ACPIMMIO region and the UART/I2C controller MMIO regions which shouldn't
be configured as WRPROT. Reserving this region for the MMIO mapped SPI
flash would also result in an overlap with the MMIO resources mentioned
above.
In the case of a smaller SPI flash, reserving the full 16 MByte flash
MMIO region makes sure that the resource allocator won't try to put
anything else in the lower parts of the 16 MByte SPI mapping region.
To avoid the issues described above, always reserve/cache the maximum
amount of 16 MBytes of flash that can be mapped below 4 GB.
TEST=On boards with 16 MByte SPI flash chips, the resulting image of a
timeless build doesn't change with this patch. Verified this on Chausie
(Mendocino), Majolica (Cezanne), Cereme (Picasso) and Google/Careena
(Stoneyridge). On Mandolin (Picasso) with an 8 MByte flash, the
resulting image of a timeless build is different, but neither the
coreboot console output nor the Linux dmesg output shows any errors that
might be related to this change.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ie12bd48e48e267a84dc494f67e8e0c7a4a01a320
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66700
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
'Mendocino' was an embargoed name and could previously not be used
in references to Skyrim. coreboot has references to sabrina both
in directory structure and in files. This will make life difficult
for people looking for Mendocino support in the long term. The code
name should be replaced with "mendocino".
BUG=b:239072117
TEST=Builds
Cq-Depend: chromium:3764023
Cq-Depend: chromium:3763392
Cq-Depend: chrome-internal:4876777
Signed-off-by: Jon Murphy <jpmurphy@google.com>
Change-Id: I2d0f76fde07a209a79f7e1596cc8064e53f06ada
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65861
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
|
