Move HECI code out of raminit.c into a separate raminit_heci.c file. To
preserve reproducibility, use a temporary .c include. This will be gone
in a follow-up.
Tested with BUILD_TIMELESS=1, Packard Bell MS2290 remains identical.
Change-Id: I240552c9628f613fcfa8d2dd09b8e59c87df6019
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61928
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
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>
There is no need to have the iommu_set_resources function which only
calls pci_dev_set_resources, so assign pci_dev_set_resources directly to
the set_resources function pointer field in the iommu_ops struct.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I59c20e61a36fcc11b59d786139b4745ff662e560
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61632
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
This comment was added with the AMD family 15h Trinity IOMMU support in
commit 88ebbeb7e2 and looks like a copy of
the comment about the subtractive decode ranges in the LPC device. The
IOMMU doesn't have any subtractively decoded I/O or MMIO ranges and this
is also not what the code does. This resource is the MMIO region to
configure the IOMMU instead, so fix the comment in all copies of the
IOMMU support code.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I2e1e3a46b839b9e58b836932c1bc9b41b1b1dc02
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61631
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Leftover from using UDELAY_LAPIC on these platforms.
Change-Id: I718050925f3eb32448fd08e76d259f0fb082d2d3
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55413
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Prepares compilation for x86_64 by avoiding casts to different sizes.
Current patch fixes:
1.
src/northbridge/intel/i945/raminit.c: In function 'ram_read32':
src/northbridge/intel/i945/raminit.c:77:16: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
77 | read32((void *)offset);
| ^
2.
src/northbridge/intel/i945/rcven.c: In function 'sample_strobes':
src/northbridge/intel/i945/rcven.c:29:24: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
29 | read32((void *)addr);
| ^
src/northbridge/intel/i945/rcven.c:30:24: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
30 | read32((void *)(addr + 0x80));
| ^
3.
src/northbridge/intel/i945/gma.c: In function 'intel_gma_init_lvds':
src/northbridge/intel/i945/gma.c:98:16: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
98 | (void *)pgfx, mmiobase, piobase, pphysbase);
| ^
src/northbridge/intel/i945/gma.c:359:25: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
359 | (void *)pgfx, hactive * vactive * 4);
| ^
src/northbridge/intel/i945/gma.c:360:24: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
360 | memset((void *)pgfx, 0x00, hactive * vactive * 4);
| ^
src/northbridge/intel/i945/gma.c: In function 'intel_gma_init_vga':
src/northbridge/intel/i945/gma.c:384:17: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
384 | (u32)mmiobase, piobase, pphysbase);
|
4.
src/northbridge/intel/i945/northbridge.c: In function 'mch_domain_read_resources':
src/northbridge/intel/i945/northbridge.c:64:23: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
64 | cbmem_topk = ((uint32_t)cbmem_top() / KiB);
| ^
Change-Id: I5ac7a1cb5d85a346114f909047d5a7c21ddb43e9
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61117
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
"integrated_graphics" is already used as a "bool" at line #2128.
So set it as "bool".
Change-Id: Ic5286e691c312e8e44bbbd8e782fdfd4a13cb60f
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/60056
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Remove global variables `sblink` and `node_nums` and add function
`get_node_nums()` which reads from PCI config once and returns a static
variable.
TEST=Boot Debian 11 on PC Engines apu3
Signed-off-by: Michał Kopeć <michal.kopec@3mdeb.com>
Change-Id: I20a47f967093ef91355377c164656cabadc30fe6
Signed-off-by: Michał Kopeć <michal.kopec@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59870
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Disable LEGACY_SMP_INIT to enable PARALLEL_MP.
Also remove a large amount of APIC code that is now unnecessary.
TEST=Boot on PC Engines apu3
Boot time reduced from 1.707 seconds to 1.620 seconds average across
5 coldboots.
Inspired by CB:59693
Change-Id: Ib49e7d3f5956ac7831664d50db5f233b70aa54db
Signed-off-by: Michał Kopeć <michal.kopec@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59808
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Initialize the DPR register and check if SCLEAN needs to be run.
Allows to reliably boot the platform if ungraceful shutdown occured or
the memory controller has been locked by TXT.
TEST=Dell OptiPlex 9010 with Intel TXT enabled boots successfully
after 4s power button override or power cable unplug when SENTER was
executed. Successfully boot QubesOS 4.0 with TBoot v1.8.2
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: I4b912f121593fa55c11813262f09be1a1055e950
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59523
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Include DPR in the memory map calculations if enabled. DPR is required
for Intel TXT support.
TEST=Boot Debian 10 and see the DPR memory being reserved in E820 and
cbmem logs:
"BIOS-e820: [mem 0x000000007fc09000-0x00000000829fffff] reserved"
"TSEG base 0x80000000 size 8M"
"DPR base 0x7fd00000 size 3M"
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: Ia22e49ba58709acfa0afe0921aa71d83cc06c129
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59512
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Use the functionally-equivalent common Azalia code to get rid of
redundant code.
Change-Id: I83cf1a3a1a3854c9283ccac5e254357a32638dda
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59118
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.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>
This can now be controlled with the `MMCONF_BUS_NUMBER` Kconfig option.
Change-Id: If0fdefc5b4339acc843443c551892b397ed39c2e
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58922
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
The `find_resource` function will never return null (will die instead).
In cases where the existing code already accounts for null pointers, it
is better to use `probe_resource` instead, which returns a null pointer
instead of dying.
Change-Id: I617fea8a09049e9a87130640835ea6c3e2faec60
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58906
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
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>
As long as there is only one PCI segment we do not need
more complicated MCFG generation.
Change-Id: Ic2a8e84383883039bb7f994227e2e425366f9e13
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50666
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Populate a memory_info struct with PEI and SPD data, in order to inject
the CBMEM_INFO table necessary to populate a type17 SMBIOS table.
On Broadwell, this is done by the MRC binary, but the older Sandy Bridge
MRC binary doesn't populate the pei_data struct with all the info
needed, so we have to pull it from the SPD.
Some values are hardcoded based on platform specifications.
Change-Id: I15e00a01121150b778cfa684b9147d0cac97beb8
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58188
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
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: Ie34003a9fdfe9f3b1b8ec0789aeca8b9435c9c79
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58081
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Put the Haswell MRC glue code inside a `haswell_mrc` subfolder. Future
commits will move the Broadwell MRC/refcode glue code to be in Haswell
northbridge scope, so plan in advance.
Tested on Asrock B85M Pro4, still boots.
Change-Id: Id3e26ec1c2d5ccce928083d7ce41445908df8cf3
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55523
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
There's no need to specify the type of the `CBFS_SIZE` Kconfig symbol
more than once. This is done in `src/Kconfig`, along with its prompt.
Change-Id: I9e08e23e24e372e60c32ae8cd7387ddd4b618ddc
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56552
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This removes the need for type conversions all over the place.
Change-Id: I633a453aff17f1cbbe06b60e3efb67661733d06c
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56029
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Do the usual type conversions
TESTED: Same image with BUILD_TIMELESS=1
Change-Id: Id44eeb7660d0b521a326a5b981c04c16cf0a6f84
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56019
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Using `config_of(dev)` to access `dev->chip_info` will make coreboot die
if the latter is NULL, which is the case for devices detected at runtime
(i.e. not statically declared in the devicetree). Given that the code is
designed to work when the PEG config is all-zeroes (devicetree default),
dying because `dev->chip_info` is NULL is foolish and unwarranted.
Introduce a helper function that returns a pointer to devicetree config
when available, and otherwise returns a pointer to a zero-filled static
struct. In addition, avoid an out-of-bounds access in the very unlikely
case where the device's function is too large.
Tested on Asrock B85M Pro4, can now boot when `device pci 01.0 on end`
is commented out in its devicetree. Without this commit, it could not.
Change-Id: Ia2d3a03da9eab601fb834b0c51a8a51c9ae14c33
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55690
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
The printed values are unsigned, and should be printed accordingly.
Change-Id: Ie5edce914c389c70460b1ed3390731e3568340dd
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55493
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
GDXCBAR and EDRAMBAR are accounted for when reporting resources to the
allocator, but they are not present in the DSDT. In addition, coreboot
does not enable either range, but MRC.bin sets up GDXCBAR and does not
disable it afterwards. Not reporting GDXCBAR in the DSDT can result in
resource conflicts, and not enabling EDRAMBAR can cause issues on CPUs
with eDRAM.
Enable both GDXCBAR and EDRAMBAR in coreboot code, and report these
ranges in the DSDT. This matches what Broadwell does. The value for
the `GDXC_BASE_ADDRESS` macro matches what MRC.bin programs as well.
Tested on Asrock B85M Pro4 with an i7-4770S (no eDRAM):
- Still boots
- EDRAMBAR is now enabled with base address of 0xfed80000
- GDXCBAR is still mapped with base address of 0xfed84000
Change-Id: I5538873b30e3d02053e4ba125528d32453ef6572
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55480
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Add defines for the sizes of northbridge MMIO windows and use them where
applicable. The macro names have been taken from Broadwell.
Tested with BUILD_TIMELESS=1, Asrock B85M Pro4 remains identical.
Change-Id: I845cba8acbd478cd325d2e364138336d985f9c34
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55479
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
One of the Memory32Fixed entries covers the TXT private and public
spaces, and another covers the TPM registers. Update the comments.
Change-Id: I261d74c113fabf1d152964efd8c91de85eba4179
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55462
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Fix compilation on x86_64 by using compatible types.
The MRC blob isn't supported yet as there's no x86_32 wrapper.
Tested on HP8200:
* Still boots on x86_32.
* Boots to payload in x86_64
Change-Id: Iab29a87d52ad3f6c480f21a3b8389a7f49cb5dd8
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44677
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
hexdump and hexdump32 do similar things, but hexdump32 is mostly a
reimplementation that has additional support to configure the console
log level, but has a very unexpected len parameter that isn't in bytes,
but in DWORDs.
With the move to hexdump() the console log level for the hexdump is
changed to BIOS_DEBUG.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I6138d17f0ce8e4a14f22d132bf5c64d0c343b80d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54925
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
No board uses AMD PI 00630F01, so drop it. And drop a single reference
to the now-removed `NORTHBRIDGE_AMD_PI_00630F01` Kconfig option inside
the `drivers/amd/agesa/acpi_tables.c` file.
Change-Id: Ibc45a4a6041220ed22273c1d41f9b796e1acb901
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54897
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
TEST=boot Debian with Linux 4.14 on apu2 4GB ECC and apu3 2GB no-ECC
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: I0387071748262fdeaa5f4d9a71bb87d4d83241b6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52761
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Not all resources were being reported, add them.
TEST=boot Debian with Linux 4.14 on apu2 4GB ECC and apu3 2GB no ECC
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: Ia57ab026218f4aae0a98c2081412c4a9ebb7f57a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52927
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Move the DRAM reporting to read_resoures function before the resources
are being set. Use generic PCI domain resource allocation functions
to read and set domain resources.
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: I9605f7fad30eb093bddf9bc34e31dea9f5f846ec
Reviewed-on: https://review.coreboot.org/c/coreboot/+/53955
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Remove obsolete resource assigning functions. IO and MMIO address
registers are currently set by amd_initcpuio to cover whole PCI hole
under 4G to MMIO and IO 0x0000-0xFFFF is configured to be routed to
southbridge already. Use generic PCI and resource allocation functions
wherever possible to set northbridge resources.
TEST=boot Debian with Linux 4.14 on apu2 4GB ECC and apu3 2GB no ECC
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: I8dd5e40bce513c5ba7f1d42a06e7ab0846666942
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52926
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Memory region 0xa0000 to 0xc0000 was not reserved, the first
PCI memory resources might get assigned in this space.
FIXES: aopen/dxplplusu PCI EHCI 0:1d.7 memory resource.
Change-Id: Ia17025bde83b91d71ad719de6348197cf92e267e
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52813
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
The CMOS option system does not support negative integers. Thus, retype
and rename the option API functions to reflect this.
Change-Id: Id3480e5cfc0ec90674def7ef0919e0b7ac5b19b3
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52672
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Do not use get_dram_base_mask to calculate system DRAM limits. Shift
operation around values operating on base and mask were causing
overflows and thus incorrect system DRAM limit. Another function
returning base and limit in KiB has been developed to avoid data loss.
Keep DRAM high base and limit in calculations only for Trinity where
the physical CPU address bits is 48. Although it is almost impossible
to have a non-zero value there, the platform would have to support
nearly 256GB of RAM.
TEST=boot PC Engines apu1 2GB, apu2 4GB and apu3 2GB and boot Debian
with Linux 4.14
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: I3b5c1df96c308ff50c8de104e213219a98f25e10
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52922
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Now the bootblock is not limited to 64K so integrating vboot into the
bootblock reduces the binary size.
Change-Id: Ic92ecf8068f327a893d20924685ce571752d379f
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52787
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This macro contains a cast on the and-mask, which can suppress actual
type overflow issues. Replace it with wrapper functions around the
existing macros in device/mmio.h which still contain a type cast, but
it is a non-issue because the wrapper functions now allow compilers to
check for overflows.
Change-Id: I975bf8152fc961767f0292bff4a03aecd8c65f56
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51886
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Now that all code has been switched to make use of the new accessors,
the old ones can be dropped. Follow-ups will clean up bitwise accessors.
Change-Id: Ib4cb24ca71f3c3717ea50d147ddca74aaf0288fa
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51885
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
To keep the "main" haswell.h header short and simple, move PEG register
definitions into a separate file, as done with most other registers.
Tested with BUILD_TIMELESS=1, Asrock B85M Pro4 remains identical.
Change-Id: Ibfca00456115a4a0c861dd6738605214a7d43fd9
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51891
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
These accessors were defined as macros in order to allow verifying the
patches that replaced the accessors using BUILD_TIMELESS=1. Now that all
replacement is done, turn the new accessors into static functions to let
the compiler perform overflow checks on the arguments.
Change-Id: Iaa2ba208fba11c4a00f2b8a05eb1129a32c6c092
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52816
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Remove leading and trailing underscores and change `RAMINIT_H` to be
more consistent with other headers.
Tested with BUILD_TIMELESS=1, Asrock B85M Pro4 remains identical.
Change-Id: Ie20fcaa0f9393eb0a34054eda53b9bade63cc0d2
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51890
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Drop unused chipset type macros, remove unnecessary guards and
reorganize contents so that headers can be included at the top.
Also drop the inclusion from ASL, as it is no longer necessary.
Tested with BUILD_TIMELESS=1, Asrock B85M Pro4 remains identical.
Change-Id: I6fcc0d428d0fdbf410bcbeb6ae4809870b7b498f
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51889
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This reverts commit 4447996cc5.
It looks like the patch repurposed the `memory_reserved_for_heci_mb`
variable as an indicator if the ME firmware is fine. The change to
setup_heci_uma() made it bail out early, even though the implementation
is obviously prepared to set things up even if the requested UMA
size is 0. This also leaves the code in an inconsistent state: The
second if's condition is always true.
Resolves: https://ticket.coreboot.org/issues/305
Change-Id: Ie5a98be3f660078a85a79b5551e86f90f148974f
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52426
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Stefan Ott <coreboot@desire.ch>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Instead of counting consecutive matches (in `j`), check for a second
match directly in the control flow. Also, add some dedicated variables:
* `tap`: Keeps track of the tap value that resulted in a match and
is eventually programmed into the hardware.
* `tap2`: Is just temporarily used to search for another edge.
Keeping `tap` sync'ed with the hardware has the benefit that we don't
need to read the programmed value back for later fixups.
Change-Id: I3ae541c39efdc695f5ca74bc757b2f009239ec93
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51903
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Move the last block of the sync DLL programming up. It's independent
of the switch/case statement that it's moved around.
Change-Id: I71bc1ca1c629e4f2f4a13474c7e2c22d1a3b65d9
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51904
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
There is no nb/amd/pi northbridge left in coreboot that could be paired
with the Bolton FCH, since the remaining nb/amd/pi northbridges all use
an integrated FCH (Avalon on Mullins and Kern on Carrizo) while Bolton
is a discrete FCH. I ran into this when verifying if the common soc/amd
GPIO functionality that gets added by selecting
SOC_AMD_COMMON_BLOCK_BANKED_GPIOS is valid for all chips selecting it
and that code isn't valid for Bolton that uses the old GPIO 100
interface.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Iffe876bee96e42645e1be10730b78959b1c06d59
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52222
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Wrap `r` in parentheses to avoid unexpected behavior with compound
expressions. Fortunately, all uses of this macro do not cause issues.
Tested with BUILD_TIMELESS=1, Roda RK9 remains identical.
Change-Id: Id0f05a507c5e7e8c50e9765261d86bae73c7b5a6
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51879
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Some cases break reproducibility if refactored, and are left as-is.
Tested with BUILD_TIMELESS=1, Asus P5QL PRO remains identical.
Change-Id: I163995c0b107860449c2f36ad63e4e4ca52decb2
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51878
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The `CLKCFG_UPDATE` macro is copied from gm45 and unused. Correct it and
use the CLKCFG macros instead of magic values.
Tested with BUILD_TIMELESS=1, Asus P5QL PRO remains identical.
Change-Id: I17e972eba21282ac84c7afe10b7149cd1131fd07
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51877
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Breaking strings across multiple lines hurts greppability. Refactor the
code a bit to drop one indentation level, and then reflow the strings.
Change-Id: I0accdfd0d2c5f58e4da493ba0d4b5c6a067d92c3
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51876
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Bit 4 needs to be set then polled for after changing sync DLL taps.
Change-Id: I61b73998dec84710eec0d2561a6f4d88068e3373
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51872
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
These changes are not reproducible for some reason.
Change-Id: If1fcd0285c3a14686f7deb70d83a4c63d57d62fe
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51871
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
These changes are not reproducible for some reason.
Change-Id: I43b445b8af8871db87fb86747db8a35cec75716a
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51867
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
There are some cases in `northbridge_topology_init` where condensing the
operation using one macro changes the binary, and have been left as-is.
Tested with BUILD_TIMELESS=1, Asrock B85M Pro4 remains identical.
Change-Id: I59c7d1f8d816b95e86d39dcbf7bc7ce8c34f0770
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51865
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The {MCH,DMI,EP}BAR macros can be used for both reading and writing.
While this can sometimes be useful, compile-time overflow checking is
limited. Moreover, and-masks need to be bit-wise negated, which is easy
to forget and may result in spurious overflow warnings, and silencing
them with a cast also suppresses true integer overflow issues.
To address these limitations and for consistency with the existing MMIO
API (arch/mmio.h and device/mmio.h), these macros will be replaced with
prefixed wrappers around MMIO API functions. However, existing platform
code needs to be refactored, and the risk of introducing regressions is
substantial. To minimize the risk of breakage, the bulk of the platform
code changes will be verified using reproducible builds.
This patch introduces the new accessors, to be put to use in follow-ups.
These accessors are implemented as macros so that subsequent commits can
be verified using reproducible builds. They will be replaced with actual
functions after refactoring all platforms.
Change-Id: I85376a9e2f6cd042b41036f90de7f9edc7ad4508
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51864
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
These p-suffixed helpers allow dropping pointer casts in call-sites,
which is particularly useful when accessing registers at an offset from
a base address. Move existing helpers in chipset code to arch/mmio.h and
create the rest accordingly.
Change-Id: I36a015456f7b0af1f1bf2fdff9e1ccd1e3b11747
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51862
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Haswell MRC.bin can return zero even when raminit did not complete
successfully. When this happens, the memory controller will not have
acknowledged raminit: the mc_init_done_ack bit in the MC_INIT_STATE_G
register will be zero, and memory accesses will lock up the system.
To handle this situation more gracefully, check the mc_init_done_ack bit
after running MRC. If the bit is not set, log a fatal error and halt.
Tested on Asrock B85M Pro4:
- With badly-seated DIMMs, MRC raminit fails and coreboot dies.
- After reseating the DIMMs, the board still boots successfully.
Change-Id: I144bf827f65cd0be319c44bf3d407ddc116b129d
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51940
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
There's no good reason to use values smaller than 2 GiB here. Well, it
increases available DRAM in 32-bit space. However, as this is a 64-bit
platform, it's highly unlikely that 32-bit limitations would cause any
issues anymore. It's more likely to have the allocator give up because
memory-mapped resources in 32-bit space don't fit within the specified
MMIO size, which can easily occur when using a discrete graphics card.
Change-Id: If585b6044f58b1e5397457f3bfa906aafc7f9297
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52072
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
There's no good reason to use values smaller than 2 GiB here. Well, it
increases available DRAM in 32-bit space. However, as this is a 64-bit
platform, it's highly unlikely that 32-bit limitations would cause any
issues anymore. It's more likely to have the allocator give up because
memory-mapped resources in 32-bit space don't fit within the specified
MMIO size, which can easily occur when using a discrete graphics card.
Change-Id: I6cdce5f56bc94cca7065ee3e38af60d1de66e45c
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52070
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The `pdwm` part was supposed to be an abbreviation of `power down`, but
it is neither self-explanatory nor properly-spelled. Rename the enum.
Change-Id: I7b83c71d4534b62e18ced04eebe6a65089e1d874
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51901
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Use the actual value as it is more informative.
Change-Id: Id3bd8ccdf79d1e3fdf97cda049f81271bb017ef7
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52073
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
These typedefs are not necessary. Remove them, and rename some elements
to avoid any confusion with other DRAM generations, such as DDR4.
Change-Id: Ibe40f33372358262c540e371f7866b06a4ac842a
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51895
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reference code does an and-or operation with zero as or-value, reading
and writing to the same address. The accessed register is 32-bit, and
reference code programs bits 22, 21, 20, 16 to zero. However, coreboot
code reads the value from bits 7..0 instead. Correct this.
Change-Id: I33bf268449c2f799321be81a02bbccff855ee1fe
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51861
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reference code does a 32-bit write, and the values don't fit in 16 bits.
Change-Id: I1195c0637b5c215a45328ebae312cf620cd4c950
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51860
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reference code uses the `0x06` as an or-mask, which makes more sense.
Change-Id: I04e5262d9ab36ae866fccd90255e4a0f85328e85
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51859
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
While the macro value is the same, the DMIBAR register is not HTBONUS1.
Tested with BUILD_TIMELESS=1, Foxconn D41S remains identical.
Change-Id: I5025f115f5a55dc782092989f3d158802d1d9353
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51858
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Commit 56823f53dc (nb/intel/ironlake:
Rewrite early QPI init) rewrote this part, but the or-value is missing
one zero. Correct this magic value to align with MRC binaries.
Change-Id: Id7a6766b3f0fe415dea70cbc54afc30f808c8b16
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51857
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This was copied from Sandy Bridge and does not apply to Ironlake. These
offsets go past the MCHBAR window (MCHBAR size is 16 KiB on Ironlake).
Some of these writes would have collided with `DEFAULT_HECIBAR` if the
PCI resource had been reported as fixed. Remove the copy-pasted code.
Change-Id: I7688921ad7517cbd68a0c48262b29ecf7b4c396c
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51856
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
While 64-bit writes seem to work properly, there could be unknown
side-effects in some cases, e.g. when running in long mode. Since
reference code uses two 32-bit writes, follow suit.
Change-Id: I48ed3d94c7865b3a3cce52108e99cf1656b57fc2
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51855
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Both EHCI and xHCI USB controllers are inside the PCH (southbridge).
Now that mainboard USB configuration no longer depends on pei_data.h
definitions, the API declarations can be placed in southbridge code.
Tested with BUILD_TIMELESS=1, Asrock B85M Pro4 remains identical.
Change-Id: Ia21991b225482b33c5bc0dc52884674d301b28ba
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51569
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
With this change, only raminit.c uses pei_data.h definitions. With MRC
cornered, making it optional is just a matter of writing a replacement.
USB config definitions will be moved to Lynx Point code in a follow-up.
Tested on Asrock B85M Pro4, still boots and still resumes from S3.
Change-Id: I4bc405213e9b0828d9ced18677335533c7dd381d
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51440
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
There are at most 14 USB2 ports and 6 USB3 ports on LynxPoint-H, and
there are at most 10 USB2 ports and 4 USB3 ports on LynxPoint-LP. Limit
the array lengths accordingly to cause build errors on invalid configs.
Change-Id: Ieda7a1320d78dbbcb651f1715a87cd1d202a79f2
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51451
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
It's common to use the raw, unshifted I2C address in coreboot. Adapt
mainboards accordingly and perform the shift in MRC glue code.
Tested on Asrock B85M Pro4, still boots and still resumes from S3.
Change-Id: I4e4978772744ea27f4c5a88def60a8ded66520e1
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51458
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reorganize romstage.c to resemble sandybridge, and move everything that
needs `pei_data` into raminit.c function `perform_raminit`. Barring USB
settings, coreboot code no longer depends on pei_data.h definitions. It
still depends on MRC, though. For now.
Tested on Asrock B85M Pro4, still boots and still resumes from S3.
Change-Id: I433f88db5fe7a7533ab6837015647ec31fb45e88
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51449
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Mainboards do not need to know about `pei_data` to tell northbridge code
where to find the SPD data. Adjust `mb_get_spd_map` to take a pointer to
a struct instead of an array, and update all the mainboards accordingly.
Currently, the only board with memory-down in the tree is google/slippy.
Mainboard code now obtains the SPD index in `mb_get_spd_map` and adjusts
the channel population accordingly. Then, northbridge code reads the SPD
file and uses the index that was read in `mb_get_spd_map`, and copies it
to channel 0 slot 0 unconditionally. MRC only uses the first position of
the `spd_data` array, and ignores the other positions. In coreboot code,
`setup_sdram_meminfo` uses the data of each SPD index, so `copy_spd` has
to account for this.
Tested on Asrock B85M Pro4, still boots and still resumes from S3.
Change-Id: Ibaed5c6de9853db6abd08f53bbfda8800d207c3e
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51448
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
MRC only uses the SPD data for the first index, and ignores the rest.
Moreover, index 1 corresponds to the second DIMM on the first channel,
which does not exist on ULT (only one DIMM per channel is supported).
Copy the SPD to the first DIMM on channel 1 instead. Adjust northbridge
code to retrieve the serial number from the correct SPD data block.
Tested on Google Wolf, both channels are still correctly detected.
Change-Id: Ic60ff75043e6b96a59baa9e5ebffb712a100a934
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51443
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Done for consistency with other platforms. This also drops redundant S3
resume logging, as `southbridge_detect_s3_resume` already prints it.
Tested on Asrock B85M Pro4, still boots and still resumes from S3.
Change-Id: Id96c5aedad80702ebf343dd0a351fbd4e7b1c6c1
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51438
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
The `HPET_ADDRESS` Kconfig option has the same value. Use it instead.
Change-Id: I268e949d4396aa20e38f719b36cc4e6226efe082
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49743
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
There's no need to finalize the northbridge in SMM. This also makes
unification with Broadwell easier.
Tested on Asrock B85M Pro4, still boots and registers get locked.
Change-Id: I8b2c0d14a79e4fcd2e8985ce58542791cef9b1fe
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51157
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Add devicetree configuration parameters for mainboard-specific settings,
and provide reasonable defaults, which should usually be good enough.
This is based on Haswell SA Reference Code version 1.9.0 (Nov 2014).
Tested on Asrock B85M Pro4, registers now have the expected values.
Change-Id: I0dcdd4ca431c2ae1e62f2719c376d8bdef3054bd
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47223
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
DPR register's size field is given in whole MiB, so correct where it is
used to ensure the correct size multiple (KiB vs. MiB) is used with it.
Fixes: 5d7c3a4f0 ("nb/intel/haswell/northbridge.c: Correct DPR handling")
Change-Id: I3ca388907c61f1e47eab44ae8bc26e0f611fe1e3
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51104
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The tXP bitfield is 3 bits wide, and the tXPDLL bitfield is 5 bits wide.
Clamp any values that would overflow this field. Bits in TC_DTP already
get set when the tXP and/or tXPDLL values are large.
Change-Id: Ie7f3e8e01ff7edd2652562080554c0afadde0bb9
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49889
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
There are platforms that support error correction types other than
single-bit ECC. Extend meminfo to accomodate additional ECC types.
It is assumed that `struct memory_info` is packed to save space. Thus,
use `uint8_t` instead of an enum type (which are usually 4 bytes wide).
Change-Id: I863f8e34c84841d931dfb8d7067af0f12a437e36
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50178
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Instead, convert the struct to a union and pass in a pointer to it.
Tested on out-of-tree HP ProBook 6550b, still boots.
Change-Id: I60e3dca7ad101d840759bdc0c88c50d9f07d65e2
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45367
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This allows booting without ME firmware, even though the 30-minute
auto-shutdown still happens. Without this patch, an HP ProBook 6550b
cannot get past the `setup_heci_uma` function call.
Change-Id: I446c02ac6034ede75cb873a2e676c40e4ef84b7c
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51072
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Rewrite early QPI initialisation to account for variables in the
register values. Trace replays did not capture these relationships.
Tested on out-of-tree HP 630, still boots.
Change-Id: I5d393e8222be286ab4d4dc074d85f721b07bbca4
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49586
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
DPR size is in MiB, but the range boundaries are expressed in KiB. In
addition, DPR and TSEG use the same attributes, so unify both regions.
Also improve a comment about DPR, since `is special` is uninformative.
Change-Id: I4479483e17890b5a4c39165138fa1c5f8215bc84
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46987
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The per-lane registers need to be modified in some cases. Also, MRC
does not have any delay after the loop, so remove it.
Tested on out-of-tree HP 630, still boots.
Change-Id: If02e171d2e999f4a5be5b43ecc5aafe8ca092951
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49585
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Given that the PCI devices/registers being accessed are about QuickPath,
this code must be part of QuickPath init. Move it with the other code.
Tested on out-of-tree HP 630, still boots.
Change-Id: I0854e7f0ce3070eed1adc0603f68a9d1552204d4
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49584
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Transform the existing functions so that their functionality does not
overlap. Also, deduplicate printing these values in debug builds.
Tested on out-of-tree HP 630, still boots.
Change-Id: I3f50dcf56284c9648b116bc5aacc0adf2d863b5d
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49583
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The platform performs a CPU-only reset after initializing QPI (QuickPath
Interconnect) and before actually performing raminit. The state is saved
in the sticky scratchpad register at MCHBAR + 0x2ca8.
Relocate some QuickPath init to a separate file. All moved functions are
only used within QPI init code, and had to be relocated in one commit.
Tested on out-of-tree HP 630, still boots.
Change-Id: I48e3517285d8fd4b448add131cd8bfb80641e7ef
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49582
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Introduce the `get_bits_420` helper to avoid doing the same thing in
three different ways, and also correct a related register write.
Tested on out-of-tree HP 630, still boots.
Change-Id: Iec87f080714f0f07f5d43200ec01d6d3f31e8120
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49579
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Dummy reads followed by writes are actually read-modify-write operations
in disassembled binaries. Handling of the scratchpad register 0x2ca8 is
still nonsense, but that should be taken care of in a separate commit.
Tested on out-of-tree HP 630, still boots.
Change-Id: Ie33f42ecdb25febf3c82febeca13662232dea9ec
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45606
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
We only need to toggle one bit at a time. Introduce `rmw_500` to
simplify the code. The rank population doesn't seem to matter.
Tested on out-of-tree HP 630, still boots.
Change-Id: Ic1a680dae90889c84c9b2c536745e254475ff878
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49577
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This makes it clear what this function pointer is used for.
Change-Id: I2090e164edee513e05a9409d6c7d18c2cdeb8662
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51009
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The .disable function pointer is only referenced inside
set_vga_bridge_bits() and is used to unset VGA decoding on the
internal GFX device.
Change-Id: I0443a45522b2267e8e23b28e4e2033f25a7ccbf0
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51008
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The .disable function pointer is only referenced inside
set_vga_bridge_bits() and is used to unset VGA decoding on the
internal GFX device.
Change-Id: I6888b08ac11ba2431601fa179d063cee0bb93370
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51007
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Let's not have CBMEM hooks in between the different
INITRAM timestamps.
Change-Id: I46db196bcdf60361429b8a81772fa66d252ef1a3
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50973
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Move wait for TXT and early ME init out of `collect_system_info`, and
then drop the first call to it. Also drop a useless register read.
Tested on out-of-tree HP 630, still boots.
Change-Id: I9b167f44cbd96864bf1e8b616576af19cbbfd90c
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49581
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
It's not used, and GPIO registers are on the southbridge.
Change-Id: I0b7b6edc22d461007f24618eca42091439a53d3c
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45423
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The 100 MHz reference clock seems to be unstable when using high
multipliers. Use the 133 MHz reference clock instead.
Change-Id: I400e4f91776306d54d818fa249d7a845020ac37b
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45503
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The thing that this function initializes is the MPLL (Memory PLL). So,
call it by its name. Also add a missing newline in a printk, and update
a comment on the callsite of this function.
Tested on Asus P8Z77-V LX2, still boots.
Change-Id: I86ab643bc87253554346dfed3630eb9ddbd44eb3
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45502
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
This write was copied from Sandy Bridge. Neither Haswell reference code
nor Broadwell perform this write. Therefore, it seems safe to remove it.
Change-Id: I8869ff3e66362d9910235c554c3a07e91f479a82
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46994
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This bit is primarily used to issue RDA commands. There doesn't seem to
be any limitation regarding the number of address bits.
Change-Id: I2804f67319c9bc736f9086af408853056aabedd6
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50473
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
QCLK means "quadrature clock", and is equivalent to one half of a full
clock cycle (tCK). Fix the comment. The `QCLK_PI` value is still valid.
Change-Id: I7089fc32381addc280a71761a377075f107b5c62
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49363
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Use global variables to provide mainboard USB settings, and have the
northbridge code copy it into the `pei_data` struct. For now.
To minimize diffstat noise, this patch does not reindent the now-global
mainboard USB configuration arrays. This is cleaned up in a follow-up.
Change-Id: I273c7a6cd46734ae25b95fc11b5e188d63cac32e
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50538
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Was copy-pasted from bd82x6x and no mainboard actually needs it.
The few globals moved outside the GNVS will be removed, relocated or
replaced with acpigen later.
Change-Id: I590a355f1bd1e54365b2e329cfdc62384446a15c
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49280
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Comparing against MRC, looks like the values for TA3 and TA4 are
backwards. All of them. Thus, correct the tables accordingly.
Tested on Acer G43T-AM3, DDR3-1066 and CL = 8 now works.
Change-Id: I2c99502b8f105c77098c888b024a4c3c2c8877d4
Tested-by: Michael Büchler <michael.buechler@posteo.net>
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49388
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Michael Büchler <michael.buechler@posteo.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Fix a typo and do some style improvements.
Change-Id: Ibc7e1869faa6b9ae12a51b1c3d209bbd8e54b0d2
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49402
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Using MCHBAR32_AND_OR() in these two cases changes the order of
additions slightly. Originally, the MCHBAR offset and the base
register offset (0x5a4/0x5b4) were added first. Due to the added
parentheses in the register macros, now the complete register
offset is calculated first and then added to MCHBAR. Associativity
tells us that this doesn't change the result.
Changes in the resulting binary were verified manually on the
object file.
Change-Id: Id10882225c8e82b02583aa73e73d661c25abdef9
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50355
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Clean up cosmetics after refactoring the code. Reflow long lines and
align values in the tables, and also remove a now-unnecessary scope.
Tested with BUILD_TIMELESS=1, Asus P5QL PRO remains identical.
Change-Id: I2712c1ad5404d6968d18d762e6048c5da120ff78
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49400
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
The first RCOMP group (data) is programmed differently, and has its own
tables. Remove the unused first index from the other tables, and adjust
the loop bound accordingly. Cosmetics are cleaned up in a follow-up.
Tested on Asus P5QL PRO (DDR2), still boots.
Change-Id: I3010acbd00f762c91aebeaf1625ed7543b14bf74
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49399
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
The RCOMP data group is special and is programmed differently. Prepare
to simplify the code by programming it outside of the loop. Subsequent
commits will simplify the logic even further, then clean up cosmetics.
The special DDR3 case in the loop overwrites the command group strength
multiplier value. It doesn't need to be programmed for each RCOMP group.
Add a comment to justify not programming this register while programming
the settings for the RCOMP data group.
Tested on Asus P5QL PRO (DDR2), still boots.
Change-Id: I5c2484f48e3c07e8e787b1894932e342e8e8a75c
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49398
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
These settings can be programmed with a single register write. Factor
the writes out into a single function to avoid some redundancy.
Tested on Asus P5QL PRO, still boots.
Change-Id: I3a08c255dd2b0deae650c7fe2ba4e1f4d1cef581
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49396
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
MRC uses an incorrect mask when programming this register, but the reset
default value is zero and it is only programmed once. As it makes no
difference, we can safely use the correct mask. Document this difference
in a comment to indicate the deviation from MRC behavior is intentional.
The default value for this register was dumped from Asus P5QL PRO.
Change-Id: I93b0c382f76e141b319414258e40a8bfe6c7848a
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49391
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Consistently use commas after the last element of arrays, and also align
columns of values and comments. Remove `MHz` units from DDR speed values
to avoid confusion, as the memory's actual clock speed is half of these.
Tested with BUILD_TIMELESS=1, Asus P5QL PRO remains identical.
Change-Id: Id13022483c6221ce87d21dd21a5cfe4317a55ccd
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49390
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Time has proven this statement to be unnecessary. Uncommenting it would
not have any effect on the existing code, thus remove it completely.
Change-Id: Iff4cdd71435e4fd69d4f3284e9fb2830fdd5b173
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49389
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
These accessors can be reused for several other northbridges.
Tested with BUILD_TIMELESS=1, Roda RK9 remains identical.
Change-Id: Ia16ccc63dddebf938f4e9a7f5518e4d25d3e7e66
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49748
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Drop casts to prevent pointer arithmetic and for consistency with other
platforms. These macros will be factored out in a subsequent commit.
Change-Id: I959e7378a8bf46fd1772192090a751d7a2f6f470
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49747
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Guarding the MCHBAR macro breaks reproducibility, but should not have
any functional impact.
Change-Id: I8be8d7b8a0f289d2be76d3dec43999f6b42e3265
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49746
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
It was commented that the need for the delay was mainly related
to external displays and only with VBIOS execution. Move the
delay such that it is done only when we actually need to execute
the VBIOS aka option rom.
A delay is currently only defined for librem/purism_bdw in
its Kconfig. As the description of the issue sounds like it
would equally happen on other platforms when VBIOS is involved,
promote the Kconfig visible option to global scope.
Change-Id: I4503158576f35057373f003586bbf76af4d59b3d
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48787
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Create `FIXED_RCBA_MMIO_BASE` and use it everywhere, except in cases
where a pointer cast would be necessary. Instances in Sandy Bridge MRC
code were left as-is intentionally, so as not to collide with another
cleanup patch train.
Tested with BUILD_TIMELESS=1, these boards remain identical:
- Asus P8Z77-V LX2
- Packard Bell MS2290
Change-Id: I642958fbd6f02dbf54812d6a75d6bc3087acc77a
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50036
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This partially reverts:
- Commit 77d3b655ed
- Commit 487c1a24f5
- Commit 875c21f491
- Commit c4d1b47ad9
- Commit b96c358751
- Commit 9cbf26d18e
It is intentional to use <device/pci_ops.h> whenever one needs to use
PCI config access. The bootblock.c files needing I/O config do not need
to be an exception to this.
Change-Id: Ifba05717dad404a844618815c5347a05e07a3362
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50231
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Note that bootblock.c originally wrote a reserved bit of the PCIEXBAR
register. The `length` bitfield was set to 0, so assume 256 busses.
Moreover, the ASL reservation for MMCONFIG was only for 64 busses.
Change-Id: I7366a5096aacd92401535be020358447650b4247
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49759
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Note that bootblock.c originally wrote a reserved bit of the PCIEXBAR
register. The `length` bitfield was set to 0, so assume 256 busses.
Change-Id: Ie967747b4bf559b5aedc67cbcd35bca51f5a692e
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49760
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Bootblock enabling needs some special handling. Also, the definition of
the `get_pcie_bar` function is incorrect for Ironlake, so remove it.
With this patch, using 64 and 128 for MMCONF_BUS_NUMBER should work.
However, it has not been tested. Using 256 busses should still work.
Change-Id: Ic466ddc7b80f60af5cbff53583281440f02974c7
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49761
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Only specify the type of MMCONF_BASE_ADDRESS and MMCONF_BUS_NUMBER once.
Change-Id: Iacd2ed0dae5f1fb6b309124da53b3fa0eef32693
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50032
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Use the same variable name as soc/intel to implement a common
_PIC method at top-level ASL.
Change-Id: I48f9e224d6d0101c2101be99cd18ff382738f0dd
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49903
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
All callsites of `rmw_1d0` use the same `flag` value.
Change-Id: I84fab5d3fd270ce684cd6ca892c213b0d8610283
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49578
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reference code does not run any DMI recipe for Sandy Bridge. Create a
helper function and exit early for Sandy Bridge. The CPUID value will
be used in a follow-up, since DMI setup has stepping-specific steps.
Change-Id: I5d7afb1ef516f447b4988dd5c2f0295771d5888e
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48413
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Increase DCACHE_RAM_SIZE to 32kB and remove "NO_CBFS_MCACHE".
It’s quite safe to increase DCACHE_RAM_SIZE. All LGA775 targets
should have at least 256K L2 cache. That is plenty for XIP RO cache of
bootblock + romstage and a 32K CAR.
Change-Id: I393b2727bd90a990c3108a4dbead62b17d7fc531
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49505
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
This cosmetic change does 2 things:
- change bitwise shifting to division
- Make the division by / KiB explicit for fixed legacy ranges like
0xa0000.
Change-Id: Ia6c2ee29e37040ea9b11505e9888c7f6f8da78bc
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49625
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
This memory is used for option roms and BIOS. This matches the ACPI
code.
Change-Id: I53dd4b967569889108352ca70086a12ce252e8e0
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49624
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
This cosmetic change does 2 things:
- change bitwise shifting to division
- Make the division by / KiB explicit for fixed legacy ranges like
0xa0000-0xbffff.
Change-Id: I626989fa6625e0b3613a11e709c614d40a788b0e
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49623
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
This cosmetic change does 2 things:
- change bitwise shifting to division
- Make the division by / KiB explicit for fixed legacy ranges like
0xa0000-0xbffff.
Change-Id: If4e05f496abc05e06a944b244824376f3937a57b
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49621
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Given the lack of documentation for this platform, having this info
in coreboot logs (e.g. from board_status) can be pretty useful.
Change-Id: I6a743c1efc1b6da71589460a69bfe4785e3e77a2
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49576
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
It looks like we didn't care to reserve the VGA MMIO (a & b segments)
and the c..f segments, initially. It was probably never needed until
the new resource allocator that will make use of any unclaimed space.
Change-Id: Iebdae64914d9f8301cafc67a5aba933c11294707
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49603
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
This reverts commit 27af8a7e5d.
Reason for revert: This depends on CB:45517 which hasn't landed yet.
Change-Id: I2a6fbf54cfe01bf25e9ea8da84f6f2a17418f0ae
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49647
Tested-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
For a long time, second parameter 'stop' has been
ignored. The tested range is within 1 MiB above 'start'.
Change-Id: Icbf94cd6a651fbf0cd9aab97eb11f9b03f0c3c31
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48561
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Command timing is the absolute value of the most negative `pi_coding`
value across all ranks, or zero if there are no negative values. Use the
MAX() macro to ease proving that `cmd_delay` can never be negative, and
then drop the always-false underflow check.
The variable type for `cmd_delay` still needs to be signed because of
the comparisons with `pi_coding`, which is a signed value. Using an
unsigned type would result in undefined and also undesired behavior.
Change-Id: I714d3cf57d0f62376a1107af63bcd761f952bc3a
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49320
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Clock is a differential signal and propagates faster than command and
control, therefore its timing needs to be offset with `pi_code_offset`.
It is also a periodic signal, so it can safely wrap around.
To avoid potential undefined behavior, make `clk_delay` signed. It makes
no difference with valid values, because the initial value can be proven
to never be negative and `pi_code_offset` is always positive. With this
change, it is possible to add an underflow check, for additional sanity.
Change-Id: I375adf84142079f341b060fba5e79ce4dcb002be
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49319
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Commit 7584e550cc (nb/intel/sandybridge: Clean up program_timings)
introduced this condition along with a comment that says the opposite.
Command and clock timings always need to be computed, so drop both the
nonsensical condition and the equally-worthless corresponding comment.
Change-Id: I509f0f6304bfb3e033c0c3ecd1dd5c9645e004b2
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49318
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
