Age | Commit message (Collapse) | Author |
|
Rename SPIROM_BASE_ADDRESS_REGISTER to SPI_BASE_ADDRESS_REGISTER to
clarify that this isn't the address the SPI flash gets mapped, but the
address of the SPI controller MMIO region. This also aligns the register
name with the PPR.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ifd9f98bd01b1c7197b80d642a45657c97f708bcd
Reviewed-on: https://review.coreboot.org/c/coreboot/+/62578
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jason Glenesk <jason.glenesk@gmail.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
Shorten define names containing PCI_{DEVICE,VENDOR}_ID_ with
PCI_{DID,VID}_ using the commands below, which also take care of some
spacing issues. An additional clean up of pci_ids.h is done in
CB:61531.
Used commands:
* find -type f -exec sed -i 's/PCI_\([DV]\)\(EVICE\|ENDOR\)_ID_\([_0-9A-Za-z]\{2\}\([_0-9A-Za-z]\{8\}\)*[_0-9A-Za-z]\{0,5\}\)\t/PCI_\1ID_\3\t\t/g'
* find -type f -exec sed -i 's/PCI_\([DV]\)\(EVICE\|ENDOR\)_ID_\([_0-9A-Za-z]*\)/PCI_\1ID_\3/g'
Change-Id: If9027700f53b6d0d3964c26a41a1f9b8f62be178
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39331
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
|
|
Add a comment to point out that the read_resources functions aren't
missing a pci_dev_read_resources call that would add the resources for
the BARs of the PC device.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ie480832e0d7954135d2171dda986e477ef7b6c09
Reviewed-on: https://review.coreboot.org/c/coreboot/+/62547
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
|
|
In the northbridge's and root complex' read_resources function, the
GNB IOAPIC resource used MMIO base address of the GNB IOAPIC as index
which might be misleading. Instead use idx++ as a unique index for this
resource.
TEST=Resource allocator doesn't complain and no related warnings or
errors in dmesg. The update_constraints console output changes like
expected:
Before: PCI: 00:00.0 fec01000 base fec01000 limit fec01fff mem (fixed)
After: PCI: 00:00.0 0d base fec01000 limit fec01fff mem (fixed)
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I8061364879d772469882fc060f92676de6f600a9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/62546
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
|
|
In the northbridge's and root complex' read_resources function, the
mmconf resource used the number of the MMIO_CONF_BASE MSR as index which
might be misleading. Instead use idx++ as a unique index for this
resource.
TEST=Resource allocator doesn't complain and no related warnings or
errors in dmesg. The update_constraints console output changes like
expected:
Before: PCI: 00:00.0 c0010058 base f8000000 limit fbffffff mem (fixed)
After: PCI: 00:00.0 06 base f8000000 limit fbffffff mem (fixed)
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Id66c6153fad86bed36db7bd2455075f4a0850750
Reviewed-on: https://review.coreboot.org/c/coreboot/+/62545
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
|
|
After the patch that moved the generation of the PPKG object to
Stoneyridge's acpi.c, only the PNOT object remained in its cpu.asl, so
rename it to pnot.asl.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I0deb2d75cae98b8fcd31297d7fac5f27525efe65
Reviewed-on: https://review.coreboot.org/c/coreboot/+/62540
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
|
|
Generate the PPKG object in the generate_cpu_entries function instead of
generating the PCNT object that is the used in the PPKG method in
cpu.asl to provide the PPKG object. This both simplifies the code and
aligns Stoneyridge with the other AMD SoCs. This will also make the code
behave correctly in a case where the number of CPU cores/threads isn't a
power of two.
TEST=None, but equivalent change on Picasso was verified to not break
anything on Mandolin.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ib42d718102151a72a5fe812e83eb2eb4f9e7b611
Reviewed-on: https://review.coreboot.org/c/coreboot/+/62539
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
|
|
Both the HPET_BASE_ADDRESS define from arch/x86/include/arch/hpet.h and
the HPET_ADDRESS Kconfig option define the base address of the HPET MMIO
region which is 0xfed00000 on all chipsets and SoCs in the coreboot
tree. Since these two different constants are used in different places
that however might end up used in the same coreboot build, drop the
Kconfig option and use the definition from arch/x86 instead. Since it's
no longer needed to check for a mismatch of those two constants, the
corresponding checks are dropped too.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ia797bb8ac150ae75807cb3bd1f9db5b25dfca35e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/62307
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Lance Zhao
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
All x86 chipsets and SoCs have the HPET MMIO base address at 0xfed00000,
so define this once in arch/x86 and include this wherever needed. The
old AMD AGESA code in vendorcode that has its own definition is left
unchanged, but sb/amd/cimx/sb800/cfg.c is changed to use the new common
definition.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ifc624051cc6c0f125fa154e826cfbeaf41b4de83
Reviewed-on: https://review.coreboot.org/c/coreboot/+/62304
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
When "fadt->FADT_MinorVersion" is not explicitly set to the right value, gcc sets it up to "0".
So set it correctly for treewide.
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Change-Id: Ic9a8e097f78622cd78ba432e3b1141b142485b9a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/62221
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jason Glenesk <jason.glenesk@gmail.com>
Reviewed-by: Lance Zhao
|
|
The AMD SoCs had a check to make sure that HPET_ADDRESS_OVERRIDE isn't
set so that the HPET_ADDRESS Kconfig option will have the right default
value. Instead check if the HPET_ADDRESS Kconfig value matches the
HPET_BASE_ADDRESS define in the SoC code which is the case if
HPET_ADDRESS_OVERRIDE isn't selected.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Icf1832eb36c031e93ba24f342e9a8a7bf13faecc
Reviewed-on: https://review.coreboot.org/c/coreboot/+/62275
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: I8b209da90b5a591f62e760961c64c4c63e6ef65b
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/62040
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jason Glenesk <jason.glenesk@gmail.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
Change-Id: I6a0e9b33c6a1045a3a4a6717487525b82d41e558
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/62036
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lance Zhao
|
|
Now that the console system itself will clearly differentiate loglevels,
it is no longer necessary to explicitly add "ERROR: " in front of every
BIOS_ERR message to help it stand out more (and allow automated tooling
to grep for it). Removing all these extra .rodata characters should save
us a nice little amount of binary size.
This patch was created by running
find src/ -type f -exec perl -0777 -pi -e 's/printk\(\s*BIOS_ERR,\s*"ERROR: /printk\(BIOS_ERR, "/gi' '{}' ';'
and doing some cursory review/cleanup on the result. Then doing the same
thing for BIOS_WARN with
's/printk\(\s*BIOS_WARNING,\s*"WARN(ING)?: /printk\(BIOS_WARNING, "/gi'
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I3d0573acb23d2df53db6813cb1a5fc31b5357db8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61309
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Reviewed-by: Lance Zhao
Reviewed-by: Jason Glenesk <jason.glenesk@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>
|
|
Since we need the GPIO defines in the devicetree settings, include
gpio.h in each SoC's chip.h file which will indirectly include the
soc-specific soc/gpio.h header instead of having it indirectly included
via soc/i2c.h.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Id26721a6b8ae94784d4a90d7ccac28fef2be36dd
Reviewed-on: https://review.coreboot.org/c/coreboot/+/60977
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
|
|
Found using:
diff <(git grep -l '#include <console/console.h>' -- src/) <(git grep -l 'console_time_report\|console_time_get_and_reset\|do_putchar\|vprintk\|printk\|console_log_level\|console_init\|get_log_level\|CONSOLE_ENABLE\|get_console_loglevel\|die_notify\|die_with_post_code\|die\|arch_post_code\|mainboard_post\|post_code\|RAM_SPEW\|RAM_DEBUG\|BIOS_EMERG\|BIOS_ALERT\|BIOS_CRIT\|BIOS_ERR\|BIOS_WARNING\|BIOS_NOTICE\|BIOS_INFO\|BIOS_DEBUG\|BIOS_SPEW\|BIOS_NEVER' -- src/) |grep "<"
Change-Id: Iff7fdd679ac31a121d56746ed8efa1b3da932638
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/60924
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
Change-Id: Ibd3e7a62a2e833017f550eddd915b7dfb539d019
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/60558
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
The AOAC device states shouldn't be stored in GNVS, but be read from the
AOAC registers during runtime. Same for the EHCI controller's BAR0. The
location and size of the XHCI firmware can either be statically
determined at build-time or have coreboot generate ACPI objects that
contain the needed addresses. Since I can't easily test changes that
require booting to a desktop on Stoneyridge at the moment, only add
TODOs for now.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Suggested-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Change-Id: I3691b05606b9430cb60923780a6131993a9887d4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/60196
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
|
|
Split the southbridge code into a bootblock and a ramstage part to align
it more with Picasso and Cezanne. Also move the implementation of
fch_clk_output_48Mhz to the end of early_fch.c since it's not really
related to the functions that were previously around it.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ib660fbef8dc25ba0fab803ccd82b3408878d1588
Reviewed-on: https://review.coreboot.org/c/coreboot/+/60142
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
|
|
Split the code that gets called from the AGESA wrapper from the rest of
the FCH/southbridge code that directly interacts with the hardware.
Since the remaining parts of southbridge.c aren't used in romstage,
drop it from the list of build targets for romstage.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I6197add0e1396a82545735653110e1e17bf9c303
Reviewed-on: https://review.coreboot.org/c/coreboot/+/60141
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
|
|
Factor out enable_aoac_devices out of southbridge.c to aoac.c to align
Stoneyridge more with Picasso and Cezanne.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ied4d821138507639cad1794f6c5017b5873b761f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/60140
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
|
|
We shouldn't be providing -I include paths to the root of the soc
specific directory. It allows for lazy includes that can collide,
but there's no way of knowing the winning path since the winning
path is determined by Makefile.inc parsing order.
This is taken from CB:41355
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I45ed219e4e0cccf3d4f04cc70dc1ef77c518afff
Reviewed-on: https://review.coreboot.org/c/coreboot/+/60201
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I9b37efc89e505c2de99536b59e7d7e2bb1d54bff
Reviewed-on: https://review.coreboot.org/c/coreboot/+/60199
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
All SPI interface setup related functionality that Stoneyridge
implemented in its southbridge code is already present in the common AMD
SoC code, so use that code instead.
The common fch_spi_early_init function requires the SPI controller's
base address to be set, so call lpc_set_spibase(SPI_BASE_ADDRESS) right
before it. fch_spi_early_init then calls lpc_enable_spi_rom and
lpc_enable_spi_prefetch which can be removed from the board code now.
Next it calls fch_spi_configure_4dw_burst which does the same as the now
removed sb_disable_4dw_burst function when
SOC_AMD_COMMON_BLOCK_SPI_4DW_BURST is set to n which is the default.
This option can also only be set to y for SoCs that aren't Stoneyridge.
Finally fch_spi_early_init calls fch_spi_config_modes which configures
the SPI mode and speed settings according to the Kconfig settings and
the settings in the amdfw part. On Kahlee this was done by calls to
sb_read_mode and sb_set_spi100 before. The previous patch added the
remaining Kconfig settings, so the resulting register values don't
change in the non-EM100 case. In the EM100 case the TPM speed is changed
from 64 to 16 MHz.
TEST=Both the non-EM100 mode with a real SPI flash and the EM100 mode
with a first-generation EM100 results in Google/Barla reaching the
payload and the show_spi_speeds_and_modes call in bootblock prints the
expected settings:
relevant bootblock console output in non-EM100 case:
SPI normal read speed: 33.33 MHz
SPI fast read speed: 66.66 Mhz
SPI alt read speed: 66.66 Mhz
SPI TPM read speed: 66.66 Mhz
SPI100: Enabled
SPI Read Mode: Dual IO (1-2-2)
relevant bootblock console output in EM100 case:
SPI normal read speed: 16.66 MHz
SPI fast read speed: 16.66 MHz
SPI alt read speed: 16.66 MHz
SPI TPM read speed: 16.66 MHz
SPI100: Enabled
SPI Read Mode: Normal Read (up to 33M)
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I8f37a3b040808d6a5a8e07d39b6d4a1e1981355c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59968
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
|
|
According to https://uefi.org/specs/ACPI/6.4/04_ACPI_Hardware_Specification/ACPI_Hardware_Specification.html#pm1-event-grouping
> For ACPI/legacy systems, when transitioning from the legacy to the G0
> working state this register is cleared by platform firmware prior to
> setting the SCI_EN bit (and thus passing control to OSPM). For ACPI
> only platforms (where SCI_EN is always set), when transitioning from
> either the mechanical off (G3) or soft-off state to the G0 working
> state this register is cleared prior to entering the G0 working state.
This means we don't want to clear the PM1 register on resume. By
clearing it the linux kernel can't correctly increment the wake count
when the power button is pressed. The AMD platforms implement the _SWS
ACPI methods, but the linux kernel doesn't actually use these methods.
BUG=b:172021431
TEST=suspend zork and push power button and verify power button
wake_count increments. Verified other wake sources still work.
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: Iaa886540d90f4751d14837c1485ef50ceca48561
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59929
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
Stoneyridge selects ARCH_X86 unconditionally and all coreboot code will
run on the x86 cores. On Picasso and later, the Chromebooks run verstage
on the PSP which is an ARM V7 core which needs some special handling
cases in the code, but this doesn't apply to Stoneyridge.
TEST=Timeless build results in an identical image for Google/Careena.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I013efd13b56c0191af034a8c4b58e9b26a31c6e9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59960
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
|
|
According to https://uefi.org/specs/ACPI/6.4/16_Waking_and_Sleeping/sleeping-states.html?highlight=power%20states#
> For ACPI/legacy systems, when transitioning from the legacy to the G0
> working state this register is cleared by platform firmware prior to
> setting the SCI_EN bit.
This change makes sure we clear the PM/GPE blocks are cleared before
enabling the SCI_EN bit.
BUG=b:172021431
TEST=Boot guybrush and morphius to OS and verify suspend resume still
works.
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: Icc6f542185dc520f8d181423961b74481c0b5506
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59928
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
Use a read modify write sequence when setting the SPI_USE_SPI100 bit in
the SPI100_ENABLE register. This avoids clearing other bits in the
register which might cause instabilities of the SPI interface. The
reference code for Stoneyrige also only sets the SPI_USE_SPI100 bit and
doesn't zero out the other bits.
TEST=None
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I4d32fc2084bb34ea57924bae68511c6836587790
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59933
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
|
|
Despite Stoneyridge being one only SoC in soc/amd that uses the first
generation of the PSP mailblox interface, this code is common for all
SoCs that use the first PSP mailbox interface generation, so move it to
the common PSP generation 1 code.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I78126cb710a6ee674b58b35c8294685a5965ecd6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59701
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
PSP_MAILBOX_BAR is defined as PCI_BASE_ADDRESS_4, so use it instead of
PCI_BASE_ADDRESS_4 in the code.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I8658b674b9adea85dfc71d7036ccf3ae17464b58
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59700
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
|
|
Stoneyridge uses the same GPIO bank peripheral as Picasso and Cezanne so
we can use the common AMD SoC GPIO ACPI code.
TEST=none
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ifa1fc923cd5b779765917b171b5a7222f18a176a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59596
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
|
|
Cezanne already uses a define for this and it's better to define and use
constants instead of magic values.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ifa4b3b3cdb161670128b284a3396fc5a85545608
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59586
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
|
|
Related to https://review.coreboot.org/c/coreboot/+/58555
commit-id: 35b7e0a2d82ac
In 58555, we added the SOC ID for Stoneyridge in amdfwtool
command line. But it raised building error because it then called
"set_efs_table" without setting SPI mode. So we skipped calling that.
But in set_efs_table, it has case for Stoneyridge. The boards also
need to have this setting. So we remove the skipping and give the
proper SPI mode in mainboard Kconfig.
Change-Id: I24499ff6daf7878b12b6044496f53379116c598f
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58871
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
For the stoneyridge, soc_name is not set in Makefile, so set_efs_table
is not called. Keep it unchanged.
Change-Id: I0e82188ce64733420a578446e22a077ef789be92
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58555
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
None of the *_DEVID defines was used in the code, so drop those. The SoC
code uses the PCI ID defines from include/device/pci_ids.h instead.
Since it might still be useful to have the PCI device IDs as a reference
in the SoC's pci_devs.h, add those as comments instead.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I7c77d648dac57b15b56f631bd8b2494676c00a8b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59268
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
|
|
Currently, the MMCONF Kconfigs only support the Enhanced Configuration
Access mechanism (ECAM) method for accessing the PCI config address
space. Some platforms have a different way of mapping the PCI config
space to memory. This patch renames the following configs to
make it clear that these configs are ECAM-specific:
- NO_MMCONF_SUPPORT --> NO_ECAM_MMCONF_SUPPORT
- MMCONF_SUPPORT --> ECAM_MMCONF_SUPPORT
- MMCONF_BASE_ADDRESS --> ECAM_MMCONF_BASE_ADDRESS
- MMCONF_BUS_NUMBER --> ECAM_MMCONF_BUS_NUMBER
- MMCONF_LENGTH --> ECAM_MMCONF_LENGTH
Please refer to CB:57861 "Proposed coreboot Changes" for more
details.
BUG=b:181098581
BRANCH=None
TEST=./util/abuild/abuild -p none -t GOOGLE_KOHAKU -x -a -c max
Make sure Jenkins verifies that builds on other boards
Change-Id: I1e196a1ed52d131a71f00cba1d93a23e54aca3e2
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57333
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
|
|
Since all other defines for the number of certain things are at the top
of the file, move NUMBER_SMITYPES there as well to keep things
consistent.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Idfb599531d6cc382ab258bd1eae89e7b35fa9e79
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58953
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
|
|
SCIMAPS is the total number of SCI to GEVENT mappings. configure_scimap
returns early when the scimap is greater or equal than SCIMAPS, so for
SMITYPE_ACDC_TIMER it returned early without doing what was expected
from it to do despite that being a valid value, so fix this off-by-one.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ibaf8c5618ddbf0b8d4cd612a7f1347d8562bbfcb
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58952
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
|
|
BUG=b:140165023
Change-Id: Ieedd6c9f3abeed9839892e5d07127862cd47d57f
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58771
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
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>
|
|
The comments are not correct anymore. With AGESA there is no need to
synchronize TOM_MEMx msr's between AP's. It's also not the best place
to do so anyway.
Change-Id: Iecbe1553035680b7c3780338070b852606d74d15
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58693
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
Change-Id: I88f62c18b814ac0ddd356944359e727d6e3bba5a
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58688
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Mariusz Szafrański <mariuszx.szafranski@intel.com>
|
|
The line length is no longer limited to 80 characters, so there's no
need for that line break any more.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I7a8fb472f00e039f25a71ee526a3dd0bc6c754f6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58858
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
|
|
With using a Kconfig option to add the x86 LAPIC support code to the
build, there's no need for adding the corresponding directory to subdirs
in the CPU/SoC Makefile. Comparing which CPU/SoC Makefiles added
(cpu/)x86/mtrr and (cpu/)x86/lapic before this and the corresponding
MTRR code selection patch and having verified that all platforms
added the MTRR code on that patch shows that soc/example/min86 and
soc/intel/quark are the only platforms that don't end up selecting the
LAPIC code. So for now the default value of CPU_X86_LAPIC is chosen as y
which gets overridden to n in the Kconfig of the two SoCs mentioned
above.
Change-Id: I6f683ea7ba92c91117017ebc6ad063ec54902b0a
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44228
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
|
|
No SoC uses the ramstage-only x86_enable_cache helper function to call
enable_cache with some added port 0x80 and console output.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Suggested-by: Angel Pons <th3fanbus@gmail.com>
Change-Id: I7c5039e1341fd4089078ad7ffb2fe6584a94045c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58547
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
|
|
Since cpu/x86/Makefile.inc already adds the pae sub-directory, there is
no need to include it in the Makefile of a CPU or SoC, so remove it from
those Makefiles.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I78368f7eb880fb64f511a2fa8c8acde222d0dca3
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58546
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
All x86-based CPUs and SoCs in the coreboot tree end up including the
Makefile in cpu/x86/mtrr, so include this directly in the Makefile in
cpu/x86 to add it for all x86 CPUs/SoCs. In the unlikely case that a new
x86 CPU/SoC will be added, a CPU_X86_MTRR Kconfig option that is
selected be default could be added and the new CPU/SoC without MTRR
support can override this option that then will be used in the Makefile
to guard adding the Makefile from the cpu/x86/mtrr sub-directory.
In cpu/intel all models except model 2065X and 206AX are selcted by a
socket and rely on the socket's Makefile.inc to add x86/mtrr to the
subdirs, so those models don't add x86/mtrr themselves. The Intel
Broadwell SoC selects CPU_INTEL_HASWELL and which added x86/mtrr to the
subdirs. The Intel Xeon SP SoC directory contains two sub-folders for
different versions or generations which both add x86/mtrr to the subdirs
in their Makefiles.
Change-Id: I743eaac99a85a5c712241ba48a320243c5a51f76
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44230
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
|
|
For coreboot proper, I/O APIC programming is not really required,
except for the APIC ID field. We generally do not guard the related
set_ioapic_id() or setup_ioapic() calls with CONFIG(IOAPIC).
In practice it's something one cannot leave unselected, but maintain
the Kconfig for the time being.
Change-Id: I6e83efafcf6e81d1dfd433fab1e89024d984cc1f
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55291
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
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>
|
|
Picasso and Cezanne define and use APU_I2C[01234]_BASE for the base
addresses of the I2C controllers, so align Stoneyridge with this. The
ACPI device names aren't changed from I2C[ABCD] to I2C[0123] for now
since this might change behavior in the OS and would also change the
resulting binary of a timeless build.
TEST=Timeless build results in identical image for Google/Treeya.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I9c400c073eba5c14bd35703b717f75df89a8719d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58370
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Now that the I2C[ABCD]_BASE_ADDRESS defines aren't macros that calculate
the MMIO addresses any more, those defines can also be used in the ACPI
code.
TEST=Timeless build results in identical image for Google/Treeya.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I7de2f83dc2f8061d8f1735caf10314bcddb2d3fa
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58337
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
|
|
The I2C_BUS_ADDRESS(x) macro isn't used to iterate over the I2C
controller base addresses, so drop this and use the fixed MMIO address
for the I2C[ABCD]_BASE_ADDRESS defines instead which also allows using
those defines in the ACPI code.
TEST=Timeless build results in identical image for Google/Treeya.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Idd7484a0322dc5167cbb7fdcd9a2583f0dbed50e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58336
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
|
|
Before this patch the reservation of the MMIO region of the I2C
controllers was done in the LPC controller PCI device despite the I2C
controllers already being devices in the devicetree. This patch
implements this functionality as read_resources function of the I2C
device instead. This will only reserve the memory when the I2C devices
are enabled in devicetree which is a change from the previous behavior.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I67c853df3be2f593ecfa113ae2f74e5df7cf74e0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58307
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Since the GPIO mux/control MMIO regions are within the ACPIMMIO region,
we need to call enable_acpimmio_decode_pm04 here first so that accessing
the GPIO registers will work.
BUG=None
TEST=Build and boot to OS in Guybrush.
Change-Id: I4bc076261c72cf999a5f2464b74cff6bf694d473
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57782
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
|
|
These issues were found and fixed by codespell, a useful tool for
finding spelling errors.
Signed-off-by: Martin Roth <martin@coreboot.org>
Change-Id: Ieafbc93e49fcef198ac6e31fc8a3b708c395e08e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58082
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Since the binaryPI glue code is specific to a binary interface, but not
for a hardware block, move it out of the common blocks directory. This
also brings the binaryPI support in line with the FSP support which is
used on the newer generations. This also drops the
SOC_AMD_COMMON_BLOCK_PI Kconfig option and makes use of the already
existing SOC_AMD_PI Kconfig option instead.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I014e538f2772938031950475e456cc40dd05d74c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57884
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
|
|
The code in soc/amd/common/block/s3 is specific to the AMD binaryPI
coreboot integration, so move the code to soc/amd/common/block/pi. This
drops the SOC_AMD_COMMON_BLOCK_S3 Kconfig option and integrates the
dependencies and selections into the SOC_AMD_COMMON_BLOCK_PI Kconfig
option. Since only selecting SOC_AMD_COMMON_BLOCK_PI but not
SOC_AMD_COMMON_BLOCK_S3 resulted in missing functions in the linking
process, we don't lose support for any working configuration by only
having one Kconfig option for both parts.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ib2bd99a88d8b05216688bc45d9c4f23a007ce870
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57883
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
|
|
This brings the AMD SoC GPIO code in line with the Intel SoC code and
removes the not really needed suffix.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ie2dbec81dfe503869beb2872b01a7475e2b88b33
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57842
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
|
|
Add and use the I2C_RESET_SCL_PIN macro for populating the i2c_scl_pins
array that is used for the sb_reset_i2c_peripherals call to bring the
I2C buses into a defined state.
TEST=Timeless build results in identical image for Mandolin.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Suggested-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: Ifedc09d0bf745545fa0510df7d5037f02b9012a6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57479
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
|
|
The code under `cpu/x86/tsc` is only compiled in when its `Makefile.inc`
is included from platform (CPU/SoC) code and the `UDELAY_TSC` Kconfig
option is enabled.
Include `cpu/x86/tsc/Makefile.inc` once from `cpu/x86/Makefile.inc` and
drop the now-redundant inclusions from platform code. Also, deduplicate
the `UDELAY_TSC` guards.
Change-Id: I41e96026f37f19de954fd5985b92a08cb97876c1
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57456
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
drive_scl in soc/amd/common/block/i2c/i2c.c writes the raw GPIO MMIO
configuration register and drives it as output, so don't initially
configure the GPIO as input with no pull up/down. This is a preparation
to use the common AMD GPIO access functions instead of the raw register
accesses, since the gpio_set function only sets the output value, but
doesn't reconfigure the direction. Using gpio_output there instead would
reconfigure the direction as well, but would result in doubling the
number of MMIO accesses, so just configure the GPIOs correctly right
away to avoid that.
TEST=The waveform on the SCL pin of I2C3 on a barla/careena Chromebook
looks exactly the same as before during the reset_i2c_peripherals call.
This was probed at the SCL pad of the unpopulated I2C level shifter on
the side that is connected to the SoC.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I8e94afe0c755a02abcc722d5094e220d8781f8f5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56807
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Specify the type of the `DIMM_SPD_SIZE` Kconfig symbol once.
Change-Id: I619833dbce6d2dbe414ed9b37f43196b4b52730e
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57257
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
commit de7262f82cdc1a7c868dbc9ca41e186e885eb2ba (soc/amd: remove special
GPIO_2 override soc_gpio_hook) removed the workaround that needed those
definitions, so remove the now unused GPIO_2_EVENT definitions.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I3f3e3061eade0e0cd25e2263451ccf6cefdc4ea4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56812
Reviewed-by: Jason Glenesk <jason.glenesk@gmail.com>
Reviewed-by: Martin Roth <martinroth@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
BUG=b:194919326
TEST=See SPI settings in bootblock
Signed-off-by: Martin Roth <martinroth@chromium.org>
Change-Id: I8ee8981986990240b09414cde8b84d9b109cb5b2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56961
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
|
|
Change-Id: I916f19e022633b316fbc0c6bf38bbd58228412be
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56218
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lance Zhao
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
The biosram accessor support in soc/amd/common/block/acpimmio/biosram.c
is only used on Stoneyridge and the old amd/southbridge code and not on
Picasso or Cezanne. It also only builds as a 32 bit binary and breaks
when trying to build as a 64 bit binary, since the size of an uintptr_t
is different on those two. There is no support for using the 32 bit
binaryPI with a 64 bit coreboot while there is code to use a 32 bit FSP
with 64 bit coreboot, so not building this for FSP-based SoC support
moves us one step closer to be able to build coreboot as 64 bit binary
for Picasso and Cezanne.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I2d87ec2fa1b217eaf55d865e4390308812502e56
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56570
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
|
|
Stoneyridge has an integrated FCH and no south bridge, so change the sb
prefix to fch.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I5154ae1158f864d4a2aca55e6bcce6a742c6afe1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56527
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This aligns the mca_check_all_banks implementation in the common mca.c
with the one in the common mcax.c file. Do the MCA bank count check
before the !is_warm_reset() check, so that a mismatch also gets printed
on the cold boot path.
Change-Id: Idbd3e9ce9c7483f84f87adab7adac47335cd59aa
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56311
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
For Cezanne stubs are added for the functions that the SoC-specific code
needs to provide. Since the mca_is_valid_bank stub on Cezanne always
returns false, the checks get skipped for it at the moment. The actual
functionality will be added in a later patch.
Change-Id: Ic31e9b1ca7f8fac0721c95935c79150d7f774aa4
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56290
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Change-Id: I960a2f384f11e4aa5aa2eb0645b6046f9f2f8847
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56283
Reviewed-by: Martin Roth <martinroth@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: I139d1fe41bad5213da8890c2867f275b6847e3e1
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56281
Reviewed-by: Martin Roth <martinroth@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: Ia489dbfba59c334cf29f96a4000cef73b9b797d4
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56279
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This patch changes the way how the not implemented MCA bank 3 gets
skipped. For the not implemented bank 3 the name gets set to NULL
resulting in mca_is_valid_bank returning false causing the bank to get
skipped. This is a preparation for commonizing the MCA(X) handing in the
soc/amd sub-tree.
Change-Id: I40d6a6752504d804c45b445fce7e763e80161211
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56277
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Change-Id: Id640fd8006c47ce1db8a8729407c1c9a9c1e79c3
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56272
Reviewed-by: Martin Roth <martinroth@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: Ifbcad4d81fb9f6c359a870be73b05ed86441e7f0
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56271
Reviewed-by: Martin Roth <martinroth@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Add this macro to be able to conveniently access the MC_CTL_MASK
register for each MCA bank. Also drop the unused definitions for
MC1_CTL_MASK and MC4_CTL_MASK.
Change-Id: I23ce1eac2ffce35a2b45387ee86aa77b52da5494
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56261
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
|
|
This MSR isn't an architectural MSR, so it shouldn't be in the common
x86 MSR definition header file. From family 17h on this register has
moved to a different location.
Change-Id: Id11d942876da217034e6f912b1058f00bd15c22c
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56246
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
|
|
Change-Id: I53413b4051b79d7c2f24b1191ce877155e654400
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56259
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
When accessing the MCA MSRs, the MCA bank number gets multiplied by 4
and added to the IA32_MC0_* define to get the MSR number. Add a macro
that already does this calculation to avoid open coding this repeatedly.
Change-Id: I2de753b8c8ac8dcff5a94d5bba43aa13bbf94b99
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56243
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: Id0cf8269d1b695e05c55f33af92978b8244090fa
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56242
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: I5496fd27f5c56d35ab95a5e02ea313b5b5536668
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56241
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: Id7a716a2598a6a7bea2d2d56898ea6329b5a3bec
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56240
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: I7cd05a389c34c2e5f3d0ab4cd06d60a7e3e5cad9
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56239
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: Ib31075fd615eaa8492ce0179b3b21317554f1c80
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56238
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Only the fields bank and sts from the mca_bank struct were used outside
a local scope, so remove the rest. Also rename the struct that now only
contains the bank number and the status MSR content to mca_bank_status.
Change-Id: I925347dff950ac2bd021635ca988c02fba48df7f
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56237
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: I23aa4d36d4e6d4c7ed66800c2e7963c4ed03c393
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56236
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Those registers are architectural MSR and this also gets them in line
with IA32_MC0_CTL and IA32_MC0_STATUS. Also move them below the
definitions for IA32_MC0_STATUS, so that the numbers of the MSRs are
ascending.
Change-Id: Icef6526c896720248f5b648ddf1a271bdf46917c
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56235
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Since initial_lapicid() returns an unsigned int, change the type of the
local variables the return value gets assigned to to unsigned int as
well if applicable. Also change the printk format strings for printing
the variable's contents to %u where it was %d before.
Change-Id: I289015b81b2a9d915c4cab9b0544fc19b85df7a3
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55063
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Use the common mca_get_bank_count function instead of open-coding the
functionality to get the MCA bank number. Also re-type the num_banks
variable from signed in to unsigned int, since the number of MCA bank is
always positive.
Change-Id: I126767cf9ad468cab6d6537dd73e9b2dc377b5c4
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56185
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
|
|
Change-Id: Ib74ff1d585f8ef54960e6a1eafd5a280907f8675
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56180
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Introduce the `ARCH_ALL_STAGES_X86` Kconfig symbol to automatically
select the per-stage arch options. Subsequent commits will leverage
this to allow choosing between 32-bit and 64-bit coreboot where all
stages are x86. AMD Picasso and AMD Cezanne are the only exceptions
to this rule: they disable `ARCH_ALL_STAGES_X86` and explicitly set
the per-stage arch options accordingly.
Change-Id: Ia2ddbae8c0dfb5301352d725032f6ebd370428c9
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55759
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
|
|
To generalise the choice of 32-bit or 64-bit coreboot on x86 hardware,
have platforms select `ARCH_X86` directly instead of through per-stage
Kconfig options, effectively reversing the dependency order.
Change-Id: If15436817ba664398055e9efc6c7c656de3bf3e4
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55758
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
|
|
Using existing defines instead of magic values improves readability of
the code. Also add comments to the MADT IRQ overrides to make it clearer
what those actually do.
TEST=Timeless build results in identical binary for amd/gardenia
(Stoneyridge), amd/mandolin (Picasso) and amd/majolica (Cezanne)
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I224ffbe8eb65bcdd5fc70c0ff8b15d55b3f6be01
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55613
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Factoring out those defines brings the Stoneyridge SoC code a bit more
in line with the Cezanne and Picasso SoC code.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ifba7f13cc926ac28376233aa0bf317164ca9bbd6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55588
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
On Linux, in order to set wake alarms >24 hours, the RTC Date Alarm
field must be set to a valid non-zero value. If not, there are two
consequences:
1. Alarms >24 hours don't work
2. The kernel will refuse to enter suspend because it can't resume as
expected to service the alarm.
Since the RTC Date Alarm and RTC AltCentury fields are supported on
Stoneyridge, set them.
This is a mirror of commit 041fcf5902
("soc/amd/picasso/acpi: Set missing RTC offsets") for picasso.
BUG=b:187516317
TEST=On a Chrome OS 'grunt' device, run
`time powerd_dbus_suspend --suspend_for_sec=172800`
and verify the system suspended and woke up after 48 hours
BRANCH=grunt
Signed-off-by: Anand K Mistry <amistry@google.com>
Change-Id: I10831b982662e680fa71aa81d02935e1b7e7a7a1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55001
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
|
|
Note that there are assumptions about LAPIC MMIO location
in both AMD and Intel sources in coreboot proper.
Change-Id: I2c668f5f9b93d170351c00d77d003c230900e0b4
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55194
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This also adds BERT table gerenation support for Cezanne, but since the
functionality to populate the BERT memory region isn't implemented yet,
this won't result in a BERT table being generated on Cezanne, since
bert_generate_ssdt will always return false there.
TEST=BERT ACPI table generation still works on AMD/Mandolin
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I69b4a9a7432041e1f4902436fa4e6dee5332dbd2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55056
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
|
|
Implement acpi_soc_get_bert_region so that the common ACPI code will
generate a BERT ACPI table that points to the BERT memory region instead
of generating the BERT table in the SoC=specific code.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I86d4f5ef74d4d40cb93ac4a3feaf28b99022ebd5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55055
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
|