Make sure the build breaks in case of warnings.
BUG=none
TEST=run the following command with the previous patch removed and
then restored:
$ for b in rambi storm nyan_big; do
cros_workon-$b start libpayload
emerge-$b libpayload
done
all builds succeed with the restored patch and fail when a
compilation warning is thrown.
Change-Id: I9bdcd8938f59913e4ba86df5e4921b3f821ef920
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/200110
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Seems that the 'if (cursor_enabled)' check in
video_console_fixup_cursor() that was removed in commit 1f880bca0 really
meant to check for 'if (console)'. Looks like the whole video console
driver is built extra robust to not fail no matter how screwed up the
console is, so let's add this missing check here as well. Also fixed up
a few other missing 'if (!console)' checks while I'm at it.
However, what payloads should really be doing is check the return value
of video_(console_)init() and not call the other video functions if that
failed. This also adapts video_console_init() to correctly pass through
the return value for that purpose (something that seems to have been
overlooked in the dd9e4e58 refactoring).
BUG=chrome-os-partner:28494
TEST=None. I don't know what Dave did to trigger this in the first
place, but it's pretty straight-forward.
Change-Id: I1b9f09d49dc70dacf20621b19e081c754d4814f7
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/200688
Reviewed-by: David Hendricks <dhendrix@chromium.org>
GPIO init marcos are not enough to initialize different gpio attributes
BUG=none
TEST=emerge-rambi coreboot works well
Change-Id: I193fa7b3e22632cacb555e726e3dd3991f4f4faa
Signed-off-by: Kane Chen <kane.chen@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/200531
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
When doing DP attach, we need to make sure the register change to
take effect immediately, otherwise it may fail to catch the attach
timing.
BRANCH=None
BUG=chrome-os-partner:28128
TEST=Display works and system boots up on Nyan and Big
Change-Id: I569dc435a1aa4aac0d5ecd0655d2ad87a791246d
Signed-off-by: Vince Hsu <vinceh@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/200414
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Jimmy Zhang <jimmzhang@nvidia.com>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
We initialized the dc before the plld's initialization. So some
of the dc init settings did not took effect. This patch moves
the clock_display() before the dc init call.
BRANCH=None
BUG=chrome-os-partner:28128
TEST=Display works and system boots up on Nyan and Big
Change-Id: If2c40e2526fdf7a6aa33a2684ba324bd0ec40e90
Signed-off-by: Vince Hsu <vinceh@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/200413
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Jimmy Zhang <jimmzhang@nvidia.com>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
There is a hub in USB port2 downstream.
BUG=chrome-os-partner:28964
BRANCH=None
TEST=emerge-nyan_blaze coreboot depthcharge chromeos-bootimage and verify usb
port2 is workable
Change-Id: I0e698970729911f401f89594232f9d49e4da93cc
Signed-off-by: Neil Chen <neilc@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/200417
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Our tests with the I2C bit clear mechanism (recovering from "lost
arbitration" errors) show that the bit clear hardware does not work
correctly in some situations. When a wedged slave device tries to send
more than one 0-to-1-to-0 transition to the host (e.g. leftover bits
from an aborted read), the controller never transitions the BC_ENABLE
bit back to zero.
This patch adds a long timeout to the bit clear code that waits for
register transitions as a safeguard. This way, We will still eventually
exit the function (probably followed by a reboot). Our tests show that
this will recover from all conditions after at most a few reboots.
BRANCH=nyan
BUG=chrome-os-partner:28323
TEST=Ran wedge_ack and wedge_read tests with software_i2c patch, system
recovered as expected in all cases.
Change-Id: I6c37119130e1240e1ef3a5944582abbcd2e39ff0
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/200265
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Gabe Black <gabeblack@chromium.org>
This patch adds I2C emulation in software through raw toggling of the
SDA/SCL lines. Platforms need to provide bindings to toggle their
respective I2C busses for this to work (e.g. by pinmuxing them as GPIOs,
currently only enabled for Tegra).
This is mostly useful as a debugging feature, to drive unusual states on
a bus and closely monitor the device output without the need of a bus
analyzer. It provides a few functions to "wedge" an I2C bus by aborting
a transaction at certain points, which can be used to test if a system
can correctly recover from an ill-timed reboot. However, it can also
dynamically replace the existing I2C transfer functions and drive
some/all I2C transfers on the system, which might be useful if a driver
for the actual I2C controller hardware is not (yet) available.
Based on original code by Doug Anderson <dianders@chromium.org> and
Hung-ying Tyan <tyanh@chromium.org> for the ChromeOS embedded
controller project.
BRANCH=None
BUG=chrome-os-partner:28323
TEST=Spread tegra_software_i2c_init()/tegra_software_i2c_disable()
through the code and see that everything still works.
Change-Id: I9ee7ccbd1efb38206669a35d0c3318af16f8be63
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/198791
Reviewed-by: Doug Anderson <dianders@chromium.org>
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
The kernel will not track wakeup events for devices unless they have
a defined _PRW. There is no EC output of the lid signal coming to
a GPIO and instead it pulses PCH_WAKE#.
BUG=chrome-os-partner:27631
TEST=Manual on Rambi.
- Run lidclose + lidopen on EC console, verify that wakeup_count
increments.
- Run lidclose + lidopen in rapid succession, verify that suspend
request is aborted.
BRANCH=Rambi.
Change-Id: I8d4c58a7bb37d7e474ec094fe96e46e1bfd980de
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/200289
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
BUG=none
BRANCH=nyan
TEST=built and booted on Big under various modes, verified that
expected boot mode showed up using "mosys eventlog list"
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I8d98487a2cb910874c8d741008ae59a6c89102e7
Reviewed-on: https://chromium-review.googlesource.com/199691
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
The handling of LPDDR is a bit messy in Intel platforms. There
is no traditional SPD so instead one is created by hand from the
provided datasheets.
These have varying (and sometimes unexpected) geometry and it can
be important during bringup to know what configuration is being
passed to the memory training code.
This could in theory be put in a more generic location, but for now
this is the only board with LPDDR3 where I have found it valuable.
BUG=chrome-os-partner:28234
TEST=Build and boot on samus, look for SPD details on the console.
CQ-DEPEND=CL:199920
CQ-DEPEND=CL:199921
CQ-DEPEND=CL:199922
CQ-DEPEND=CL:199943
CQ-DEPEND=CL:*163751
Change-Id: Ibce0187ceb77d37552ffa1b4a5935061d7019259
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/199923
Switch from the haswell cpu/northbridge/southbridge interface
to the soc/intel/broadwell interface.
- Use new headers where appropriate
- Remove code that is now done by the SOC generic code
- Update GPIO map to drop LP specific handling
- Update INT15 handlers, drop all but the boot display hook
BUG=chrome-os-partner:28234
TEST=Build and boot on samus
CQ-DEPEND=CL:199920
CQ-DEPEND=CL:199921
CQ-DEPEND=CL:199923
CQ-DEPEND=CL:199943
CQ-DEPEND=CL:*163751
Change-Id: I56f3543612e89e2cdb4256b1bcd4279f5546b918
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/199922
This needs to be executed in both romstage and ramstage
for the different PEI binary stages.
It uses the broadwell interface now instead of haswell.
BUG=chrome-os-partner:28234
TEST=Build and boot on samus
CQ-DEPEND=CL:199920
CQ-DEPEND=CL:199922
CQ-DEPEND=CL:199923
CQ-DEPEND=CL:199943
CQ-DEPEND=CL:*163751
Change-Id: Ida05bd17b9e54f08ed0e2767361c9301a2e97709
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/199921
The code to find the SPD data for the mainboard based on GPIOs
is moved from romstage.c into spd.c.
It relies on the updated pei_data structure from broadwell instead
of the haswell interface.
BUG=chrome-os-partner:28234
TEST=Build and boot on samus
CQ-DEPEND=CL:199921
CQ-DEPEND=CL:199922
CQ-DEPEND=CL:199923
CQ-DEPEND=CL:199943
CQ-DEPEND=CL:*163751
Change-Id: I5bd56f81884dae117b35a1ffa5fb6e804fd3cb9c
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/199920
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
When emerging libpayload a warning is generated about selfboot() being
defined without a prior prototype.
Addinf cbfs.h when CBFS use if compiled fixes the warning.
BUG=none
TEST=run the following
$ for b in rambi storm nyan_big; do
cros_workon-$b start libpayload
emerge-$b libpayload
done
verify that there is no compilation warnings thrown any more
Change-Id: Ic9cb5571f708bb006a0d477e451fd1f3b3eb833f
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/200099
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Add support for enabling different coreboot stages (bootblock, romstage and
ramstage) to have arm64 architecture. Most of the files have been copied over
from arm/ or arm64-generic work.
BUG=None
BRANCH=None
TEST=Compiled successfully for rush board with bootblock being armv4 and
romstage and ramstage being armv8
Change-Id: Icd59bec55c963a471a50e30972a8092e4c9d2fb2
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/197397
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
ARM processors save the PC value in the Link Register when they handle
and exception, but they store it with an added offset (depending on the
exception type). In order to make crashes easier to read and correctly
support more complicated handlers in libpayload, this patch adjusts the
saved PC value on exception entry to correct for that offset.
(Note: The value that we now store is what ARM calls the "preferred
return address". For most exceptions this is the faulting instruction,
but for software interrupts (SWI) it is the instruction after that. This
is the way most programs like GDB expect the stored PC address to work,
so let's leave it at that.)
Numbers taken from the Architecture Reference Manual at the end of
section B1.8.3.
BRANCH=none
BUG=chrome-os-partner:18390
TEST=Provoked a data abort and an undefined instruction in both coreboot
and depthcharge, confirmed that the PC address was spot on.
Change-Id: Ia958a7edfcd4aa5e04c20148140a6148586935ba
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/199844
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This adds a generic helper function for adding boot reason in the
ChromeOS case. If vboot is enabled, it will use information passed
in via the vboot handoff table in cbmem to determine mode and
reason in the case of recovery.
BUG=chromium:373467
BRANCH=nyan
TEST=built along with follow-up CL and booted on Big under various
modes, verified entry was added to eventlog with "mosys eventlog list"
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I50a7aa6d55eb46413fe9929e732d6eb18c758d4b
Reviewed-on: https://chromium-review.googlesource.com/199690
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
The video console runs a video_console_fixup_cursor() function after
every printed character to make sure the cursor is still in the output
window and avoid overflows. For some crazy reason, this function does
not run when cursor_enabled is false... however, that variable is only
about cursor *visibility*, and it's imperative that we still do proper
bounds checking for our output even if the cursor itself doesn't get
displayed (otherwise we can end up overwriting malloc cookies that cause
a panic on the next free() and other fun things like that).
In fact, there seems to be no reason at all to even keep track of the
cursor visibility state in the generic video console framework (the
specific backends already do it, too), so let's remove that code
entirely. Also set the default cursor visibilty in the corebootfb
backend to 0 since that's consistent with what the other backends do.
BUG=None
TEST=Turn on video console on Big, generate enough output to make it
scroll, make sure it does not crash.
Change-Id: I1201a5bccb4711b6ecfc4cf47a8ace16331501b4
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/196323
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
The calling convention of payload entry function is different by architecture.
For example, X86 takes no arguments and ARM needs first param to be a
cb_header_ptr*.
To help payloads load and execute other payloads easily and correctly, we should
provide the selfboot() function in libpayload, using same prototype as defined
in Coreboot environment.
BUG=none
TEST=emerge-nyan libpayload # pass
BRANCH=none
Change-Id: I8f1cb2c0df788794b2f6f7f5500a3910328a4f84
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/199503
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
The libpayload build environment has been changed slightly and here are the
minimal changes to compile ubootcli under ebuild system:
- Allow overriding LIBPAYLOAD_DIR.
- Include only single libpayload.a.
- Revise build flags.
- Increase heap/stack size so video console init is fine.
- Remove abort() which may be defined in libpayload.
- Change weak link default function to non-inline (so it will be provided).
BUG=none
TEST=With a crafted ubootcli.ebuild:
emerge-nyan ubootcli # arm pass
emerge-rambi ubootcli # x86 pass
Change-Id: Icd3bd9f29a3682cd1a2c148a2a57ce44efe33664
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/199476
Reviewed-by: Julius Werner <jwerner@chromium.org>
Some EABI conformant toolchains like GCC need additional functions like raise.
To prevent payloads adding arch-specific implementations everywhere, we should
provide the default version in libpayload.
BUG=none
TEST=emerge-nyan libpayload # pass
BRANCH=none
Change-Id: Id1e3c29590aa5881aefd944a7551949ce9a47b8f
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/199686
Hook the soc/intel/broadwell directory into the configuration
and build system so it can be used by mainboards.
BUG=chrome-os-partner:28234
TEST=build and boot on wtm2
Change-Id: Ia48ac644a8cefb2cf9c64efaa1bd9737ddfb8b1f
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/199893
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This provides a driver for the ADSP (aka SST -- smart sound tech)
that is built into the southbridge in haswell/broadwell.
This block shares pins with HDA so they cannot both be enabled at
the same time so if HDA is disabled the pins are routed to the
ADSP block.
The ADSP device needs to be put into ACPI mode so a new block of
BARs and enable status is added to the device_nvs structure.
The ACPI _HID is expected to be different for haswell and broadwell
so a new ACPI method is added to check if the PCH is WildcatPoint
and then used in the base ADSP ACPI device definition.
BUG=chrome-os-partner:28234
TEST=Build and boot on samus with ADSP device enabled and check
firmware log for HDA disabled message and that the HDA PCI device
is gone. With sio_acpi_mode=1 the ADSP PCI device is also gone
and is instead enumerated by ACPI.
Change-Id: I73d950725ce29d44a5da9aab00c7f784ba63f2d1
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/199892
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add defines for PCI device+function for SA/PCH devices and
complete the list by adding entries for devices that were missing.
Then make use of these defines in pch.c and serialio.c.
BUG=chrome-os-partner:28234
TEST=Build and boot on wtm2
Change-Id: Id1b284cfab8a72acf040ea1ce1c38324abccc110
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/199891
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The two UARTs built into the haswell/broadwell PCH can be used for
standard console output if configured properly. There is a magic bit
in the IOBP settings for the UART device that will put it into "byte
addressing mode" so it is compatible with standard 16550 UART drivers.
When in this mode the linux kernel driver will be unable to talk to
the device so it is indicated as disabled via the ACPI driver.
Note that this by itself is not enough to get working MMIO UART
in coreboot because the current code is heavily tied with the oxpcie
driver. I have a separate set of patches to disentangle the generic
MMIO UART code from the oxpcie driver but I want to get that series
in upstream first.
BUG=chrome-os-partner:28234
TEST=None
Change-Id: I9e689456aa5017784328d1be33ad072f79db1920
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/199807
This function will enable the EHCI port 1 on haswell/broadwell
PCH to act as USB debug port. This is hardcoded to port 1.
The EHCI controller must be kept enabled if CONFIG_USBDEBUG
is enabled so this logic is added to the ehci ramstage driver.
BUG=chrome-os-partner:28234
TEST=enable CONFIG_USBDEBUG and build+boot with USB debug output.
Note that libpayload does not support usbdebug yet (I have separate
patches for that) so no payload output is visible.
Change-Id: I704a4786438173b2f3ee2c246636f5a24d8b428c
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/199412
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
CBMEM IDs are converted to symbolic names by both target and host
code. Keep the conversion table in one place to avoid getting out of
sync.
BUG=none
TEST=manual
. the new firmware still displays proper CBMEM table entry descriptions:
coreboot table: 276 bytes.
CBMEM ROOT 0. 5ffff000 00001000
COREBOOT 1. 5fffd000 00002000
. running make in util/cbmem still succeeds
Change-Id: I0bd9d288f9e6432b531cea2ae011a6935a228c7a
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/199791
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The main benefit of adding this skeleton is the addition of the
correct memory map to CBMEM. Attempts to load depthcharge do not fail
because of unavailability of the bounce buffer.
BUG=chrome-os-partner:27784
TEST=boot updated firmware on AP148, observe
CPU: Qualcomm 8064
in the ramstage console output as well as not failing to load
depthcharge any more.
Change-Id: I56c1fa34ce3967852be6eaa0de6e823e64c3ede8
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/199675
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Dynamic cbmem support has been enabled on storm, but the proper
initialization at romstage is missing.
Proper DRAM base address definition is also necessary so that CBMEM is
placed in the correct address range (presently at the top of DRAM).
BUG=chrome-os-partner:27784
TEST=build boot coreboot on ap148, observe the following in the
console output:
Wrote coreboot table at: 5fffd000, 0xe8 bytes, checksum 44a5
coreboot table: 256 bytes.
CBMEM ROOT 0. 5ffff000 00001000
COREBOOT 1. 5fffd000 00002000
Change-Id: I74ccd252ddfdeaa0a5bcc929be72be174f310730
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/199674
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Include the required modules in romstage and enable early console.
BUG=chrome-os-partner:27784
TEST=observe the romstage prompt in the console output:
coreboot-4.0 romstage Tue May 13 17:08:58 PDT 2014 starting...
Change-Id: Ie3853b9afc53246e6eb997f279ccd4dbb08f748b
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/199673
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Eliminate duplicated printout and if needed, print only changed
information.
BUG=none
TEST=verified that the 'New segment dstaddr...' message is not
duplicated anymore
Change-Id: Ia13593394fccbb225f2bd9ab2b9228bac29d50fb
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/199672
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This is just a convenience - when printing a pre-ram coreboot banner,
add the actual stage name to it.
BUG=none
TEST=manual
. with CONFIG_EARLY_CONSOLE enabled the banners look as follows (the
last one is for ramstage reads 'booting' instead of 'starting'):
coreboot-4.0 bootblock Tue May 13 14:13:37 PDT 2014 starting...
coreboot-4.0 romstage Tue May 13 14:13:37 PDT 2014 starting...
coreboot-4.0 Tue May 13 14:13:37 PDT 2014 booting...
Change-Id: I218c0d3bbfa4a9bdff5632855c520af8626d6495
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/199671
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This is a placeholder for a real libpayload config, it is fairly close
to the real one and will allow building chrome os image for storm in
the meanwhile.
BUG=chrome-os-partner:27784
TEST=manual
. with this and some other patches 'emerge-storm libpayload
depthcharge' does not fail anymore.
Change-Id: Ie1a96310a7b329fac9d869cfe83005ea20c7e235
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/198928
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Fix pointer related casts since this can create a problem for 64-bit systems.
BUG=None
BRANCH=None
TEST=Compiled successfully for link, nyan using emerge-* libpayload
Change-Id: I4cbd2d9f1efaaac87c3eba69204337fd6893ed66
Reviewed-on: https://chromium-review.googlesource.com/199564
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
This adds the Kconfig entries for supporting the broadwell SOC.
This is merged from the various cpu/northbridge/southbridge Kconfig
files that existed for haswell and lynxpoint.
BUG=chrome-os-partner:28234
TEST=Build and boot on wtm2+broadwell
Change-Id: I485b5b80389d5e743e4f8f4c187deb0671a0a697
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/199411
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
- Add a function to initialize the common parts of global NVS.
- Add a function to create the HPET table.
- Add a function to create MADT table overrides.
BUG=chrome-os-partner:28234
TEST=None
Change-Id: I304767edf9d5b6ad6059e1015bfca7480723be51
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/199409
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
- Fix header includes
- Use ACPI_BASE_ADDRESS instead of get_pmbase()
- Remove chip_operations as those are now in chip.c
BUG=chrome-os-partner:28234
TEST=None
Change-Id: I28712275a46b64941796bca46ec1bd648b8178f6
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/199408
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Instead of using a C-state table provided by the mainboard
devicetree use a different set of C-states for S0ix and non-S0ix
systems and use a devicetree setting to choose the appropriate set.
BUG=chrome-os-partner:28234
TEST=None
Change-Id: I11175d36fcb68ecad2420e5059234ae1910156f7
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/199407
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This is common code that can be shared across all broadwell
systems instead of being implemented in every main board.
BUG=chrome-os-partner:28234
TEST=None
Change-Id: I2535f4d71c28b5804c65619e7818170f5a277e26
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/199406
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This is very similar to the handling on baytrail platform.
- This late-stage reference code binary is in RW firmware so it
can be updated.
- The reference code binary is in ELF format to be relocated and
executed early in ramstage.
- The reference code binary is staged in SMM region so it can be
reused in the resume path.
- PEI data structure is filled in by common broadwell code as well
as mainboard specific code.
BUG=chrome-os-partner:28234
TEST=None
Change-Id: I9a47e7dd4dfaeeafd41a63170e259ef77b8df3e2
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/199404
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
- This driver will get called shortly after ramstage is loaded
and will execute the second reference code binary.
- Prepare for S3 resume handling by determining whether this is
a valid resume path.
- Add function to save the ACPI PM1 wake source on resume for
use in ACPI _SWS method.
BUG=chrome-os-partner:28234
TEST=None
Change-Id: Ic9f8cfc9f4b9c72d3dfb3b1f3f716d266814bc46
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/199403
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
In order to not mess up legacy bootloaders do not reserve the
SMM relocation region but instead backup and restore the contents
during CPU init and SMM relocation.
BUG=chrome-os-partner:28234
TEST=None
Change-Id: Icc939d454dd8f3a5a6db917a8a96e3800ebdb1bc
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/199402
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This change updates the cfg file for Micron/Samsung 2GB,
792MHz DRAM based on the data generated by t124_emc_reg_tool.
BUG=none
BRANCH=blaze
TEST=emerged coreboot, booted successfully into kernel.
Change-Id: I840cdd967c3b38479946a497a91da89bef5a98ad
Signed-off-by: Jerry Wang <jerryw@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/199296
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Tom Warren <twarren@nvidia.com>
If the kernel does not properly handle the TPM and send it a
TPM_SaveState command before suspend then it will not be in
the correct state on resume. In order to easily detect this
case add a new post code for TPM failure and use it in the
vboot resume path.
BUG=chromium:371105
TEST=Build and boot on wtm2.
Change-Id: I412520b521387a8e18ad1c6f5a64b39cdd5c88ec
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/199371
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
There is a status bit for this event in most intel chipsets that
we can read and report. Start by adding the new event type.
BUG=chrome-os-partner:28234
TEST=build and boot on wtm2
Change-Id: Ib06411e3b87a1d069fb469943dd445bee6c1291f
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/199370
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
- Remove ULT specific hooks and apply them to all broadwell and
haswell CPUs that are supported.
- Rename functions to be more generic rather than haswell specific.
- Clean up code and comments.
BUG=chrome-os-partner:28234
TEST=None
Change-Id: I658f47fd653fa702a0039def130e4a92bda4600e
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/199395
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
