This is a copy/paste of picasso with a few things removed. With this
change we can jump into depthcharge.
Allocated resources:
PCI: 00:00.0 resource base 0 size a0000 align 0 gran 0 limit 0 flags e0004200 index 0
PCI: 00:00.0 resource base a0000 size 20000 align 0 gran 0 limit 0 flags f0000200 index 1
PCI: 00:00.0 resource base c0000 size 40000 align 0 gran 0 limit 0 flags f0004200 index 2
PCI: 00:00.0 resource base 100000 size 1f00000 align 0 gran 0 limit 0 flags e0004200 index 3
PCI: 00:00.0 resource base 2000000 size 1c0000 align 0 gran 0 limit 0 flags f0004200 index 4
PCI: 00:00.0 resource base 21c0000 size cde40000 align 0 gran 0 limit 0 flags e0004200 index 5
PCI: 00:00.0 resource base f8000000 size 4000000 align 0 gran 0 limit 0 flags f0000200 index c0010058
PCI: 00:00.0 resource base 100000000 size 30e340000 align 0 gran 0 limit 0 flags e0004200 index 6
PCI: 00:00.0 resource base 40e340000 size cc0000 align 0 gran 0 limit 0 flags f0004200 index 7
PCI: 00:00.0 resource base 40f000000 size 1000000 align 0 gran 0 limit 0 flags f0004200 index 8
PCI: 00:00.0 resource base 410000000 size 20000000 align 0 gran 0 limit 0 flags f0004200 index 9
PCI: 00:00.0 resource base cfffe000 size 2000 align 0 gran 0 limit 0 flags f0004200 index a
PCI: 00:00.0 resource base ceffe000 size 1000000 align 0 gran 0 limit 0 flags f0004200 index b
TEST=Boot majolica and see depthcharge finally loading:
Starting depthcharge on MAJOLICA...
new_rt5682_codec: chip = 0x1A
Looking for NVMe Controller 0x3004cac8 @ 00:01:07
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I52682ec2a06c7e219c221648f241e18e26a9358e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50339
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change allows VBOOT to build when the mainboard hasn't implemented
any of the VBOOT functions yet.
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I42ca8f0dba9fd4a868bc7b636e4ed04cbf8dfab0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50341
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The same functionality is needed on Cezanne.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I40f9d2fe7d144e94369a417225bcca0a299d1f45
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50400
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
No PCI or PNP functions are used in here.
TEST=Timeless build results in identical image.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I577e2ecdc59dbd09e739ae800cbe021168a34812
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50399
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
No PCI or PNP functions are used in here.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I46851656db1f1866a82f06ceab67c93019cc6af1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50398
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
ACPI S3 is a global state and it is no longer needed to
pass it as a parameter.
Change-Id: Id0639a47ea65c210b9a79e6ca89cee819e7769b1
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50360
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Hide the detail of allocation from cbmem from the FSP.
Loading of a BMP logo file from CBFS is not tied to FSP
version and we do not need two copies of the code, move
it under lib/.
Change-Id: I909f2771af534993cf8ba99ff0acd0bbd2c78f04
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50359
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
It's not obvious how to set specific byte of a multi-byte field in the
set file. Add an example (and a template) for setting MAC address.
Change-Id: Iea983071682ffebd61757497d43c70cc8214043d
Signed-off-by: Evgeny Zinoviev <me@ch1p.io>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39664
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Swift Geek (Sebastian Grzywna) <swiftgeek@gmail.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Jacob Garber <jgarber1@ualberta.ca>
update telemetry to improve the performance.
BUG=b:168585079
BRANCH=zork
TEST=1. emerge-zork coreboot
2. run AMD stardust test => pass
Change-Id: Ie0c941815d062d9af01858faf2121bc69f23ab44
Signed-off-by: Kevin Chiu <kevin.chiu@quantatw.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50283
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Kangheui Won <khwon@chromium.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
We can never pass memory location of dynamically loaded BMP files in the
static devicetree. The parameters passed to FSP are filled at runtime.
Change-Id: Ib835ec0d9349ec96d5635e228063f2b7000b70fd
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50361
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The only reference to CID1 is in common/acpi/wifi.asl and
only two braswell boards include it. Everywhere else
the value in GNVS was unused.
Change-Id: I09ea756fb3743e33d1e221f0a0df3a6fdc3fc3ba
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50297
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
- Add support for ME Soft Temporary Disable Mode. In this mode, ME
doesn't load its kernel and freezes at Bring UP (BUP) phase. This mode
is saved in ME NVRAM (and thus will remain for next reboots and
poweroffs).
- Add support of new CMOS option for Sandy Bridge and Ivy Bridge
ThinkPads.
HOW TO USE
To disable ME:
1. nvramtool -w me_state=Disabled
2. reboot
To enable it back:
1. nvramtool -w me_state=Normal
2. reboot
To check current status:
intelmetool -m
Tested on ThinkPad X230 and ThinkPad X220.
BACKGROUND
There's no Intel documentation that would explain how this should be
implemented, in public. Working binary sequence for MKHI command to put
ME in Soft Temporary Disable Mode, as well as a way to bring ME out of
it (by writing to H_GS register), was found and published by researchers
from PT Security:
1. To disable ME, BIOS issues the disable command (before End of Post)
and reboots. ME is supposed to be disabled on the next boot after
DID (DRAM Init Done).
My numerous tests show that issuing the command and rebooting is not
enough. If we reboot too early, ME will not be disabled. Apparently,
it is doing something in background after receiving the command. It
works with a delay of 500-1000 ms.
I also tried to dump all known (documented) registers, such as GMES
and HFS, before and during the next 2 seconds after execution of the
disable command to find a possible indication that something's
changed in ME and we're ready to reboot. Found nothing
unfortunately.
2. To enable ME back, host writes value 0x20000000 to H_GS.
PT slides don't contain any more information on it, but my tests
show, that after writing this value, GMES[31:28] is changing from
0x01 (BUP phase) to 0x03 (Policy Module) to 0x06 (Host
Communication). Then, after some more time, fw_init_complete bit of
HFS becomes 1.
This means that ME starts loading its kernel immediately, without
reboot.
On the other hand, Lenovo BIOS clearly perform a reboot after
enabling it (one reboot after saving the settings, then ThinkPad
logo appears, and then one more reboot). I'm assuming we have to
reset too.
Change-Id: Ic01526c9731cbef4e8552bbc352133a2415787c2
Signed-off-by: Evgeny Zinoviev <me@ch1p.io>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37115
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
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>
Old archive is not available anymore. The tint sources inside the new
archive are the same (something changed in a debian subdirectory but
we aren't using it), so a libpayload_tint.patch is still valid.
Signed-off-by: Mike Banon <mikebdp2@gmail.com>
Change-Id: If556fac7d1d8379a022f59ed6aee1450b7bc5aa7
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48616
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
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>
Felix Held