The printed address ranges in the tree (resource allocator and even
some MTRR code) usually shows the range inclusive (meaning from start
address to the real end address of the range). Though there is still
some code in the MTRR context which prints the ranges with an exclusive
end. This patch aligns the printing of ranges in the MTRR code to be
consistent among the tree so that the shown end addresses are now
inclusive.
Change-Id: I0ca292f9cf272564cb5ef1c4ea38f5c483605c94
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63541
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
This patch aims to make timestamps more consistent in naming,
to follow one pattern. Until now there were many naming patterns:
- TS_START_*/TS_END_*
- TS_BEFORE_*/TS_AFTER_*
- TS_*_START/TS_*_END
This change also aims to indicate, that these timestamps can be used
to create time-ranges, e.g. from TS_BOOTBLOCK_START to TS_BOOTBLOCK_END.
Signed-off-by: Jakub Czapiga <jacz@semihalf.com>
Change-Id: I533e32392224d9b67c37e6a67987b09bf1cf51c6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/62019
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
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>
Some Intel southbridges have HPET_MIN_TICKS in their Kconfig files, but
the CONFIG_HPET_MIN_TICKS symbol is used in the common acpi code in
acpi/acpi.c, so define this option in arch/x86/Kconfig to have it
defined in all cases where the function that ends up using this
information gets called. Since we now have the type information for this
Kconfig option in a central place, it can be dropped from the Kconfig
file of the Intel southbridges that change the default value.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ibe012069dd4b51c15a8fbc6459186ad2ea405a03
Reviewed-on: https://review.coreboot.org/c/coreboot/+/62298
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Commit b433d26ef1 (arch/x86: Define
HPET_ADDRESS_OVERRIDE) added this Kconfig option and referenced the
via/cx700 chipset which has been dropped before the 4.9 release. No SoC
in the current tree selects HPET_ADDRESS_OVERRIDE and all SoCs have
their HPET mapped at 0xfed00000, so drop this unused and no longer
needed Kconfig option.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I4021ed6f84473c7a9223323fc8aa5d3f935d8084
Reviewed-on: https://review.coreboot.org/c/coreboot/+/62276
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Commit 0e688b113d (arch/x86/id.S: Fix
building with clang) broke building with GCC 8.3 so this approach
should work for both GCC 8.3 and clang. The clang error is:
CC bootblock/arch/x86/id.o
/tmp/id-35b17a.s:35:7: error: expected relocatable expression
.long - ver
^
/tmp/id-35b17a.s:36:7: error: expected relocatable expression
.long - vendor
^
/tmp/id-35b17a.s:37:7: error: expected relocatable expression
.long - part
^
Change-Id: Ide3d313800641d4d9b5f79127f84d9fdb4ec2b96
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61927
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
This reverts commit 0e688b113d.
Reason for revert: Breaks building with GCC 8.3 which is currently
needed to build bootable coreboot images for Ironlake boards:
src/arch/x86/id.S: Assembler messages:
src/arch/x86/id.S:14: Error: value of 4294967344 too large for field of 4 bytes at 48
src/arch/x86/id.S:15: Error: value of 4294967327 too large for field of 4 bytes at 52
src/arch/x86/id.S:16: Error: value of 4294967318 too large for field of 4 bytes at 56
Change-Id: I9e13b15c062bc6598717382b1fedfa120c6d7209
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61926
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
The following error message is now gone:
CC bootblock/arch/x86/id.o
/tmp/id-35b17a.s:35:7: error: expected relocatable expression
.long - ver
^
/tmp/id-35b17a.s:36:7: error: expected relocatable expression
.long - vendor
^
/tmp/id-35b17a.s:37:7: error: expected relocatable expression
.long - part
^
Tested with BUILD_TIMELESS=1 on x86_32 with gcc. The binary stays the
same.
Change-Id: I930e7b96c4428bcb95ff1903e6a3e7679171ffee
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51500
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
"hb-mode" is a -machine flag for QEMU. "hb" stands for Hostboot, which
is OpenPower firmware created by IBM.
QEMU for PPC64 can run initial program in two different modes:
* hb-mode=off with load address 0x00000000
* hb-mode=on with load address 0x08000000
Real hardware always loads firmware at 0x08000000 and coreboot shouldn't
require a special build to be run on QEMU.
Memory layout is updated to reflect change of load address.
Change-Id: I1bdc97a095bd46fccc862985b3bd24f4fa5bc054
Signed-off-by: Yaroslav Kurlaev <yaroslav.kurlaev@3mdeb.com>
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57082
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com>
BSS is loaded as part of the bootblock, it is zeroed in the file so it
doesn't have to be cleared explicitly by the code.
Code for clearing is left as a comment along with a warning about alignment
requirements.
Vector operations are sometimes generated for code such as
'uint8_t x[32] = {0}', this results in an exception when vector registers
(VR) are not enabled. VSR (vector-scalar register) operations are also
enabled, there is no reason not to.
Change-Id: I878ef61619eb4a191805c8911d001312a0d717a0
Signed-off-by: Krystian Hebel <krystian.hebel@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57076
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com>
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>
Each time the spinlock is acquired a byte is decreased and then the
sign of the byte is checked. If there are more than 128 cores the sign
check will overflow. An easy fix is to increase the word size of the
spinlock acquiring and releasing.
TEST: See that serialized SMM relocation is still serialized on
systems with >128 cores.
Change-Id: I76afaa60669335090743d99381280e74aa9fb5b1
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/60539
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
According to util/kbc1126/README.md, for these ECs to work, the
address and size of their two firmware should be written to $s-0x100`
(`$s` means the image size, done with kbc1126_ec_insert), which means
that every existing section (especially those used to store code)
should not overlap this address, otherwise the bootblock will get
damaged when inserting firmwares of the EC.
In this commit, ecfw_ptr is a structure initialized at build time
according to CONFIG_KBC1126_FW1_OFFSET and CONFIG_KBC1126_FW2_OFFSET
(to do so, they should be redefined as hex), and linked to
CONFIG_ECFW_PTR_ADDR within bootblock, so kbc1126_ec_insert is not
needed at build time any more.
Test passed on Elitebook Folio 9470m.
Signed-off-by: Bill XIE <persmule@hardenedlinux.org>
Change-Id: I4f0de0c4d7283e630242fbe84a46e0547783c49e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51671
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
The commit d023909b "treewide: Disable R_AMD64_32S relocation support"
clflush the address stored in _cbmem_top_ptr, which is the same address
cbmem_top() returns, instead of clflush _cbmem_top_ptr itself.
Fix that by providing the correct address to clflush.
Change-Id: If74591e7753cd9c3c097516430a212d416f53e4d
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59871
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
CONFIG(SMP) was an invalid condition to use in cases where one
stage requires spinlocks and another one does not. The
stage not requiring spinlock still required <smp/spinlock.h>
to be implemented with no-op stubs.
This reverts commit 037ee4b556
soc/amd/picasso: Add dummy spinlock for psp_verstage
Change-Id: Iba52febdeee78294f916775ee9ce8a82d6203570
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59094
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
List of changes:
1. Create Module Type macros as per Memory Type
(i.e. DDR2/DDR3/DDR4/DDR5/LPDDR4/LPDDR5) and fix compilation
issue due to renaming of existing macros due to scoping the Memory
Type.
2. Use dedicated Memory Type and Module type for `Form Factor`
and `TypeDetail` conversion using `get_spd_info()` function.
3. Create a new API (convert_form_factor_to_module_type()) for
`Form Factor` to 'Module type' conversion as per `Memory Type`.
4. Add new argument as `Memory Type` to
smbios_form_factor_to_spd_mod_type() so that it can internally
call convert_form_factor_to_module_type() for `Module Type`
conversion.
5. Update `test_smbios_form_factor_to_spd_mod_type()` to
accommodate different memory types.
6. Skip fixed module type to form factor conversion using DDR2 SPD4
specification (inside dimm_info_fill()).
Refer to datasheet SPD4.1.2.M-1 for LPDDRx and SPD4.1.2.L-3 for DDRx.
BUG=b:194659789
TEST=Refer to dmidecode -t 17 output as below:
Without this code change:
Handle 0x0012, DMI type 17, 40 bytes
Memory Device
Array Handle: 0x000A
Error Information Handle: Not Provided
Total Width: 16 bits
Data Width: 16 bits
Size: 2048 MB
Form Factor: Unknown
....
With this code change:
Handle 0x0012, DMI type 17, 40 bytes
Memory Device
Array Handle: 0x000A
Error Information Handle: Not Provided
Total Width: 16 bits
Data Width: 16 bits
Size: 2048 MB
Form Factor: Row Of Chips
....
Change-Id: Ia337ac8f50b61ae78d86a07c7a86aa9c248bad50
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56628
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jakub Czapiga <jacz@semihalf.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@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>
AMD platforms require the SPI contents to be 64 byte aligned in order to
use the SPI DMA controller.
BUG=b:179699789
TEST=Build guybrush and verify cbfs was invoked with -a 64
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I842c85288acd8f7ac99b127c94b1cf235e264ea2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56579
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Introduce the `smbios_dev_info` devicetree keyword to specify the
instance ID and RefDes (Reference Designation) of onboard devices.
Example syntax:
device pci 1c.0 on # PCIe Port #1
device pci 00.0 on
smbios_dev_info 6
end
end
device pci 1c.1 on # PCIe Port #2
device pci 00.0 on
smbios_dev_info 42 "PCIe-PCI Time Machine"
end
end
The `SMBIOS_TYPE41_PROVIDED_BY_DEVTREE` Kconfig option enables using
this syntax to control the generated Type 41 entries. When this option
is enabled, Type 41 entries are only autogenerated for devices with a
defined instance ID. This avoids having to keep track of which instance
IDs have been used for every device class.
Using `smbios_dev_info` when `SMBIOS_TYPE41_PROVIDED_BY_DEVTREE` is not
enabled will result in a build-time error, as the syntax is meaningless
in this case. This is done with preprocessor guards around the Type 41
members in `struct device` and the code which uses the guarded members.
Although the preprocessor usage isn't particularly elegant, adjusting
the devicetree syntax and/or grammar depending on a Kconfig option is
probably even worse.
Change-Id: Iecca9ada6ee1000674cb5dd7afd5c309d8e1a64b
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57370
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
The number of redirection table entries (aka interrupt vectors) inside
an I/O APIC may depend of the SKU, with the related register being of
type read/write-once. Provide support utilities to either lock or set
this registers value.
Change-Id: I8da869ba390dd821b43032e4ccbc9291c39e6bab
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55289
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
There are two possible code sections where the cpu_info macros can be
included: .code32 and .code64
Doing a `push %eax` while in a .code64 section will result in a compiler
error. This macro manually pushes the 32-bit register onto the stack so
we can share the code between 32 and 64 bit builds.
We also can't implicitly dereference per_cpu_segment_selector because
it's a 32-bit address. Trying to do this results in the following:
E: Invalid reloc type: 11
E: Illegal use of 32bit sign extended addressing at offset 0x1b2
If we load the address first, then dereference it, we can work around
the limitation.
With these fixes, 64-bit builds can now use CPU_INFO_V2.
BUG=b:179699789
TEST=Boot qemu 64 bit build with CPU_INFO_V2 and 4 CPUs. See AP init
work as expected.
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I4e72a808c9583bb2d0f697cbbd9cb9c0aa0ea2dc
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58232
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
With the recent addition of SMBIOS table 20, the cbmem area on
google/brya0 overflows and
ERROR: Increase SMBIOS size
SMBIOS tables: 2128 bytes.
is seen in the logs.
Therefore, double the size of the SMBIOS area from 2 KiB to 4 KiB to
accomodate more tables as needed. This happens during ramstage so 2k
is not a big deal at this point.
Change-Id: I43aa6a88d176e783cc9a4441b35b8d608c4101cd
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58432
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Since cpu_info() is no longer required to use threads, we no longer need
to initialize it in romstage or earlier. This code was also incomplete
since it didn't initialize the %gs segment.
BUG=b:179699789
TEST=Boot guybrush to OS
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I615b718e9f035ca68ecca9f57d7f4121db0c83b0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58203
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
We only ever start and execute threads on the BSP. By explicitly
checking to see if the CPU is the BSP we can remove the dependency on
cpu_info. With this change we can in theory enable threads in all
stages.
BUG=b:194391185, b:179699789
TEST=Boot guybrush to OS and verify coop multithreading still works
Suggested-by: Julius Werner <jwerner@chromium.org>
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: Iea4622d52c36d529e100b7ea55f32c334acfdf3e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58199
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
