Age | Commit message (Collapse) | Author |
|
Explain why the flash is no longer cached.
BUG=none
TEST=none
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: Ibb18f363a215d665d53a722ed76896a75d1c5608
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42108
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This change allows treating the PMC as a 'hidden' PCI device on Jasper
Lake, so that the MMIO & I/O resources can be exposed as belonging to
this device, instead of the system agent and LPC/eSPI.
Change-Id: Ie07987c68388d03359c43f64a849dc6e3f94676e
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42018
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
Change-Id: I9025ca3b6b438e5f9a790076fc84460342362fc2
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41919
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-by: Wim Vervoorn <wvervoorn@eltan.com>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
By vendor choice override fadt->preferred_pm_profile here.
Change-Id: I0453c0edc9aeb86cf4f5d912613b8fa8beb63ab4
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41917
Reviewed-by: Wim Vervoorn <wvervoorn@eltan.com>
Reviewed-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: Iad7e7af802212d5445aed8bb08a55fd6c044d5bf
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41916
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
While working on psp_verstage, I noticed that this file had a number of
unnecessary includes. Remove them.
BUG=b:158124527
TEST=Build & boot psp_verstage on trembyle
Signed-off-by: Martin Roth <martin@coreboot.org>
Change-Id: I32188e2dda39ece9dc98d0344824d997a2e80303
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42065
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
|
|
Change-Id: Ie004a94a49fc8f53c370412bee1c3e7eacbf8beb
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41944
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michael Niewöhner
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
Currently, having libgfxinit try to enable VGA will result in a hang.
On the Asrock B85M Pro4, DDI E (VGA) was not being enabled in coreboot,
so it did not hang. However, this renders Linux's i915 driver unable to
use VGA at all. In absence of monitors with digital inputs, this is bad.
To work around this problem, mark DDI E as enabled, and comment out VGA
from gma-mainboard.ads for the time being. This allows one to use a VGA
monitor, even if it only works after Linux drivers have taken over.
Change-Id: Idd6a9e8515a1065ad3c6ddf136896fef9f0fa732
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42099
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Michael Niewöhner
|
|
The ASL code is copied from the Purism Librem 13v3, and is not needed,
as the standard fixed power button is used. It was removed for the
Pursim devices in commit 2d977b2dcb (mb/purism: remove duplicate ACPI
power button).
Change-Id: I18155ea672e7309b367ad4170f2f00f0b3e557db
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41019
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Mimoja <coreboot@mimoja.de>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
This is copied from the Purism Librem 13v3, and is not needed, as the
standard fixed power button is used. It was removed for the Pursim
devices in commit 2d977b2dcb (mb/purism: remove duplicate ACPI power
button).
Change-Id: I8fe19b8fbcc11d859a75b3dc6b9bcc42c80d13f1
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41018
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Rafael Send <flyingfishfinger@gmail.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Port commit d7b88dcb (mb/google/x86-boards: Get rid of power button
device in coreboot) to AMD AGESA Hudson boards.
No idea, if this is correct for the two laptops. The Lenovo G505s also
incorrectly defines two power buttons.
[ 0.911423] input: Power Button as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input1
[ 0.911434] ACPI: Power Button [PWRB]
[ 0.911493] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input2
[ 0.912326] ACPI: Power Button [PWRF]
If the generic power button device is needed, the POWER_BUTTON flag
should be set in FADT.
The GPE ACPI code seems to originate from commit 806def8c (I missed the
svn add on r3787. These are the additional files., Add AMD dbm690t ACPI
support.), and was copied over.
Change-Id: I88950e15faf1b90ca6e688864bac40bf9779c32e
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40754
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Mike Banon <mikebdp2@gmail.com>
|
|
Port commit d7b88dcb (mb/google/x86-boards: Get rid of power button
device in coreboot) to AMD AGESA Hudson boards
(SOUTHBRIDGE_AMD_PI_AVALON).
The GPE ACPI code seems to originate from commit 806def8c (I missed the
svn add on r3787. These are the additional files., Add AMD dbm690t ACPI
support.), and was copied over.
Change-Id: Ibeec73c15f2282f7ab0be88f96693bcb551b3e45
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40753
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com>
|
|
This change adds device_operations for UART MMIO devices that provides
following operations:
1. uart_acpi_name: Returns ACPI name of UART device. Generation of
UART device node is not yet moved to SSDT, but will be done in
follow-up CLs.
2. scan_bus: Uses scan_static_bus to scan devices added under the UART
devices. This allows mainboard to add devices under the UART MMIO
device.
Change-Id: I18abbe88952e7006668657eb1d0c177e53e95850
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42068
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
|
|
According to the Wilco EC spec the BTSC bit of PWSR is always cleared
when PWSR is read so that battery status change events are only
triggered one time. Testing of the Wilco EC has verified this behavior.
This changes the way in which the battery status change bit is used from
checking the bit state against the previous value to always issuing a
battery event when the BTSC bit is set. The other bits in PWSR indicate
state directly and do not behave like the BTSC bit.
BUG=b:157113138
TEST=Deploy on Drallion and verify that battery events are generated
BRANCH=drallion, sarien
Signed-off-by: Mathew King <mathewk@chromium.org>
Change-Id: I8fbf2ee1158ddd790b04a20b1eb27a6cce4f5c81
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42017
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
|
|
Change-Id: I3f08b9cc34582165785063580b3356135030f63e
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41782
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: David Guckian
|
|
Change-Id: I5156eb97648927e5fe6e467abb8e3e055a231fec
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41686
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
Add support for RT 1308 audio amplifier in TGLRVP.
We are using the i2c generic driver here to generate
the SSDT file. Datasheet:ALC-1308-CG-version-08.
BUG=none
BRANCH=none
TEST=Build and boot tglrvp successfully. In kernel console
use the "aplay -l" command to check soundcard is listed.
Change-Id: I41d205a3ab87db85baf49e9e8a582c226ba5832d
Signed-off-by: Shaunak Saha <shaunak.saha@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41808
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Sathyanarayana Nujella <sathyanarayana.nujella@intel.com>
Reviewed-by: Srinidhi N Kaushik <srinidhi.n.kaushik@intel.com>
Reviewed-by: Wonkyu Kim <wonkyu.kim@intel.com>
|
|
BUG=b:156564296
BRANCH=octopus
TEST=emerge-octopus coreboot
Change-Id: I99b04fec88da481e21b7a05807a4f1edeb3a5bdf
Signed-off-by: Tony Huang <tony-huang@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42036
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Justin TerAvest <teravest@chromium.org>
|
|
This is a standard MSR. No reason for picasso to define its own.
BUG=b:147042464
TEST=Boot to OS on trembyle
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: Idcfae356d35ff08ced4b7e5ccfc132a8492a6824
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42087
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
We don't use amd_setup_mtrrs, bsp_topmem or bsp_topmem2 in picasso.
BUG=b:147042464
TEST=Boot to OS on trembyle
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I1941934975dfea4f189347811b003a33996c887a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42086
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Change-Id: I1632d03a7a73de3e3d3a83bf447480b0513873e7
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41685
Reviewed-by: David Guckian
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: I03c25ad5d9864406e1a021e39a5736ac72c8825a
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38197
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Enable Cr50 update in recovery mode, so that we can at least still
update the process for most cases (that an update is pending in recovery
mode is not impossible but should be unlikely in the field).
Leave manual recovery unaffected so at least that would still work even
if Cr50 wedges in a weird way that it thinks it has an update on every
boot or something.
Setting the recovery_reason to VB2_RECOVERY_TRAIN_AND_REBOOT allows the
update to be applied.
BUG=b:154071064
BRANCH=none
TEST=builds
Thanks to Julius Werner for the suggested fix.
Change-Id: Iba341a750cce8334da4dcf6353ca8cd1268d170f
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41988
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
Reference:
- TGL User Guide #613584 Rev 2.2
- TGL User Guide #605534 Rev 1.0
BRANCH=none
BUG=none
TEST=build and boot tglrvp
Change-Id: I5da80fd4ad321b1ded369c2b6c039b73fcb3773e
Signed-off-by: Jamie Ryu <jamie.m.ryu@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41516
Reviewed-by: Wonkyu Kim <wonkyu.kim@intel.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: I779387fb0c9d3ad6e16d4ccfc39c38dfe6620345
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40806
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
This change adds memory parts used by variant wheelie to
mem_list_variant.txt and generates DRAM IDs allocated to these parts.
BUG=b:157862308
Change-Id: I53f6f5c832cd40068a6d4379ace849f6e8ad7a91
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41990
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Now that dedede is moved to using the auto-generated SPDs, we no
longer need the .spd.hex files in spd/ folder. Hence, this change
drops the files.
Change-Id: I026b3c61a2a88a7cd2c9842a26eb336324853add
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41882
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This change switches dedede and family to using auto-generated SPDs
obtained using gen_spd.go and gen_part_id.go.
Change-Id: I6fadae0abcfb6e50d3cc502098ace9b668667a51
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41881
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
GENERIC_SPD_BIN assumes that the SPDs are all placed in mainboard and
have .spd.hex as the suffix. Disable GENERIC_SPD_BIN for dedede as it
already provides its own rules for SPD inclusion. In follow up
changes, GENERIC_SPD_BIN can be re-enabled by updating gen_spd.go tool
to use similar suffixes and allowing different paths to be provided
for SPD by mainboard.
Change-Id: If10144e0b2bd67884af69f60e5117e388a3ae5da
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42054
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
gen_part_id.go
This change adds mem_list_variant.txt that contains the list of
memory parts used by waddledoo and Makefile.inc generated by
gen_part_id.go using mem_list_variant.txt.
In the final change of the series, all dedede variants will be
switched from using the current SPDs to new auto-generated SPDs.
Differences in auto-generated SPD from current SPD are as follows:
Part: MT53E512M32D2NP-046 WT:E
Byte# Current New Explanation
4 0x15 0x16 This part has only 1 die. Hence,
density per die is 16Gb.
6 0x90 0x04 1 die in package and 2 channels per
die.
9 0x40 0x00 Unused by MRC.
19 0x0F 0xFF As per JEDEC spec, tckMax should be
100ns. So, value should be 0xFF as
per datasheet.
123 0x00 0xE5 Fine offset for taa. Expected value
is 0xE5 as per datasheet.
125 0xE1 0xE0 Fine offset for tckMin. As per
datasheet tckMin is 0.468ns. So, this
comes out to be 0xE0.
Additionally, manufacturer name bytes are set to 0.
Part: NT6AP256T32AV-J2
Waddledoo started assigning DRAM part IDs from 1. So, this change
fills in Nanya part as ID 0 (though it is currently unused).
Change-Id: I3879c4f3ad942eb349b52aad397333f576599bbd
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41880
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
|
|
gen_part_id.go
This change adds mem_list_variant.txt that contains the list of
memory parts used by wheelie and Makefile.inc generated by
gen_part_id.go using mem_list_variant.txt.
In the final change of the series, all dedede variants will be
switched from using the current SPDs to new auto-generated SPDs.
Differences in auto-generated SPD from current SPD are as follows:
Part: MT53E512M32D2NP-046 WT:E
Byte# Current New Explanation
4 0x15 0x16 This part has only 1 die. Hence,
density per die is 16Gb.
6 0x90 0x04 1 die in package and 2 channels per
die.
9 0x40 0x00 Unused by MRC.
19 0x0F 0xFF As per JEDEC spec, tckMax should be
100ns. So, value should be 0xFF as
per datasheet.
123 0x00 0xE5 Fine offset for taa. Expected value
is 0xE5 as per datasheet.
125 0xE1 0xE0 Fine offset for tckMin. As per
datasheet tckMin is 0.468ns. So, this
comes out to be 0xE0.
Additionally, manufacturer name bytes are set to 0.
Change-Id: If307bfb1d376e32af08af4f020f9e125f6a415dd
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41879
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
|
|
gen_part_id.go
This change adds mem_list_variant.txt that contains the list of
memory parts used by waddledee and Makefile.inc generated by
gen_part_id.go using mem_list_variant.txt.
In the final change of the series, all dedede variants will be
switched from using the current SPDs to new auto-generated SPDs.
Differences in auto-generated SPD from current SPD are as follows:
Part: MT53E512M32D2NP-046 WT:E
Byte# Current New Explanation
4 0x15 0x16 This part has only 1 die. Hence,
density per die is 16Gb.
6 0x90 0x04 1 die in package and 2 channels per
die.
9 0x40 0x00 Unused by MRC.
19 0x0F 0xFF As per JEDEC spec, tckMax should be
100ns. So, value should be 0xFF as
per datasheet.
123 0x00 0xE5 Fine offset for taa. Expected value
is 0xE5 as per datasheet.
125 0xE1 0xE0 Fine offset for tckMin. As per
datasheet tckMin is 0.468ns. So, this
comes out to be 0xE0.
Additionally, manufacturer name bytes are set to 0.
Part: NT6AP256T32AV-J2
Byte# Current New Explanation
4 0x14 0x15 This part has only 1 die. Hence,
density per die is 8Gb.
6 0x90 0x04 1 die in package and 2 channels per
die.
Manufacturer name bytes are set to 0.
Change-Id: I7a68a29ca3632e22f3960c9fc44acf3ce4f87c9c
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41878
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
|
|
This change adds the following memory parts to LP4x global list and
generates SPDs using gen_spd.go for TGL and JSL:
1. MT53E512M32D2NP-046 WT:E
2. K4U6E3S4AA-MGCR
3. H9HCNNNCPMMLXR-NEE
4. K4UBE3D4AA-MGCR
BUG=b:157862308, b:157732528
Change-Id: Ib7538247d39dfe5faab277d646f87f09103d6969
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41989
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Now that volteer is moved to using the auto-generated SPDs, we no
longer need the spd/ folder under each variant. Hence, this change
drops the spd/ folders and the SPD files within them.
BUG=b:156126658
Change-Id: Icb36adeb11fd68a84df5b225db32fb8d840a530f
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41619
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This change switches volteer and family to using auto-generated SPDs
obtained using gen_spd.go and gen_part_id.go.
BUG=b:147321551,b:155423877
Change-Id: I9ed48f0b51714b072a0459d0b70b5417a49db54f
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41618
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
|
|
gen_part_id.go
This change adds mem_list_variant.txt that contains the list of
memory parts used by volteer and Makefile.inc generated by
gen_part_id.go using mem_list_variant.txt.
In the final change of the series, all volteer variants will be
switched from using the current SPDs to new auto-generated SPDs.
Differences in auto-generated SPD from current SPD are as follows:
Part: K4U6E3S4AA-MGCL
Byte# Current New Explanation
6 0x95 0x94 Signal loading is not used by
MRC. Set bits 1:0 to 00.
16 0x48 0x00 Signal loading is not used by
MRC. Set to 0x00.
19 0x0F 0xFF As per JEDEC spec, tckMax should be
100ns. So, value should be 0xff as
per datasheet.
21,22 0x55,0x00 0x54,0x05 As per datasheet, part supports CAS
latencies 20,24,28,32,36. So value
should be 0x54, 0x05.
24 0x8C 0x87 taa is .468ns * CAS-36 which results
in byte 24 being 0x87 as per datasheet.
123 0x00 0xE5 Fine offset for taa. Expected value
is 0xE5 as per datasheet.
124 0x7F 0x00 Fine offset for tckMax. Expected
value is 0x00 as per datasheet.
125 0xE1 0xE0 Fine offset for tckMin. As per
datasheet tckMin is 0.468ns. So, this
comes out to be 0xE0.
Part: K4UBE3D4AA-MGCL
Byte# Current New Explanation
6 0xB5 0xB4 Signal loading is not used by
MRC. Set bits 1:0 to 00.
16 0x48 0x00 Signal loading is not used by
MRC. Set to 0x00.
19 0x0F 0xFF As per JEDEC spec, tckMax should be
100ns. So, value should be 0xff as
per datasheet.
123 0x00 0xE5 Fine offset for taa. Expected value
is 0xE5 as per datasheet.
Part: H9HCNNNBKMMLXR-NEE
Byte# Current New Explanation
6 0x95 0x94 Signal loading is not used by
MRC. Set bits 1:0 to 00.
16 0x48 0x00 Signal loading is not used by
MRC. Set to 0x00.
19 0x0F 0xFF As per JEDEC spec, tckMax should be
100ns. So, value should be 0xff as
per datasheet.
21,22 0x55,0x00 0x54,0x05 As per datasheet, part supports CAS
latencies 20,24,28,32,36. So value
should be 0x54, 0x05.
24 0x8C 0x87 taa is .468ns * CAS-36 which results
in byte 24 being 0x87 as per datasheet.
123 0x00 0xE5 Fine offset for taa. Expected value
is 0xE5 as per datasheet.
124 0x7F 0x00 Fine offset for tckMax. Expected
value is 0x00 as per datasheet.
125 0xE1 0xE0 Fine offset for tckMin. tckMin is
calculated as (1/4267)*2 which comes
out to be 0.46871. Some datasheets
round this down to 0.468 and others
round it up to 0.469. JEDEC spec uses
0.468. As per that, this value comes
out to be 0xE0.
Part: H9HCNNNFAMMLXR-NEE
Byte# Current New Explanation
4 0x15 0x16 As per datasheet, density is 16Gb per
logical channel. So value should be 0x16.
6 0xF9 0xB8 This device has 4 logical dies
instead of 8. Also, signal loading is
not used by MRC.
16 0x48 0x00 Signal loading is not used by
MRC. Set to 0x00.
20,21, 0x92,0x55, 0x12,0x29, As per datasheet, part supports CAS
22 0x00 0x15 latencies 6,10,16,22,26,32,36,40. So value
should be 0x12,0x29,0x15.
24 0x8C 0x96 taa is .468ns * CAS-40 which results
in byte 24 being 0x96 as per datasheet.
29,30 0xE0,0x0B 0xC0,0x08 As per datasheet, this corresponds to
280ns in MTB units which is 0x08C0.
31,32 0xF0,0x05 0x60,0x04 As per datasheet, this corresponds to
140ns in MTB units which is 0x04C0.
123 0x00 0xE2 Fine offset for taa. Expected value
is 0xE2 as per datasheet.
124 0x7F 0x00 Fine offset for tckMax. Expected
value is 0x00 as per datasheet.
125 0xE1 0xE0 Fine offset for tckMin. tckMin is
calculated as (1/4267)*2 which comes
out to be 0.46871. Some datasheets
round this down to 0.468 and others
round it up to 0.469. JEDEC spec uses
0.468. As per that, this value comes
out to be 0xE0.
Part: MT53E1G32D2NP-046 WT:A
Byte# Current New Explanation
4 0x15 0x16 As per datasheet, density is 16Gb per
logical channel. So value should be 0x16.
5 0x21 0x29 As per datasheet, this part has 17row
address bits and 10column address
bits. This results in 0x29.
6 0xB5 0x94 This device has 2 logical dies. Also,
MRC does not use signal loading.
16 0x48 0x00 Signal loading is not used by
MRC. Set to 0x00.
12 0x0A 0x02 As per datasheet, this is 1rank and
16-bit wide channel. So, value should
be 0x02.
21,22 0x55,0x00 0x54,0x05 As per datasheet, part supports CAS
latencies 20,24,28,32,36. So value
should be 0x54, 0x05.
24 0x8C 0x87 taa is .468ns * CAS-36 which results
in byte 24 being 0x87 as per datasheet.
29,30 0xC0,0x08 0xE0,0x0B As per datasheet, this corresponds to
380ns in MTB units which is 0x0BE0.
31,32 0x60,0x04 0xF0,0x05 As per datasheet, this corresponds to
190ns in MTB units which is 0x05F0.
123 0x00 0xE5 Fine offset for taa. Expected value
is 0xE5 as per datasheet.
124 0x7F 0x00 Fine offset for tckMax. Expected
value is 0x00 as per datasheet.
125 0xE1 0xE0 Fine offset for tckMin. As per
datasheet tckMin is 0.468ns. So, this
comes out to be 0xE0.
BUG=b:147321551,b:155423877
Change-Id: I3998b2cd91020130bacf371fce9b0d307304acbe
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41617
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
gen_part_id.go
This change adds mem_list_variant.txt that contains the list of
memory parts used by halvor and Makefile.inc generated by
gen_part_id.go using mem_list_variant.txt.
In the final change of the series, all volteer variants will be
switched from using the current SPDs to new auto-generated SPDs.
Differences in auto-generated SPD from current SPD are as follows:
Part: H9HKNNNCRMBVAR-NEH
Byte# Current New Explanation
4 0x16 0x15 As per datasheet, density is 8Gb per
logical channel. So value should be 0x15.
6 0xB9 0x94 Signal loading is not used by
MRC. Set bits 1:0 to 00. 2 channels 2
dies. Hence, 0x94
19 0x0F 0xFF As per JEDEC spec, tckMax should be
100ns. So, value should be 0xff as
per datasheet.
29,30 0xE0,0x0B 0xC0,0x08 As per datasheet, this corresponds to
280ns in MTB units which is 0x08C0.
31,32 0xF0,0x05 0x60,0x04 As per datasheet, this corresponds to
140ns in MTB units which is 0x0460.
125 0xE1 0xE0 Fine offset for tckMin. tckMin is
calculated as (1/4267)*2 which comes
out to be 0.46871. Some datasheets
round this down to 0.468 and others
round it up to 0.469. JEDEC spec uses
0.468. As per that, this value comes
out to be 0xE0.
Part: MT53E1G64D4SQ-046 WT:A
Byte# Current New Explanation
5 0x21 0x29 As per datasheet, this part has 17row
address bits and 10column address
bits. This results in 0x29.
6 0xB9 0x94 Signal loading is not used by
MRC. Set bits 1:0 to 00. 2 channels,
2 dies. Hence, 0x94.
19 0x0F 0xFF As per JEDEC spec, tckMax should be
100ns. So, value should be 0xff as
per datasheet.
125 0xE1 0xE0 Fine offset for tckMin. As per
datasheet tckMin is 0.468ns. So, this
comes out to be 0xE0.
BUG=b:147321551,b:155423877
Change-Id: I28b065a00380516d8686279a92ef68b9f17e2f65
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41616
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
gen_part_id.go
This change adds mem_list_variant.txt that contains the list of
memory parts used by malefor and Makefile.inc generated by
gen_part_id.go using mem_list_variant.txt.
In the final change of the series, all volteer variants will be
switched from using the current SPDs to new auto-generated SPDs.
Differences in auto-generated SPD from current SPD are as follows:
Part: K4U6E3S4AA-MGCL
Byte# Current New Explanation
6 0x95 0x94 Signal loading is not used by
MRC. Bits 1:0 set to 0.
16 0x48 0x00 Signal loading is not used by
MRC. Set to 0x00.
19 0x0F 0xFF As per JEDEC spec, tckMax should be
100ns. So, value should be 0xff as
per datasheet.
21,22 0x55,0x00 0x54,0x05 As per datasheet, part supports CAS
latencies 20,24,28,32,36. So value
should be 0x54, 0x05.
24 0x8C 0x87 taa is .468ns * CAS-36 which results
in byte 24 being 0x87 as per datasheet.
123 0x00 0xE5 Fine offset for taa. Expected value
is 0xE5 as per datasheet.
124 0x7F 0x00 Fine offset for tckMax. Expected
value is 0x00 as per datasheet.
125 0xE1 0xE0 Fine offset for tckMin. As per
datasheet tckMin is 0.468ns. So, this
comes out to be 0xE0.
BUG=b:155239397,b:147321551
Change-Id: I8b8bdc55314f538aff4dd1944a0b745357744d8c
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41615
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
gen_part_id.go
This change adds mem_list_variant.txt that contains the list of
memory parts used by ripto and Makefile.inc generated by
gen_part_id.go using mem_list_variant.txt.
In the final change of the series, all volteer variants will be
switched from using the current SPDs to new auto-generated SPDs.
Differences in auto-generated SPD from current SPD are as follows:
Part: K4U6E3S4AA-MGCL
Byte# Current New Explanation
6 0x95 0x94 Signal loading is not used by
MRC. Bits 1:0 set to 0.
16 0x48 0x00 Signal loading is not used by
MRC. Set to 0x00.
19 0x0F 0xFF As per JEDEC spec, tckMax should be
100ns. So, value should be 0xff as
per datasheet.
21,22 0x55,0x00 0x54,0x05 As per datasheet, part supports CAS
latencies 20,24,28,32,36. So value
should be 0x54, 0x05.
24 0x8C 0x87 taa is .468ns * CAS-36 which results
in byte 24 being 0x87 as per datasheet.
123 0x00 0xE5 Fine offset for taa. Expected value
is 0xE5 as per datasheet.
124 0x7F 0x00 Fine offset for tckMax. Expected
value is 0x00 as per datasheet.
125 0xE1 0xE0 Fine offset for tckMin. As per
datasheet tckMin is 0.468ns. So, this
comes out to be 0xE0.
BUG=b:155239397,b:147321551
Change-Id: Ibb06443a5c7fd80915f66b806cdd7c3ae1275b05
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41614
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This change uses gen_spd.go and global_lp4x_mem_parts.json.txt to
generate SPD files for currently known LP4x memory parts that
can be used with JSL-based mainboards.
Following files are added:
1. spd-*.hex: SPD files auto-generated by gen_spd.go
2. spd_manifest.generated.txt: Manifest file auto-generated by
gen_spd.go
Mainboards can use the SPD files from SoC directly when creating
SPD binary to add to CBFS.
Change-Id: Ic52506b809c66b9f7cf25a100a959d85c67addf2
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41876
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This change uses gen_spd.go and global_lp4x_mem_parts.json.txt to
generate SPD files for currently known LP4x memory parts that can be
used with TGL-based mainboards.
Following files are added:
1. spd-*.hex: SPD files auto-generated by gen_spd.go
2. spd_manifest.generated.txt: Manifest file auto-generated by
gen_spd.go
Mainboards can use the SPD files from SoC directly when creating SPD
binary to add to CBFS.
BUG=b:147321551,b:155239397
Change-Id: Ic3935e4f6d106cbdf496fdfa28a0991e2d238fd9
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41875
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
|
|
Remove unused includes
Change-Id: I7e8109870168db7f477f205a0b3020b7b2be5f5f
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41541
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Advertising SMI triggers in FADT is only valid if we exit with
SMI installed. There has been some experiments to delay SMM
installation to OS, yet there are new platforms that allow some
configuration access only to be done inside SMM.
Splitting static HAVE_SMI_HANDLER variable helps to manage cases
where SMM might be both installed and cleared prior to entering
payload.
Change-Id: Iad92c4a180524e15199633693446a087787ad3a2
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41910
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
When no SMI is installed, FADT should not advertise a trigger
mechanism that does not respond.
Change-Id: Ifb4f99c11a72e75ec20b9faaf62aed5546de91fa
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41909
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
If running on older (like before 2.4.0) version of QEMU there is
no SMI support, so never advertise SMI in FADT for the emulation.
Behaviour if ACPI daemon tries to raise SMI under these conditions
is unknown.
Change-Id: I170058793798648c6713de1530d89ec2ac53e39a
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41907
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
When no SMI is installed, FADT should not advertise a trigger
mechanism that does not respond.
Change-Id: Ia61e50fb49719e9e18e81a27f355cdbd755a3f40
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41906
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
When no SMI is installed, FADT should not advertise a trigger
mechanism that does not respond.
Change-Id: Iefa1e7d80367dbe380f69e768238b4124a45626f
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41905
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This patch adds support for the Prodrive Hermes mainboard.
Tested with CoffeeLakeFspBinPkg FSP 7.0.68.41.
Untested:
* CNVi
* Intel Graphics
Tested:
* CPU Intel Xeon E2288G
* CPU Intel Core i3-9100F
* CPU Intel Core i7 9700KF
* CPU Intel Core i7 9700E
* CPU Intel Core i7 9700F
* CPU Intel Core i5 9600K
* CPU Intel Pentium Gold G5400
* PCIe Link Width x8 on Slot6 by changing PCIe mux
* All four DDR4 slots in different configurations
* USB2.0 HDR1
* USB2.0 HDR2
* USB3.0 HDR
* Slot1
* Slot2
* Slot3
* Slot4
* Slot6
* M2.M NVMEe
* Ethernet PHYs 0-4
* Aspeed BMC PCIe
* Aspeed BMC USB
* Aspeed Graphics init
* USB3 backplane all working
* I801 SMBUS
Not Working:
* Intel HDA
Change-Id: Id7d051d3fa6823618691d5572087c9ae589c2862
Signed-off-by: Christian Walter <christian.walter@9elements.com>
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Signed-off-by: Christian Walter <christian.walter@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38303
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
|
|
Set up cpus:
* setup apic IDs.
* setup MSR to enable fast string, speed step, etc.
* Enable turbo
Signed-off-by: Jonathan Zhang <jonzhang@fb.com>
Signed-off-by: Reddy Chagam <anjaneya.chagam@intel.com>
Change-Id: I5765e98151f6ceebaabccc06db63d5911caf7ce8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40112
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
|
|
We decided to store the FSG on eMMC instead of SPI flash, so we don't
need this region anymore. Getting rid of it allows us to put more space
into CBFS (to store hi-res bitmaps). Also grow VPD by some remaining
amount to keep the FMAP alignment reasonable.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: If73450b65718affae71b6ada70ded5c5f45cfb4c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41980
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Philip Chen <philipchen@google.com>
|