If deep Sx is enabled and prev sleep state was not S0, then if SUS
power was lost, it means that the platform had entered deep Sx. Add an
elog entry for deep Sx variant in this case.
BUG=b:38436041
TEST=Verified that elog entries are updated correctly:
Deep S5:
59 | 2017-05-19 10:39:08 | Kernel Event | Clean Shutdown
60 | 2017-05-19 10:39:09 | ACPI Enter | S5
61 | 2017-05-19 10:39:17 | System boot | 22
62 | 2017-05-19 10:39:17 | EC Event | Power Button
63 | 2017-05-19 10:39:17 | ACPI Deep Sx Wake | S5
64 | 2017-05-19 10:39:17 | Wake Source | Power Button | 0
65 | 2017-05-19 10:39:17 | Chrome OS Developer Mode
Deep S3:
66 | 2017-05-19 10:40:11 | ACPI Enter | S3
67 | 2017-05-19 10:40:16 | EC Event | Power Button
68 | 2017-05-19 10:40:16 | ACPI Deep Sx Wake | S3
69 | 2017-05-19 10:40:16 | Wake Source | Power Button | 0
Normal S3:
77 | 2017-05-19 10:43:22 | ACPI Enter | S3
78 | 2017-05-19 10:43:39 | EC Event | Power Button
79 | 2017-05-19 10:43:39 | ACPI Wake | S3
80 | 2017-05-19 10:43:39 | Wake Source | Power Button | 0
Change-Id: Ia251334ae44668c2260d8d2e816f85f1f62faac4
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/19798
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This is useful for debugging based on eventlog to identify if platform
entered normal or deep Sx.
BUG=b:38436041
Change-Id: Ic7d8e5b8aafc07aed385fe3c4831ab7d29e1f890
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/19797
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Use SATA common code from soc/intel/common/block/sata
and clean up code.
Change-Id: Ib5d65f1afda6b2f8098f1c006623a48cf2690593
Signed-off-by: Aamir Bohra <aamir.bohra@intel.com>
Reviewed-on: https://review.coreboot.org/19735
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com>
Add SATA code support in intel/common/block to initilalize
SATA controller, allocate resources and configure SATA port
status.
Change-Id: I42ec0059f7e311a232c38fef6a2e050a3e2c0ad3
Signed-off-by: Aamir Bohra <aamir.bohra@intel.com>
Reviewed-on: https://review.coreboot.org/19734
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com>
Since the conversion of this board to soc/broadwell in 0aa06cbf18
(wtm2: Convert to use soc/intel/broadwell), the NGI for this board
is not hooked up anywhere. Also, the code doesn't compile anymore.
Change-Id: I6387203349b78c8e95333eaf44b345aa30eac7c5
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/19801
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Remove guards and let the linker take care of it.
Change-Id: I96ad8002845082816153ca5762543768998a5619
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/19744
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
This makes the code more readable since it avoids messing with two
dimensional arrays and needing remember what the indices mean.
Also introduces an unused coarse element which is 0 for all default
DLL settings on DDR2.
Change-Id: I28377d2d15d0e6a0d12545b837d6369e0dc26b92
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/19767
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
All those boards do not have a serial port.
Don't attempt to decode the COMA/COMB IO range.
Change-Id: Ide7e818f87e70e3f559d0769ccde89c35da961d6
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/19571
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Do not lock ETR3 CF9GR in early romstage.
As of Change-Id: I2cb30267a6342db1f3b11715034219ffb18ca678 this is done
in bd82x6x's finalize handler.
Change-Id: Iea091511f0d2a6128d3a19e9413090c85e4c2e57
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/19570
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Hides JEDEC steps using the RAM_SPEW macro.
Also hides a hexdump of SPDs.
Change-Id: Ie2b484cf1f1d296823df0473e852d9d07ca20246
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/18924
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
It is not really known why there is such a long delay, but it works
fine without it.
TESTED on ga-g41m-es2l.
Change-Id: Idff5b978bbf161f8520d8000848e7b11c98c3945
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/19514
Reviewed-by: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
Only board using this code was tyan s2735 which was removed in
f76de841f1 "[REMOVAL] tyan/s2735"
Change-Id: I03a101adc1eedfa9669e0b44c54c2c6fa08bd5f2
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/19507
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
Define a new spi_flash_ops structure, move all spi flash operations to
this structure and add a pointer to this structure in struct spi_flash.
BUG=b:38330715
Change-Id: I550cc4556fc4b63ebc174a7e2fde42251fe56052
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/19757
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
1. Rename __spi_flash_probe to spi_flash_generic_probe and export it
so that drivers can use it outside spi_flash.c.
2. Make southbridge intel spi driver use spi_flash_generic_probe if
spi_is_multichip returns 0.
3. Add spi_flash_probe to spi_ctrlr structure to allow platforms to
provide specialized probe functions. With this change, the specialized
spi flash probe functions are now associated with a particular spi
ctrlr structure and no longer disconnected from the spi controller.
BUG=b:38330715
Change-Id: I35f3bd8ddc5e71515df3ef0c1c4b1a68ee56bf4b
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/19708
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Pointer to spi_slave structure can be passed in as const to spi flash
probe functions since the probe functions do not need to modify the
slave properties.
BUG=b:38330715
Change-Id: I956ee777c62dbb811fd6ce2aeb6ae090e1892acd
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/19707
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Instead of making all SPI drivers allocate space for a spi_flash
structure and fill it in, udpate the API to allow callers to pass in a
spi_flash structure that can be filled by the flash drivers as
required. This also cleans up the interface so that the callers can
maintain and free the space for spi_flash structure as required.
BUG=b:38330715
Change-Id: If6f1b403731466525c4690777d9b32ce778eb563
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/19705
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add a new member page_size to spi_flash structure so that the various
spi flash drivers can store this info in spi_flash along with the
other sizes (sector size and total size) during flash probe. This
removes the need to have {driver}_spi_flash structure in every spi
flash driver.
This is part of patch series to clean up the SPI flash and SPI driver
interface.
BUG=b:38330715
Change-Id: I0f83e52cb1041432b0b575a8ee3bd173cc038d1f
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/19704
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested and working:
* HDD LED
* Booting GNU Linux 4.9 from HDD using SeaBios
* Booting GNU Linux 4.9 from USB using SeaBios
* Native GFX init
* All Fn function keys
* Speakers
* PCIe Wifi
* Camera
* WWAN
* Fan (Dynamic Thermal Managment)
* Flashing using internal programmer
* Dual memory DIMMs running at up to DDR3-1866
* AC events
* Touchpad, trackball and keyboard
* USB3 ports running at SuperSpeed
* Ethernet
* Headphone jack
* Speaker mute
* Microphone mute
* Volume keys
* Fingerprint sensor
* Lid switch
* Thinklight
* TPM (disable SeaBios CONFIG_TCGBIOS)
* CMOS options:
** power_on_after_fail
** reboot_counter
** boot_option
** gfx_uma_size
** usb_always_on
Untested:
* Booting Windows
* Hybrid graphics
* Docking station
* VGA
Broken:
* Wifi LED is always on
Change-Id: I5403cfb80a57753e873c570d95ca535cf5f45630
Signed-off-by: Philipp Deppenwiese <zaolin@das-labor.org>
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/18011
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Hide device 4 and device 7 if disabled.
Allows devicetree settings to take effect.
Tested on Lenovo T430.
Change-Id: I64a19e2bbdb1640e1d732f6e4486f73cbb0bda81
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/19689
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reserve the whole TZRAM area because it will be marked as secure-only
by BL31 and can not be accessed by the non-secure kernel.
CQ-DEPEND=CL:452659
BUG=chrome-os-partner:57361
BRANCH=firmware-gru-8785.B
TEST=the reserve memory is resized
Change-Id: Ie3ab39598f3f7cb96feb0c574e230e7fcb53a1a4
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: f34d254e1dfc9ae95a784aba22503e75a2fa65f1
Original-Change-Id: I39c4cb530f41a7b0f7f3064125072dd85b62276f
Original-Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/418102
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-(cherry picked from commit ea9fe064a9b1e1ce81fca74f829a0fb6e78ce426)
Original-Reviewed-on: https://chromium-review.googlesource.com/452640
Original-Tested-by: Julius Werner <jwerner@chromium.org>
Original-Commit-Queue: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/19431
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Submodule 3rdparty/arm-trusted-firmware 236c27d21f..3944adca59
This brings in 241 new commits from the upstream arm-trusted-firmware
repository, merged to the upstream tree between December 30, 2016 and
March 18, 2017.
3944adca Merge pull request #861 from soby-mathew/sm/aarch32_fixes
..
e0f083a0 fiptool: Prepare ground for expanding the set of images at
runtime
Also setup ATF builds so that unused functions don't break the build.
They're harmless and they don't filter for these like we do.
Change-Id: Ibf5bede79126bcbb62243808a2624d9517015920
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/18954
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
The 'cbmem -1' flag that cuts off console output before the last boot
will ignore content from earlier stages if it was truncated due to lack
of pre-CBMEM console space. This patch makes the "log truncated" message
more specific and adds it as an additional cut-off marker to 'cbmem -1'
to counteract that problem.
Also raise the log level of the coreboot banner one step to BIOS_NOTICE
to make it more likely to be included in the output for 'cbmem -1' to
find. (I believe NOTICE is reasonable but I wouldn't want to go as far
as WARN which should be reserved for actual problems. Of course this is
not ideal, but then again, our whole log-level system really isn't... it
would be better if we could make it always print a banner to the CBMEM
console without affecting the UART at the same time, but that would
require a larger amount of work.)
Change-Id: I58288593dfa757e14f4a9da4ffa7e27b0b66feb9
Reported-by: https://ticket.coreboot.org/issues/117
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/19720
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
There's no users of vbe_mode_info_valid() aside from the local
compilation units. Remove the declaration and make the function
static to the current global implementers.
Change-Id: I4872ac6ad15ba6a86bba69d51a8348b9921c152d
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/19730
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Nico Huber <nico.h@gmx.de>
For some reason the "interface" for adding framebuffer information
is sitting in src/include/vbe.h while also guarding the call to
fill_lb_framebuffer() with vbe_mode_info_valid() along with some
macro if CONFIG_* for good measure.
Move the fill_lb_framebuffer() declaration to coreboot_tables.h and
provide a comment about how it should be used. Also, now that
there's no need for the notion of a global vbe_mode_info_valid()
remove it from the conditional call path of fill_lb_framebuffer().
Change-Id: Ib3ade6314624091ae70424664527a02b279d0c9b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/19729
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
We have several different UART implementations of which three support a
timeout when receiving characters. In all of these three implementations
there is a bug where when the timeout is hit the last received character
will be returned instead of the needed 0.
The problem is that the timeout variable i is decremented after it has
been checked in the while-loop. That leads to the fact that when the
while-loop is aborted due to a timeout i will contain 0xffffffff and not
0. Thus in turn will fool the following if-statement leading to wrong
return value to the caller in this case. Therefore the caller will see a
received character event if there is none.
Change-Id: I23ff531a1e729e816764f1a071484c924dcb0f85
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/19731
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Vendorcode decides already in AMD_INIT_POST the exact location
of UMA memory. To meet alignment requirements, it will extend
uma_memory_size. We cannot calculate base from size and TOP_MEM1,
but need to calculate size from base and TOP_MEM1 instead.
Also allows selection of UmaMode==UMA_SPECIFIED to manually set
amount of memory reserved for framebuffer.
Change-Id: I0c375e5da0dfef6cef0c50272356cd32a87b1ff6
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/19346
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Vendorcode decides already in AMD_INIT_POST the exact location
of UMA memory. To meet alignment requirements, it will extend
uma_memory_size. We cannot calculate base from size and TOP_MEM1,
but need to calculate size from base and TOP_MEM1 instead.
Also allows selection of UmaMode==UMA_SPECIFIED to manually set
amount of memory reserved for framebuffer.
Change-Id: I2514c70a331c7fbf0056f22bf64f19c9374754c0
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/19328
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
AGESA and binaryPI boards have no easy way to determine correct
cbmem_top() location early enough when GFXUMA is enabled, so they
will use these functions with EARLY_CBMEM_INIT as well.
At the end of AmdInitPost() the decisions of UMA base and size
have not been written to hardware yet. The decisions are stored
inside AGESA heap object we cannot locate from coreboot proper
until after AmdInitEnv().
Modify code such that weak backup functions are only defined
for LATE_CBMEM_INIT; they are somewhat troublesome to handle.
Change-Id: Ifef4f75b36bc6dee6cd56d1d9164281d9b2a4f2a
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/19306
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Ravi Sarawadi