* cpuinfo: Add support for Vortex86
Hardcode cache for family 5, use CPUID cache info for family 6.
* cpuinfo: Add support for Vortex86EX
The EX does not have brand string so hardcode name and cache.
* In determine_cache_size(), add an additional test to ensure that only
Vortex86 CPUs are handled, allowing Zhaoxin CPUs to fall through.
Also, remove the no_temperature var to keep only the enable_temperature flag
Older Atom still have the enable_temperature flag hard-coded to false until further tests are done
* Make sure the build workflow actually uses the chosen compiler.
Also clean up the repetitive nature of the workflow by defining the word
size as another matrix axis and making iso the default target.
Signed-off-by: Kimon Hoffmann <Kimon.Hoffmann@lawo.com>
* Disabled clang as a compiler alongside gcc.
The state of the current makefiles/source code is not compatible with
clang, so it makes no sense to try to build with it.
Signed-off-by: Kimon Hoffmann <Kimon.Hoffmann@lawo.com>
Read the memory controller configuration (instead of just relying on SPD data) to get the actual live settings.
Currently supported platforms:
* Intel SNB to RPL (Core 2nd Gen to Core 13th Gen) - Desktop only (no Server nor Mobile)
* AMD SMR to RPL (Zen to Zen4) - Desktop only (no Server, Mobile nor APU).
Individual commits below for archival:
* First functions skeleton for reading IMC/ECC Registers
* Change directory name from 'chipsets' to 'mch' (Memory Controller Hub)
* Add Intel HSW and fix new files encoding
* First Intel HSW IMC implementation
* Add an option to disable MCH registers polling
* Remove old include from Makefiles
* Better Makefile and padding fixes
* Statically init 'imc' struct to generate string relocation record
* Small typos & code fixes
* Add IMC support for Intel Core 6/7/8/9th Gen (SKL/KBL/CFL/CML) This is a bit more complex than Haswell and below because MMIO switched to 64-bit with Skylake (lot of) betatesting needed
* Add IMC read support for Intel SNB/IVB (2nd/3rd gen Core)
* Fix hard-lock on Intel SNB/IVB due to wrong access type on MCHBAR pointer
* Move AMD SMN Registers & offsets to a specific header file
* Add IMC Read support for AMD Zen/Zen2 CPUs
* Change 'IMC' to 'MCH' in Makefiles to match actual mch/ directory
* Add IMC Reading support for Intel ADL&RPL CPUs (Core Gen12&13)
* Add support for Intel Rocket Lake (Core 11th Gen) and AMD Vermeer
* Add IMC reading for AMD Zen4 'Raphael' AM5 CPUs
* Various Cleanup #1
Change terminology from Intel-based 'MCH' (Memory Controller Hub) to more universal 'IMC' (Integrated Memory Controller) Integrate imc_type var into imc struct. Remove previously created AMD SNM header file
* Various Cleanup 2
* Change DDR5 display format for IMC specs
DDR5 Freq can be > 10000 and timings up to 63-127-127-127, which overwflow the available space.
This commit remove the raw frequency on DDR5 (which may be incorrect due to Gear mechanism) and leave a bit of space to display the Gear engaged in the future
On some modern ULV cores (eg: Gracemont), the 2 following I/O reads to check APIC Timer working status are fused in the frontend, leading to the same value being reported twice and the code falling back to the (unusually disabled on these platforms) PIT timer.
Whether this behavior is intentional or not is unknown.
As usleep/sleep is not available at this point, a dirty delay is added between the two reads.
* cpuinfo: Fix WinChip and Cyrix/NSC CPU name and cache info
Always populate the cache info from extended CPUID, it is not used for
Intel CPUs, even though it is present, and is useful for non-Intel CPUs.
Fix the CPU name and cache sizes for Centaur and Cyrix/NSC CPUs without
brand string, which are the WinChip C6 and all Cyrix CPUs except the
Media GXm.
For the Media GXm and Geode GXm/GXLV/GX1, which are available with both
Cyrix and NSC vendor strings, hardcode the L1 cache size. The Geode GX2
uses standard cache info.
* Add 'Intel' in CPU names for older CPUs
* Add 'Transmeta' and 'IDT' in CPU names for older CPUs
-------
Co-authored-by: Sam Demeulemeester <github@x86-secret.com>
* Support cache and temperature info for VIA/Centaur/Zhaoxin CPUs
Use extended CPUID for VIA C3/C7/Nano cache information.
Use MSR reads for Nano/Zhaoxin and VIA C7 processor temperature.
Tested on VIA C7-D 1.5GHz.
* Small code conventions fixes
* Fix overallocation of cpuid_cache_info_t union (From PR #263)
---------
Co-authored-by: Sam Demeulemeester <github@x86-secret.com>
We have a .setup section in the EFI image that contains the remainder of
the Linux boot header and the real-mode setup code to support booting via
an intermediate bootloader. This sits between the PE header and the .text
section. We don't want the EFI loader to load this section, so simply
increase the SizeOfHeader field in the PE header to cover it.
The AP stacks section was being discarded by the linker because the
change in section name and attributes hadn't been propagated from
the startup64.S to startup32.S.
The alignment characteristics are only valid in COFF files. The section
alignment for image files is determined by the SectionAlignment field
in the image header.
When the reloc and sbat sections were added by PR #34, three bugs were
introduced:
1. The virtual address and size fields in the PE headers were set to the
same values as the raw address and size fields. This is incorrect, because
the sections in the image file are aligned on 512 byte boundaries, but when
loaded into memory they need to be aligned on 4096 byte boundaries.
2. The value programmed into the SizeOfImage field was too large, as it
double-counted the region before the start of the .text section.
3. The value programmed into the SizeOfImage field no longer included the bss
size. That potentially allowed the EFI loader to load the image immediately
before a reserved region of memory without leaving enough space for the bss
section.
This commit fixes those bugs by calculating both file and virtual memory
offsets & sizes in the ld script. Note that we can't add a bss section to the
EFI image because many EFI loaders fail to load images that have uninitialised
data sections. Instead the text region size in virtual memory is increased
to include the bss size.
This fixes issue #243. It also eliminates the gaps between sections
observed in issue #202.
A headless EFI system may have no GOP devices. In this case, disable
output to the physical display, but continue to write to the shadow
buffer. This allows operation via a serial console.
* For 64-bit images, use the physical address as the test pattern in test 2.
This will make it easier to diagnose faults.
* Disable test 1 by default (issue #155).
Test 2 provides the same test coverage. Test 1 may make it slightly easier
to diagnose faults with a 32-bit image, so leave it as an option.
* For 32 bit images, use the physical address to generate the offset in test 2.
Detecting a stage change and using that to reset the offset counter
could fail when the config menu was used to skip to the next test
(issue #224).
* BadRAM: Rename pattern -> patterns
* BadRAM: Refactor COMBINE_MASK and add clarifying comment
* BadRAM: Extract DEFAULT_MASK into variable
* BadRAM: Add is_covered() for checking if pattern is already covered by one of the existing patterns
* BadRAM: Initialize patterns to 0
* BadRAM: Change how addr/masks are merged to minimize number of addresses covered by badram
Prior to this patch, a list of up to MAX_PATTERNS (=10) addr/mask tuples
(aka. pattern) were maintained, adding failing addresses one by one to
the list until it was full. When full, space was created by forcing a
merge of the new address with the existing pattern that would grow the
least (with regards to number of addresses covered by the pattern) by
merging it with the new address. This can lead to a great imbalance in
the number of addresses covered by the patterns. Consider the following:
MAX_PATTERNS=4 (for illustrative purposes).
The following addresses are faulted and added to patterns:
0x00, 0x10, 0x20, 0x68, 0xa0, 0xb0, 0xc0, 0xd0
This is the end result with the implementation prior to this commit:
patterns = [
(0x00, 0xe8),
(0x00, 0x18),
(0x68, 0xf8),
(0x90, 0x98)
]
Total addresses covered: 120.
This commit changes how the merges are done, not only considering a
merge between the new address and existing patterns, but also between
existing patterns. It keeps the patterns in ascending order (by .addr)
in patterns, and a new address is always inserted into patterns (even if
num_patterns == MAX_PATTERNS, patterns is of MAX_PATTERNS+1 size). Then,
if num_patterns > MAX_PATTERNS, we find the pair of patterns (only
considering neighbours, assuming for any pattern i, i-1 or i+1 will
be the best candidate for a merge) that would be the cheapest to
merge (using the same metric as prior to this patch), and merge those.
With this commit, this is the result of the exact same sequence of
addresses as above:
[
(0x00, 0xe0),
(0x68, 0xf8),
(0xa0, 0xe8),
(0xc0, 0xe8)
]
Total addresses covered: 72.
A drawback of the current implementation (as compared to the prior)
is that it does not make any attempt at merging patterns until
num_patterns == MAX_PATTERNS, which can lead to having several patterns
that could've been merged into one at no additional cost. I.e.:
patterns = [
(0x00, 0xf8),
(0x08, 0xf8)
]
can appear, even if
patterns = [
(0x00, 0xf0)
]
represents the exact same addresses with one pattern instead of two.
* fixup! BadRAM: Change how addr/masks are merged to minimize number of addresses covered by badram
Co-authored-by: Anders Wenhaug <anders.wenhaug@solutionseeker.no>
Sam Demeulemeester