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 to only need one CPU device ID table entry
per family & model combination and not one per stepping.
TEST=Mandolin with a Picasso APU with PICASSO_B1_CPUID (0x00810f81)
still finished mpinit and boots successfully even though now only
PICASSO_B0_CPUID (0x00810f80) with CPUID_ALL_STEPPINGS_MASK specified as
device match mask. When commenting out the line with PICASSO_B0_CPUID
as a negative test, mpinit fails as expected.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I00ba43834ad86ecffa09d60599b17d122acd0b99
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72848
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>
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>
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>
The syscfg has to option to automatically mark the range between 4G and
TOM2, which contains DRAM, as WB. Making it generally not necessary to
allocate MTRRs for memory above 4G if no PCI BARs are placed up there.
Change-Id: Ifbacae28e272ab2f39f268ad034354a9c590d035
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64868
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Implementation for setup_lapic() did two things -- call
enable_lapic() and virtual_wire_mode_init().
In PARALLEL_MP case enable_lapic() was redundant as it
was already executed prior to initialize_cpu() call.
For the !PARALLEL_MP case enable_lapic() is added to
AP CPUs.
Change-Id: I5caf94315776a499e9cf8f007251b61f51292dc5
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58387
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
When the mp_init_with_smm call returns a failure, coreboot can't just
continue with the initialization and boot process due to the system
being in a bad state. Ignoring the failure here would just cause the
boot process failing elsewhere where it may not be obvious that the
failed multi-processor initialization step was the root cause of that.
I'm not 100% sure if calling do_cold_reset or calling die_with_post_code
is the better option here. Calling do_cold_reset likely here would
likely result in a boot-failure loop, so I call die_with_post_code here.
BUG=b:193809448
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ifeadffb3bae749c4bbd7ad2f3f395201e67d9e28
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58859
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Each CPU/SoC checks the return value of the mp_init_with_smm and prints
the same error message if it wasn't successful, so move this check and
printk to mp_init_with_smm. For this the original mp_init_with_smm
function gets renamed to do_mp_init_with_smm and a new mp_init_with_smm
function is created which then calls do_mp_init_with_smm, prints the
error if it didn't return CB_SUCCESS and passes the return value of
do_mp_init_with_smm to its caller.
Since no CPU/SoC code handles a mp_init_with_smm failure apart from
printing a message, also add a comment at the mp_init_with_smm call
sites that the code might want to handle a failure.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I181602723c204f3e43eb43302921adf7a88c81ed
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58498
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Using cb_err as return type clarifies the meaning of the different
return values. This patch also adds the types.h include that provides
the definition of the cb_err enum and checks the return value of
mp_init_with_smm against the enum values instead of either checking if
it's non-zero or less than zero to handle the error case.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ibcd4a9a63cc87fe176ba885ced0f00832587d492
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58491
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Since the MCA(X) registers have defined values on the cold boot path,
the is_warm_reset check can be dropped. Also the warm reset bit in the
NCP_ERR register doesn't behave as the PPR [1] suggested; no matter if
something was written to the register or the machine went through a warm
reset cycle, the NCP_WARM_BOOT bit never got set.
[1] checked with PPR for AMD Family 17h Models 11h,18h B1 (RV,PCO)
#55570 Rev 3.15
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I4e6df98ffd5d15ca204c9847a76c19c753726737
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55059
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Trying to limit the number of available cores by setting the MAX_CPUS
Kconfig option to a lower value than the SoC's default might result in
cores being enabled in the FSP-S, but not fully initialized in coreboot
which will cause some malfunction. Add a static assert to make sure
that this option isn't changed from the default. To limit the maximum
number of cores, use the downcore_mode and disable_smt devicetree
settings instead.
TEST=Build fails if MAX_CPUS isn't the expected default.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I3cfe09f8bb89a2154d37a37398df982828c824f9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52611
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The common code gets moved to soc/amd/common/block/cpu/smm, since it is
related to the CPU cores and soc/amd/common/block/smi is about the SMI/
SCI functionality in the FCH part. Also relocation_handler gets renamed
to smm_relocation_handler to keep it clear what it does, since it got
moved to another compilation unit.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I45224131dfd52247018c5ca19cb37c44062b03eb
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50462
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Stefan thinks they don't add value.
Command used:
sed -i -e '/file is part of /d' $(git grep "file is part of " |egrep ":( */\*.*\*/\$|#|;#|-- | *\* )" | cut -d: -f1 |grep -v crossgcc |grep -v gcov | grep -v /elf.h |grep -v nvramtool)
The exceptions are for:
- crossgcc (patch file)
- gcov (imported from gcc)
- elf.h (imported from GNU's libc)
- nvramtool (more complicated header)
The removed lines are:
- fmt.Fprintln(f, "/* This file is part of the coreboot project. */")
-# This file is part of a set of unofficial pre-commit hooks available
-/* This file is part of coreboot */
-# This file is part of msrtool.
-/* This file is part of msrtool. */
- * This file is part of ncurses, designed to be appended after curses.h.in
-/* This file is part of pgtblgen. */
- * This file is part of the coreboot project.
- /* This file is part of the coreboot project. */
-# This file is part of the coreboot project.
-# This file is part of the coreboot project.
-## This file is part of the coreboot project.
--- This file is part of the coreboot project.
-/* This file is part of the coreboot project */
-/* This file is part of the coreboot project. */
-;## This file is part of the coreboot project.
-# This file is part of the coreboot project. It originated in the
- * This file is part of the coreinfo project.
-## This file is part of the coreinfo project.
- * This file is part of the depthcharge project.
-/* This file is part of the depthcharge project. */
-/* This file is part of the ectool project. */
- * This file is part of the GNU C Library.
- * This file is part of the libpayload project.
-## This file is part of the libpayload project.
-/* This file is part of the Linux kernel. */
-## This file is part of the superiotool project.
-/* This file is part of the superiotool project */
-/* This file is part of uio_usbdebug */
Change-Id: I82d872b3b337388c93d5f5bf704e9ee9e53ab3a9
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41194
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
They're listed in AUTHORS and often incorrect anyway, for example:
- What's a "Copyright $year-present"?
- Which incarnation of Google (Inc, LLC, ...) is the current
copyright holder?
- People sometimes have their editor auto-add themselves to files even
though they only deleted stuff
- Or they let the editor automatically update the copyright year,
because why not?
- Who is the copyright holder "The coreboot project Authors"?
- Or "Generated Code"?
Sidestep all these issues by simply not putting these notices in
individual files, let's list all copyright holders in AUTHORS instead
and use the git history to deal with the rest.
Change-Id: I4c110f60b764c97fab2a29f6f04680196f156da5
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39610
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Remove the mailbox call to notify the PSP that DRAM is ready. This
is not supported on Family 17h.
Remove the selectable SMU firmware. This is a feature of the PSP
bootloader and the standard bootloader doesn't contain the ability.
Clean up additional mentions of PSP within picasso.
Change-Id: I8abeb4c375dbff3b438cd18ccaaf66e11c86e72e
Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33754
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Richard Spiegel <richard.spiegel@silverbackltd.com>
So that everyone can see what's being updated from stoney, we're
starting with a direct copy of the stoney directory. There are
arguments both for and against doing it this way, but I believe
This the most transparent way. We've moved much of the duplicated
stoney code into the soc/amd/common directory and will continue
that work as it becomes obvious that we have unchanged code between
the SOCs.
Makefile.inc has been renamed as makefile.inc so that it won't
build in jenkins until the directory is updated.
Other than that change, this is an exact copy of the stoneyridge
SOC directory which will be updated in the follow-on commits in
the patch train.
TEST=None
BUG=b:130804851
Signed-off-by: Martin Roth <martinroth@chromium.org>
Change-Id: I6809bd1eea304f76dd9000c079b3ed09f94dbd3b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32407
Reviewed-by: Richard Spiegel <richard.spiegel@silverbackltd.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
