Age | Commit message (Collapse) | Author |
|
Suggested by Nico Huber in CB:38766
Change-Id: Ib8a340f17a12951bc6bc67e3093046575e7b0e46
Signed-off-by: Eugene D Myers <cedarhouse@comcast.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40438
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
Suggested by Nico Huber in CB:38765.
This placement makes the address calculation simpler and
makes its location indepedent of the number of CPUs.
As part of the change in the BIOS resource list address
calculation, the `size` variable was factored out of the
conditional in line 361, thus eliminating the else.
Change-Id: I9ee2747474df02b0306530048bdec75e95413b5d
Signed-off-by: Eugene D Myers <cedarhouse@comcast.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40437
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Add a FMAP which supports SMMSTORE and non-ChromeOS payloads,
since Apollo Lake-based devices like Reef cannot use an
automatically-generated FMAP due to strict layout requirements.
Change-Id: If570f92f4f81c0e29777c87756fc5e45af549064
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40907
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
Drop the DeepSx config as it's unsupported and disabled for the boards.
Change-Id: I91cd15b26a41f376561630cf45ffa192745eae84
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40858
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
The table of initial i440BX register values has a bitmask that allows
preserving certain bits as they are programmed. This feature has been
unused since day one and probably will never be used. So drop it.
Drop DRB, RPS, PGPOL registers from the table as they will be
programmed during RAM init. These two reductions combined saved ~104
bytes.
Drop unneeded SDRAMC "+0".
Slightly compact a comment block.
TEST=Boot tested on asus/p2b-ls, i440bx config did not change
Change-Id: I020f616455bb671fe284993a488beb6386a03d0d
Signed-off-by: Keith Hui <buurin@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40391
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
This change makes power_res_dev_states[] to be static const * const as
complained by Jenkins.
BUG=b:155428745
Change-Id: Ice2fff6ab3bcd72a059bc905b7462a681f2e6aaf
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40935
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
This change adds a helper function cpu_get_lapic_addr() that returns
LOCAL_APIC_ADDR for x86. It also adds a weak default implementation
which returns 0 if platform does not support LAPIC. This is being
done in preparation to move all ACPI table support in coreboot out of
arch/x86.
BUG=b:155428745
Change-Id: I4d9c50ee46804164712aaa22be1b434f800871ec
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40929
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
|
|
ACPI_SATA_GENERATOR is currently used to include sata.c in
ramstage. However, there is no need to guard this inclusion using a
separate Kconfig. All other files that deal with ACPI tables are
included based on the state of HAVE_ACPI_TABLES. This change includes
sata.c in ramstage if HAVE_ACPI_TABLES is selected. If the ACPI
function isn't used, linker will optimize it out.
BUG=b:155428745
Change-Id: I9a319cfe7c3f973b15ccbd0f13bd1ed07571a398
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40928
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
I rushed CB:40895 in to fix a bug only to introduce another. xhci_init()
no longer crashes, but it doesn't correctly initialize the XHCI
controller either, and unfortunately the error messages are all hidden
behind USB_DEBUG. This patch fixes the incorrect address calculation to
what it was before CB:39838.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I14293e2135108db30ba6fd2efea0573fe266fa37
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40956
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
In order to isolate mainboard code from direct FSPS manipulation
allow sd/emmc0 configuration to be supplied by devicetree.cb.
BUG=b:153502861
Change-Id: I2569ccccd638faaf2c9ac68fe582ecb9fa967d9f
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/coreboot/+/2146439
Commit-Queue: Aaron Durbin <adurbin@google.com>
Tested-by: Aaron Durbin <adurbin@google.com>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40876
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
AMD has rewritten AGESA (now at v9) for direct inclusion into UEFI
build environments. Therefore, unlike the previous Arch2008
(a.k.a. v5), it can't be built without additional source, e.g. by
combining with EDK II, and it has no entry points for easily
building it into a legacy BIOS.
AGESA in coreboot now relies on the FSP 2.0 framework published
by Intel and uses the existing fsp2_0 driver.
* Add fsp_memory_init() to romstage.c. Although Picasso comes out
of reset with DRAM alive, this call is added to maximize
compatibility and facilitate internal development. Future work
may look at removing it. AGESA reports the memory map to coreboot
via HOBs returned from fsp_memory_init().
* AGESA currently sets up MTRRs, as in most older generations.
Take ownership back immediately before running ramstage.
* Remove cbmem initialization, as the FSP driver handles this.
* Add chipset_handle_reset() for compatibility.
* Top of memory is determined by the FSP driver checking the HOBs
passed from AGESA. Note that relying on the TOM register happens
to be misleading when UMA is below 4GB.
BUG=b:147042464
TEST=Boot trembyle to payload
Change-Id: Iecb3a3f2599a8ccbc168b1d26a0271f51b71dcf0
Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34423
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
FSP AGESA overrides the MTRRs that coreboot set up. Until this is fixed
we need to save and restore the MTRRs to undo what AGESA did.
Once AGESA is fixed, we can delete these files.
BUG=b:155426691, b:147042464
TEST=Boot trembyle and see MTRRs being modified
Saving Variable MTRR 0: Base: 0x00000000 0xff000005, Mask: 0x0000ffff 0xff000800
Saving Variable MTRR 1: Base: 0x00000000 0x08070006, Mask: 0x0000ffff 0xffff0800
Saving Variable MTRR 2: Base: 0x00000000 0x00000000, Mask: 0x00000000 0x00000000
Saving Variable MTRR 3: Base: 0x00000000 0x00000000, Mask: 0x00000000 0x00000000
Saving Variable MTRR 4: Base: 0x00000000 0x00000000, Mask: 0x00000000 0x00000000
Saving Variable MTRR 5: Base: 0x00000000 0x00000000, Mask: 0x00000000 0x00000000
Saving Variable MTRR 6: Base: 0x00000000 0x00000000, Mask: 0x00000000 0x00000000
Saving Variable MTRR 7: Base: 0x00000000 0x00000000, Mask: 0x00000000 0x00000000
Saving Fixed MTRR 0: 0x00000000 0x00000000
Saving Fixed MTRR 1: 0x00000000 0x00000000
Saving Fixed MTRR 2: 0x00000000 0x00000000
Saving Fixed MTRR 3: 0x00000000 0x00000000
Saving Fixed MTRR 4: 0x00000000 0x00000000
Saving Fixed MTRR 5: 0x00000000 0x00000000
Saving Fixed MTRR 6: 0x00000000 0x00000000
Saving Fixed MTRR 7: 0x00000000 0x00000000
Saving Fixed MTRR 8: 0x00000000 0x00000000
Saving Fixed MTRR 9: 0x00000000 0x00000000
Saving Fixed MTRR 10: 0x00000000 0x00000000
Saving Default Type MTRR: 0x00000000 0x00000800
Saving SYS_CFG: 0x00000000 0x00000800
...
MSR 0x200 was modified: 0x00000000 0x00000006
MSR 0x201 was modified: 0x0000ffff 0x80000800
MSR 0x202 was modified: 0x00000000 0x80000006
MSR 0x203 was modified: 0x0000ffff 0xc0000800
MSR 0x204 was modified: 0x00000000 0xc0000006
MSR 0x205 was modified: 0x0000ffff 0xf0000800
MSR 0x250 was modified: 0x06060606 0x06060606
MSR 0x258 was modified: 0x06060606 0x06060606
SYS_CFG was modified: 0x00000000 0x00740000
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I6048b25bd8a32904031ca23953f9726754b5a294
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40922
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Perform the P2SB hide/unhide trick. This is needed so that BAR0
(0xfd000000) is not reclaimed by resource allocator, since it can
not deal with a device that does not exist (hidden).
Signed-off-by: Andrey Petrov <anpetrov@fb.com>
Change-Id: I5db0ae4e31d72ba86efba5728b2afc68d3180d5d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40921
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Maxim Polyakov <max.senia.poliak@gmail.com>
|
|
Use common P2SB driver. This is needed to address a problem when
enumerator does not see p2sb device (since it is hidden) but it
is active and BAR is decoded.
Change-Id: I9cb821a5684f15f1e1486872bf806a6ee3d0676f
Signed-off-by: Andrey Petrov <anpetrov@fb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40920
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Maxim Polyakov <max.senia.poliak@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Add p2sb.h that is shared by all currently supported Xeon SP CPUs.
Change-Id: Idcbff7ad587cb116897a953c079fb0a8b86cc2ed
Signed-off-by: Andrey Petrov <anpetrov@fb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40919
Reviewed-by: Maxim Polyakov <max.senia.poliak@gmail.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Enable P2SB in static device tree so that hide/unhide trick
works.
Change-Id: I7dc20b001605b715155d333a07580e21a5f24136
Signed-off-by: Andrey Petrov <anpetrov@fb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40918
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Maxim Polyakov <max.senia.poliak@gmail.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
These parameters were found to work fine for 2-socket configuration,
for FSP based on tag 16.D.21.
Signed-off-by: Andrey Petrov <anpetrov@fb.com>
Change-Id: I466a7f2951ef307036ddaed0be0aacf98dd2710f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40917
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Maxim Polyakov <max.senia.poliak@gmail.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
It is necessary to rename the file gpio.h so that there are no conflict
with another file (src/include/gpio.h)
Change-Id: I4e3ef5882d6cb0ddbcb8357b54106ff2f47e4c51
Signed-off-by: Maxim Polyakov <max.senia.poliak@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40733
Reviewed-by: Andrey Petrov <andrey.petrov@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: I8599dca99c1f34e3937c5b77b3505815ce625b46
Signed-off-by: Maxim Polyakov <max.senia.poliak@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39453
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
If the current pad configuration can not be defined using standard
macros from the gpio_defs.h [1], then the intelp2m utility generates
"advanced" _PAD_CFG_STRUCT() macros. However, often this configuration
in the vendor’s firmware is erroneous. Change the extended macros to
standard ones taking into account the information based on the schematic
diagram and the previous GPIO configuration for FSP-M [2].
[1] src/soc/intel/common/block/include/intelblocks/gpio_defs.h
[2] src/mainboard/ocp/tiogapass/skxsp_tp_gpio.h
Change-Id: I56e45b1df77acbdd67e6325c3745a7ad137f8805
Signed-off-by: Maxim Polyakov <max.senia.poliak@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40732
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Andrey Petrov <andrey.petrov@gmail.com>
|
|
This format of PCH GPIOs configuration, unlike the raw DW0 and DW1
registers values from the inteltool dump, is more understandable and
makes the code much cleaner. The gpio.h file with PAD_CFG macros was
automatically generated using the util/intelp2m [1] utility:
./intelp2m -p lbg -file tiogapass/vendorbios/inteltool_gpio.log
According to the documentation [2], the Host Software Pad Ownership
register only affects the pads that are configured as input (GPI).
The intelp2m utility takes this into account when converting macros
and ignores bits from this register for the corresponding pads.
[1] https://review.coreboot.org/c/coreboot/+/35643
[2] Intel Document Number: 549921
Change-Id: I21e98721e58b00be9196927837daa2b5d2560822
Signed-off-by: Maxim Polyakov <max.senia.poliak@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40731
Reviewed-by: Andrey Petrov <andrey.petrov@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
According to changes in the soc/xeon_sp code [1,2], server motherboards
with Lewisburg PCH can use the soc/intel/common/gpio driver to configure
GPIO controller. This patch adds pads configuration map, which has the
format required by the GPIO driver. The data for this was taken from the
inteltool register dump with AMI firmware. The gpio.h file with pad
configuration was generated automatically using the util/intelp2m [3]:
./intelp2m -raw -p lbg -file tiogapass/vendorbios/inteltool_gpio.log
[1] https: //review.coreboot.org/c/coreboot/+/39425
[2] https: //review.coreboot.org/c/coreboot/+/39428
[3] https: //review.coreboot.org/c/coreboot/+/35643
Change-Id: I818d040fa33f3e7b94b73c9bbbafca5df424616d
Signed-off-by: Maxim Polyakov <max.senia.poliak@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39427
Reviewed-by: Andrey Petrov <andrey.petrov@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Since CPX FSP headers are not released yet, populate certain
settings with hard-coded offsets. Provided values are probably
not correct and I do not understand what they mean and there is
no documentation available yet. However they were found to work
to a certain degree.
TEST=tested on OCP Sonora Pass EVT
Change-Id: I0f78cde69cb8a49a388a412b97bf8713e5b380ea
Signed-off-by: Andrey Petrov <anpetrov@fb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40554
Reviewed-by: Andrey Petrov <andrey.petrov@gmail.com>
Reviewed-by: Maxim Polyakov <max.senia.poliak@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: I9b15b5458bb8140fa9bb6b0ffb6b9c78e8d8a93b
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40848
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Just a minimal set of board files needed to get it to boot
in 1 CPU mode.
Signed-off-by: Ryback Hung <ryback.hung%quantatw.com@gtempaccount.com>
Change-Id: Ia7b45c78b38d091bd9535899b681746e13efb4fe
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40469
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Maxim Polyakov <max.senia.poliak@gmail.com>
Reviewed-by: Andrey Petrov <andrey.petrov@gmail.com>
|
|
Change-Id: I353daf35c843521b089ff8411a9ba8c801605ff9
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40846
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Change-Id: Ie213b8c08e2d2b33a1dc1fda632163160d1cd70e
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40849
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Change-Id: If7e2c84c39039e0dc6811f247390f856fc634b33
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40844
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Change-Id: I09cc69a20dc67c0f48b35bfd2afeaba9e2ee5064
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40843
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Change-Id: I0fd1a758d8838b3eea5640b41eee6a6893360aa3
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40850
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
The AMD64 Architecture Programmer's Manual, Volume 2: Systems
Programming says the following about variable MTRRs:
Variable Range Size and Alignment.
The size and alignment of variable memory-ranges (MTRRs) and I/O ranges
(IORRs) are restricted as follows:
* The boundary on which a variable range is aligned must be equal to the
range size. For example, a memory range of 16 Mbytes must be aligned on a
16-Mbyte boundary (i.e., naturally aligned).
* The range size must be a power of 2 (2^n , 52 > n > 11), with a minimum
allowable size of 4 Kbytes. For example, 4 Mbytes and 8 Mbytes are
allowable memory range sizes, but 6 Mbytes is not allowable.
Print out errors if these conditions are violated. I didn't assert since
`set_var_mtrr` can be used in boot block before the serial console is
enabled.
BUG=b:147042464
TEST=Boot trembyle and see MTRR errors:
MTRR Error: base 0xcc800000 must be aligned to size 0x1000000
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I8b8c734c7599bd89cf9f212ed43c2dd5b2c8ba7b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40762
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Let's gather some documentation ideas for the season of docs. I reused
the project ideas style (thanks Patrick). Feel free to add yourself as a
mentor here. Also if you have more ideas, please add them to the
document.
Change-Id: I72221cbd53b99cdc946109753cf72af9c865a1e5
Signed-off-by: Christian Walter <christian.walter@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40662
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: I11b8743234cb1292db8c930edecf8fb5c47d63fd
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40741
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
Add GPIO_PCH_WP (GPP_C11) to associate GPP_PCH_WP with community
zero.
TEST=Build coreboot, flash, boot to
and log into kernel, execute "wp enable" in console,
execute "crossystem" at kernel prompt and verify that "wpsw_cur"
shows as being "1", Execute "wp disable" in console, execute
"crossystem" at kernel prompt and verify "wpsw_cur" is 0.
Change-Id: Ie4ae1365a7611b8be3e795798c171e3f7ea9e417
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40744
Reviewed-by: Usha P <usha.p@intel.com>
Reviewed-by: Maulik V Vaghela <maulik.v.vaghela@intel.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
BUG=b:153642124
TEST=Saw I2C communication
Change-Id: I31f8b97d1ff7b687d7e078d5b594d1ad73c815e7
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/coreboot/+/2145457
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40868
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
sb_reset_i2c_slaves is called in fch_pre_init.
BUG=b:153675916
TEST=Builds on trembyle
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I157e473984257d633ceb3ef9df45c71a31c5c00b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40867
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
fch_early_init already calls i2c_soc_early_init().
BUG=b:153675916
TEST=Boot trembyle and only see 1 i2c initialization message
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I689616fb617904df1781be3abe9d1dc580608173
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40866
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Mainboards must provide their DDI descriptors.
BUG=b:153502861
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/coreboot/+/2146443
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/coreboot/+/2146439
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/coreboot/+/2146438
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/coreboot/+/2145453
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/coreboot/+/2145454
Change-Id: Ib3f115711e74d0e6eb5b063b3dccb36b265779af
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40875
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
The expected error code observed in clear_pending_events() should
be EC_RES_UNAVAILABLE(9), not EC_RES_INVALID_COMMAND(1).
BUG=b:153896701
Change-Id: I609490ceef675267760d34b5e9775211da93347c
Signed-off-by: Victor Ding <victording@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40900
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Harrison Peak (HrP) 9560 module needs a reset pin for BT power sequence.
BUG=b:155248677
TEST=Boot into OS and check BT is functional.
Signed-off-by: Eric Lai <ericr_lai@compal.corp-partner.google.com>
Change-Id: I55ed1b095ba53c414c44088f4a6e7720b970e2f2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40831
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
understanding
BIT 1 -> DEBUG_INTERFACE_UART_8250IO
BIT 4 -> DEBUG_INTERFACE_LPSS_SERIAL_IO
Change-Id: I566b9dc82b2289af42e58705ebeee51179886f1f
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40904
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Wonkyu Kim <wonkyu.kim@intel.com>
|
|
Update USB3 ports configuration as schematics design.
BUG=b:155026295
TEST=Boot into OS and check WWAN device detected by lsusb.
Signed-off-by: Ivy Jian <ivy_jian@compal.corp-partner.google.com>
Change-Id: Icb938e5a9c05fcc9772219b081a6f05334261baf
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40818
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
An array of 64bit integers is passed to acpi_dp_add_integer_array() but
it is not const so can't take a const array without a compiler error.
The function does not modify the array so it can be made const without
breaking anything and allowing a const array to be passed in the future.
BUG=b:146482091
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Change-Id: I98ecdaef5ddfa2026390e2812f5ea841ee51f073
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40882
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
The generic container HID is defined in ACPI specification as PNP0A05.
BUG=b:146482091
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Change-Id: I3632e77533a47f22b92259b469b03e63f51687e0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40881
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
Currently if a child table is created and added to a property list
without adding any properties to that child it will generate an
empty package. For example:
struct acpi_dp *dsd = acpi_dp_new_table("_DSD");
struct acpi_dp *prop = acpi_dp_new_table("PROP");
acpi_dp_add_child(dsd, "dsd-prop", prop);
acpi_dp_write(dsd);
Results in an empty PROP package:
Name (_DSD, Package (2)
{
ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b")
Package (1) {
Package (2) {
"dsd-prop",
"PROP"
}
}
}
Name (PROP, Package (0)
{
}
Empty packages don't seem to be explicitly forbidden, but they don't
serve a purpose with device properties. Instead, if packages without
any properties or children are skipped then this empty package is not
written and the added child property can refer to another property that
is already defined.
This allows creating property references to existing tables, which can
save duplication and namespace collision issues with nested properties.
BUG=b:146482091
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Change-Id: I9fee2ceb8a4496b90c7210533eee8c2b186cdfff
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40880
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
BUG=b:152019429
BRANCH=None
TEST=1. provision dram_part_num field of CBI
2. modify mainboard - dedede to report DRAM part number from CBI
3. check DRAM part number is correct in SMBIOS for memory device
Change-Id: I509d06a81bd005c5afe6e74a2da2ca408dee7b29
Signed-off-by: Marco Chen <marcochen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40833
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
|
|
Separate specific setting to variant from baseboard.
baseboard/romstage.c in current release is only utilized by
careena, we could remove it from the rest of variant build.
BUG=b:154357210,b:154848243
BRANCH=master
TEST=emerge-grunt coreboot
Change-Id: I658526e44aadc47bdc5538f506a1bfe2e5f20f63
Signed-off-by: Kevin Chiu <Kevin.Chiu@quantatw.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40796
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Fix FSP CAR on platforms that have ROM_SIZE of 32MiB.
CodeRegionSize must be smaller than or equal to 16MiB
to not overlap with LAPIC or the CAR area at 0xfef00000.
Tested on Intel CFL, the new code allows to boot using FSP-T.
Change-Id: I4dfee230c3cc883fad0cb92977c8f5570e1a927c
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39491
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Andrey Petrov <andrey.petrov@gmail.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
Fix code blocks, add a newline, use inline code blocks for commands.
Change-Id: Iecf04b00ed12323c124517f2557cc8b60640b618
Signed-off-by: Evgeny Zinoviev <me@ch1p.io>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39670
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Peter Lemenkov <lemenkov@gmail.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
LTE module is lost after idle overnight, with this workaround,
host will not initiate U3 wakeup at the same time with device,
which will avoid the race condition.
Disable XHCI LFPS power management.
If the option is set in the devicetree, the bits[7:4] in
XHCI MMIO BAR + offset 0x80A4 (PMCTRL_REG) will be updated
from default 9 to 0.
BUG=b:146768983
BRANCH=octopus
TEST=build coreboot with DisableXhciLfpsPM being set to 1 and flash
the image to the device. Run following command to check if
bits[7:4] is set 0:
>iotools mmio_read32 "XHCI MMIO BAR + 0x80A4"
Signed-off-by: Pan Sheng-Liang <sheng-liang.pan@quanta.corp-partner.google.com>
Change-Id: Ib8e5ae79e097debf0c75ead232ddbb2baced2a2a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40303
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marco Chen <marcochen@google.com>
Reviewed-by: Henry Sun <henrysun@google.com>
Reviewed-by: Justin TerAvest <teravest@chromium.org>
|