Defining the memory mapped base in fmap for example "FLASH@0xff800000
0x80000" for a 8M flash is optional in fmap files. This will also
reflect in the generated fmap_config.h. Fix the assembly cbfs walker
walkcbfs.S for fmap lacking a definition of the flash base.
Change-Id: I96b18f675e625abee503648ffdc6031978a4269a
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55452
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com>
pmc_set_power_failure_state() is usually called twice, once upon boot
(with `target_on == true`) and once from SMM when the system is shut
down (with `target_on == false`). Assuming settings didn't change
between these calls, there is only one case where we actually need
to write the register value: when updating the state for the
MAINBOARD_POWER_STATE_PREVIOUS feature.
This suits us well as we want to avoid unnecessary writes so we
don't clobber the value set upon boot from within SMM. Due to
inaccessible option backends, SMM might not know the current
option state.
The assumption above, that the option value didn't change, may not
be true if the user changed the option on purpose. In the future,
one would have to reboot the machine for option changes to take
effect. However, this doesn't seem to make a huge difference: One
already needed a controlled shutdown for the update to take effect
before. A reboot doesn't seem much more expensive.
Change-Id: I58dd74b8b073f4f07db090bf7fddb14b5df8239a
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55539
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch create separate helper functions to fill-in required
FSP-M UPDs as per IP initialization categories.
This would help to increase the code readability and in future
meaningful addition of FSP-M UPDs is possible rather adding UPDs randomly.
TEST=FSP-M UPD dump shows no change without and with this code change.
Change-Id: I5f23292fd1bd44d0cd55fbefd490b090ccd48365
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55225
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Updating the APOB takes a considerable amount of time. I decided to be
granular and split out the operations so we know when we read vs read +
erase + write.
BUG=b:179092979
TEST=Boot guybrush and dump timestamps
3:after RAM initialization 3,025,425 (44)
920:starting APOB read 3,025,430 (5)
921:starting APOB erase 3,025,478 (48)
922:starting APOB write 3,027,727 (2,249)
923:finished APOB 3,210,965 (183,238)
4:end of romstage 3,210,971 (6)
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I08e371873112e38f623f452af0eb946f5471c399
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55401
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
APIC Serial Bus pins were removed with ICH5 already, so a choice
'irq_on_fsb = 0' would not take effect. The related register BOOT_CONFIG
0x3 is also not documented since ICH5.
For emulation/qemu-q35 with ICH9 the choice INTERRUPT_ON_APIC_BUS was
wrong and ignored as BOOT_CONFIG register emulation was never implemented.
For ICH4 and earlier, the choice to use FSB can be made based on the
installed CPU model but this is now just hardwired to match P4 CPUs of
aopen/dxplplusu.
For sb/intel/i82371eb register BOOT_CONFIG 0x3 is also not defined
and the only possible operation mode there is APIC Serial Bus, which
requires no configuration.
Change-Id: Id433e0e67cb83b44a3041250481f307b2ed1ad18
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55257
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
In acpi_soc_get_bert_region after the bert_errors_region call is was
checked if the region parameter is NULL after the call; since region is
a parameter of acpi_soc_get_bert_region, it's non-NULL. What we should
be checking here is if region points to a non-NULL pointer.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reported-by: Coverity (CID:1457506)
Change-Id: I0523504d65725ab2d2df4db28a5dedd90697b917
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55541
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Split up PCH Kconfig into a separate file. While we're at it, also sort
selected options alphabetically.
Tested with BUILD_TIMELESS=1, coreboot.rom for the Purism Librem 13 v1
remains identical when not adding the .config file in it.
Change-Id: Ic3ff982e7108bf2d25a22e56ac2fbb93070df164
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55490
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
These macros were used to generate ACPI P-state entries, but Broadwell
now uses Haswell CPU code. These macros are unused and can be removed.
Tested with BUILD_TIMELESS=1, Purism Librem 13 v1 remains identical.
Change-Id: Ib2baca2964d9177e7ab6630d4ced22c5d332fb6e
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55487
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Keep deduplicating code. Have Broadwell PCH ASL borrow some equivalent
Lynx Point ASL files, and drop the now-unused files from Broadwell PCH.
Tested with BUILD_TIMELESS=1, Purism Librem 13 v1 remains identical.
Change-Id: If5a8712a846bbf7c42db92167763935dee74c26f
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55485
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Use hostbridge.asl from Haswell instead of Broadwell. Both files are
equivalent. Then, drop the now-unused hostbridge.asl from Broadwell.
Tested with BUILD_TIMELESS=1, Purism Librem 13 v1 remains identical.
Change-Id: I87d51727b75a9c59e2f5f3ba8d48c575ce93c78c
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55484
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Include Haswell memmap.h from Broadwell iomap.h to deduplicate identical
definitions. This also prevents the definitions from falling out of sync
while the unification process is ongoing.
Tested with BUILD_TIMELESS=1, Purism Librem 13 v1 remains identical.
Change-Id: I850e5521effba3818f4e2a13b94281bf07857d50
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55483
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>
