The updated MRC wrapper allow the IO hole size to be
configured from the coreboot side of things.
BUG=None
BRANCH=baytrail
CQ-DEPEND=CL:*152595
TEST=Built and booted. Also changed io hole size from mainboard as test.
Change-Id: I7a626764aecce94bbaf35d884606480f22a9aa84
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/183269
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
This adds the very basic top-level support for determining the
system wake source from ACPI. It only implements the _SWS method
in the _SB scope which just returns a bit index into the PM1
status register for the first fixed functional block.
This can be used to determine wake source of RTC or Power Button
but does not help determine wake source for USB or GPIO.
The ACPI spec says to return -1 if no source can be determined
from PM1 status register.
BUG=chrome-os-partner:8127
BRANCH=baytrail
TEST=build and boot on rambi
1) Test resume from S3 by RTC:
ACPI System Wake Source is PM1 Index 10
(bit 10 is RTC_STS in ACPI spec, ACPI_EVENT_RTC in kernel)
2) Test resume from S3 by power button:
ACPI System Wake Source is PM1 Index 8
(bit 8 is PWRBTN_STS in ACPI spec, ACPI_EVENT_POWER_BUTTON in kernel)
3) Test resume from S3 by USB:
ACPI System Wake Source is PM1 Index -1
Change-Id: Ifc5c0867f82cf291af157537b8c13fe44923d8f5
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/183333
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
There are several things in GNVS being initialized in the
mainboard ACPI table creation step that are shared across all
boards using the chipset.
Move the init that is not board specific into a shared function
and call it from the table creation step.
BUG=chrome-os-partner:8127
BRANCH=baytrail
TEST=build and boot on rambi device
Change-Id: I178193d7fe298ec26247402370a1af9280bb09c1
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/183332
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Update the microcode for c0 parts to 809.
BUG=None
BRANCH=baytrail
TEST=Built and booted on B3.
Change-Id: I733ce8eeae0b0eafe4a3a2dbeb09feba051c496a
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/183256
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
The sdram_param.h from cbootimage has different type and #ifdef names that
should be changed to comply with Coreboot.
Note we also changed field names so it will be easier to cope with translating
BCT config file (*.cfg) into simple C structure definition.
BUG=none
TEST=none
Change-Id: I41fbc628da920863b4ae3d8795cb6dfe4fd31dca
Reviewed-on: https://chromium-review.googlesource.com/182614
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Hung-Te Lin <hungte@chromium.org>
Tested-by: Hung-Te Lin <hungte@chromium.org>
A raw copy from NVIDIA cbootimage:
http://nv-tegra.nvidia.com/gitweb/?p=tools/cbootimage.git;\
a=blob;f=src/t124/nvboot_sdram_param_t124.h
This file containts required structure for initializing SDRAM.
BUG=none
TEST=none # The file is not used yet.
Change-Id: I580f7a86af84bc0fd8d88c4b59606893e73ea01c
Reviewed-on: https://chromium-review.googlesource.com/182613
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Hung-Te Lin <hungte@chromium.org>
Tested-by: Hung-Te Lin <hungte@chromium.org>
To initialize memory without BootROM, we need more details in the PMC registers,
including "io_dpd3_req", "por_dpd_ctrl", and various mask values.
BUG=none
TEST=emerge-nyan chromeos-coreboot-nyan # successfully.
Change-Id: I5444e64f49a66320319a5c59ce14635364b74f39
Reviewed-on: https://chromium-review.googlesource.com/183231
Tested-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Jimmy Zhang <jimmzhang@nvidia.com>
Commit-Queue: Hung-Te Lin <hungte@chromium.org>
To implement memory initialization without BCT, we need more details of memory
controller registers (mc).
Note some register names have been changed, so Nyan mainboard VPR code is also
modified.
BUG=none
TEST=emerge-nyan chromeos-coreboot-nyan # successfully.
Change-Id: I179aa41c5a6419fc94cc3343ff23080d1db19ca2
Reviewed-on: https://chromium-review.googlesource.com/182992
Tested-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Jimmy Zhang <jimmzhang@nvidia.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Hung-Te Lin <hungte@chromium.org>
This blob is loaded by the kernel and is what runs immediately after resuming
from lp0. It turns on the main CPUs and returns control to them and runs on
the AVP. The directory is totally independent from coreboot and has its own
Makefile. The only external dependency is on the stdint.h header file. The
openssl command line utility is used to sign the blob. Its header is defined
in C and built as part of the image.
BUG=None
TEST=With changes to coreboot which save the SDRAM parameters for use by the
boot ROM, used this blob to suspend and resume using LP0. USB had to be
disabled because those drivers don't work across suspend and resume.
BRANCH=None
Change-Id: I056a1f9ad3fa333f5b1ca140c8b7be819ffa11c7
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/183152
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
I messed up in setting this register, it should be using Tj_max-Temp
which in the default case works out to be 90-90=0.
This was apparently heavly throttling the CPU at idle temps.
BUG=chrome-os-partner:17279
BRANCH=baytrail
TEST=build and boot on rambi, run graphics_WebGLPerformance test
Change-Id: I4338280cf50db84dc44313d6fb6771ea5af21dad
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/183280
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Aaron Durbin <adurbin@chromium.org>
Tested-by: Aaron Durbin <adurbin@chromium.org>
These values are for the 2 and 4 core B-step parts.
BUG=chrome-os-partner:17279
BRANCH=baytrail
TEST=boot on rambi and check for valid GPU power values from DPTF
Change-Id: I2772cb9dbf17560fc31f871a111f32131c7e5105
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/183101
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit 701273892c7bdaf898a94a337fae9f7373a9c748)
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/183102
This change makes it possible for vboot to avoid an
exploit that could cause involuntary switch to dev mode.
It gives depthcharge/vboot some information on the
type of input device that generated a key.
BUG=chrome-os-partner:21729
TEST=manually tested for panther
BRANCH=none
CQ-DEPEND=CL:182420,CL:182241,CL:182946
Change-Id: I87bdac34bfc50f3adb0b35a2c57a8f95f4fbc35b
Reviewed-on: https://chromium-review.googlesource.com/182357
Reviewed-by: Luigi Semenzato <semenzato@chromium.org>
Tested-by: Luigi Semenzato <semenzato@chromium.org>
Commit-Queue: Luigi Semenzato <semenzato@chromium.org>
Add support for initializing the rtc device. Also
add RTC well loss events to the eventlog and properly
clear the event so it doesn't get added again.
BUG=None
BRANCH=baytrail
TEST=Built and booted. Tested battery loss. Eventlog
has RTC event. In addition the rtc device can
be properly probed in the kernel resulting in
/sys/class/rtc/rtc0 being available.
Change-Id: I1ca608b069dc50db116d75963d5542a7f9b1811f
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/183051
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
There's no reason to enable them, so keep them disabled to avoid
any unexpected behavior.
BUG=chrome-os-partner:24607
BRANCH=none
TEST=Built and booted on Nyan (rev1).
Change-Id: Ice7401b9986e6cc920356a3a5a082285c9b2f0a5
Reviewed-on: https://chromium-review.googlesource.com/181063
Tested-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Gabe Black <gabeblack@chromium.org>
RAM_ID GPIOs were previously changed to GPIO_FUNC0 to configure for MMIO
access when legacy was the default. Now, MMIO is the default, so these
GPIOs can conform to the normal labeling scheme. This change should have
no functional impact.
BUG=chrome-os-partner:25043
TEST=Manual on Rambi. Verify RAM_ID GPIOs on test unit are read with
identical values as before.
BRANCH=Rambi.
Change-Id: I2f76395064ea6e4170b2eaad6e67bfc1aa22b54e
Reviewed-on: https://chromium-review.googlesource.com/182934
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Shawn Nematbakhsh <shawnn@chromium.org>
Tested-by: Shawn Nematbakhsh <shawnn@chromium.org>
Apply the SOC thermal settings from DPTF reference code for
SdpProfile=4 and adjust graphics PUNIT setting to match.
BUG=chrome-os-partner:17279
BRANCH=baytrail
TEST=boot on rambi and check for valid GPU power values from DPTF
Change-Id: I59fc4b75b52084ebcc4c0556563afca0585ea6b8
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182786
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
When the thermal sensor on Panther is unavailable (early on resume)
it will return 0x80 which causes our AML thermal code to overflow,
which causes the system to shut down. Instead, return a reasonable
value in those cases so that the system will continue running until
the sensor gets back on its feet.
BUG=chrome-os-partner:24918
BRANCH=panther
TEST=suspend_resume_test survived more than 100 iterations on Panther
Change-Id: Ib2d714c39d353ce2415361bc6590784a3f6837d2
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/182369
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Sometimes the SuperIO seems to provide wrong readings, especially early
on after a resume from suspend. This will cause the system to power off.
If that happens, wait for 1s and read again, to make sure the high
temperature value was not just a flaky read.
BUG=chrome-os-partner:24918
BRANCH=panther
TEST=Boot tested on Panther.
Change-Id: Ib3768528d90e34448e96ad587b2503d8d8b1a775
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/182188
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Though the limited documentation indicates the default is
0 for the gfx_turbo_disable bit, in practice that isn't
true. Knock down the gfs_turbo_disable bit to enable
graphics turbo mode.
BUG=chrome-os-partner:25044
BRANCH=baytrail
TEST=Built and booted. Added debug code to output SB_BIOS_CONFIG.
Noted that bit 7 was set to 0.
Change-Id: I11210c6a0b29765cb709a54d6ebd94211538807b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182640
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
The Codec and ALS both have interrupt sources that can be configured.
The ALS kernel driver currently does not try to use it but the codec
driver does for things like jack detect.
ACPI Devices are added, but as with other ACPI devices the HID may
need to be updated once more official strings are decided.
BUG=chrome-os-partner:24380
BRANCH=baytrail
TEST=manual: build and boot on rambi and check for functional lightsensor
Change-Id: Ib51a2aaf32d5597926fcbe9183947e9ac53e1468
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182366
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This code should have been BSD licensed but was checked in with a GPL license.
BUG=chrome-os-partner:24957
TEST=Built libpayload for nyan.
BRANCH=None
Change-Id: Ic939fd21710c1d52b57b84d3038ec0c0ce4443cd
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/182344
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
On baytrail, it appears that the turbo disable setting is
actually building-block scoped. One can see this on quad
core parts where if enable_turbo() is called only on the
BSP then only cpus 0 and 1 have turbo enabled. Fix this
by calling enable_turbo() on all non-bsp cpus.
BUG=chrome-os-partner:25014
BRANCH=baytrail
TEST=Built and booted rambi. All cpus have bit 38 set to 0
in msr 0x1a0.
Change-Id: Id493e070c4a70bb236cdbd540d2321731a99aec2
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182406
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
In the past the turbo disable setting (bit 38) of the
IA32_MISC_ENABLES msr has been package scoped. That means
knocking the turbo disable bit down enabled turbo for the
entire package. Sadly, that's no longer true on all Intel
processors. Therefore, allow non-packaged scoped turbo
setting by introducing the CPU_INTEL_TURBO_NOT_PACKAGE_SCOPED
Kconfig option. It defaults to false which was the original
assumption.
BUG=chrome-os-partner:25014
BRANCH=baytrail
TEST=Built and ran both ways successfully.
Change-Id: I71a31e76ff47878023081fc47da643187517b597
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182405
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
This patch adds another cache invalidation stub to the x86 arch to
make it usable in common code. This whole stuff should probably be
redesigned anyway but I just want to get it working and unblock my CL
for now... more cleanups coming later.
BUG=None
TEST=Builds on Falco.
Change-Id: I2e8bdd8aa0e6723209384c24042f053f2e993fe6
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182534
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This will allow USB devices to wake the system (if 5V is not turned off)
and the controller to enter D3 at runtime. (if autosuspend is enabled)
BUG=chrome-os-partner:23629
BRANCH=baytrail
TEST=build and boot on baytrail
1) with modified EC to leave 5V on in S3 ensure that waking from suspend
with USB keyboard works.
2) with laptop-mode-tools usb autosuepend config updated see that device
enters D3 at runtime when no external devices attached.
Change-Id: Ia396d42494e30105f06eb3bd65b4ba8b1372cf35
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182536
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch switches every last part of Coreboot on ARM over to Thumb
mode: libpayload, the internal libgcc, and assorted assembly files. In
combination with the respective depthcharge patch, this will switch to
Thumb mode right after the entry point of the bootblock and not switch
back to ARM until the final assembly stub that jumps to the kernel.
The required changes to make this work include some new headers and
Makefile flags to handle assembly files (using the unified syntax and
the same helper macros as Linux), modifying our custom-written libgcc
code for 64-bit division to support Thumb (removing some stale old files
that were never really used for clarity), and flipping the general
CFLAGS to Thumb (some more cleanup there as well while I'm at it).
BUG=None
TEST=Snow and Nyan still boot.
Change-Id: I80c04281e3adbf74f9f477486a96b9fafeb455b3
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182212
Reviewed-by: Gabe Black <gabeblack@chromium.org>
The memcpy/memset/memmove assembly implementations have been taken from
U-Boot, which originally got them from Linux. I turns out that they are
actually not that bad, but they could use an update. This patch pulls in
the current Linux upstream versions of those files, removing some old
U-Boot cruft such as checking whether the two pointers in a memcpy() are
equal (really now?) or side-stepping the R8 register because it was used
for special purposes. It also returns to the good old Linux
ENTRY/ENDPROC macros since we have them now anyway, and straightens out
the W() macro in preparation for unified thumb support.
BUG=None
TEST=Snow still boots.
Change-Id: I138af269b423bef0a237759ac29f1ee58ca206a0
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182179
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
libgcc/macros.h contains some useful assembly macros that are common in
Linux kernel code and facilitate things such as unified ARM/THUMB
assembly. This patch moves it to a more general place where it can be
used by other code as well.
BUG=None
TEST=Snow still boots.
Change-Id: If68e8930aaafa706c54cf9a156fac826b31bb193
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182178
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
In order to support probing I2C devices when the controller is
in ACPI mode the mainboard needs to decalre them in the proper
scope with the address/interrupt information. The touchpad devices
are ATML0000/ELAN0000 and the touchscreen is ATML0001 so they can
be distinguished in userland scripts based on ID. There is also
a special "ISTP" node that indicates whether the devices is a
touchpad (=1) or touchscreen (=0) in case this is useful to drivers.
These names may not be final but they are a starting point and can
be easily changed.
Atmel devices also have a bootloader mode which needs to be
declared as a separate device. Unfortunately it does not work as
expected to have multiple I2cSerialBus() resources declared in a
single device and have it select properly, even with the use of
StartDependentFn(), so bootloader devices are declared separately.
The original devices are left in \_SB scope and are only enabled
if the I2C controllers are in PCI mode. The new devices are only
enabled if the I2C controllers are in ACPI mode.
BUG=chrome-os-partner:24380
BRANCH=baytrail
TEST=manual
1) Ensure there is no change in functionality by default and that
the devices are still probed by chromeos_laptop in the kernel.
2) Enable lpss_acpi_mode=1 in devicetree.cb and kernel changes to
add _HID entries for devices in appropriate drivers. Ensure that
the devices are probed successfully. Further changes are needed
to the chromeos-touch-firmware scripts to load config and update
firmware based on the new ACPI _HID entries.
3) Put touchpad in bootloader mode (by flashing bad firmware) and
ensure that it is detected at address 0x25 and the firmware is
able to be updated.
Change-Id: I5b9b47ddc94474a677497271e963f62cb09438e0
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182259
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The current byte value was being converted to an int
when checking against literal 0xff. As the type of
the current pointer was char (signed) it was sign
extending the value leading to 0xffffffff != 0xff.
Fix this by using an unsigned type and using a
constant type for expected erase value.
BUG=chrome-os-partner:24916
BRANCH=baytrail
TEST=Booted after chromeos-firmwareupdate. Noted that MRC
cache doesn't think the erased region isn't erased.
Change-Id: If95425fe26da050acb25f52bea060e288ad3633c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182154
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
On a firmware update the MRC cache is destroyed. On the
subsequent boot the MRC region was attempted to be erased
even if it was already erased. This led to spi part taking
longer than it should have for an unnecessary erase
operation. Therefore, check that the region is erased
before issuing the erease command.
BUG=chrome-os-partner:24916
BRANCH=baytrail
TEST=Booted after chromeos-firmeareupdate. Noted no
error messages in this path.
Change-Id: I6fadeb6bc5fc178abb0a7e3f0898855e481add2e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182153
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
There is no speaker and no builtin microphone in this system,
hence disable them in the verb table.
BRANCH=panther
BUG=chrome-os-partner:24230
TEST=Boot Panther, see Microphone and Speaker disappear
in Audio Settings
Change-Id: I32bacec38ba3ba0c2359a8fc94e12af64f576012
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/182006
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Some files were accidentally made GPL when they were added to libpayload. This
change changes them over to a BSD license to be in line with the intended
license of libpayload.
BUG=chrome-os-partner:24957
TEST=Built libpayload for nyan.
BRANCH=None
Change-Id: Ia95ac4951b173dcb93cb489705680e7313df3c92
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/182202
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Nothing can actually use this as the EC cannot speak
using baytrail's SERIRQ protocol. Also, the voltage
bridge is going away so nothing will be hooked up to it.
Therefore disable this it.
BUG=chrome-os-partner:24693
BRANCH=rambi
TEST=Built and booted.
Change-Id: I406bb9c227578ec0a75eaf67143b3b27cb7880ae
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182082
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Fix the smeared screen observed when FB has not been initialized.
BUG=None
TEST=graphics comes up clean.
Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com>
Change-Id: I1ce2365d07d0463968fe50fc45a278badc9e9c0d
Reviewed-on: https://chromium-review.googlesource.com/182090
Tested-by: Jimmy Zhang <jimmzhang@nvidia.com>
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Jimmy Zhang <jimmzhang@nvidia.com>
The hack seems to set up coreboot display to use window B. We eventually
want to use the same window as the kernel is going to use (I think), so
that's what this patch does.
We think window B is hiding the contents of window A, which is why we
weren't seeing ChromeOS UI come up. This fix makes that not happen anymore
by making coreboot use window A.
BUG=chrome-os-partner:24844
TEST=Can boot ChromeOS to UI from coreboot.
Change-Id: I24b95200ba2e8eaeadecd45392ccee5e270aa7da
Reviewed-on: https://chromium-review.googlesource.com/182001
Tested-by: Andrew Chew <achew@nvidia.com>
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
Tested-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-by: Jimmy Zhang <jimmzhang@nvidia.com>
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Andrew Bresticker <abrestic@chromium.org>
This improves boot time in 2 ways for a firmware upgrade:
1. Normally MRC would detect the S0 state without an MRC cache
even though it's told to the S5 path. When it observes this
state a cold reset occurs. The cold reset stays in S5 for
at least 4 seconds which is time observed by the end user.
2. As the EC was running RW code before the reset after firmware
upgrade it will still be running the older RW code. Vboot will
then reboot the EC and the whole system to put the EC into RO
mode so it can handle the RW update.
The issues are mitigated by detecting the system is in S0 with
no MRC cache and the EC isn't in RO mode. Therefore we can do the
reboot without waiting the 4 secs and the EC is running RO so
the 2nd reboot is not necessary.
BUG=chrome-os-partner:24133
BRANCH=rambi,squawks
TEST=Booted. Updated firmware while in OS. Rebooted. Noted the
EC reboot before MRC execution.
Change-Id: I1c53d334a5e18c237a74ffbe96f263a7540cd8fe
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182061
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
It's helpful to have a generic function that will tell
the EC to reboot if the EC isn't running a specified
image. Add that and implement google_chromeec_early_init()
to utilize the new function still maintaing its semantics
of if recvoery mode is enabled the EC should be running its
RO image. There is a slight change in that no communication
is done with the EC if not in recovery mode.
BUG=chrome-os-partner:24133
BRANCH=rambi,squawks
TEST=Built and boot with recovery request. Noted EC reboot.
Change-Id: I22240f6a11231e39c33fd79796a52ec76b119397
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182060
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Set critical temperature thresdholds to 70C. This will cause DPTF
framework to shut down the system so it may need to be higher or
lower but will need some testing.
BUG=chrome-os-partner:17279
BRANCH=rambi
TEST=build and boot on rambi, start DPTF framework and observe it
using specified critical thresholds.
Change-Id: Ibbf6d814295eb5ff006cb879676b7613f5eb56a3
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182025
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Added a method in each temp sensor to disable the aux trip points
and then a wrapper function to call this method for each enabled
temperature sensor.
The event handler function is changed to not use a switch statement
so it does not need to be serialized. This was causing issues
with nested locking between the global lock and the EC PATM mutex.
Some unused code in temp sensors that was added earlier is removed
and instead a critical threshold is specified in _CRT.
The top level DPTF device _OSC method is expanded to check for the
passive policy UUID and initialize thermal devices. This is done
for both enable and disable steps to ensure that the EC thermal
thresholds are reset in both cases.
Additionally the priority based _TRT is specified with TRTR=1.
BUG=chrome-os-partner:17279
BRANCH=rambi
TEST=build and boot on rambi, load esif_lf kernel drivers and start
esif_uf application. Observe that temperature thresholds are set
properly when running 'appstart Dptf' and that they are disabled
after running 'appstop Dptf'
Change-Id: Ia15824ca42164dadae2011d4e364b70905e36f85
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182024
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The PATx methods will be passed a temperature in deci-kelvin,
so it needs to be converted back to kelvin before being sent
to the EC.
The PAT disable method is changed to take the temperature ID
as an argument so individual sensors can be disabled.
BUG=chrome-os-partner:17279
BRANCH=rambi
TEST=build and boot on rambi, load esif_lf kernel drivers and
esif_uf userspace application. Start and stop DPTF and see
that temperature thresholds are set to sane values.
Change-Id: Ieeff5a5d2d833042923c059caf3e5abaf392da95
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182023
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Some SSD modules don't support DEVSLP correctly due to their
firmware. Since the power savings are minimal, don't use
DEVSLP to prevent potential problems. Some of the symptoms
are that sometimes this causes USB devices to not work properly.
BUG=chrome-os-partner:23186,
BRANCH=panther
TEST=Boot tested on Panther
Change-Id: Iba3f721c73e0e760b6a9861ca23480ddb923df40
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/181957
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
The SMI on TCO timer timeout policy was copied from other
chipsets. However, it's not very advantageous to have
the TCO timer timeout trigger an SMI unless the firmware
was the one responsible for setting up the timer.
BUG=chromium:321832
BRANCH=rambi,squawks
TEST=Manually enabled TCO timer. TCO fires and logged in
eventlog.
Change-Id: I420b14d6aa778335a925784a64160fa885cba20f
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/181985
The PMC in baytrail maintains an additional set
wake status in memory-mapped registers. If these
bits aren't cleared the device won't be able to
go to S5 or S3 without being immediately woken up.
Therefore clear these registers.
BUG=chrome-os-partner:24913
BRANCH=rambi,squawks
TEST=Ensured PRSTS bit 4 is cleared after a reboot and S3 and S5 work
correctly.
Change-Id: I356e00ece851961135b4760cebcdd34e8b9da027
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/181984
When CONFIG_ELOG is selected the reset, power, and wake
events are logged in the eventlog.
BUG=chrome-os-partner:24907
BRANCH=rambi,squawks
TEST=Various resets and wake sources. Interrogated eventlog
to ensure results are expected.
Change-Id: Ia68548562917be6c2a0d8d405a5b519102b8c563
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/181983
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
The memory reference code doesn't maintain some of
the registers which contain valuable information in order
to log correct reset and wake events in the eventlog. Therefore
snapshot the registers which matter in this area so that
they can be consumed by ramstage.
BUG=chrome-os-partner:24907
BRANCH=rambi,squawks
TEST=Did various resets/wakes with logging patch which
consumes this structure. Eventlog can pick up reset
events and power failures.
Change-Id: Id8d2d782dd4e1133113f5308c4ccfe79bc6d3e03
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/181982
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
This is a first cut at the u-boot cli. It builds and loads and runs
and has no commands. That's next.
Interestingly, this is code right from our u-boot tree, and it's full
of style violations which I don't intend to fix.
Remove dependency on anything else, but this won't work until the
libpayload serial drivers for arm are set up.
BUG=None
TEST=build and boot on nyan and get a u-boot cli prompt.
BRANCH=None
Change-Id: I52cf7c02e2bdd00a82e6e48fd2471416c87e4627
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://chromium-review.googlesource.com/179721
Reviewed-by: Puneet Kumar <puneetster@chromium.org>
Commit-Queue: Puneet Kumar <puneetster@chromium.org>
Tested-by: Puneet Kumar <puneetster@chromium.org>
