| Age | Commit message (Collapse) | Author |
|---|
|
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>
|
|
Change-Id: I01ee0ba99eca6ad4c01848ab133166f8c922684d
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55569
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
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>
|
|
The HDAU stub device enables HDMI audio under MacOS.
Change-Id: Ifa2155512dd909a4e4a753f6475541e9410dfe91
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58272
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
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>
|
|
Change-Id: Ida3d2dcdf89342b084c8e1fbf3fae7e47a7238d2
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50137
Reviewed-by: Jamal Wright <Crabstorage@getbackinthe.kitchen>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
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>
|
|
TESTED on foxconn g41m.
Change-Id: I2d5d5dfbd76a84aa400e44b4bc2ac4f3b5b6f739
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56022
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
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>
|
|
Introduce a helper variable to avoid some redundancy and to reduce the
diffstat noise in follow-up changes.
Tested with BUILD_TIMELESS=1, Asrock B85M Pro4 remains identical.
Change-Id: I490675aaddd2b5a13d990664431f79a605999254
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55689
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
Use `dev->path.pci.devfn` to obtain the `devfn` that `PCI_FUNC` needs.
Tested on Asrock B85M Pro4, `PCI_FUNC` now obtains the correct value.
Change-Id: Ia3bbd56ce0adba9d24f62ffc016cd825bcf3cc6a
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55688
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
Tested with BUILD_TIMELESS=1, Packard Bell MS2290 remains identical.
Change-Id: I7e37d32251fa3dcc64aec62dd2d814463c4a9999
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55580
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
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>
|
|
Change-Id: Idc7c38206b1ddfe486298cd3921fcb762a89ec51
Signed-off-by: Mate Kukri <kukri.mate@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55243
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: I9833c4f6c43b3e67f95bd465c42d7a5036dff914
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55196
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
Add parentheses around macro parameters to avoid operation order issues.
Change-Id: I9528f3d6b221854fddd2db6d2b45c63bfdda0092
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54953
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
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>
|
|
Add brackets around the parameters to avoid operation order problems.
Tested with BUILD_TIMELESS=1, Roda RK9 remains identical.
Change-Id: Icb9d6e8bdafdac7ad820b1629d04e7bdfbcd4b3f
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54280
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Paul Menzel <paulepanter@mailbox.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>
|
|
Tested with BUILD_TIMELESS=1, Asrock B85M Pro4 and Purism Librem 13 v1
remain identical.
Change-Id: I74b633fb0b012304b5b4bd943272ed82dcb6f7d5
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52468
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This reverts commit 4447996cc582d2c8745802b84b1f5a635e33a22a.
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>
|
|
Change-Id: I8896531d6df729709456bc6e79e02136d9ea7b3b
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47112
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.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>
|
|
Extract some common code patterns into functions.
Change-Id: I5f8d40bb55d4b4f0639e0287881ae0ecde298590
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51905
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
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>
|
|
These macros aren't needed anywhere else, so reduce their visibility.
Change-Id: Ie8d14849b4fb86d34a841d4a13ee3bbb46f9f71c
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52061
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Tested with BUILD_TIMELESS=1, Getac P470 remains identical.
Change-Id: Ifea441ad95293ad93d11a5f2521370cfd387289b
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51883
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
Tested with BUILD_TIMELESS=1, Roda RK9 remains identical.
Change-Id: I18f40d1bc3172b3c1b6b4828cefdb91aea679ba2
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51880
Reviewed-by: Nico Huber <nico.h@gmx.de>
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>
|
|
Change-Id: I67f38bcb1ec0fbbfb7f2f3fcfaf2f9bf2d9ac92c
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51875
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Try to unbreak long lines and user-visible strings.
Tested with BUILD_TIMELESS=1, Asus P5QL PRO remains identical.
Change-Id: I1bbf08cf665157840380517302ca581718e3cbe4
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51874
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Tested with BUILD_TIMELESS=1, Asus P5QL PRO remains identical.
Change-Id: I143e69446614ddc80562e5931c260329257fd3cb
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51873
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>
|
|
Some cases break reproducibility if refactored, and are left as-is.
Tested with BUILD_TIMELESS=1, Foxconn D41S remains identical.
Change-Id: I484f04455fe4baa69888645554fcd72881ba197d
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51869
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Tested with BUILD_TIMELESS=1, Packard Bell MS2290 remains identical.
Change-Id: Ia0a086bd28b796d2cbe1c7a056922721c95612b8
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51868
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>
|
|
One instance in northbridge.c breaks reproduciblity when changed.
Tested with BUILD_TIMELESS=1, Asus P8Z77-V LX2 remains identical.
Change-Id: I2148183827bcacc9e6edb91b26ad35eb2dae5090
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51866
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>
|
|
Except for some formatting differences, the macros are equivalent.
Change-Id: I5dc4f115b0873fb96683263ecd152d3d1504647d
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51863
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: Ie59593d3e3e0c455ffd3813980d1c2fe801c3c18
Signed-off-by: Keith Hui <buurin@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41461
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
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>
|
|
Use the mainboard-provided SPD map and skip unused addresses.
Change-Id: I2b5b71cff290343c1000d5613209049fa9724e3d
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51899
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 56823f53dc6de5a804f7c88b9f24847133ddc876 (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>
|
|
Change-Id: Ia338ce1a36aa0a14017201c1fc16f84915f55c07
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51156
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
Compute timings first, then display them. Drop unneeded comments, too.
Tested on Asus P8Z77-V LX2, still boots.
Change-Id: I121cf9c4db76ec0ced36caf764b1a1a51e47b552
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45501
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>
|
