Read bInterval from endpoint descriptors and store it in our endpoint_t
struct. The interval is encoded dependently on the device' speed and the
endpoint's type. Therefore, it will be normalized to the binary logarithm
of the number of microframes, i.e.
t = 125us * 2^interval
The interval attribute will be used in the xHCI driver.
Original-Change-Id: I65a8eda6145faf34666800789f0292e640a8141b
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/3449
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
(cherry picked from commit aee44fa37d)
BUG=chrome-os-partner:21969
TEST=None
Change-Id: Ic42ad3c193390d5838b563346604b1ef9f385b52
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/168094
xHCI requires special treatment of set_address since it determines
the device number itself (instead of the driver, as with the other
controllers). The controller also wants to validate a chosen device
configuration and we need to setup additional structures for the
device and the endpoints.
Therefore, we add three functions to the hci_t structure, namely:
set_address()
finish_device_config()
destroy_device()
Current implementation for the Set Address request moved into
generic_set_address() which is set_address() for the UHCI, OCHI and
EHCI drivers. The latter two are only provided as hooks for the xHCI
driver.
The Set Configuration request is moved after endpoint enumeration.
For all other controller drivers nothing changes, as there is no other
device communication between the lines where the set_configuration()
call moved.
Original-Change-Id: I6127627b9367ef573aa1a1525782bc1304ea350d
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/3447
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
(cherry picked from commit 482af6d15c)
BUG=chrome-os-partner:21969
TEST=None
Change-Id: Ieb3af316a8d9aadb55a204b9f86281a511d14abd
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/168093
These values are already used in this usb stack.
Original-Change-Id: If96f1dc2b67fbc13dfc4ae2d84e8f9945aa03163
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/3448
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
(cherry picked from commit 4fc7b6c994)
BUG=chrome-os-partner:21969
TEST=None
Change-Id: I203f4adbdb74a9274014531037bda7d073e155f6
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/168092
During device initialization, skip any non-endpoint descriptor before
reading the endpoint descriptors. By now, only HID descriptors were
skipped.
Original-Change-Id: I190f3ae44b864aa71d5f32c3738097cf8f33a61b
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/3446
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
(cherry picked from commit 735f55c29c)
BUG=chrome-os-partner:21969
TEST=None
Change-Id: I74dac90d7acc858bd82dd410a93396f3bf873eea
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/168091
The compiler gets mad when the types are equivalent size but not necessarily
interchangeable because of strict aliasing checks. Since uint32_t is likely to
be used when trying to read 32 bit data, it makes sense for them to be the
compatible.
This change was originally written for ARM but applies to x86 as well.
BUG=None
TEST=Built and booted on link.
BRANCH=None
Change-Id: I91b5e39f40e516405b9802032c87d3b15ed52c23
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/169121
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
This is needed to make LTO happy with assembler functions.
BRANCH=none
TEST=boot tested on pit
BUG=none
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: I4dbfe193d470c795cfef2272f45a78fe156c4912
Reviewed-on: https://chromium-review.googlesource.com/168963
It turns out that my previous commit to make the EHCI stack cache aware
on ARM devices wasn't quite correct, and the problem is actually much
trickier than I thought. After having some fun with more weird transfer
problems that appear/disappear based on stack alignment, this is my
current worst-case threat model that any cache managing implementation
would need to handle correctly:
Some upper layer calls ehci_bulk() with a transfer buffer on its stack.
Due to stack alignment, it happens to start just at the top of a cache
line, so up to 64 - 4 bytes of ehci_bulk's stack will share that line.
ehci_bulk() calls dcache_clean() and initializes the USB transfer.
Between that point and the call to dcache_invalidate() at the end of
ehci_bulk(), any access to the stack variables in that cache line (even
a speculative prefetch) will refetch the line into the cache. Afterwards
any other access to a random memory location that just happens to get
aliased to the same cache line may evict it again, causing the processor
to write out stale data to the transfer buffer and possibly overwrite
data that has already been received over USB.
In short, any dcache_clean/dcache_invalidate-based implementation that
preserves correctness while allowing any arbitrary (non cache-aligned)
memory location as a transfer buffer is presumed to be impossible.
Instead, this patch causes all transfer data to be copied to/from a
cache-coherent bounce buffer. It will still transfer directly if the
supplied buffer is already cache-coherent, which can be used by callers
to optimize their transfers (and is true by default on x86).
CQ-DEPEND=CL:169170
BUG=chrome-os-partner:21969
TEST=Make sure Snow still boots from the USB 2.0 port.
Change-Id: I112908410bdbc8ca028d44f2f5d388c529f8057f
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/169231
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
keyboard_init attempts to read the existing mode register, set the
'XLATE' bit, and write it back. The implementation is buggy because the
keyboard may be active at the time we read the mode, and we can
misinterpret scancode data as the reply to our command. It leads to
problems where the KB gets disabled in firmware.
In fact, setting the 'XLATE' bit is completely unnecessary, even if we
desire QEMU keyboard support. We already set this bit when we initialize
the keyboard in pc_keyboard_init. Basically, this code does nothing
(or worse), so just remove it.
BUG=chrome-os-partner:22134
TEST=Manual on Peppy. Spam keyboard going into recovery mode, verify the
keyboard still remains functional. Verify keyboard functions in dev
mode, recovery mode, and verified boot.
BRANCH=FalcoPeppy
Change-Id: Ia3f953d66eaa0c120d2371955a3ad73a2326cc88
Original-Change-Id: Iab23f03fa8bced74842c33a7d263de5f449bb983
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/168515
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
These symbols are not used anywhere in our C code, so
when using GCC's link time optimization feature they
will be dropped even though they're needed by libgcc.
Hence we need to mark them as used so GCC does not stumble
and fall over its own guts.
BUG=none
BRANCH=none
TEST=boot tested on pit.
Change-Id: Ib2e9ea2610b57ab8244d5b699dd56025a4f08a01
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/168773
When using GCC for linking, we should pass CFLAGS to the compiler
BRANCH=none
BUG=none
TEST=boot tested on pit
Change-Id: Ic46a9a38dddd763368635de77f576f7ae5b1b774
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/168962
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
This commented out code is a left over from x86.
BUG=none
BRANCH=none
TEST=none
Change-Id: Ice806000c73d5a068962914d067d4de7b3d75f45
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/168961
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Reviewed-by: David Hendrix <dhendrix@chromium.org>
timer initialization is the first thing happening in
the Exynos CPU's bootblock code. Hence we don't need
to keep track of it in several places, and we don't
need to do it over and over again (e.g. in each stage)
BUG=none
BRANCH=none
TEST=boot tested on pit
Change-Id: I7bd9a0b7930fc9c37faabd62e3eecc3e5614a879
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/168994
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Right now some console specific objects are included
in the bootblock even if CONFIG_BOOTBLOCK_CONSOLE is
disabled while others are not. Make all of them conditional
and also fix a preprocessor misuse in bootblock_simple.c
and a stray (useless) die() in the Exynos wakeup code that
made inclusion of those files necessary.
BRANCH=none
BUG=none
TEST=boot tested on pit
Change-Id: Ia7f9d17654466f199b0e13afbdc9e14c9706530f
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/168772
Reviewed-by: David Hendrix <dhendrix@chromium.org>
The ARM linker scripts work fine with the gold linker.
This also requires to enhance the LINKER_SUFFIX variable
with a platform suffix so that it can be different on
ARMv7 and x86
BUG=none
BRANCH=none
TEST=boot tested on pit
Change-Id: I7d3b57991b1e40d0305be3fc4bc63d322392d98e
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/168771
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add a new function to split transfer requests into chunks of
64KB in order to be as compatible as possible with devices that
choke when sent large transfer requests.
BUG=chrome-os-partner:22297
BRANCH=falco,peppy,wolf,leon
TEST=manual: successfully boot from various USB3 sticks on Falco
Change-Id: Id11990bd149af14af5535de4af47bda21d1ab51e
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/169170
Reviewed-by: Julius Werner <jwerner@chromium.org>
A recent change to support early firmware selection on ARM broke snow and was
incompletely implemented on pit and kirby. This change fixes snow by applying
the remaining part of the change that had been applied to the other two
boards, and also hooks up real values in the get_write_protect_state function.
BUG=None
TEST=Built and booted on snow and pit, built for kirby.
BRANCH=None
Change-Id: Ifef7ad1bf399f79353daec3dd46973f2b2022e37
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/169120
Reviewed-by: David Hendrix <dhendrix@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
When changing the from ROMCC to CC, three spaces got lost.
This fixes the build output. Purely cosmetical
BRANCH=none
TEST=none
BUG=none
Change-Id: I8850b6e0cc72ec07c2baf3cb574b13914517bb6c
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/168960
Reviewed-by: David Hendrix <dhendrix@chromium.org>
Commit-Queue: David Hendrix <dhendrix@chromium.org>
This patch cleans out a lot of unused variables in the
ARM Kconfig files and introduces CONFIG_RAMSTAGE_BASE
which is similar to CONFIG_RAMBASE on x86.
This gets rid of the hard coded assumption that on ARM
coreboot is always executed at the lowest DRAM address.
But in fact, this might not be true because we might want
coreboot to live at the end of RAM, or in SRAM
BUG=none
BRANCH=none
TEST=successfully booted on pit.
Change-Id: I03e992645f9eb730e39a521aa21f702959311f74
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/168645
Reviewed-by: David Hendrix <dhendrix@chromium.org>
Tested-by: David Hendrix <dhendrix@chromium.org>
When using dynamic CBMEM the CBMEM area is initialized before
entering ram stage, and so we need a way smaller temporary buffer
for the CBMEM console during early bits of ram stage. In practice
around 256 bytes are needed, but keep the buffer at 1k so we make
sure we don't run out.
TEST=Boot tested on pit
BRANCH=none
BUG=none
Change-Id: I462810b7bafbcc57f8e5f9b1d1f38cfdf85fa630
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/168575
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
BRANCH=none
TEST=none
BUG=none
Change-Id: I01a11923fc1b250afeed36acc20793fd072421ba
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/168574
Reviewed-by: Gabe Black <gabeblack@chromium.org>
All ARM systems we support have dynamic CBMEM support.
Hence drop non-dynamic CBMEM support from the mainboard
specific code.
BUG=none
BRANCH=none
TEST=boot tested on pit
Change-Id: Icdff8dd8306ca40f86f08dee2a65f03a526b99db
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/168573
Reviewed-by: Gabe Black <gabeblack@chromium.org>
The locality is requested when the TPM is initialized and released when
it's cleaned up. There's no reason to set it to the same thing again and
restore it back to the same value before and after every transaction.
BUG=None
TEST=Built and booted on pit.
BRANCH=None
forward ported from https://chromium-review.googlesource.com/#/c/168400
Change-Id: I291d1f86f220ef0eff6809c6cb00459bf95aa5e0
Signed-off-by: Gabe Black <gabeblack@google.com>
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/168584
Reviewed-by: Gabe Black <gabeblack@chromium.org>
I assume from the code in the TPM driver that the TPM spec defines
different types of delays and timeouts which each have a particular
duration, and that the TPM can tell you how long each type is if you ask
it. There was a large table, some members of a data structure, and a
function or two which managed the timeouts and figured their value for
different operations. The timeout values for the various "ordinals"
were never set in the vendor specific data structure, however, and
always defaulted to 2 minutes. Similarly the timeouts a, b, c, and d
were never overridden from their defaults. This change gets rid of all
the timeout management code and makes the "ordinal" timeout 2 minutes
and the a, b, c, and d timeouts 2 seconds, the larger of the two default
values.
This is a port from depthcharge to coreboot, original change:
https://chromium-review.googlesource.com/#/c/168363/
BUG=None
TEST=Built and booted on kirby
BRANCH=None
Signed-off-by: Gabe Black <gabeblack@google.com>
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: I79696d6329184ca07f6a1be4f6ca85e1655a7aaf
Reviewed-on: https://chromium-review.googlesource.com/168583
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
This patch renames the x86 way of doing things to
explicitly mention CMOS (which is not available on
our ARM platforms) and adds an implementation to
get VBNV through the Chrome EC. We might want to
refine this further in the future to allow VBNV
in the EC even on x86 platforms. Will be fixed when
that appears. Also, not all ARM platforms running
ChromeOS might use the Google EC in the future, in
which case this code will need additional work.
Signed-off-by: Stefan Reinauer <reinauer@google.com>
BRANCH=none
TEST=needs further changes
BUG=none
Change-Id: Ice09d0e277dbb131f9ad763e762e8877007db901
Reviewed-on: https://chromium-review.googlesource.com/167540
Reviewed-by: David Hendrix <dhendrix@chromium.org>
Tested-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
On ARM platforms the TPM is not attached through LPC but through I2C.
This patch adds an I2C TPM driver that supports the following chips:
* Infineon SLB9635
* Infineon SLB9645
In order to select the correct TPM implementation cleanly, CONFIG_TPM
is moved to src/Kconfig and does the correct choice.
BRANCH=none
TEST=compile tested on peach_pit (more work needed to use this)
BUG=none
Change-Id: I2def0e0f86a869d6fcf56fc4ccab0bc935de2bf1
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/167543
Reviewed-by: ron minnich <rminnich@chromium.org>
Pit used GPIO X06, and while that's connected in the schematic on kirby as
well, it's with an unstuffed resistor. The line is actually connected to
GPIO Y00.
BUG=None
TEST=Built and booted on kirby with corresponding kernel device tree changes.
Suspended and resumed using the lid switch on servo and saw that the firmware
resumed instead of rebooting.
BRANCH=None
Change-Id: Iaa7497899cb4514ba94b1e414377799a0ce30e51
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/168521
Reviewed-by: ron minnich <rminnich@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Transfered over from pit.
BUG=None
TEST=None
BRANCH=None
Change-Id: If6ef44951fcf3d2c7253333ef5e4da31614b3032
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/168362
Reviewed-by: ron minnich <rminnich@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
All this samsung_get_base_address_of_device_with_a_really_long_name()
boilerplate makes my eyes bleed... I think there are so much cleaner
ways to do this. Unfortunately changing this ends up touching nearly
every Exynos5 file, but I hope you agree that it's worth it (and the
sooner we get it over with, the better... I can't bring myself to make
another device fit into that ugly scheme).
This also removes the redundant EXYNOS5 base address definitions from
the 5420 directory when there are EXYNOS5420 ones, to avoid complete
confusion. The new scheme tries to use EXYNOS5 for base addresses and
exynos5 for types that are common between the two processors, and
EXYNOS5420/exynos5420 for things that have changes (although I probably
didn't catch all differences).
BUG=None
TEST=Try to write some code that flips a single PMU register bit without
getting super frustrated with all the extra stuff you need to set up.
Change-Id: I87e58434490ed55a9bbe743af1f9bf2520dec13f
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/167579
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: ron minnich <rminnich@chromium.org>
This board was cloned from Falco, and the EC was replaced
by the ITE IT8772F SuperI/O
Signed-off-by: Stefan Reinauer <reinauer@google.com>
BUG=none
BRANCH=none
TEST=none
Change-Id: Ia41af8425ab6c24746253abd025acd3365dd5a18
Reviewed-on: https://chromium-review.googlesource.com/167131
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Tested-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Some drivers (like the I2C TPM driver) call mdelay instead of
udelay. While it's a shame that these chips are so slow, the
overhead of having those functions available in romstage is
minimal.
Signed-off-by: Stefan Reinauer <reinauer@google.com>
BRANCH=none
TEST=compile tested
BUG=none
Change-Id: I1fa888fc5ca4489def16ac92e2f8260ccc26d792
Reviewed-on: https://chromium-review.googlesource.com/167542
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
This is needed by some drivers and use cases (mostly
around ChromeOS functionality on ARM)
Signed-off-by: Stefan Reinauer <reinauer@google.com>
BRANCH=none
TEST=compile tested, no functional change
BUG=none
Change-Id: I38dfdcb4c2e3dde1e94315828a195b077660b4ff
Reviewed-on: https://chromium-review.googlesource.com/167541
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Since we're now supporting ARMv7 relocations, we can enable
rmodule support on Exynos 5420. This does not automatically
enable relocatable ramstage.
Signed-off-by: Stefan Reinauer <reinauer@google.com>
BRANCH=none
TEST=needs more changes
BUG=none
Change-Id: Ic3af1eabb3b816944587a46409224f778d941b8a
Reviewed-on: https://chromium-review.googlesource.com/167403
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Long term we should unify ARM and x86 handling of situations like this.
Signed-off-by: Stefan Reinauer <reinauer@google.com>
BRANCH=none
TEST=needs further changes
BUG=none
Change-Id: Iac598234262264117553c8ce915ddcb7fcc6509e
Reviewed-on: https://chromium-review.googlesource.com/167402
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
This is needed for early vboot selection
Signed-off-by: Stefan Reinauer <reinauer@google.com>
BRANCH=none
TEST=needs further changes
BUG=none
Change-Id: Ibfd36c59e96513b65f5ff5239b4ecc02e807039b
Reviewed-on: https://chromium-review.googlesource.com/167401
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Now that we're enabling 3.5GB...
BUG=chrome-os-partner:22144
BRANCH=none
TEST=loaded depthcharge on kirby
Change-Id: Ic21d0efbf1fe7593737e010e3ad2dc81edc3b276
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/167666
Reviewed-by: ron minnich <rminnich@chromium.org>
The EC recently added events for Thermal and Battery shutdown
to provide some sort of notification to the OS that it is
about to pull power.
BUG=chrome-os-partner:21175
BRANCH=falco
TEST=emerge-falco chromeos-coreboot-falco
Original-Change-Id: Ibbdb5f11b8fa9fc80612a3cc10667c612420b1bb
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/167301
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Duncan Laurie <dlaurie@google.com>
(cherry picked from commit 03a53ed5e58caa018d49df193510d95bdf5bed7b)
Change-Id: I0cdf89a60b541840029db58d49921340e7ab60eb
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/167314
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The ALC283 needs a double function reset to ensure that all settings
are reset and the firmware beep is functional.
BUG=chrome-os-partner:21216
BRANCH=falco
TEST=several reboots in developer mode with successful beep
Original-Change-Id: Id9ddc6f4914957f39c5f9cdfaaac354808929146
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/167291
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Duncan Laurie <dlaurie@google.com>
(cherry picked from commit c59865ac464af308baedcd69aa662f46ff3a04d3)
Change-Id: Ie6f3a8179376bc97a6d22712dd965f5e0e6ec5d6
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/167313
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
There seem to be a significant number of shutdowns during suspend resume
tests related to critical temperatures. It is possible that we are getting
a bad reading from PECI and shutting down prematurely in some cases.
If we get a reading that is above critical then wait for the EC to re-poll
and then re-check the temperature in case it was just a bad reading.
Also add some ACPI debug messages when this happens.
BUG=chrome-os-partner:19980
BRANCH=falco,peppy
TEST=emerge-falco chromeos-coreboot-falco
Original-Change-Id: I0ab7bdcc50d133981c0f36fc696b06d4a1d939a7
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/66937
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit a39d7b11dd7b2af37fc2658542d56b32e3966ed4)
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Change-Id: Ib612266511d90749ec6507f8467c71523ee8fb95
Reviewed-on: https://chromium-review.googlesource.com/66939
Tested-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Duncan Laurie <dlaurie@chromium.org>
We were running this loop 100 times with 5 ms delays. Change it
to run 500 times with 1 ms delays, which gives us the same
overall timeout but lets us bail out a bit sooner -- in practice,
at most, 4 ms sooner but every bit counts. Note, however, that
the tighter timing does reduce opportunities for threading. There
is a non-obvious set of tradeoffs on timeouts.
BUG=None
TEST=build and boot with this test and note we still have graphics
BRANCH=None
Change-Id: I4af671c2a791aa92e446e66ac2fe5710d1e6aa4c
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: https://chromium-review.googlesource.com/167387
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: ron minnich <rminnich@chromium.org>
Tested-by: ron minnich <rminnich@chromium.org>
This cleans up a few minor things (mostly #defines) of the memory code
for exynos5420, pit, and kirby. Specifically:
- CONCONTROL.empty is read-only, so don't try to set it and also
get rid of the unneeded DMC_CONCONTROL_EMPTY_ENABLE #define.
- MEMBASECONFIG* overlaps members of the mem_timings struct and
are mainboard-dependent anyway, so get rid of 'em.
- DMC_MEMCONTROL_TP_DISABLE corresponds to a reserved bit. It may
have been deprecated.
- Same with TIMING* #defines.
- Clarify DDR_MODE_* usage and use mem->mem_type when appropriate.
Signed-off-by: David Hendricks <dhendrix@chromium.org>
BUG=none
BRANCH=none
TEST=built and booted on pit and kirby
Change-Id: Ideb21efcc97b24f7e115e90051c20daef4480f17
Reviewed-on: https://chromium-review.googlesource.com/167500
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: ron minnich <rminnich@chromium.org>
This updates DRAM usage for Kirby so that we can actually
use the available 3.5GB:
- The chips on Kirby have 16 row address lines.
- CONFIG_DRAM_SIZE_MB should be 3584 (4096-512).
- We use 2 DMC channels on Kirby (each with 2GB).
Signed-off-by: David Hendricks <dhendrix@chromium.org>
BUG=chrome-os-partner:22144
BRANCH=none
TEST=built and booted (sorta) on Kirby, mem test succeeds
Change-Id: I86d1a96d0d1a028587f7655f8de5a2e52165e9d2
Reviewed-on: https://chromium-review.googlesource.com/167489
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: ron minnich <rminnich@chromium.org>
membaseconfig0/1 are utterly dependent on the mainboard's particular
DRAM setup. This defines their values in the mem_timings struct for
pit and kirby.
Signed-off-by: David Hendricks <dhendrix@chromium.org>
BUG=none
BRANCH=none
TEST=booted on pit, ran /usr/local/opt/punybench/bin/memcpy_test -b,
tested on kirby in follow-up patch
Change-Id: Ifd782d1229b2418f8ddbf0bcb3f45cc828ac34b0
Reviewed-on: https://chromium-review.googlesource.com/167488
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: ron minnich <rminnich@chromium.org>
This changes the number of chip selects that we configure from 2 to 1.
On current setups with (x16 memory 4Gbit chips) that means that we're
at 2GByte.
Technically we should add a second setting in the ares_ddr3_timings
and select between the two of the based on board strappings. That
would make the CONFIG_RUN_TIME_BANK_NUMBER would work properly. I've
changed the ddr3_mem_ctrl_init() so it should handle that, but I'm not
actually doing the board strapping read right now.
This change means that accesses to 0xA0000000 - 0xFFFFFFFF on 2G
systems will no longer put the system in a messed up state (leading to
a hang). It also prevents some of the weird boot behavior that we've
seen that comes and goes depending on U-Boot alignment. See
<http://crosbug.com/p/20577>.
This patch was ported from: https://gerrit.chromium.org/gerrit/66117
Signed-off-by: David Hendricks <dhendrix@chromium.org>
BUG=none
BRANCH=none
TEST=booted on pit, ran suspend_stress_test --memory_check ran for
100 iterations and reboot seemed fine.
Change-Id: Ib4cfe420aac30bd817438f06d01e8671afc4a27d
Reviewed-on: https://chromium-review.googlesource.com/167210
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: ron minnich <rminnich@chromium.org>
