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>
The "bufferable" bit was erroneously set for the writethrough policy
making it the same as writeback.
(credit to jwerner for pointing this out)
Signed-off-by: David Hendricks <dhendrix@chromium.org>
BUG=none
BRANCH=none
TEST=compiled only, writethrough isn't actually used at the moment.
Change-Id: I567d57f0e522cb4b82988894ba9b4638642bf8db
Reviewed-on: https://chromium-review.googlesource.com/167323
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Tested-by: ron minnich <rminnich@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
This patch makes the EHCI driver work on ARM platforms which usually do
not support automatic cache snooping. It uses the new DMA memory
mechanism (which needs to be correctly set up in the Coreboot mainboard
code) to allocate all EHCI-internal communication structures in
cache-coherent memory, and cleans/invalidates the externally supplied
transfer buffers in Bulk and Control functions with explicit calls as
necessary.
BUG=chrome-os-partner:21969
TEST=Make sure booting from the EHCI port now works without any
additional tweaks.
Change-Id: Ie8a62545d905b7a4fdd2a56b9405774be69779e5
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/167339
This minor refactoring patch changes the signature of all limited cache
invalidation functions in Coreboot and libpayload from unsigned long to
void * for the address argument, since that's really what you have in
95% of the cases and I think it's ugly to have casting boilerplate all
over the place.
CQ-DEPEND=CL:167358
BUG=chrome-os-partner:21969
TEST=Make sure all payloads still compile cleanly when this and
dependent changes are in.
Change-Id: Ic9d3b2ea70b6aa8aea6647adae43ee2183b4e065
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/167338
This patch adds a mechanism to set aside a region of cache-coherent
(i.e. usually uncached) virtual memory, which can be used to communicate
with DMA devices without automatic cache snooping (common on ARM)
without the need of explicit flush/invalidation instructions in the
driver code.
This works by setting aside said region in the (board-specific) page
table setup, as exemplary done in this patch for the Snow, Pit and Kirby
boards. It uses a new mechanism for adding board-specific Coreboot table
entries to describe this region in an entry with the LB_DMA tag.
Libpayload's memory allocator is enhanced to be able to operate on
distinct types/regions of memory. It provides dma_malloc() and
dma_memalign() functions for use in drivers, which by default just
operate on the same heap as their traditional counterparts. However, if
the Coreboot table parsing code finds a CB_DMA section, further requests
through the dma_xxx() functions will return memory from the region
described therein instead.
BUG=chrome-os-partner:21969
TEST=Manual
Change-Id: Ia9c249249e936bbc3eb76e7b4822af2230ffb186
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/167155
There are three Coreboot table tags that all define some kind of memory
region, and each has their own homologous struct. I'm about to add a
fourth so I'll just clean this up and turn it into a generic struct
lb_range instead.
BUG=chrome-os-partner:21969
TEST=None
Change-Id: Id148b2737d442e0636d2c05e74efa1fdf844a0d3
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/167154
Fine tuning DDR timings value for better stability
* Changed Data Driver Strength from 34 ohms to 30 ohms, expected to
enhance signal integrity.
* Changed DQ signal from 0xf to 0x1f000f, to keep default value safe.
* Changed mrs[2] and added new mrs direct command for setting WL/RL
without resetting DLL.
* Added explicit reset value write in phy_con0 instead of just setting
a bit, to ensure that reset happens.
* Added DREX automatic control for ctrl_pd in none read memory state.
This is ported from: https://gerrit.chromium.org/gerrit/61405
Signed-off-by: David Hendricks <dhendrix@chromium.org>
BUG=none
BRANCH=none
TEST=booted on pit, suspend_stress_test --memory_check -c10 passed
Change-Id: I59e96e6dede7b49c6572548aca664d82ad110bb1
Reviewed-on: https://chromium-review.googlesource.com/66995
Reviewed-by: ron minnich <rminnich@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Fine tuning DDR timings value for better stability
* Changed Data Driver Strength from 34 ohms to 30 ohms, expected to
enhance signal integrity.
* Changed DQ signal from 0xf to 0x1f000f, to keep default value safe.
* Changed mrs[2] and added new mrs direct command for setting WL/RL
without resetting DLL.
* Added explicit reset value write in phy_con0 instead of just setting
a bit, to ensure that reset happens.
* Added DREX automatic control for ctrl_pd in none read memory state.
This is ported from: https://gerrit.chromium.org/gerrit/61405
Signed-off-by: David Hendricks <dhendrix@chromium.org>
BUG=none
BRANCH=none
TEST=booted on pit, suspend_stress_test --memory_check -c10 passed
Change-Id: I59e96e6dede7b49c6572548aca664d82ad110bb1
Reviewed-on: https://chromium-review.googlesource.com/66995
Reviewed-by: ron minnich <rminnich@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Select internal PWM controls (for now) and max brightness.
The code is there for power on timings, but commented out.
If it is ever needed it's going to save some time for future
coders to have it where it is.
BUG=None
TEST=Build, boot, see display.
BRANCH=None
Change-Id: I1e5506df57dacb19e946f7edc8b702013bb14044
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: https://chromium-review.googlesource.com/167104
Reviewed-by: ron minnich <rminnich@chromium.org>
Tested-by: ron minnich <rminnich@chromium.org>
Commit-Queue: ron minnich <rminnich@chromium.org>
For many boards, the EDID is known and is set in the ramstage. Reading
the EDID is slow and if we have it we do not want to reread it.
If the raw_edid struct member is non-null, skip reading the EDID.
BUG=None
TEST=Build and boot and verify that the panel works
BRANCH=None
Change-Id: I63fb11aa90b2f739a351cdc3209faac2713ea451
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: https://chromium-review.googlesource.com/167116
Reviewed-by: Gabe Black <gabeblack@google.com>
Tested-by: ron minnich <rminnich@chromium.org>
Commit-Queue: Ronald Minnich <rminnich@google.com>
The address is 8 on kirby.
BUG=None
TEST=Boot and notice that the parade setup now works
BRANCH=None
Change-Id: Ifb10912aab6437714ef9c7ee8f1958fb68019e70
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: https://chromium-review.googlesource.com/167115
Reviewed-by: Gabe Black <gabeblack@google.com>
Tested-by: ron minnich <rminnich@chromium.org>
Commit-Queue: Ronald Minnich <rminnich@google.com>
Tested-by: Ronald Minnich <rminnich@google.com>
This disables the internal pull resistors for SLIM_PD_BUF
and SLIM_CABLE_DET_BUF as per frh's advice.
Signed-off-by: David Hendricks <dhendrix@chromium.org>
BUG=none
BRANCH=none
TEST=Display works on Kirby without rework
Change-Id: I8b5fa56a7a0004ed1df5a115913d454e1d66750d
Reviewed-on: https://chromium-review.googlesource.com/167179
Reviewed-by: Ronald Minnich <rminnich@google.com>
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
This patch flushes the caches and disables the MMU before resuming.
c32b9b3 ("Set up caching in the bootblock.") had a bug where the
dcache and MMU remained enabled in the resume path. This caused
the machine to hang on resume. However, other bugs were preventing
us from testing this properly earlier on so it went unnoticed until
now.
Signed-off-by: David Hendricks <dhendrix@chromium.org>
BUG=none
BRANCH=none
TEST=Built and booted on pit, powerd_dbus_suspend works again,
"suspend_stress_test --memory_check" ran 10 times without problems.
Change-Id: Ib1774f09d286a4d659da9fc2dad1d7a6fc1ebe5e
Reviewed-on: https://chromium-review.googlesource.com/67007
Reviewed-by: ron minnich <rminnich@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
This patch intends to remove all code which enables hardware read
leveling. We need to disable h/w read leveling because new ASV table
is merged in kernel (which is based on the new characterization
condition) and new characterization environment has h/w read leveling
disabled, so we should also disable this. Also, disabling h/w read
leveling improves the MIF LVcc value (LVcc value is the value at which
DDR will fail to work properly), improve LVcc means we have enough
voltage margin for MIF. When h/w leveling is enabled, we have almost
zero volatge margin.
This was ported from: https://gerrit.chromium.org/gerrit/66070
Signed-off-by: David Hendricks <dhendrix@chromium.org>
BUG=none
BRANCH=none
TEST=booted on pit, suspend_stress_test --memory_check -c10 passed
Change-Id: Id0a2d77e6214325f226d51ae08464b39424cea83
Reviewed-on: https://chromium-review.googlesource.com/66994
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
CLKOUT for PCIE ports 2-5 and CLKOUT_XDP are not used
and can be disabled.
This change was modled after the change made in Falco:
Falco-Change-Id: I0f996e90f0ae42780de3a0c8dc5db00ec600748b
The only difference per schematic for Peppy was PCIe 1 supports
a NGFF interface. PCIe 0 is connected to WLAN.
BUG=chrome-os-partner:21780
BRANCH=peppy
TEST=manual
Change-Id: Ib4871cb2655316cb260ab33ada6b9d81f271377f
Signed-off-by: Steven Sherk <steven.sherk@se-eng.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/66693
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Shawn Nematbakhsh <shawnn@chromium.org>
Commit-Queue: Shawn Nematbakhsh <shawnn@chromium.org>
This patch moves around some of the existing Exynos5 USB 2.0 PHY code
to make it cleaner in preparation of the 3.0 PHYs. It moves the VBUS
GPIOs (which are completely board-specific) into the mainboard code and
makes sure to only initialize PHYs on the boards that actually need
them. It also removes the USB 3.0 PLL hack that was needed on Snow from
the Pit and Kirby boards (which do not have that PLL anymore).
BUG=chrome-os-partner:21969
TEST=Manual
Change-Id: Ia35f47a765acff60481f0907f7448ec4f78e0937
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/66887
Reviewed-by: Stefan Reinauer <reinauer@google.com>
The recovery mode pin has no external pull up and will float low, turning on
recovery mode even though nobody asked for it. We should enable the internal
pull up so that it doesn't float around.
BUG=None
TEST=Built and booted into depthcharge on kirby. Saw that a manual recovery
mode request was no longer detected. Now we end up in recovery mode because
we have no disk.
BRANCH=None
Change-Id: Ic9c5d7ea4b584e770030cdf5dbb1fa37f0344db8
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/66880
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
The EHCI host controllers in Samsung Exynos SoC seem to be a little more
picky than Intel ones. When they reach the dummy_qh in the periodic
frame list, they try to access the next qTD pointer even though it's
NULL, an run into a HostSystemError. This patch explicitly sets the
Terminate bit on those pointers to mark them invalid.
BUG=chrome-os-partner:18635
TEST=Fix all the other issues with EHCI on ARM, then make sure it works.
Change-Id: I50fa79bbf1c5fab306d7885c01efd66b13e279b8
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/66884
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
For now using the same gma.c and i915io.c files as for slippy
BUG=None
BRANCH=None
TEST=Compiled successfully both with and without MAINBOARD_DO_NATIVE_VGA_INIT set
in config
Change-Id: Ieb09d0152d525aa090eeb86ebfa253d450d22820
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/64373
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
This is required only for haswell since the register configs have changed.
Also, created mainboard specific header file
BUG=None
BRANCH=None
TEST=Built and booted on falco and slippy boards with different panels
Change-Id: I61bf8d7cef1f204735a2f72225c48d6e44a99945
Signed-off-by: Furquan Shaikh <furquan@google.com>
Conflicts:
src/mainboard/google/slippy/gma.c
src/mainboard/google/slippy/i915io.c
Conflicts:
src/mainboard/google/slippy/gma.c
Change-Id: I77f2542ca8228358f59aafd99c0d13168ab47fb5
Reviewed-on: https://gerrit.chromium.org/gerrit/66853
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
