There's a config option which selects between the emmc and spi config files
depending on what the firmware is intended to boot from. These are copied from
the files installed by the tegra-bct-nyan ebuild, except that the spi config
file has been modified so that there's only one copy of the BCT and so that it
only has one configuration. This is to save space in the final image.
BUG=None
TEST=With this and other changes, built an image for nyan and saw that the bct
exactly matched what was installed by the tegra-bct-nyan ebuild.
BRANCH=None
Change-Id: Ibf1b895bb3ed060d394fc6ffcec67b6972bb21e3
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/170923
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
The config file which cbootimage processes to create a BCT could come from
multiple different files, individually selected based on config options,
and/or split up into different files for organizational purposes. This change
adds a special-class which collects those files and concatenates them all
together in a bct.cfg which can be processed more easily by other parts of the
build.
While the BCT files themselves are potentially very board specific, for
instance ones that hold memory timing information, this bit of code which
collects them is not. It has to be in each board file instead of alongside the
CPU, however, to ensure that the special class is set up before another
Makefile tries to use it. If we end up with lots of Tegra based boards which
duplicate this code over and over, we might want to revisit how this works.
BUG=None
TEST=Built for nyan while forcing the bct.cfg rule to be executed. Verified
that the bct.cfg was created successfully. With other changes, used the
bct.cfg in an image.
BRANCH=None
Change-Id: I58e1373434f89e69298990ea4643a19d8afdc309
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/170922
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
The INTERMEDIATE variable was used to hook dd-ing the BL1 into the image for
Exynos SOCs, but we can do that directly without having a special hook.
BUG=None
TEST=Built for pit and snow and verified that the BL1 was still copied into
the image as expected.
BRANCH=None
Change-Id: I434506b52ca4ea1d01e25a785cbfe66dfdea21c4
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/170921
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
This commit always selects COLLECT_TIMESTAMPS and starts
tracking TSC values from the early stages of bootblock.
The initial timestamp value is saved in mm0 and mm1 while
in bootlbock. This approach works because romcc is not configured
to use mmx registers for its compilation.
Additionally, the romstage api with the mainboard was changed to
always pass around a pointer to a romstage_params structure as the
timestamps are saved in there until ram is up.
BUG=chrome-os-partner:22873
BRANCH=None
TEST=Built and booted with added code to print out timestamps at
and of ramstage. Everything looks legit.
Change-Id: Iba8d5fff1654afa6471088c46a357474ba533236
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170950
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Configure all GPIOs as default (function 0), except for SMBus / UART
GPIOs.
BUG=chrome-os-partner:22863
TEST=Manual. Using bayleybay GPIO table, set UART GPIOs to 'function 1',
and verify UART still works after GPIO configuration. Also, verify
legacy GPIO config is functional by toggling test pin.
Change-Id: I429e0b161767af296e7ff69ecbfde2c3a1c2e74a
Reviewed-on: https://chromium-review.googlesource.com/170839
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Shawn Nematbakhsh <shawnn@chromium.org>
Tested-by: Shawn Nematbakhsh <shawnn@chromium.org>
During ramstage, call mainboard_get_gpios to get initial GPIO configuration
from the mainboard code, then initialize GPIOs as requested.
BUG=chrome-os-partner:22863
TEST=Manual. Using bayleybay GPIO table, set UART GPIOs to 'function 1',
and verify UART still works after GPIO configuration. Also, verify
legacy GPIO config is functional by toggling test pin.
Change-Id: Ic58d8ddd15c4dc48a751a83f6d26c7809c1efc42
Reviewed-on: https://chromium-review.googlesource.com/170306
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Shawn Nematbakhsh <shawnn@chromium.org>
Tested-by: Shawn Nematbakhsh <shawnn@chromium.org>
Peppy had some issues with FUI. We decided it was time to create
peppy-specific gma.c and i915io.c files. Using yabel and the i915tool,
we generated a replay attack, then interpolated against the slippy
i915io.c to get something working.
Also, in preparation for moving code out of the mainboard gma.c to
generic driver code, we got rid of some hardcodes in the mainboard
gma.c that have no business being there. The worst were the
computation of gmch_[m,n] and it turns out that we had some
long-standing bugs related to confusion about 'bpp'. I've killed the
word bpp everywhere I could because there are at least 3 things that
correspond to bpp. We now have framebuffer, pipe, and panel bpp. The
names are long because I want to avoid all the mistakes we've all been
making in the last year :-) Sadly, that means a lot of changes not just
peppy-related, but they are simple and in a good cause.
The test pattern generation is driven by a global variable in
mainboard/peppy/gma.c. I've found in the past that it's very useful
to have a function like this available, as one can activate it while
using a jtag debugger: halt at the right place in ramstage, set the
variable to 1, continue. It's not enough code to worry about always
including.
The last hard-codes for M and N registers are gone, and the function
to set from generic intel_dp.c code works. To avoid screen trash on a
dev mode boot, which we liked but nobody else did :-), we now take the
time to put a pleasing background color that sort of doubles as a
power LED.
Rough timing is ramstage start is at 2.2, and dev setup is done at
3.3. These new platforms are depressingly slow to boot. Rom init alone
is taking 1.9 seconds. 13 years ago it was 3 seconds from power on to bash
prompt. These CPUs are at least 10x faster and take much longer to get going.
Future work, once we get this through, is to move more functions to the
intel driver, and combine the mainboard i915io.c into the mainboard gma.c.
That separation only existed because i915io.c was generated by a tool, and it
had lots of ugliness. Most ugliness is gone.
BUG=None
TEST=build and boot on peppy and get a screen, in both dev and normal modes.
BRANCH=None
Change-Id: I6a6295b423a41e263f82cef33eacb92a14163321
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: https://chromium-review.googlesource.com/170013
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Ronald Minnich <rminnich@chromium.org>
Tested-by: Ronald Minnich <rminnich@chromium.org>
Reviewed-by: Furquan Shaikh <furquan.m.shaikh@gmail.com>
BUG=None
TEST=With this and other changes, built for the nyan board.
BRANCH=None
Change-Id: Icdde4cf5e1abb3ae1ad14279ebc129919ba30074
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/170837
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Most things still needs to be filled in, but this will allow us to build
boards which use this SOC.
BUG=None
TEST=With this and other changes, built for the nyan board.
BRANCH=None
Change-Id: Ic790685a78193ccb223f4d9355bd3db57812af39
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/170836
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
The pattrs structure is intended for the supporting coreboot
code to reference instead of going back to the source of
the values (msrs, cpuid, etc). It essentially serves as a global
structure for collecting attributes about the platform/processor.
Additionally, the implementation provides a point during boot to
hoook work before device enumeration/initialization by providing
a init() function to soc_intel_baytrail_ops that is called before
device work in the boot state machine.
BUG=chrome-os-partner:22862
BUG=chrome-os-partner:22863
BRANCH=None
TEST=Built and booted. Noted pattrs output.
Change-Id: I073da8aca29635146fb0d4a2625b2b7564fd8414
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170403
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
When USB3 devices are attached while in suspend, or two USB3 devices
that are both plugged in are switched to the other port while in
suspend the kernel does not seem to notice this -- despite the cold
attach status bit. This results in the devices showing up in the USB
list at the old enumerated device numbers and higher layers continuing
to think they are present but not reseponding.
With the kernel workaround to deal with devices that are logically
disconnected it is possible for firmware to send a warm port reset to
devices that are in this state and then the kernel will see them disappear
and handle it properly.
This same issue exists in the EFI firmware on the Whitetip Mountain 2
reference board so it is not specifically a coreboot bug. If this
behavior is fixed in the kernel then this workaround could be removed
since it is in RW firmware.
BUG=chrome-os-partner:22818
BRANCH=falco,peppy,wolf,leon
TEST=manual:
1) attach two USB3 devices
2) suspend system
3) switch the ports that the USB3 devices are attatched to
4) resume system
5) confirm that the devices are re-enumerated and come up properly
Original-Change-Id: Ifba3ffc94a06dc0b2436d7d7d464d824657362af
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170335
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit 203d200268f4af6445224962190cbc66ad2a83e4)
Change-Id: I54fd2847ee25a60f25c2cefebdc1a3c18455464a
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170579
I have been attempting to work around USB3 issues that appear in the
kernel with hacks in the firmware, but this is resulting in more
headaches in the kernel.
Instead remove all the work that was being done at resume time and undo
the change that was issuing a warm reset to all ports at suspend time.
The bad device behavior will be dealt with at the kernel level to
handle devices that get stuck in polling state after enable/disable
sequence.
BUG=chrome-os-partner:22754
BRANCH=falco,peppy,wolf,leon
TEST=manual:
suspend/resume with several misbehaving devices:
Kingston USB3 Media Reader
Transcend USB3 Media Reader
Various ADATA USB3 drives
Various Kingston USB3 sticks
Original-Change-Id: I0894454af42d2ced456fe0da921d74c9e74902d0
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170107
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit c2abb4d0dad6ed00e1e230d604c4c0a76eb4eef7)
Change-Id: Ib215d9c230f90a1c9f34bf29254bb9feec28c67e
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170578
This resolves WiFi issues after suspend/resume.
It needs related SPI descriptor soft strap change to
enable SLP_WLAN as a GPIO instead of owned by the ME.
BUG=chrome-os-partner:22175
BRANCH=bolt
TEST=manual: suspend/resume and test wifi
Change-Id: I03f4458d1e52a913770d391061baa6cfa41e8558
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170577
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
I just spent half a day (including the time to implement a stack dumper)
to figure out that I am reading from a NULL pointer. A problem this
simple should be more easy to catch. Let's mark the address range below
SRAM as uncached so that the MMU can yell at you right away for being
the bad programmer you are when you access a NULL pointer.
BUG=None
TEST=Manual
Change-Id: I4a3a13f75bf21b25732be2ecb69d47503eff1b53
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170112
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
This file isn't compiled into anything, and probably wouldn't since it has a
lot of baggage from it's U-Boot origins.
BUG=None
TEST=Built for pit.
BRANCH=None
Change-Id: I29d87afd2a283010a653d3d48fdd3a79622e3b99
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/170423
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: David Hendrix <dhendrix@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
The source file reset.c, present in both the exynos5250 and 5420 directories,
is not being built for either SOC. Let's get rid of the clutter.
BUG=None
TEST=Built for snow and pit.
BRANCH=None
Change-Id: Iab4c7982a271d08cbaf3207b6f5431f0ef52697e
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/170402
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: David Hendrix <dhendrix@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
The dunit on baytrail is the dram unit. Provide a means
to access the configuration registers there using the
proper IOSF mechanisms.
BUG=chrome-os-partner:22875
BRANCH=none
TEST=Built and booted. Able to read dram registers.
Change-Id: I4d5c019720a7883fe93f3e1860bcd57ce2ea6542
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170490
Prior to this commit the coreboot resource allocator
was not using proper addresses. That's not surprising there
wasn't any code to initialize the resources properly. This
commit initializes the memory map accoring to the BUNIT
registers.
BUG=chrome-os-partner:22860
BUG=chrome-os-partner:22862
BRANCH=None
TEST=Built and booted. Noted output for resource assignments
is sane.
Change-Id: Ice8d067d8b993736de5c5b273a0f642fa034a024
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170429
The coreboot device modeling for pci devices wants
a pci_operations structure for all devices. This structure
just sets the subsystem vendor and device id. Add a common
one that all the other pci drivers can use for Bay Trail.
BUG=chrome-os-partner:22860
BRANCH=None
TEST=Built and booted while utilizing this new structure.
Change-Id: I39949cbdb83b3acb93fe4034eb4278d45369e321
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170428
The graphics device needs to have its resource contraints
initialized before running the reference code. Right now just
use a 256MiB aperture, 32MiB of stolen memory data, and 2MiB
GTT memory.
BUG=chrome-os-partner:22869
BRANCH=None
TEST=Built and booted. Noted amount of stolen memory matches
configuration as well as BAR size within the graphics
device.
Change-Id: I328bf858f288363187cf705d6340947393b5ff10
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170427
Take advantage of the cache early in bootblock. The
intent is to speed up cbfs walking when trying to locate
romstage.
BUG=chrome-os-partner:22857
BRANCH=None
TEST=Built and booted.
Change-Id: If03210103c9782390230915db3b4a9759d172dce
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170426
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
B2 and B3 steppings are now bumped to version 313.
BUG=chrome-os-partner:22858
BRANCH=None
TEST=Built.
Change-Id: I09ae5110b66c725e959e95fc15bc85ccf371495d
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170425
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
The UART / serial console is put in retention state by kernel during suspend /
resume path, which caused Coreboot not able to print any messages during resume.
Sending values to the padret_uart_opt inside PMU may release UART, but that may
also cause unexpected output when kernel is back. However, it's still very
helpful when we are debugging suspend/resume inside Coreboot.
To get UART message on resume, call wakeup_enable_uart() in boot block or
romstage (before console_init).
BUG=none
TEST=emerge-peach_pit chromeos-coreboot-peach_pit
Change-Id: Ib5759cb402c6e018d9dba14fad8b61f6a1b1a265
Reviewed-on: https://chromium-review.googlesource.com/170440
Tested-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Commit-Queue: Hung-Te Lin <hungte@chromium.org>
These dependencies came indirectly through kconfig.h which was included
automatically with a -include option which was either part of INCLUDES or
specified directly.
A similar change was checked in for ARM upstream.
BUG=None
TEST=Built for falco.
BRANCH=None
Change-Id: I640b8115f6526c546fe5d251ef2c04e0e78e6ac9
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/170122
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
These dependencies came indirectly through kconfig.h which was included
automatically with a -include option which was either part of INCLUDES or
specified directly. With this change, I'm able to build for beaglebone with
make -j 48.
BUG=None
TEST=Built for kirby.
BRANCH=None
Change-Id: Ib2a69c47baaeddec9f73a059a94afc258c2ca79a
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170121
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
This will be needed for Link Time Optimizations
BUG=none
BRANCH=none
TEST=boot tested on Link
Change-Id: I92c3fac2ac0d4ea9e3afa73fefa93a856054a24b
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/56121
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
This patch enhances the armv7 exception handlers in Coreboot and
libpayload to show the correct SP and LR registers from the aborted
context, and also dump a part of the current stack. Since we cannot
access the banked registers of SVC mode from a different exception mode,
it changes Coreboot (and its payloads) to run in System mode instead. As
both modes can execute all privileged instructions, this should not have
any noticeable effect on firmware operation (please correct me if I'm
wrong!).
BUG=None
TEST=Cause a data_abort in Coreboot or depthcharge. Marvel at the
beautifully displayed stack dump that helps you debug the abort.
Change-Id: I0e04f47619e55308f7da4a3a99c9cae6ae35cc30
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170045
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The Bayley Bay reference board is a Bay Trail mobile and/or
desktop reference board.
BUG=chrome-os-partner:22292
BRANCH=None
TEST=Built and booted to romstage.
Change-Id: Ia0a4f94244ce7ac3a960de796170c091e384f976
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/168388
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
The initial Bay Trail code is intended to support
the mobile and desktop version of Bay Trail. This support
can train memory and execute through ramstage. However,
the resource allocation is not curently handled correctly.
The MRC cache parameters are successfully saved and reused
after the initial cold boot.
BUG=chrome-os-partner:22292
BRANCH=None
TEST=Built and booted on a reference board through ramstage.
Change-Id: I238ede326802aad272c6cca39d7ad4f161d813f5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/168387
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Trustzone needs to be initialized/disabled both on boot and on wake, so it
needs to be done before ramstage which doesn't run on wake. cpu.c isn't
compiled into romstage and fixing that causes other problems, so the trustzone
functions were split out.
BUG=chrome-os-partner:22759
TEST=Built and booted on for snow, pit and kirby. Successfully slept and woke
on each.
BRANCH=None
Change-Id: I8fc630237ebec1f02a91600f8baf3d4e9ea66d0e
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/169817
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
The CPU_ADDR_BITS was being unconditionally set.
Don't do that.
BUG=None
BRANCH=None
TEST=Built bayleybay and can now set CPU_ADDR_BITS properly.
Change-Id: Idbc63328fade8f5f05f7f46282139b86e6694989
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/169711
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
The W25Q64DW spi part is programatically equivalent
to the other W25Q64 parts except it operates at 1.8V.
Just add a new entry with the appropriate ID.
BUG=chrome-os-partner:22292
BRANCH=None
TEST=SPI controller can program the part.
Change-Id: I65b0261223a9fefcb07477a43b6a3edb8228dd03
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170011
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
On ARM the SPI flash is not memory mapped. Use the CBFS
interface to map the correct portion.
BRANCH=none
TEST=boot tested on pit
BUG=none
Change-Id: I8ea9aa0119e90a892bf777313fdc389c4739154e
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/169781
Reviewed-by: David Hendrix <dhendrix@chromium.org>
Only have the SPI driver produce output when CONFIG_DEBUG_SPI is
enabled.
BRANCH=none
TEST=booted on Pit, saw SPI messages from spi_claim_bus() go away
BUG=none
Change-Id: Ib911182b9b6a85e1a7b308f03c9b1bdba2fa0bf4
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/170026
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: David Hendrix <dhendrix@chromium.org>
BUG=none
BRANCH=none
TEST=boot tested on pit, but more changes needed
Change-Id: I778ea787b20a7d7d7b202b1b5e7f956d2fde6629
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/169621
On x86 VbExGetTimer() uses rdtsc. However, on all
other platforms, let's just use coreboot's monotonic timers.
BUG=none
BRANCH=none
TEST=more changes needed, but boot tested on pit
Change-Id: I0cd359f298be33776740305b111624147e2c850d
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/169620
That extra struct is not needed, we already defined it earlier on.
Also fix coding style in the file.
BRANCH=none
TEST=boot tested on pit
BUG=none
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: I586d290f2f3ba2f44aca7fdee400b88547465599
Reviewed-on: https://chromium-review.googlesource.com/169780
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
This patch adds support for the DesignWare3 USB 3.0 DRD controller and
PHY to the Exynos5250 and Exynos5420 CPUs. It also adds code to the
Google Snow, Pit and Kirby boards to turn these controllers on where
applicable.
BUG=chrome-os-partner:21969
TEST=Manual
Change-Id: Idcca627363a69f1d65402e1acb9a62b439f077ff
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/169452
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Currently the workaround for indicating a "full" battery kicks
in at 3%, but this turns out to be too high for some devices.
So move the workaround start point to 6% from full, or 94%.
BUG=chrome-os-partner:21959
BRANCH=falco,peppy,wolf,leon
TEST=emerge-falco chromeos-coreboot-falco
Change-Id: Ib4305df3a68e89f3a10a096d0e89d8105ea9037b
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/169549
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Some USB3 devices are not showing up after suspend/resume cycles.
In particular if a device uses a lower power state like U2 it may
take longer to come up and the firmware needs to wait after sending
a warm port reset.
In addition skipping port reset to connected ports in the way into
suspend was causing problems so instead send all ports a reset
before suspend.
BUG=chrome-os-partner:22402
BRANCH=falco,peppy,leon,wolf
TEST=manual:
Suspend/resume with ADATA HE720 HDD (and other devices) both
connected at suspend and connecting while in suspend and ensure
that the devices always show up in the kernel.
Change-Id: Ib7b15dc65792742b4ceb7dcfc4b2c83192eafcc2
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/169548
Reviewed-by: Aaron Durbin <adurbin@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
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>
