When this board was added, S3 resume was tested and working, so it must
be good enough.
Change-Id: Ie095868ea2de7846b995271baf8155e57b495e40
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38088
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
These values are the same that were hardcoded in autoport before. As
done in commit 08caa79 (util/autoport: Trim gfx.did to size), ensure
that the hardcoded values make at least some sense.
Change-Id: I9950fd10e45f5016611a5d5b6a9e41c2b0f25a5f
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38086
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
It has no reason to be disabled.
Change-Id: Iba82b6f71bc3d3a86576b719f2709595b530b702
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38085
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
hp/z220_sff_workstation was using BOARD_HP_COMPAQ_8200_ELITE_SFF_PC, and
hp/compaq_8200_elite was using a very long name. Fix that.
Change-Id: I434cde42c7b9f30f8de77b96bc924aa298bad921
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38083
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>
It makes more sense for them to be above the southbridge block.
Change-Id: I7dc06a46123f4bfc23d91f9c8cc4c9bdc4fb64f5
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38082
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Set up the proper IRQ routing for OHCI/EHCI devices which appear if
XHCI controller is disabled (CONFIG_HUDSON_XHCI_ENABLE is not set).
Now both "USB 3.0" ports are working fine at OHCI/EHCI "USB 2.0" mode.
They also work fine if XHCI controller is enabled.
Signed-off-by: Mike Banon <mikebdp2@gmail.com>
Change-Id: I50a773eeab890627abc963e0a61f781d1cea3259
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38241
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Due to build rules, dummy acpi_tables source files were added in many
mainboards. With commit 1e83e5c61a
("src/arch/x86: Build mainboard acpi_tables source if present"),
the build system will build mainboard acpi_tables only if present. Remove
the dummy/empty/blank acpi_tables source files.
BUG=None
TEST=Build test with some google mainboards.
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Change-Id: I0cef34368e2e5f5e3b946b22658ca10c7caad90a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37854
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Wim Vervoorn <wvervoorn@eltan.com>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
According to intels datasheet
Document Number: 341078-001
10th Generation Intel® Core™ Processor Families
Volume 2 of 2
we can dump the ICL MCHBAR similiar as on 8th / 9th gen CPUs.
The difference is that on ICL the MCHBAR address is definited by
the bits 38:16 instead of 38:15 giving the constraint that it has
to be 64kbit instead of 32kbit aligned. (Section 3.1.13)
Change-Id: Ia597a4b3738c11cb48ce5808d8459b4a2a768077
Signed-off-by: Johanna Schander <coreboot@mimoja.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38211
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
Since all the `subsystemid` lines in these devicetrees use the same
values, factor them out via inheritance.
There are some exceptions though. There are some enabled devices which
lack a `subsystemid` entry. Looks like HP uses the same subsystem ID
on every device, so assume that these devices should also use that
subsystem ID as well.
While we are at it, tidy up all the now-empty device blocks.
Change-Id: Iccd74fff9456e1204735a80ecc4f7685624cb78e
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38081
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
'Status' is assigned a value three times before it is checked.
Remove the first two assignments.
Change-Id: Id7136d62b4dbd6dce877983467960373b3a7ac22
Signed-off-by: Joe Moore <awokd@danwin1210.me>
Found-by: Coverity CID 1241809
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36257
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Enable COM2 port on SuperIO if UART index is 1. This change allows
to use full RS232 COM1 port for different purposes when COM2 is selected
as main port.
TEST=flash coreboot with console on COM2 and observer output with UBS-TTL
converter connected to COM2 header on PC Engines apu1
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: I1e72c5a43a302658f86dafd863e5a67580eae3e4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/29791
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
While we are at it, also:
- Rename related variables to match the register names.
- Update some comments to better reflect what some registers are about.
- Add various FIXME comments on registers that seem to be used wrongly.
With BUILD_TIMELESS=1, this commit does not change the coreboot build of:
- Asus P8H61-M PRO with native raminit.
- Gigabyte GA-H61MA-D3V with native raminit.
- Lenovo Thinkpad X230 with native raminit.
- Lenovo Thinkpad X220 with MRC raminit.
Change-Id: I5e5fe56eaa90842dbbdd1bfbbcb7709237b4c486
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38036
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
The SDIO device is disabled so remove it from the devicetree.
BUG=N/A
TEST=build
Change-Id: I6497f6134d8fc001bf4cb7e348ae00077aa34814
Signed-off-by: Wim Vervoorn <wvervoorn@eltan.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38129
Reviewed-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The HDA controller was disabled because no codec exists on the board.
However, this also disabled audio over HDMI.
To correct this, enable Azalia and the HDA controller in the devicetree.
BUG=N/A
TEST=tested on facebook monolith
Change-Id: I7be2c29151dc9d6c247c3332fb9adfb34449c703
Signed-off-by: Wim Vervoorn <wvervoorn@eltan.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38128
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Incorrect values read from a different memory region will cause
incorrect computations. VceFlags array size should be 4 based on
similar code in f15 branch, and because
f16kb/Proc/GNB/Modules/GnbInitKB/GnbF1TableKB.c only loads
4 values for VceFlags in DefaultPpF1ArrayKB. Leaving it at 5
results in an out-of-bounds read of PP_FUSE_ARRAY_V2_fld16
in line 901 of
f16kb/Proc/GNB/Modules/GnbGfxIntTableV3/GfxPwrPlayTable.c
when Index reaches 4.
Change-Id: I0242c0634e66616018e6df04ac6f1505b82a630f
Signed-off-by: Joe Moore <awokd@danwin1210.me>
Found-by: Coverity CID 1241878
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38056
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Mike Banon <mikebdp2@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The RW_MRC_CACHE was not included in a UNIFIED_MRC_CACHE region which is
expected by some parts of the code.
Add the UNIFIED_MRC_CACHE and include the RW_MRC_CACHE in this region.
BUG=N/A
TEST=tested on facebook monolith
Change-Id: I1654ca210dc2a8e976d698fd8330641da23e8380
Signed-off-by: Wim Vervoorn <wvervoorn@eltan.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38130
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Frans Hendriks <fhendriks@eltan.com>
Even if they were corrected, they just rephrase the code.
Change-Id: Iebc4e8c9eb0f44f84acf532ad12a5d064075a102
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38047
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Frans Hendriks <fhendriks@eltan.com>
The check to validate if the logo file was loaded correctly was
incorrect.
Now check the actual logo size.
BUG=N/A
TEST=build
Change-Id: Ib3a808dd831986e8347512892ee88983d376d34c
Signed-off-by: Wim Vervoorn <wvervoorn@eltan.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38124
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Frans Hendriks <fhendriks@eltan.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The check to validate if the logo file was loaded correctly was
incorrect.
Now check the actual logo size.
BUG=N/A
TEST=build
Change-Id: I4df2076b2f0cc371848a912c622268dfec24e2ef
Signed-off-by: Wim Vervoorn <wvervoorn@eltan.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38123
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
DRAM calibration sets vcore to different voltages at different
frequencies. After DRAM calibration, vcore should be restored to the
default voltage, which is 800mV for both eMCP and discrete DDR devices.
BRANCH=kukui
BUG=b:146618163
TEST=bootup pass
Change-Id: Ia87b4ac78a32dbd4c4ab52e84d307cb46525afa1
Signed-off-by: Huayang Duan <huayang.duan@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37924
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
For timestamps added before CBMEM coming online and call to
timestamp_sync_cache_to_cbmem(), ts_table->base_time was
subtracted twice. The second time though, the value of zero
was subtracted.
Make the stamps logged on the console relative to base_time too,
such that cbmem -1 and cbmem -c outputs will match.
Remove comments about postponing initialisation of timestamps
to ramstage, that does not happen anymore.
Change-Id: Ia786c12c68c8921c0d09bc58a29fefdc72bf0c6d
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38301
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
As logging is guarded by Kconfig, increase the level from BIOS_SPEW
to BIOS_INFO.
The original callsite inside timestamp_add_table_entry() was also
called when syncing from timestamps from .bss to CBMEM. We should
not reprint the values then.
Change-Id: I72ca4b6a04d8734c141a04e651fc8c23932b1f23
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38300
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Angel Pons