This driver applies to 10ec:8168
Previously, this driver resetted the nic and set a hardcoded
MAC address. Now the driver reads a default MAC address
from CBFS in the form of a string:
echo -n "xx:xx:xx:xx:xx:xx" > macaddress
and store the macaddress file in CBFS with the same name.
TESTED on GA-G41M-ES2L and GA-945GCM-S2L:
MAC address was detected
Change-Id: If1af91120fa3efca3f1406334a83ed1e59fbdaf9
Signed-off-by: Damien Zammit <damien@zamaudio.com>
Reviewed-on: https://review.coreboot.org/17672
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
This makes CHIPSEC happy. We don't enable PAVP, but it shouldn't hurt
to lock it nevertheless.
Change-Id: I9428f0b6e8868832eb79f7aea24cbc7961c2aa8f
Signed-off-by: Dennis Wassenberg <dennis.wassenberg@secunet.com>
Reviewed-on: https://review.coreboot.org/17352
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
CHIPSEC found that the TCO_Lock was not set.
This is used to prevent changing the TCO_EN bit.
Change-Id: I42364dbef2511e656662566cf94591e76c6847ed
Signed-off-by: Dennis Wassenberg <dennis.wassenberg@secunet.com>
Reviewed-on: https://review.coreboot.org/17351
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The EM4/EM5 registers in the mini-HD audio device must be set based
on the GPU cdclk value in order for HDMI audio to function properly.
Add variables to save the correct values when initializing the GPU,
and accessor functions to retrieve them in order to set the registers
when initializing the mini-HD audio device.
Change-Id: Icce7d5981f0b2ccb09d3861b28b843a260c8aeba
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/17718
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
Simplify set_power_led() by consolidating switch and setting values
as needed inline based on LED state.
Fix non-off LED polarity for Tricky using correct value from Chromium source
TEST: power on Tricky, observe LED lit / solid
Change-Id: I8bc7c4ae3f83d3f37b76fd5c90a4faed7057ebee
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/17719
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Add helper function to find a device by path type
in the device tree.
Change-Id: I8846f63bd2488788ea3c7ab5154e7cf431a252bc
Credits-to: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Signed-off-by: Dhaval V Sharma <dhaval.v.sharma@intel.com>
Reviewed-on: https://review.coreboot.org/17731
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
1. Define controller for fast SPI.
2. Separate out functions that are specific to SPI and flash controller
in different files.
BUG=chrome-os-partner:59832
BRANCH=None
TEST=Compiles successfully for reef.
Change-Id: If07db9d27bbf4f4eb6024175cb7753c6cf4fb793
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/17562
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
1. Add new structure spi_ctrlr_buses that allows platform to define a
mapping from SPI controller to buses managed by the controller.
2. Provide weak implementations of spi_init and spi_setup_slave that
will be used by platforms using the new interface.
BUG=chrome-os-partner:59832
BRANCH=None
TEST=Compiles successfully
Change-Id: Ia6f47941b786299f4d823895898ffb1b36e02f73
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/17561
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Skylake uses a special SPI Flash controller and does not require
spi_claim_bus and spi_release_bus functionality. This was a leftover
call from earlier cleanup, so remove it.
Change-Id: Iea260813cf72b94b7e7c661dbe494a74351dc357
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/17729
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add the new time stamps *finalize chips* to track, when the method
`dev_finalize_chips()` is called, so that the real time of
`write_tables()` is known.
Change-Id: I65ca0ec4c07c2eaa14982989cb206d23d8a2293f
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: https://review.coreboot.org/17725
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
This will be used by new Roda boards. Four UARTs and PS/2 keyboard and
mouse are exposed to ACPI. Since our boards only use the environment
controller part, most of the usual pnp interfaces are untested.
Change-Id: Ifeb0327ad115759411716f82585ace5ce55b8464
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/17287
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
ITE super-i/o chips need a fourth byte and have a special register
to exit config mode.
Change-Id: Ic40873649d567b87d3a937f2bf068649e67715de
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/17286
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Resource is actually stored even before read_resources, but
that's where we currently log this resource.
For Intel, use PCI config register offset as the resource
index, while AMD side uses MSR address.
Change-Id: I6eeef1883c5d1ee5bbcebd1731c0e356af3fd781
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17696
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Doing PCI config operations via MMIO window by default is a
requirement, if supported by the platform. This means chipset
or CPU code must enable MMCONF operations early in bootblock
already, or before platform-specific romstage entry.
Platforms are allowed to have NO_MMCONF_SUPPORT only in the
case it is actually not implemented in the silicon.
Change-Id: Id4d9029dec2fe195f09373320de800fcdf88c15d
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17693
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
- Drastically reduced RW_MRC_CACHE size to hold one update. Now
that this area isn't changing after every S5 entry there's no
need make it so large.
- ELOG area reduced by 4KiB for subsequent area alignment. In practice
this doesn't matter because the elog library only uses 4KiB bytes.
16KiB->12KiB is a nop.
- Moved RW_NVRAM for subsequent alignment.
- Most importantly, RW_SECTION_(A|B) are aligned to 64KiB boundaries
and sized to 64KiB multiples. This ensures updates don't need a
read-modify-write that could force a system into recovery if
an inopportune power event occurred.
BUG=chrome-os-partner:60492
BRANCH=reef
Change-Id: I2a2e2797897c934db1a3f9627c6c13a9b2aad540
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/17727
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
We may support different sdram sizes on one board in future, so
we need to calculate sdram sizes from sdram drvier.
BRANCH=None
BUG=None
TEST=boot kevin
Change-Id: I43e8f164ecdb768c051464b4dbc7d890df8055d0
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 3c4d8b3cb647b2f9cebc416c298817c16d49330e
Original-Change-Id: I95d5ef34de9d79ebca3600dc7a4b9e14449606ff
Original-Signed-off-by: Lin Huang <hl@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/411600
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/17629
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Gru only uses USB 2.0 in firmware to avoid all the madness associated
with Type-C port orientation and USB 3.0 tuning. We do this by isolating
the SuperSpeed lines in the Type-C PHY so it looks like they aren't
connected to the device.
Unfortunately, some devices seem to already get "locked" into SuperSpeed
mode as soon as they detect Rx terminations once, and can never snap out
again on their own. Since the terminations are already connected during
power-on reset we cannot disable them fast enough to prevent this, and
the only solution we found to date is to power-cycle the whole USB port.
Now, Gru's USB port power is controlled by the EC, and unfortunately we
have no direct host command to control it. We do however have a command
to force a certain USB PD "role", and forcing our host into "sink" mode
makes it stop sourcing power to the port. So for lack of a saner
solution we'll use this to work around our problem.
BRANCH=gru
BUG=chrome-os-partner:59346
TEST=Booted Kevin in recovery mode, confirmed that my "problem stick"
gets detected immediately (whereas previously I had to unplug/replug
it). Booted Kevin to OS in both developer and normal mode and confirmed
that USB still seems to work.
Change-Id: Ib3cceba9baa170b13f01bd5c01bd413be5b441ba
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: cd695eda33299e50362f1096c46f2f5260c49036
Original-Change-Id: I2db3d6d3710d18a8b8030e94eb1ac2e931f22638
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/413031
Reviewed-on: https://review.coreboot.org/17628
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Normally firmware should have no business messing with the USB PD role
(source/sink/whatever) in the EC. But, as so often happens, ugly issues
crop up that require weird work-arounds, and before you know it you need
to do this for some reason that only makes sense in context. I do now,
so add this function to send the necessary host command in the simplest
possible fashion.
BRANCH=gru
BUG=chrome-os-partner:59346
TEST=Used it in a follow-up patch.
Change-Id: I07d40feafd6a8387a633d6384efb205baf578d76
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 8b71767caccff9b77d458182ce8066f7abf6321c
Original-Change-Id: Ie8d0be98f6b703f4db062fe2f728cd2588347202
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/413030
Original-Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-on: https://review.coreboot.org/17627
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Resource allocator and 64-bit PCI BARs will need it and
PCI use is not really restricted to x86.
Change-Id: Ie97f0f73380118f43ec6271aed5617d62a4f5532
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17733
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
MMCONF operations are already the default so these
would never be used.
Change-Id: I671f3d2847742e400bc4ecfccc088e3b79d43070
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17691
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
MMCONF was explicitly used here to avoid races of 0xcf8/0xcfc access
being non-atomic and/or need to access 4kiB of PCI config space.
All these platforms now have MMCONF_SUPPORT_DEFAULT.
I liked the style of code in pci_mmio_cfg.h more, and used those to
replace the ones in io.h.
Change-Id: Ib5e6a451866c95d1edb9060c7f94070830b90e92
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17689
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The code originates from times before __SIMPLE_DEVICE__ was
introduced. To keep behaviour unchanged, use explicit PCI
IO operations here.
Change-Id: I44851633115f9aee4c308fd3711571a4b14c5f2f
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17720
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
MMCONF was explicitly used here to avoid races of 0xcf8/0xcfc access
being non-atomic and/or need to access 4kiB of PCI config space.
All these platforms now have MMCONF_SUPPORT_DEFAULT.
Change-Id: If62537475eb67b7ecf85f2292a2a954a41bc18d1
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17545
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
MMCONF was explicitly used here to avoid races of 0xcf8/0xcfc access
being non-atomic and/or need to access 4kiB of PCI config space.
All these platforms now have MMCONF_SUPPORT_DEFAULT.
Change-Id: I943e354af0403e61263f1c780f02c7b463b3fe11
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17529
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Linux needs these SBI calls, but so far it seems to work when they don't
do anything.
Change-Id: I2cd0bb3ab91e89805fed84ec87e4a48ce70c3a46
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/17593
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Do not abort the initialization of PTN3460 if HW-ID could not be
retrieved and just assume that the HW-ID does not match 7.9.2.0.
In this case PTN3460 will be setup to a working condition even
if this field is missing.
This makes this driver more robust with faulty blocks.
Change-Id: I301fb165a7924768e44182d92be820294beb0280
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/17671
Tested-by: build bot (Jenkins)
Reviewed-by: Mario Scheithauer <mario.scheithauer@siemens.com>
While searching for a field in all blocks ensure that the checked block
is available and can be used. In this way a field can be retrieved from
every block and not just the first one.
Change-Id: Idbd7656ab0664763cb065f5e817193ad1d9e0871
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/17670
Tested-by: build bot (Jenkins)
Reviewed-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Boards with this chipset do not have any reference of
MMCONF_BASE_ADDRESS being written to chipset registers.
Either board support is already broken or FSP takes
care of this early and Kconfig lacks the notice that
this parameter must match with the chosen FSP binary.
CPU bootblock associated with this chipset uses
exclusive PCI IO access already.
Untested.
Change-Id: I07d20d81266ff6aaa6384d20a806d52fd4568e08
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17547
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit 36b81af (spi: Pass pointer to spi_slave structure in
spi_setup_slave) changes the way spi_setup_slave handles the spi_slave
structure. Instead of expecting spi controller drivers to maintain
spi_slave structure in CAR_GLOBAL/data section, caller is expected to
manage the spi_slave structure. This requires that spi_flash drivers
maintain spi_slave structure and flash probe function needs to make a
copy of the passed in spi_slave structure.
This change fixes the regression on Lenovo X230 and other mainboards.
Change-Id: I0ad971eecaf3bfe301e9f95badc043193cc27cab
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/17728
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Iru Cai <mytbk920423@gmail.com>
These headers & comments indicating a lack of functionality don't help
anything. We discourage copyrights and licenses on empty files, so
just clear these.
Change-Id: Id2ab060a2726cac6ab047d49a6e6b153f52ffe6d
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/17657
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
Combine existing boards google/falco and google/peppy with new
ChromeOS devices leon and wolf, using their common reference board
(slippy) as a base.
Chromium sources used:
firmware-falco_peppy-4389.81.B d7703cac [falco: Add support for Samsung...]
firmware-leon-4389.61.B ea1bf55 [haswell: Enable 2x Refresh Mode]
firmware-wolf-4389.24.B 7c5a9c2 [Wolf: haswell: Add small delay before...]
Additionally, some minor cleanup/changes were made:
- I2C devices set to use ACPI (vs PCI) mode
- I2C device ACPI entries adjusted as per above
- I2C devices set to use level (vs edge) interrupt triggering
- XHCI finalization enabled in devicetree
- HDA verb entries use simplified macro entry format
Existing google/falco and google/peppy boards will be removed in a
subsequent commit.
Variant setup modeled after google/beltino
Change-Id: I087df5f98c1bb4ddd0ab24ee9ff786a9d38d87be
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/17621
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
No need for these boards to exist separately once included as
variants under google/slippy
Change-Id: I52a476ceaadf50487d6fe21e796d7844f946d8b3
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/17622
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Follow on patch to clean up the previous retry code.
Previous patches:
coreboot commit 079b5c65
(rockchip/rk3399: display: Retry edp initialization if it fails)
cros commit 28c57a6e
(rockchip/rk3399: display: retry edp initialization if edp initial fail)
- Reduce the jumping around via goto statements
- Break the retry code out into a separate function that also
prints the error messages.
BRANCH=gru
BUG=chrome-os-partner:60150
TEST=Rebuild Kevin and Gru
Change-Id: I3b6cf572073e4dcac83da09621bafde179af2613
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/17642
Tested-by: build bot (Jenkins)
Reviewed-by: Julius Werner <jwerner@chromium.org>
Split raminit.c into smaller parts. Move all functions that will
be used by chip-specific code into raminit_common.c.
The chip-specific changes includes new configuration values
for IvyBridge and 100Mhz reference clock support, including new
frequencies.
No functionality is changed.
Tested on Lenovo T420.
Change-Id: If7bb5949f4b771430f3dba1b754ad241a7e8426b
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/17604
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
1. Define a new structure spi_ctrlr that allows platforms to define
callbacks for spi operations (claim bus, release bus, transfer).
2. Add a new member (pointer to spi_ctrlr structure) in spi_slave
structure which will be initialized by call to spi_setup_slave.
3. Define spi_claim_bus, spi_release_bus and spi_xfer in spi-generic.c
which will make appropriate calls to ctrlr functions.
BUG=chrome-os-partner:59832
BRANCH=None
TEST=Compiles successfully
Change-Id: Icb2326e3aab1e8f4bef53f553f82b3836358c55e
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/17684
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
For spi_setup_slave, instead of making the platform driver return a
pointer to spi_slave structure, pass in a structure pointer that can be
filled in by the driver as required. This removes the need for platform
drivers to maintain a slave structure in data/CAR section.
BUG=chrome-os-partner:59832
BRANCH=None
TEST=Compiles successfully
Change-Id: Ia15a4f88ef4dcfdf616bb1c22261e7cb642a7573
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/17683
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
1. Use size_t instead of unsigned int for bytes_out and bytes_in.
2. Use const attribute for spi_slave structure passed into xfer, claim
bus and release bus functions.
BUG=chrome-os-partner:59832
BRANCH=None
TEST=Compiles successfully
Change-Id: Ie70b3520b51c42d750f907892545510c6058f85a
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/17682
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add support for Kaby Lake RVP7 board
* Add RVP7 board support in Kconfig
* Override default descriptor and ME binary paths in Kconfig
since those binaries will differ for RVP3 and RVP7
* Add RVP7 board name in board_info.txt and Kconfig.name
* Add devicetree.cb for RVP7 in the variants path
* Add gpio.h for RVP7 in variants/include/variant path
* Made board specific code for retrieving spd, i.e., in RVP7
there is non-soldered DIMMs, so SPD is read through smbus,
unlike RVP3 where memory DIMMs are soldered down with board.
Hence for RVP3, the spd binaries will be fixed and can be
kept as binary file in cbfs.
BUG=none
BRANCH=none
TEST=Built and boot Kaby Lake RVP7
Change-Id: I6f3d17d857bad1b5cf39f0bc900c760fee72da48
Signed-off-by: Barnali Sarkar <barnali.sarkar@intel.com>
Reviewed-on: https://review.coreboot.org/17637
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
TRAINING, not TARINING.
BUG=none
BRANCH=none
TEST=still builds
Change-Id: I8b7ffd0f0544a58865865a8b09d9c153db9c2674
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: b1ea846ce1ffd654d7d34c2a1d43b0fddbd4ae32
Original-Change-Id: I4940279ed7217cc20fe29c8b3603d1853acbfc5e
Original-Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/411801
Original-Commit-Ready: Patrick Georgi <pgeorgi@chromium.org>
Original-Tested-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Reviewed-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://review.coreboot.org/17677
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Nico Huber <nico.h@gmx.de>
With addition of new features in VBT its size got increased
more than 6k and was unable to pass using mailbox 4 hence pass
using mailbox 3 to kernel.
BRANCH=none
BUG=chrome-os-partner:60026
TEST=firmware screen and Chrome OS screen should come up.
Change-Id: I359cf9bc402881161c9623cada689496716e04a5
Signed-off-by: Abhay Kumar <abhay.kumar@intel.com>
Reviewed-on: https://review.coreboot.org/17585
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Provide the rise and fall times for the i2c buses and let the
library perform the necessary calculations for the i2c
controller registers instead of manually tuning the values.
BUG=chrome-os-partner:58112
BRANCH=master
TEST=emerge-pyro coreboot
Change-Id: I68be9b96dc731eb0084ee5e15921866818637e73
Signed-off-by: Kevin Chiu <Kevin.Chiu@quantatw.com>
Reviewed-on: https://review.coreboot.org/17652
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Independent of Board DMIC configuration, add all DMIC points
i.e. add DMIC-1ch, DMIC-2ch, DMIC-4ch endpoints.
This allows flexibility to userspace to open capture devices as needed.
This is a temporary fix; once upper layers support choosing
particular channels from 4-ch PCM stream, we will limit exposing only
DMIC-4ch endpoint.
BUG=chrome-os-partner:60444
BRANCH=none
TEST=Verify All DMIC blobs are included
Change-Id: I9729a3570c0668f3da4e7986291ebad6fe1de47a
Signed-off-by: Sathyanarayana Nujella <sathyanarayana.nujella@intel.com>
Reviewed-on: https://review.coreboot.org/17660
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
As per guidelines CPU security level should be dropped before OS start,
so that certain MSRs are locked out. Drop privilege levels on all logical
CPUs.
BUG=chrome-os-partner:60454
TEST=iotools rdmsr x 0x120, make sure bit 6 is set, rdmsr x 0x121 results
in io error.
Change-Id: I67540f6da16f58b822db9160d00b7a5e235188db
Signed-off-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-on: https://review.coreboot.org/17665
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Currently we enable ACPI PM timer emulation only on BSP. So the timer
doesn't work on other cores and that breaks OSes that use it. Also,
microcode uses this information to figure out ACPI IO base, and that
is used for other features. This patch enables ACPI timer emulation
on all the logical CPUs.
BUG=chrome-os-partner:60011
TEST=iotools rdmsr x 0x121, x={0..3}, make sure it is set
Change-Id: I0d6cb8761c1c25d3a2fcf59a49c1eda9e4ccc70c
Signed-off-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-on: https://review.coreboot.org/17663
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Some PCI-e capability registers are located starting from
0x100, these are not accessible using the conventional
PCI IO config operations at 0xcf8/0xcfc, unless PCI_CFG_EXT_IO
was selected.
Thus any feature that calls pciexp_find_extended_cap()
depends on either MMCONF_SUPPORT_DEFAULT or PCI_CFG_EXT_IO
being enabled on the platform.
In theory there can be system without MMCONF_SUPPORT, but
with complete PCI Express configuration space available
using PCI_CFG_EXT_IO. Do not use explicit PCI MMCONF
operations here, but rely on the default PCI access
method to be able to access all of the configuration space.
While at it, convert to IS_ENABLED() everywhere in the source
and organize Kconfig file better.
Change-Id: Ica6e16d2fb2adc532e644c4b2c47806490235715
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17546
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Error reporting can be enabled together with ASPM, there
is no other use for function return value.
Change-Id: I58081fac0df5205a5aea65d735d34b375c2af9cd
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17654
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
In order to mirror the full flexibility of the NHLT library that
allows a caller to set the OEM revision field in the ACPI header
modify the variant callback to override the value.
Change-Id: I16e539b350a50e3c163be1439c8637b82e53a759
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/17651
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins)
In the ACPI header there's an OEM revision field that was previously
just being implicitly set to 0. Allow for a board to provide a
non-zero value for this field.
Change-Id: Icd40c1c162c2645b3990a6f3361c592706251f82
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/17650
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Stash and reload postcar stage in the stage cache for increased
S3 resume speed. It's impact is small (2 ms or so), but there's
no need to go to the boot media on resume to reload something
that was already loaded. This aligns with the same paths we take
on ramstage as well.
Change-Id: I4313794826120853163c7366e81346858747ed0a
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/17649
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Instead of putting all the functions inline just put the
current implementation into a C file. That way all the implementation
innards are not exposed.
Lastly, fix up the fallout of compilation units not including the
headers they actually use.
Change-Id: I01fd25d158c0d5016405b73a4d4df3721c281b04
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/17648
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Instead of having callers query the romstage handoff resume
status by inspecting the object themselves add
romstage_handoff_is_resume() so that the same information
can be queried easily.
Change-Id: I40f3769b7646bf296ee4bc323a9ab1d5e5691e21
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/17647
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
The same pattern was being used throughout the code base
for initializing the romstage handoff structure. Provide
a helper function to initialize the structure with the S3
resume state then utilize it at all the existing call sites.
Change-Id: I1e9d588ab6b9ace67757387dbb5963ae31ceb252
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/17646
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
We don't need to do explicit pci_io_read/write operations,
as we can use MMCONF everywhere. AGESA code still enables
extended cf8/cfc should it be needed by payload or OS.
Change-Id: Ib08028bda1b5226bb3b6b67e91f514480a9fc5ee
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17536
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Vendorcode always does PCI MMCONF access once it is
enabled via MSR.
In coreboot proper, we don't give opportunity to make
pci_read/write calls before PCI MMCONF is enabled via MSR.
This happens early in romstage amd_initmmio() for all cores.
Change-Id: Id6ec25706b52441259e7dc1582f9a4ce8b154083
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17534
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This allows us to set MMCONF_SUPPORT_DEFAULT since we enable
MMCONF early in romstage.
Change-Id: I380cf483bfe4e2d64969110ae6d5d04c3ced2418
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17532
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
We don't need to do explicit pci_io_read/write operations,
as we can use MMCONF everywhere. AGESA code still enables
extended cf8/cfc should it be required by payload or OS.
Change-Id: I278e5e26eb9a247f67927cbc67e04f081ca50f7b
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17535
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Vendorcode always does PCI MMCONF access once it is
enabled via MSR.
In coreboot proper, we don't give opportunity to make
pci_read/write calls before PCI MMCONF is enabled via MSR.
This happens early in romstage amd_initmmio() for all cores.
Change-Id: If31bc0a67b480bcc1d955632f413f5cdeec51a54
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17533
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This allows us to set MMCONF_SUPPORT_DEFAULT since we enable
MMCONF early in romstage.
Change-Id: I994bb257db96300c2eb8872be6fae2a92bbabab4
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17531
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The SSCN and FMCN methods provide the optimal HCNT/LCNT timing values to
the driver, and are necessary when using I2C devices (eg, trackpad and
touchscreen) in ACPI (vs PCI) mode. Add these methods using the
timing values from Broadwell, which work for Haswell/Lynxpoint as well.
TEST: build google/peppy with trackpad/touchscreen devices in ACPI mode,
observe proper operation under Windows [8.1/10] and Linux [Mint 18]
Change-Id: I25f07ac474b041358315530e5f391bb33d9c4d04
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/17620
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Prabal Saha <coolstarorganization@gmail.com>
In bootblock, cpu flex ratio is set to non-turbo max.
In FSP UPD, if CpuRatioOverride is zero, then it tries to program cpu
ratio to zero. Since it is different than the non-zero value programmed
in bootblock, FSP gives reset.
To avoid the reset, set FSP UPD for CPU flex ratio override to that
value as set in bootblock.
Change-Id: I8cae5530ec97cedfbd71771f291db6f55a9fd5c2
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Signed-off-by: Naresh G Solanki <naresh.solanki@intel.com>
Reviewed-on: https://review.coreboot.org/17555
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add support of Variant board model for existing intel/kblrvp,
since there might be more RVP board supports under
intel/kblrvp. Existing is for KBL RVP3 board.
BUG=none
BRANCH=none
TEST=Built and boot Kaby Lake RVP3
Change-Id: I041a07a273dbb77e422d48591f06b5f1011cd9f7
Signed-off-by: Barnali Sarkar <barnali.sarkar@intel.com>
Reviewed-on: https://review.coreboot.org/17630
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Use common lib spd_bin to get spd.
Change-Id: If94413fc36a98f7694f560955bbb80abefe32166
Signed-off-by: Naresh G Solanki <naresh.solanki@intel.com>
Reviewed-on: https://review.coreboot.org/17435
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add library to:
1. add spd.bin in cbfs, generated from mainboard/spd/*.spd.hex files.
2. runtime get spd data with spd index as input.
3. fetch spd over smbus using early smbus functions.
Change-Id: I44fe1cdb883dd1037484d4bb5c87d2d4f9862bf8
Signed-off-by: Naresh G Solanki <naresh.solanki@intel.com>
Reviewed-on: https://review.coreboot.org/17434
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
With commit 2c3054c1(soc/intel/skylake: Add USB Port Over
Current (OC) Pin programming) USB OC pin programming is already
initiated from devicetree.cb, hence remove it from ramstage.c.
BUG=none
BRANCH=none
TEST=Built and booted KBLRVP from USB device
Change-Id: Icb47533aa57f208d5a52560db924169b908c7a88
Signed-off-by: Barnali Sarkar <barnali.sarkar@intel.com>
Reviewed-on: https://review.coreboot.org/17635
Tested-by: build bot (Jenkins)
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
FSP 2.0 implementation conditionally sets PMRR base based on
EnableC6Dram UPD. Therefore, handle the case of the PMRR base not being
set since FSP 2.0 changed behavior from FSP 1.1 implementation.
If prmrr base is non-zero value, then top_of_ram is prmrr base.
If Probeless trace is enabled, then deduct trace memory size from
calculated top_of_ram.
Change-Id: I2633bf78705e36b241668a313d215d0455fba607
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Signed-off-by: Naresh G Solanki <naresh.solanki@intel.com>
Reviewed-on: https://review.coreboot.org/17554
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
In FSP 2.0 the UPD to send extra VR Mailbox commands is switched from
SendVrMbxCmd to SendVrMbxCmd1. Use the same in silicon initialization.
Change-Id: I46bd50c9acc0456e2483f20ccb5e9ec2a0de232a
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-on: https://review.coreboot.org/17578
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
1. Move existing IO decode range from pch_lpc_init to early
stage before SIO init.
2. At the same time, enable SIO decode range (0x2e/0x2f)
for platform which use super IO.
Change-Id: I72df16d0a784686d8cadfbee09b5aef60576ac43
Signed-off-by: Teo Boon Tiong <boon.tiong.teo@intel.com>
Reviewed-on: https://review.coreboot.org/17337
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Legacy PME are enabled by default in FSP UPD region.
When Legacy PME is enabled, then an SCI is generated and should be
handled by OS and BIOS/Coreboot in collboration. OS requires some
ACPI methods (eg _L69) which help to determine the wake source and also
to clear some registers. But this infrastructure is not present as of
now in coreboot and also linux handles PMEs natively.
Hence the SCI was never handled by OS and the status bits were never
cleared i.e., PCI_EXP_STS.
For this reason the level triggered SCI will remain active and the
system will wake up as soon as it enters S3.
To fix this, diabled Legacy PME (PmSci for Root ports).
Change-Id: I61317eb45305bdb14be3cc1a54fd9961d6ed593e
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Signed-off-by: Naresh G Solanki <naresh.solanki@intel.com>
Reviewed-on: https://review.coreboot.org/17553
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
tune i2c devices clk for snappy:
I2C0: audio
I2C2: TPM H1
I2C3: elan touchscreen
I2C4: elan touchpad
I2C5: wacom digitizer
BUG=chrome-os-partner:59034
BRANCH=master
TEST=emerge-snappy coreboot chromeos-bootimage, and measured on EVT.
audio:
Freq. 393.7kHz
Rise Time 58.8ns
Fall time 12.11ns
TPM H1:
Freq. 398.8kHz
Rise Time 31.71ns
Fall time 13.28ns
elan touchscreen:
Freq. 390.5kHz
Rise Time 235.7ns
Fall time 37.64ns
elan touchpad:
Freq. 393.7kHz
Rise Time 288.8ns
Fall time 51.67ns
wacom digitizer:
Freq. 388.8kHz
Rise Time 124.1ns
Fall time 21.10ns
Change-Id: Ib2be9e1575d4962476423eafa80f9bb10ba40e17
Signed-off-by: Wisley Chen <wisley.chen@quantatw.com>
Reviewed-on: https://review.coreboot.org/17634
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Apollolake MRC cache is divided into two regions: constant and variable.
Currently they are clubbed together. Since variable data changes across
cold reboot it triggers invalidation of the whole cache region. This
change declubs the data, adds routines to load/store variable data on
flash.
BUG=chrome-os-partner:57515
TEST=with patch series applied: cold reboot, make sure MRC is not
updated. Do S3 suspend/resume cycle.
Change-Id: I374519777abe9b9a1e6cceae5318decd405bb527
Signed-off-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-on: https://review.coreboot.org/17237
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Piggy-back on existing MRC cache infrastructure to store variable MRC data.
Only one set of data can be valid at given point of time. Currently this
magically happens because region alignment is forced to 0x1000 and region
itself is of the same size. This needs to be somehow programmatically
enforced.
Change-Id: I8a660d356ca760b8ff9907396fb9b34cb16cf1db
Signed-off-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-on: https://review.coreboot.org/17320
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Chop off 4kb block from RW_MRC_CACHE to store variable MRC cache.
BUG=chrome-os-partner:57515
TEST=with patch series applied: cold reboot, make sure MRC is not
updated. Do S3 suspend/resume cycle.
Change-Id: I3e19fff9c9b20d6c73cbb13bfeec49e9a274bb72
Signed-off-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-on: https://review.coreboot.org/17235
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This header update contains updates for skipping punit as well as some
MRC related UPD values.
BUG=chrome-os-partner:60068
BRANCH=none
TEST=built with FSP 1.2.3 and MRC patches for coreboot
CQ-DEPEND=CL:*307357
Change-Id: I8c66c0c0febba5e67ae3290034e9b095c9e68f07
Signed-off-by: Brandon Breitenstein <brandon.breitenstein@intel.com>
Reviewed-on: https://review.coreboot.org/17631
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
These three files were added as symbolic links to the other files in
the same directory. Delete the links, and copy the real files
into their places.
Because of the varied environments that coreboot is built in, we don't
want to have symbolic links in the tree.
These three files were the only cases of symbolic links.
Change-Id: If69f40c2c4cdcabc4fdfc1d6026a91c0791756da
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/17632
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
This mainboard is identical to ga-945gcm-s2l except for NIC
which is a Realtek RTL 8101E chip (10/100 Mbit).
The schematics of ga-945gcm-s2l mention multiple NICs and ga-945gcm-s2c
and ga-945gcm-s2l have a common manual further indicating that those
boards are close to identical.
Change-Id: Iba3d401efcf208154e639c3237b201830a5151aa
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/17416
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Add `libgfxinit` as another option for native graphics initialization.
For that, the function gma_gfxinit() (see drivers/intel/gma/i915.h) has
to be called by the respective northbridge/soc code.
A mainboard port needs to select `CONFIG_MAINBOARD_HAS_LIBGFXINIT` and
implement the Ada package `GMA.Mainboard` with a single function `ports`
that returns a list of ports to be probed for displays.
v2: Update 3rdparty/libgfxinit to its latest master commit to make
things buildable within coreboot.
v3: Another update to 3rdparty/libgfxinit. Including support to select
the I2C port for VGA.
Change-Id: I4c7be3745f32853797d3f3689396dde07d4ca950
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/16952
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
It's hidden behind a configuration option `CONFIG_RAMSTAGE_LIBHWBASE`.
This also adds some glue code to use the coreboot console for debug
output and our monotonic timer framework as timer backend.
v2: Also update 3rdparty/libhwbase to the latest master commit.
Change-Id: I8e8d50271b46aac1141f95ab55ad323ac0889a8d
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/16951
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
We found that sometimes the edp doesn't get the edid or that video
config fails on kevin after a reboot. Now we will retry 3 times to
initialize it if there are errors.
BRANCH=gru
BUG=chrome-os-partner:60150
TEST=reboot kevin, the edp initialization error is no longer seen.
Change-Id: I96e20e526294fbc856fbdffcbd63accdc7371ef6
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 28c57a6e5b89c7b3a96204ec19a080067460544a
Original-Change-Id: I1382cdf4119fc4eeae5c2b36485030e3a38c2d91
Original-Signed-off-by: Lin Huang <hl@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/412622
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/17626
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
When testing USB 2.0 compatibility with different kinds
of USB 2.0 devices on Kevin board, we find that some
USB HDDs (e.g. seagate SRD00F1 1TB HDD) and some smart
phones (e.g. galaxy A5 smart phone) can't be detected.
And according to the error log, this issue is related
to USB 2.0 PHY signal problem.
For the USB HDD, error log is:
[ 592.557724] usb 5-1: new high-speed USB device number 2 using xhci-hcd
[ 592.847735] usb 5-1: new high-speed USB device number 3 using xhci-hcd
[ 593.473720] usb 5-1: new high-speed USB device number 6 using xhci-hcd
[ 594.187717] usb 5-1: new high-speed USB device number 9 using xhci-hcd
[ 595.020717] usb 5-1: new high-speed USB device number 13 using xhci-hcd
[ 595.284730] usb 5-1: new high-speed USB device number 14 using xhci-hcd
[ 595.574816] usb 5-1: new high-speed USB device number 15 using xhci-hcd
The log shows that HDD failed to high-speed handshake.
For the smart phone, error log is:
[ 1145.661625] usb 5-1: new high-speed USB device number 2 using xhci-hcd
[ 1145.771674] usb 5-1: device descriptor read/64, error -71
[ 1145.979752] usb 5-1: device descriptor read/64, error -71
[ 1146.187721] usb 5-1: new high-speed USB device number 3 using xhci-hcd
[ 1146.301754] usb 5-1: device descriptor read/64, error -71
[ 1146.509750] usb 5-1: device descriptor read/64, error -71
[ 1146.717722] usb 5-1: new high-speed USB device number 4 using xhci-hcd
[ 1146.724393] usb 5-1: Device not responding to setup address.
[ 1146.930795] usb 5-1: Device not responding to setup address.
[ 1147.137720] usb 5-1: device not accepting address 4, error -71
[ 1147.246644] usb 5-1: new high-speed USB device number 5 using xhci-hcd
[ 1147.253336] usb 5-1: Device not responding to setup address.
[ 1147.459786] usb 5-1: Device not responding to setup address.
[ 1147.665712] usb 5-1: device not accepting address 5, error -71
[ 1147.671789] usb usb5-port1: unable to enumerate USB device
The log shows that smart phone failed to read device
descriptor, error -71 may be caused by PHY signal problem.
This patch aims to tune USB 2.0 PHY with the following
parameters to support USB HDD, smart phone and some other
potential USB 2.0 devices.
1. Disable the pre-emphasize in chirp state to avoid
high-speed handshake failure.
2. Bypass ODT auto compensation to enable set max driver
strength manually. (Bit[42] of usbphy_ctrl register is
1'b1 for bypass, and Bit[41:37] of usbphy_ctrl register
is 5'b10000 for max driver strength).
3. Bypass ODT auto refresh, and set the max bias current
tuning reference. (Bit[57] of usbphy_ctrl register is
1'b1 for bypass, and Bit[52:50] of usbphy_ctrl register
is 3b'100 for max bias current tuning reference).
We have done the USB 2.0 compliance test and compatibility test
with this patch, it works well.
BRANCH=gru
BUG=chrome-os-partner:59623
TEST=plug/unplug USB HDD or smart phone in Type-C port,
check if they can be detected successfully.
Change-Id: I275c2236b8e469bfd04e9184d007eb095657225e
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 7735c514d4136978133c2299f2f58da8320bb89f
Original-Change-Id: I4e6c10faa1c03af9880a89afe4731a7065eb1e4e
Original-Signed-off-by: William wu <wulf@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/409856
Original-Commit-Ready: Eddie Cai <eddie.cai.rk@gmail.com>
Original-Tested-by: Cindy Han <cindy.han@samsung.com>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/17566
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Building an image for the Lenovo X60 on Debian 8.5 (jessie) with GCC 4.9.2,
compilation fails with the error below.
```
$ gcc --version
gcc (Debian 4.9.2-10) 4.9.2
[…]
$ make # lenovo/x60 with native graphics initialization
[…]
CC ramstage/northbridge/intel/i945/gma.o
src/northbridge/intel/i945/gma.c: In function 'probe_edid':
src/northbridge/intel/i945/gma.c:570:2: error: 'for' loop initial declarations are only allowed in C99 or C11 mode
for (int i = 0; i < 8; i++) {
^
src/northbridge/intel/i945/gma.c:570:2: note: use option -std=c99, -std=gnu99, -std=c11 or -std=gnu11 to compile your code
Makefile:316: recipe for target 'build/ramstage/northbridge/intel/i945/gma.o' failed
make: *** [build/ramstage/northbridge/intel/i945/gma.o] Error 1
```
Fix this by declaring the count variable outside the 'for' loop.
Change-Id: Icf69337ee46c86bafc4e1320fd99f8f8f5155bfe
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: https://review.coreboot.org/17623
Tested-by: build bot (Jenkins)
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
The code won't allow anything beyond CL11 due to short
CAS Latency mask and a bug in mr0 which had the wrong
bit set for CL > 11.
Increase the CAS bitmask, fix the mr0 reg to allow CAS Latencies
from CL 5 to CL 18.
Use defines instead of hardcoding min and max CAS latencies.
Tested on X220 with two 1866 MHz, CL13 memories
Tested-By: Nicola Corna <nicola@corna.info>
Change-Id: I576ee20a923fd63d360a6a8e86c675dd069d53d6
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/17502
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
This pach sets the DPTF passive temperature trip point for CPU back to
95 degree celsius from 61 degree celsius as per previous thermal
optimizations (https://review.coreboot.org/#/c/16766/).
BUG=chrome-os-partner:60038
BRANCH=master
TEST=built, booted on Reef and verified the passive trip point
funtionality.
Change-Id: I83ce69b19a94e4ea8ebedfc06f259579ed6dd5d3
Signed-off-by: Sumeet Pawnikar <sumeet.r.pawnikar@intel.com>
Reviewed-on: https://review.coreboot.org/17598
Tested-by: build bot (Jenkins)
Reviewed-by: Venkateswarlu V Vinjamuri <venkateswarlu.v.vinjamuri@intel.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add the configuration for Samsung K4E8E324EB and assign it to RAM_CODE 5.
BUG=chrome-os-partner:58983
TEST=verified on Hana EVT.
Change-Id: Iea55eb393b21e37f36d454706531f588101ee651
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 38d34ed0a0b420e1ab300a47b99035153be5b5d0
Original-Change-Id: I28724c1cf5cf12f47911a571c20280ddab4500d5
Original-Signed-off-by: PH Hsu <ph.hsu@mediatek.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/410926
Original-Commit-Ready: Julius Werner <jwerner@chromium.org>
Original-Tested-by: Yidi Lin <yidi.lin@mediatek.com>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/17567
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
The purpose of this change is to enable serial output in
bootblock stage
Change-Id: I8e075f1e70d1a6598dfdc34931218f5af9637178
Signed-off-by: Teo Boon Tiong <boon.tiong.teo@intel.com>
Reviewed-on: https://review.coreboot.org/17359
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Martin Roth <martinroth@google.com>
The devicetree parameter already existed without being
used in the code.
Change-Id: I99dd8bc7a9b2f3509a115a130062d462a62e33fd
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/17614
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
This allows to set the backlight PWM frequency and the
duty cycle in the devicetree instead of using a plain BLC_PWM_CTL
value.
Change-Id: I4d9a555ac7ea5605712c1fcda994a6fcabf9acf3
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/17597
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
Fix-up for 696abfc
nb/intel/x4x: Fix and deflate `dimm_config` in raminit
It didn't fix the channel-number shifting issue as intended.
The channel index is either 0 or 1. DIMMs are counted from 0
to 3 where 0..1 covers channel 0, and 2..3 covers channel 1.
Since we have two DIMMs per channel, we have to multiply the
channel index by 2 (or shift it left by 1) to get the index
of the first DIMM in the channel. Finally, to get the offset
of a DIMM in the channel we take its index modulo 2 (again,
the number of DIMMs per channel).
Change-Id: I2784b0cb655bfe823bf5fa48b722623dfca1ddc3
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/17612
Tested-by: build bot (Jenkins)
Reviewed-by: Damien Zammit <damien@zamaudio.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
We kept this value at it's default on the native graphics init path.
Maybe the Video BIOS path, too, I don't know if the VBIOS sets it.
The panel power sequencer uses the core display clock (CDCLK). It's
based on the HPLLVCO and a frequency selection we made during raminit.
The value written is the (actual divisor/2)-1 for a 100us timer.
v2: Fix unaligned mmio access inherited from Linux.
v3: Use MCHBAR8() instead. Also, the unaligned access might have
worked after all.
Change-Id: I877d229865981fb0f96c864bc79e404f6743fd05
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/17619
Tested-by: build bot (Jenkins)
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Current implementation checks for CONFIG_BOOTBLOCK_CONSOLE and then
initializes UART. If only CONFIG_BOOTBLOCK_CONSOLE
is enabled without enabling CONFIG_UART_DEBUG, there are
compilation issues. This is the case when using SIO UART for Skylake
DT platform. Hence initialize UART when CONFIG_UART_DEBUG is enabled
and not based on CONFIG_BOOTBLOCK_CONSOLE.
Also move BOOTBLOCK_CONSOLE out from UART_DEBUG to CPU_SPECIFIC_OPTIONS
as part of the fix needed.
Change-Id: Id422a55a68d64a06fc874bddca46b0ef5be6d596
Signed-off-by: Teo Boon Tiong <boon.tiong.teo@intel.com>
Reviewed-on: https://review.coreboot.org/17349
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
With this the system falls back to sane default
settings when nvram is invalid.
Change-Id: Ie13fd01c4f8403cbedbd7497ad9012c30f494a69
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/17042
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Set PL1 maximum power limit value back to 12W
(https://review.coreboot.org/#/c/16596/)
from 6W due to Intel's and thermal team's suggestion.
BUG=chrome-os-partner:60038
BRANCH=master
TEST=build, boot on electro dut and verify by thermal team member
Change-Id: I57ae29180962724fde72d522caa542f0f21d5922
Signed-off-by: Tim Chen <Tim-Chen@quantatw.com>
Reviewed-on: https://review.coreboot.org/17574
Tested-by: build bot (Jenkins)
Reviewed-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com>
Reviewed-by: Venkateswarlu V Vinjamuri <venkateswarlu.v.vinjamuri@intel.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Some methods like discover_402x assume an clear state.
Should fix fallback attempt raminit failures.
Change-Id: I7a6fe044c17f5e0dbfa0e9b9d2aed0c3b6ae3972
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/17471
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
By shifting the `chan` right instead of left, values were always taken
from the DIMMs of the first channel. The diff-stat also looks like an
improvement.
Change-Id: I605eb4f9b04520c51eea9995a2d4a1f050f02ecc
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/17587
Tested-by: build bot (Jenkins)
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Damien Zammit <damien@zamaudio.com>
Commit 967cd9a [ChromeOS: fix Kconfig dependencies] broke keyboard
interrupts on parrot by making SERIRQ_CONTINUOUS_MODE conditional on
CONFIG_CHROMEOS, which it should not be; fix by moving back under main
board specific options config.
Additionally, Windows [8/8.1/10] fails to enumerate the keyboard when
its ACPI entry is located under the SIO device since it is missing an
_HID entry, so add the appropriate value per ACPI spec 5 ch. 9.7
Change-Id: Ia69e9b326001d2026b15b4ec03c94f7d03c8a700
Signed-off-by: Prabal Saha <coolstarorganization@gmail.com>
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/17017
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
AMD_ENABLE_STACK was not called on x86_64 path for AGESA, while
it was for binaryPI.
Comments on BIST and cpu_init_detected were reversed, so fix those
too.
Change-Id: I0ddfaf51feb386a56d488c29d60171b05ff6fbc4
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17551
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
Due to some LVDS cable constraints even and odd lanes needs
to be swapped on certain hardware. The hardware ID will be used to
distinguish between these two cases. The swapping itself will be done by
PTN3460, which is configurable for that.
Change-Id: I339b2321a8ed1bc3bbf10aa8e50eb598b14b15fa
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/17576
Tested-by: build bot (Jenkins)
Reviewed-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Add the location of HWID field so that hwilib supports this
value as well.
Change-Id: If6d4695f861232231ac8f9c247c0a10410dac1c5
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/17575
Tested-by: build bot (Jenkins)
Reviewed-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Resetting a Realtek 8168 NIC only makes sense on targets that have
such a device.
Change-Id: I8ac9e8da1d8ecaacb19b4610a9b75f107915d691
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/17577
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
Combine existing board google/panther with new ChromeOS devices
mccloud, monroe, tricky, and zako, using their common reference board
(beltino) as a base.
Chromium sources used:
firmware-mccloud-5827.B 65bfee7 [haswell: No need pre-graphics delay...]
firmware-monroe-4921.B 1ac749d [Monroe: Disable KB/MS in ITE8772.]
firmware-tricky-5829.B 2db5322 [haswell: No need pre-graphics delay...]
firmware-zako-5219.B eacedef [haswell: No need pre-graphics delay...]
Existing google/panther board will be removed in a subsequent commit.
Variant setup modeled after google/reef
Change-Id: I5d7e0c2551e8b0707841032460c35615cefb2886
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/17329
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Once #17329 is committed, no reason to have google/panther exist
as a separate board anymore.
Change-Id: I9a11273c39423d5ff33a7d1f91c8d8cffef97ec1
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/17538
Reviewed-by: Martin Roth <martinroth@google.com>
Tested-by: build bot (Jenkins)
Asserts are only fatal if CONFIG_FATAL_ASSERTS is enabled in Kconfig.
By default this is disabled, so the assert is generally just a printf.
Die if someone decides to pass in an invalid bus number for some reason.
Addresses coverity issue 1349858 - Out-of-bounds read
Signed-off-by: Martin Roth <martinroth@google.com>
Change-Id: I9d79bc336cbbfde31f655cfd271f101e7a90ab1b
Reviewed-on: https://review.coreboot.org/17484
Reviewed-by: Nico Huber <nico.h@gmx.de>
If smbus_read_byte returned an error when reading the DIMM size,
this value would be used as an offset into an array.
Check for the error, and set the DIMM size to 0 if there's
a problem.
Addresses coverity issue 1229658 - Negative array index read
Signed-off-by: Martin Roth <martinroth@google.com>
Change-Id: I6461a0fae819dd9261adbb411c4bba07520d076d
Reviewed-on: https://review.coreboot.org/17485
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
The lb_serial structure had some new entries added, which were not being
filled in.
Fill in the values so they're not undefined.
Addresses coverity error 1354778 - Uninitialized scalar variable
Change-Id: Ia7ce07f6e4e058c91c2e063f3225497271ef93ff
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/17482
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
The lb_serial structure had some new entries added, which were not being
filled in.
Fill in the values so they're not undefined.
Addresses coverity error 1354778 - Uninitialized scalar variable
Change-Id: I57f024c35f79397d0e9fd0c800b1b0f4075caac1
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/17483
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
The defines of device IDs reflects the vendor namespace
the ID has been allocated from.
Change-Id: Id98f45d5984752a9e8c0484d4cb94e93e55b12f6
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17510
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Define early smbus functions that can be used by mainboard to fetch spd.
Change-Id: Id170b2b8e6fb3ebb147f37bf433a27d1162dc11c
Signed-off-by: Naresh G Solanki <naresh.solanki@intel.com>
Reviewed-on: https://review.coreboot.org/17433
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Add declaration for smbus write. Early smbus access also needs smbus
write function specially to read spd for DDR4 wherein page has to be
switched by smbus write.
Change-Id: I246cbdf0b52923f01dd036f63df17bf9af043c9f
Signed-off-by: Naresh G Solanki <naresh.solanki@intel.com>
Reviewed-on: https://review.coreboot.org/17557
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This removes brain, danger, emile, and romy from the tree.
This was cherry-picked from the chromeos-2016.02 branch (CL:345574),
but conflicts showed up in many files that were to be deleted anyway
possibly due to some widespread refactoring that was done between
then and now.
BUG=chromium:612660
BRANCH=none
TEST=none
Change-Id: Ie37140a9a4bb9d820a3fcbad6674b2fa737e1249
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 1ebe5038a82162f6345e319de7578f26ccd68b73
Original-Change-Id: I11f7e0870916871d8f146a6871370ace76ddec49
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/412424
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/17569
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
When IDSOPT_TRACING_ENABLED is TRUE build fails with
"cast from pointer to integer of different size"
Use "UINTN" as is done in Family 16h.
Change-Id: I362e67fc83aa609155f959535f33be9c150c7636
Signed-off-by: Łukasz Dobrowolski <lukasz@dobrowolski.io>
Reviewed-on: https://review.coreboot.org/17406
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Nico Huber <nico.h@gmx.de>
FPR is an attribute of the SPI flash component and not of the SPI bus
itself. Rename functions, file names and Kconfig option to make sure
this is conveyed correctly.
BUG=None
BRANCH=None
TEST=Compiles successfully.
Change-Id: I9f06f1a8ee28b8c56db64ddd6a19dd9179c54f50
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/17560
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
flash_programmer_probe is a property of the spi flash driver and does
not belong in the spi_slave structure. Thus, make
spi_flash_programmer_probe a callback from the spi_flash_probe
function. Logic still remains the same as before (order matters):
1. Try spi_flash_programmer_probe without force option
2. Try generic flash probing
3. Try spi_flash_programmer_probe with force option
If none of the above steps work, fail probing. Flash controller is
expected to honor force option to decide whether to perform specialized
probing or to defer to generic probing.
BUG=None
BRANCH=None
TEST=Compiles successfully
Change-Id: I4163593eea034fa044ec2216e56d0ea3fbc86c7d
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/17465
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
max_transfer_size is a property of the SPI controller and not of the spi
slave. Also, this is used only on one SoC currently. There is no need to
handle this at the spi flash layer.
This change moves the handling of max_transfer_size to SoC SPI driver
and gets rid of the max_transfer_size parameter.
BUG=None
BRANCH=None
TEST=Compiles successfully.
Change-Id: I19a1d0a83395a58c2bc1614b24518a3220945a60
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/17463
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
RW flag was added to spi_slave structure to get around a requirement on
some AMD flash controllers that need to group together all spi volatile
operations (write/erase). This rw flag is not a property or attribute of
the SPI slave or controller. Thus, instead of saving it in spi_slave
structure, clean up the SPI flash driver interface. This allows
chipsets/mainboards (that require volatile operations to be grouped) to
indicate beginning and end of such grouped operations.
New user APIs are added to allow users to perform probe, read, write,
erase, volatile group begin and end operations. Callbacks defined in
spi_flash structure are expected to be used only by the SPI flash
driver. Any chipset that requires grouping of volatile operations can
select the newly added Kconfig option SPI_FLASH_HAS_VOLATILE_GROUP and
define callbacks for chipset_volatile_group_{begin,end}.
spi_claim_bus/spi_release_bus calls have been removed from the SPI flash
chip drivers which end up calling do_spi_flash_cmd since it already has
required calls for claiming and releasing SPI bus before performing a
read/write operation.
BUG=None
BRANCH=None
TEST=Compiles successfully.
Change-Id: Idfc052e82ec15b6c9fa874cee7a61bd06e923fbf
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/17462
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Adds support for the MSI MS-7721 (FM2-A75MA-E35) motherboard.
Tested by building coreboot with:
- VGA bios (needed for onboard video)
- XHCI firmware
- SeaBIOS payload
CPU: AMD A8-6500 APU
RAM: 2x 2GB Samsung M378B5673EH1
Confirmed booting using:
- USB stick with Arch Linux (kernel 4.7.5)
- Gentoo live CD from SATA dvd drive
- Gentoo installation from SATA harddisk (kernel 4.4.26)
Change-Id: I757e011de01ca9f340fd524b10e7fa3f291d53e3
Signed-off-by: Renze Nicolai <renze@rnplus.nl>
Reviewed-on: https://review.coreboot.org/17495
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
This patch adds a copy of the Asus F2A85-M code with only minimal changes.
(to ensure that the code compiles)
A second commit will be published to remove the copied code parts that
don't apply to the MS-7221 and to make everything else actually work
on the MS-7221 board.
Change-Id: I1426c0876c7bfeb264231c0d338301133c721484
Signed-off-by: Renze Nicolai <renze@rnplus.nl>
Reviewed-on: https://review.coreboot.org/17494
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Time spent in printk() is highly unpredictable, depending of the
enabled consoles. If only CBMEM console is enabled, debugstring
is repeated tens of times, consuming preram_cbmem_console storage.
Change-Id: I2b0d9bd11c294d988a0eb84b90e77d5cc7f1f848
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17516
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Make MMCONF_SUPPORT selected with MMCONF_SUPPORT_DEFAULT.
Platforms that remain to have explicit MMCONF_SUPPORT are
ones that should be converted.
Change-Id: Iba8824f46842607fb1508aa7d057f8cbf1cd6397
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17527
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This motherboard support Intel core 2 quads.
Before this change SeaBIOS was not usable, due to it crashing before it
got to load anything.
Change-Id: Ifdaaceace04f9ba0753aab2d3b05c0519367f91f
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/17537
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Obtained from vendor bios DSDT, under "Device (HUB0),
Name (_ADR, 0x001E0000)".
The schematics also indicate that the INTA-D are hardwired to these
PIRQ lines.
Change-Id: I8e1c6cb986a2b345a5e1fddd454c7fb12fb8256a
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/17099
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
The cbmem routines pass back NULL on error. Check for this before using
the pointer.
Addresses coverity issue 1365731 - Dereference null return value
Change-Id: I92995366ffb15afd0950b9a8bbb6fe16252b2c38
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/17480
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
If no maximum string length is specified, we're intentionally passing a
value of -1 to get the string length so that it's not limited. This
makes checking tools unhappy, so actively cast it to size_t before
passing it into strlen to show that it's not an accident.
Addresses coverity issue 1129133 - Argument cannot be negative
Change-Id: I40f8f2101e170a5c96fcd39c217aa414f4316473
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/17479
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
Stage cache will save ~20ms on S3 resume for apollolake platforms.
Implementing the cache in ramstage to save silicon init and reload
it on resume. This patch adds passing S3 status to silicon init in
order to verify that the wake is from S3 and not for some other
reason. This patch also includes changes needed for quark and
skylake platforms that require fsp 2.0.
BUG=chrome-os-partner:56941
BRANCH=none
TEST=built for reef and tested boot and S3 resume path saving 20ms
Change-Id: I99dc93c1d7a7d5cf8d8de1aa253a326ec67f05f6
Signed-off-by: Brandon Breitenstein <brandon.breitenstein@intel.com>
Reviewed-on: https://review.coreboot.org/17460
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This is a stopgap for when you use SUPERIO_SMSC_SMSCSUPERIO and the
interrupt is unmapped at reset, but for whatever reason the chip is
inaccessible in smscsuperio/superio.c::enable_dev() and thus the
devicetree.cb IRQ information is not applied in ramstage and then
serial console output fails to work for more than the UART FIFO depth
in the OS.
Change-Id: I00998088975569516f7caeb7f4098b48fe437889
Signed-off-by: Jonathan A. Kollasch <jakllsch@kollasch.net>
Reviewed-on: https://review.coreboot.org/10807
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Currently, the coreboot log of a Lenovo X60, not having any IDE devices
connected, there is a trailing whitespace in the output.
[…]
PCI: 00:1f.1 init ...
i82801gx_ide: initializing...
PCI: 00:1f.1 init finished in 11 usecs
[…]
Reorder the whitespaces, so they are added when needed.
Change-Id: I640e514c89fe0246a847d1fd088def1c88e864f8
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: https://review.coreboot.org/11870
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Some X200 use a 4 MiB SOIC-8 flash chip.
Change-Id: Ie5bd359ef08cf1be369a026be376c21555d0ea18
Signed-off-by: Michał Masłowski <mtjm@mtjm.eu>
Reviewed-on: https://review.coreboot.org/8391
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
There is mismatch of VENDOR_ID_AMD with DEVICE_ID_ATI, also
the device IDs have not been defined.
Change-Id: I3076cb08e3181e7f86de38deb18f1661f037bc38
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17508
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
There is mismatch of VENDOR_ID_AMD with DEVICE_ID_ATI, also
the device IDs have not been defined.
Change-Id: I0d85893169fe877e384746931605f563c50308b2
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17509
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
It's very dangerous to set bus master enable, and more so on
a NIC, where random broadcast packets can end up in memory
in unexpected ways.
If your kernel has trouble with the fact that we do not set
bus master enable, you need to fix your kernel.
Change-Id: If07fde7961ad80125567240cb43db036346bef97
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: https://review.coreboot.org/17559
Reviewed-by: Timothy Pearson <tpearson@raptorengineering.com>
Tested-by: build bot (Jenkins)
When running with relocatable ramstage, the gdt loaded from c_start.S
is already in CBMEM (high memory). Thus, there's no need to create
a new copy of the gdt and reload.
Change-Id: I2750d30119fee01baf4748d8001a672d18a13fb0
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/17504
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
I guess it was dropped because its concept was misunderstood. The idea
is to always have it set to `Yes` in the cmos.default. Users can then
ack the loading of the defaults by setting it to `No`. If the defaults
ever get loaded again, they'll be notified by the default `Yes`.
Change-Id: I1aa6d75bd5aa153c7b11a6b74564272eaa7cc523
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/17355
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
The maximum supported rate is 12MHz. Only tested with 4MHz though,
since I couldn't set anything higher on my Linux receiver. But that
works fine with another FT*232H as receiver, whoosh.
Change-Id: Ie39aa0170882ff5b4512f0349f6f86d3f0b86421
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/17477
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
o The first 4G of physical address space is now mapped at 0.
o The first 4G of physical address space is now mapped at 1 << 38.
o The first 2G of DRAM (2 - 4 GiB of physical address space)
is now mapped at the top of memory save for the last 4K
i.e. at 0xffffffff80000000, with SBI page at the very top.
Of these, we hope to remove the *most* of the
last one once the gcc toolchain
can handle linking programs that can run at "top 33 bits
of address not all ones (but bit 63 set)". The 4K mapping
of the top of the 64 bit address space will always remain,
however, for SBI calls.
Change-Id: I77b151720001bddad5563b0f8e1279abcea056fa
Reviewed-on: https://review.coreboot.org/17403
Tested-by: build bot (Jenkins)
Reviewed-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
When MRC cache is available, first read only the SPD unique
identifier bytes required to detect possible DIMM replacement.
As this is 11 vs 256 bytes with slow SMBus operations, we save
about 70ms for every installed DIMM on normal boot path.
In the DIMM replacement case this adds some 10ms per installed DIMM
as some SPD gets read twice, but we are on slow RAM training boot path
anyways.
Change-Id: I294a56e7b7562c3dea322c644b21a15abb033870
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17491
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
For S3 resume path SPD is only used for DIMM replacement detection.
As this detection already fails in the case of removal/insertion of
same DIMM, we can rely on cbmem_recovery() failure alone to force
system reset in case someone accidentally does DIMM replacements while
system is suspend-to-ram stage.
Skipping DIMM replacement detection allows skipping slow SPD loading,
thus reducing S3 resume path time by 80ms for every installed DIMM.
Change-Id: I4f2838c05f172d3cb351b027c9b8dd6543ab5944
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17490
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Take the timestamp before SPD loading takes place, for easier
comparison against MRC blob performance and followup changes
will optimize some of the slow SPD/SMBus operations.
Change-Id: I50b5a9d02d2caf4c63e1a4025544131a085b8fb6
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17489
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Switch to use CRC of unique identifier section SPD[117..127],
remaining area of SPD data is ignored.
Change-Id: If4b43183f99f5f911ae6c311b43c29a72b9922e2
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17487
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Specification allows for the unique identifier bytes 117..125
to be excluded of CRC calculation. For such SPD, the CRC
would not identify replacement between two identical DIMM parts,
while memory training needs to be redone.
Change-Id: I8e830018b15c344d9f72f921ab84893f633f7654
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17486
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Compiled romstage is over 64kiB and exceeded XIP_ROM_SIZE,
so it was not entirely set WRPROT cacheable.
Reduces first boot raminit (including training) time by 400ms.
Change-Id: I5c4cbf581fc845150f207087c1527338ca364f60
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17488
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Update the DPTF parameters based on thermal test result.
1. Update DPTF CPU/TSR0/TSR1/TSR2 passive/critial trigger points.
CPU passive point:61
TSR0 passive point:120, critial point:125
TSR1 passive point:46, critial point:75
TSR2 passive point:100, critial point:125
2. Update PL1/PL2 Min Power Limit/Max Power Limit
Set PL1 min to 3W, and max to 6W
Set PL2 min to 8W
3. Change thermal relationship table (TRT) setting.
Change CPU Throttle Effect on CPU sample rate to 80secs
Change CPU Effect on Temp Sensor 0 sample rate to 120secs
The TRT of TCHG is TSR1, but real sensor is TSR2.
Change Charger Effect on Temp Sensor 2 sample rate to 120secs
Change CPU Effect on Temp Sensor 2 sample rate to 120secs
BUG=chrome-os-partner:60038
BRANCH=master
TEST=build and boot on electro dut
Change-Id: I7a701812cb45f51828a3cbb3343e03817645110e
Signed-off-by: Tim Chen <Tim-Chen@quantatw.com>
Reviewed-on: https://review.coreboot.org/17466
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Also memset info.dimm as it contains decoded SPD timings
used to calculate common timings.
Tested manually on Lenovo T420.
Change-Id: I659e5bc2a6cbadd9539931ee00ddea0a5253295f
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/17473
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
No need to find the same CMD rate for all channels.
Allow different CMD rates for every channel.
Tested on Lenovo T420 with different modules on each channel.
No regressions found.
Change-Id: I7036275ae89335dd3549ec392fa64824355b3cbf
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/17472
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Use register names found on forums.corsair.com.
No functionality changed.
Change-Id: Ibaede39a24e8df1c4d42cb27986ab66174b7d45b
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/17400
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Locking the PLL again once it's locked doesn't work.
The MRC doesn't do this, for some reason.
Remove fallback attempts of lowering DDR frequency.
Change-Id: Iccb54fa7d7357a22182dd26bd5b49c4073c04dc9
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/17399
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
As documented in DDR3 spec for MR2 the CWL is based on DDR frequency.
There's no to little difference for most memory modules operating at DDR3-1333.
It might fix problems for memory modules that operate at a higher frequency and
memory modules with low CL values should work even better.
Tested on Lenovo T420 with DDR3-1333 CL9 and DDR3-1600 CL11.
No regressions found.
Change-Id: Ib90b5de872a219cf80b4976b6dfae6bc02e298f4
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/17389
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
On S3 resume path, CBMEM_ID_GDT already exists but we only printed
the final "ok" string. Always tell GDT is about to be moved.
Change-Id: Ic91c5389cf4d47d28a6c54db152c18541c413bc1
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17500
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
SPD data alone consumes 0x400 of pre-ram stack, so the guard was
initially set too high, printing spurious "smashed stack detected"
messages at end of romstage.
Use the same stack size as haswell.
Change-Id: I24fff6228bc5207750a3c4bf8cf34e91cf35e716
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17501
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
vboot_handoff.c is the only place that needs the vb2 internals.
Provide it in the one place it is actually required instead of
pulling in the headers unnecessarily in common code. There is,
however, still a need to get the vb2 hashing types for a function
declaration.
Change-Id: I038fda68b1cd05fa2e66135158e5e2d18567563a
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/17475
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
The wrong value was used for reporting an error when a requested
bus speed was made that isn't supported. Use the requested value.
Change-Id: I6c92ede3d95590d95a42b40422bab88ea9ae72a1
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/17474
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
If the SoC clock speed is not supported there is supposed to
be an error printed. However, the value printed was wrong which
was dereferencing a NULL struct. Fix that.
Change-Id: I5021ad8c1581d1935b39875ffa3aa00b594c537a
Found-by: Coverity Scan #1365977
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/17468
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Don't use scratchpad registers when we have romstage_handoff
to pass S3 resume flag. Also fixes console log from reporting
early in ramstage "Normal boot" while on S3 resume path.
Change-Id: I5b218ce3046493b92952e47610c41b07efa4d1de
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17455
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Adapt implementation from haswell to prepare for removal of HIGH_MEMORY_SAVE
and moving on to RELOCATABLE_RAMSTAGE. With the change, CBMEM and SMM regions
are set to WRBACK with MTRRs and romstage ram stack is moved to CBMEM.
Also fixes regression of slower S3 resume path after commit
9b99152 intel/sandybridge: Use common ACPI S3 recovery
Skipping low memory backup and using stage cache for ramstage decreases
time spent on S3 resume path by 50 ms on samsung/lumpy.
Change-Id: I2afee3662e73e8e629188258b2f4119e02d60305
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/15790
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Align top of stack to 8 bytes, value documented as FSP1.1 requirement.
Also fix some cases of uintptr_t casted to unsigned long.
Change-Id: I5bbd100eeb673417da205a2c2c3410fef1af61f0
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17461
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
USB AO is the internal name for the dedicated charging port on
ThinkPads when in S3 or lower.
AOEN (bit 0) is internal name for enabling this feature while AOCF
(bits 2 and 3) is the configuration field. According to Peter Stuge,
AOCF can be configured in this way:
00 => AC S3 S4 S4 USB on, battery S3 USB on, battery S4 S5 off
11 => AC S3 S4 S4 USB on, battery S3 S4 S5 USB off
10, 01 => equivalent to 00
This commit also adds a new configuration field in the CMOS of the
X220 and the X201 to activate this feature. It probably can be also
added to all the ThinkPads that support this functionality.
With this functionality USB devices are able to negotiate full power
from the dedicated port (usually the yellow one) even in S3.
Tested on a X201 and X220 with an Android smartphone: with this
feature enabled it shows "Charging" when connected during S3, without
it it shows "Charging slowly" (or it doesn't charge at all on the
X201).
For some reasons the "AC only" mode doesn't work, so it has been
disabled.
Change-Id: Ie1269a4357e2fbd608ad8b7b8262275914730f6e
Signed-off-by: Nicola Corna <nicola@corna.info>
Reviewed-on: https://review.coreboot.org/17252
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
Instead of defining the same functions for reading/clearing boot-mode
switches from EC in every mainboard, add a common infrastructure to
enable common functions for handling boot-mode switches if
GOOGLE_CHROMEEC is being used.
Only boards that were not moved to this new infrastructure are those
that do not use GOOGLE_CHROMEEC or which rely on some mainboard specific
mechanism for reading boot-mode switches.
BUG=None
BRANCH=None
TEST=abuild compiles all boards successfully with and without ChromeOS
option.
Change-Id: I267aadea9e616464563df04b51a668b877f0d578
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/17449
Tested-by: build bot (Jenkins)
Reviewed-by: Julius Werner <jwerner@chromium.org>
After the RTC coin cell has been replaced, the Update Cycle Inhibit
bit must see at least one low transition to ensure the RTC counts.
The reset value for this bit is undefined. Examples have been observed
where batteries are installed on a manufacturing line, the bit's state
comes up low, but the RTC does not count.
Change-Id: I05f61efdf941297fa9ec90136124b0c8fe0639c6
Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-on: https://review.coreboot.org/17370
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
While the real-time clock updates its count, values may not be correctly
read or written. On reads, ensure the UIP bit is clear which guarantees
a minimum of 244 microseconds exists before the update begins. Writes
already avoid the problem by disabling the RTC count via the SET bit.
Change-Id: I39e34493113015d32582f1c280fafa9e97f43a40
Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-on: https://review.coreboot.org/17369
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
1. Update DPTF CPU/TSR1/TSR2 passive/critial trigger points.
CPU passive point:100, critical point:105
TSR1 passive point:48, critial point:65
TSR2 passive point:85, critial point:100
2. Update PL1/PL2 Min Power Limit/Max Power Limit
Set PL1 min to 3W, and max to 6W
Set PL2 min and max to 8W
3. Change thermal relationship table (TRT) setting.
The TRT of TCHG is TSR1, but real sensor is TSR2.
BRANCH=master
BUG=none
TEST= Compiled, verified by thermal team.
Change-Id: Ib197c36eca88e3d05f632025cf3c238e1a2eae23
Signed-off-by: Wisley Chen <wisley.chen@quantatw.com>
Reviewed-on: https://review.coreboot.org/17426
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
The following devices i2c6, i2c7, spi1, spi2, uart3
are not used.
BUG=chrome-os-partner:59880
TEST=Boot to OS and lspci command should
not list the above disabled devices.
Change-Id: I819cdb34709703e6431b49446417ed9d6b3543cd
Signed-off-by: Jagadish Krishnamoorthy <jagadish.krishnamoorthy@intel.com>
Reviewed-on: https://review.coreboot.org/17441
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Provide the rise and fall times for the i2c buses and let the
library perform the necessary calculations for the i2c
controller registers instead of manually tuning the values.
BUG=chrome-os-partner:58889,chrome-os-partner:59565
Change-Id: I0c84658471d90309cdbb850e3128ae01780633af
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/17397
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins)
This changes memory to only do CA training with one pattern,
0xfffff/0x00000 and to also make sure CA training waits for all of the
captures during training.
BRANCH=none
BUG=chrome-os-partner:56940
TEST=boot kevin and run
stressapptest -M 1500 -s 1000
Change-Id: I0982674b4f4415f4d7865923ced93fa09bdd877e
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 75cdd911cea9c4e5744fd04505b260fa5755513c
Original-Change-Id: I3b86e6d4662c6fbbf9ddef274fce191a367904e5
Original-Signed-off-by: Derek Basehore <dbasehore@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/410320
Original-Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-on: https://review.coreboot.org/17383
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
This adds a new CA training pattern for all of the supported
frequencies. This pattern increases the hold time on CA.
BRANCH=none
BUG=chrome-os-partner:57845
TEST=boot kevin and run:
while true; do sleep 0.1; memtester 500K 1 > /dev/null; done
for several hours
Change-Id: Ie5958cf67c16247ef90ee261da9faef4ffa5b339
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 8babeafe75bffcb2dab17eb007b4f5bb0eb42606
Original-Change-Id: I7f7652f88e43dc9b2f6069e60514931bf7582ed1
Original-Signed-off-by: Derek Basehore <dbasehore@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/403547
Original-Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-on: https://review.coreboot.org/17382
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Add support for following 3 modules.
- Micro MT52L256M32D1PF / MT52L512M32D2PF
- Hynix H9CCNNNBJTALAR
Hana EVT was planed to add 4 DRAM modules but RAM_CODE=5 is not used
in the end.
This patch also unifies the naming of the RAM configurations.
BUG=chrome-os-partner:58983
TEST=verified on Hana EVT.
Change-Id: I7dd44525de8e9dde01f210f4730fa8ccd4baef21
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 5dccd68149bcfd6fd0a83e310d43063bab645691
Original-Change-Id: I7c245c8c24be159e152f4f3cca25bf970b58425c
Original-Signed-off-by: Milton Chiang <milton.chiang@mediatek.com>
Original-Signed-off-by: PH Hsu <ph.hsu@mediatek.com>
Original-Signed-off-by: Yidi Lin <yidi.lin@mediatek.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/402888
Original-Reviewed-by: Pin-Huan Hsu <ph.hsu@mediatek.com>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-by: Paris Yeh <pyeh@chromium.org>
Reviewed-on: https://review.coreboot.org/17381
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
coreboot's build system picks up the BL31 image as an ELF from the ARM
Trusted Firmware submodule and inserts it into CBFS. However, the
generic 'bl31' build target we run in the ARM Trusted Firmware build
system also generates a raw bl31.bin binary file.
We don't need that binary, and with the recently added support for
multiple non-contiguous program segments in BL31 it can grow close to
4GB in size (by having one section mapped near the start and one near
the end of the address space). To avoid clogging up people's hard drives
with 4GB of zeroes, let's only build the target we actually need.
BRANCH=gru
BUG=chrome-os-partner:56314,chromium:661124
TEST=FEATURES=noclean emerge-kevin coreboot, confirm that there's no
giant build/3rdparty/arm-trusted-firmware/bl31.bin file left in the
build artifacts, and that we still generate .d prerequisite files.
Change-Id: I8e7bd50632f7831cc7b8bec69025822aec5bad27
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 31699820f4c36fd441a3e7271871af4e1474129f
Original-Change-Id: Iaa073ec11dabed7265620d370fcd01ea8c0c2056
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/407110
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/17380
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
This changes the 933 DPLL rate to 928 which has low jitter.
BRANCH=none
BUG=chrome-os-partner:57845
TEST=boot kevin and run
while true; do sleep 0.1; memtester 500K 1 > /dev/null; done
for several hours
Change-Id: I4d2a8871aaabe3b0a1a165c788af265c5f9e892c
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 54ebf8763bb8193c4b36a5e86f0c625b176d31a6
Original-Change-Id: Iaa12bf67527b6d0e809657c513b8d1c66af25174
Original-Signed-off-by: Derek Basehore <dbasehore@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/404550
Original-Reviewed-by: Douglas Anderson <dianders@chromium.org>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/17379
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
The Kevin project has been too smooth and boring for our tastes in the
last last few weeks, so we've decided to stir the pot a little bit and
reshuffle all our PLL settings at the last minute. The new settings
match exactly what the Linux kernel expects on boot, so it doesn't need
to reinitialize anything and risk a glitch.
Naturally, changing PLL rates will affect child clocks, so this patch
changes vop_aclk (192MHz -> 200MHz, 400MHz in the kernel), pmu_pclk
(99MHz -> 96.57MHz) and i2c0_src (198MHz -> 338MHz, leading to an
effective I2C0 change 399193Hz -> 398584Hz).
BRANCH=gru
BUG=chrome-os-partner:59139
TEST=Booted Kevin, sanity checking display and beep. Instrumented
rockchip_rk3399_pll_set_params() in the kernel and confirmed that GPLL,
PPLL and CPLL do not get reinitialized anymore (with additional kernel
patch to ignore frac divider when it's not used). Also confirmed that
/sys/kernel/debug/clk_summary now shows pclk_pmu_src 96571429 because
the kernel doesn't even bother to reinitialize the divisor.
Change-Id: Ib44d872a7b7f177fb2e60ccc6992f888835365eb
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 9b82056037be5a5aebf146784ffb246780013c96
Original-Change-Id: Ie112104035b01166217a8c5b5586972b4d7ca6ec
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/405785
Original-Commit-Ready: Xing Zheng <zhengxing@rock-chips.com>
Original-Tested-by: Xing Zheng <zhengxing@rock-chips.com>
Original-Reviewed-by: Xing Zheng <zhengxing@rock-chips.com>
Original-Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-on: https://review.coreboot.org/17378
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
The DDR speed Kconfig symbols needed to either be added to the Kconfig
tree, or have the code associated with them removed. I chose to add
the symbols.
- Add symbols for DDR333 - DDR667 to cygnus Kconfig. These should be
selected by the mainboard.
- Rename symbols from DDRXXX to CYGNUS_DDRXXX to match the existing
CYGNUS_DDR800 symbol.
- Rename the non Kconfig #define CONFIG_DRAM_FREQ to CYGNUS_DRAM_FREQ
because having other #defines look like Kconfig symbols is confusing.
- Change #ifdef CONFIG_DDRXXX to use IS_ENABLED
Change-Id: I3f5957a595072434c21af0002d57ac49b48b1e43
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/17386
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
The environment-controller entity is shared by many ITE super-i/o
chips. There are some differences between the chips, though. To cover
that, the super-i/o chip should select Kconfig options of this driver
accordingly.
The current implementation isn't exhaustive: It covers only those
parts that are connected on boards I could test, plus those that are
currently used by the IT8772F. The latter could be ported to use this
driver if somebody minds to test it.
Change-Id: I7a40f677f667d103ce1d09a3e468915729067803
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/17284
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
In function definition of acpigen_write_byte_buffer, buffer size written
using acpigen_emit_byte gives wrong results in generated AML code for
buffer size greater than one.
Write buffer size using acpigen_write_integer as per ACPI spec 5.0
section 20.2.5.4 BufferOp.
Change-Id: I0dcb25b24a1b4b592ad820c95f7c2df67a016594
Signed-off-by: Naresh G Solanki <naresh.solanki@intel.com>
Reviewed-on: https://review.coreboot.org/17444
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
According to PCI LOCAL BUS SPECIFICATION, REV. 3.0 page 305,
the sub-class for Entertainment en/decryption is 0x1010
Change-Id: Ia069e2ec328a8180fc1e2e70146c3710e703ee59
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/17436
Tested-by: build bot (Jenkins)
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Before the PcdeMMCBootMode in the Updatable Product Date was always
assigned and didn't take into account the + 1 increment for the default
define.
Now if the configuration indicates that the device tree should be
followed PcdeMMCBootMode is initially disabled. Else if configuration
isn't the default, assign the value with the + 1 increment substracted.
TEST=Intel/MinnowMax
Change-Id: I6755eb585d1afe3a15f83347fba834766eb44ad2
Signed-off-by: David Imhoff <dimhoff_devel@xs4all.nl>
Reviewed-on: https://review.coreboot.org/10165
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
Log the values of PcdEnableLpe and PcdeMMCBootMode even if they are
outside of the expected range.
TEST=Intel/MinnowMax
Change-Id: Ie0aea4287234b23d4e9852f3991dcc78ce8103d9
Signed-off-by: David Imhoff <dimhoff_devel@xs4all.nl>
Reviewed-on: https://review.coreboot.org/10164
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
Reef board uses GPIO_17 as DMIC config pin.
This pin distinguishes board with Quad DMIC's or Mono DMIC.
This patch adds necessary DMIC endpoints to support either of
those configurations.
CQ-DEPEND=CL:*304339,CL:409774
BUG=chrome-os-partner:56918
BRANCH=none
TEST=Verify Mono and Quad Channel DMIC record
Change-Id: I5b2825b5f39f8962985a129f8ec65265fb18f0b2
Signed-off-by: Sathyanarayana Nujella <sathyanarayana.nujella@intel.com>
Reviewed-on: https://review.coreboot.org/17158
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
GPIO register at offset 0xfc (VID Input Register) is read-only but
writing 1 to bit 0 will update initial VID input.
Change-Id: Ie372e98f8e497eede382975262a63d58c16227b9
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/17412
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Add the DIMM SPD data for memory types that are not used yet
but are on the matrix and may be used in future builds.
Also fix a typo in the part number string for one type.
BUG=chrome-os-partner:58666
TEST=build and boot on eve p0
Change-Id: I20401d7afb69f1c3ae1a3b0d6e3ec9097f54ef96
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/17437
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Currently the code considers the absence of the NVRAM firmware
rollback space a a trigger for invoking the TPM factory initialization
sequence.
Note that the kernel rollback and MRC cache hash spaces are created
after the firmware rollback space. This opens an ever so narrow window
of opportunity for bricking the device, in case a startup is
interrupted after firmware space has been created, but before kernel
and MRC hash spaces are created.
The suggested solution is to create the firmware space last, and to
allow for kernel and MRC cache spaces to exist during TPM factory
initialization.
BRANCH=none
BUG=chrome-os-partner:59654
TEST=odified the code not to create the firmware space, wiped out the
TPM NVRAM and booted the device. Observed it create kernel and
MRC cache spaces on the first run, and then reporting return code
0x14c for already existing spaces on the following restarts.
Verified that the device boots fine in normal and recovery modes
and TPM NVRAM spaces are writeable in recovery mode.
Change-Id: Id0e772448d6af1340e800ec3b78ec67913aa6289
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://review.coreboot.org/17398
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Currently the tlcl_define_space() function returns the same error
value for any non-zero TPM response code. The thing is that the caller
might want to allow attempts to re-create existing NVRAM spaces. This
patch adds a new API return value to indicate this condition and uses
it as appropriate.
BRANCH=none
BUG=chrome-os-partner:59654
TEST=for test purposes modified the code not to create the firmware
space, wiped out the TPM NVRAM and booted the device. Observed it
create kernel and MRC index spaces on the first boot and then
reporting return code 0x14c for already existing spaces on the
following restarts.
Change-Id: Ic183eb45e73edfbccf11cc19fd2f64f64274bfb2
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://review.coreboot.org/17422
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
acpigen_write_if_lequal is used to generate ACPI code to check if two
operands are equal, where operand1 is an ACPI op and operand2 is an
integer. Update name of function to reflect this and fix code to write
integer instead of emitting byte for operand2.
TEST=Verified by disassembling SSDT on reef that ACPI code generated for
If with operand2 greater than 1 is correct.
If ((Local1 == 0x02))
{
Return (0x01)
}
Else
{
Return (Buffer (One)
{
0x00 /* . */
})
}
Change-Id: If643c078b06d4e2e5a084b51c458dd612d565acc
Reported-by: Naresh G Solanki <naresh.solanki@intel.com>
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/17421
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This reverts commit 83df672d2c.
It's based on the assumption that the H8 keeps its configuration
during a suspend/resume cycle. User reports indicate that this might
not be true.
Caching the settings in a cbtable entry might be a better approach.
Change-Id: Ic4ba862ee7068ffe214c2aeaadecb4390a0e0529
Reviewed-on: https://review.coreboot.org/17411
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
BIOS needs to ensure that SPI write does not cross 256-byte
boundary. Else, if the write is across 256-byte boundary, then it
corrupts the block by wrapping write to start of current block. Thus,
ensure nuclear_spi_{read,write} operate within a single 256-byte block
only at a time.
BUG=chrome-os-partner:59813
BRANCH=None
TEST=Verified that elog writes do not corrupt the event log when write
is across 256-byte blocks.
Change-Id: I854ca2979d65b9f1232f93182cb84d4dee4f4139
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/17419
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Replace the use of the old device_t definition inside
northbridge/via/vx800.
Change-Id: I14a2b4d847f8aeb327d90f385dea998779fae24f
Signed-off-by: Antonello Dettori <dev@dettori.io>
Reviewed-on: https://review.coreboot.org/17316
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Replace the use of the old device_t definition inside
northbridge/via/cx700.
Change-Id: I6e25f898ab55ee959f1b3b8aba9616c3ba18986d
Signed-off-by: Antonello Dettori <dev@dettori.io>
Reviewed-on: https://review.coreboot.org/17315
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Replace the use of the old device_t definition inside
northbridge/intel/i855.
Change-Id: Iae66d1ef838095a560868d9c9ff81f4208f814f1
Signed-off-by: Antonello Dettori <dev@dettori.io>
Reviewed-on: https://review.coreboot.org/17314
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Replace the use of the old device_t definition inside
northbridge/amd/agesa/family10.
Change-Id: I5723e217fc739ab576cbe3a1ee6d92023190267c
Signed-off-by: Antonello Dettori <dev@dettori.io>
Reviewed-on: https://review.coreboot.org/17313
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Damien Zammit