Allow for one to write an individual byte of a 32-bit register
when sending a read/write through the IOSF messaging system.
Add PUNIT registers and fields for early sequencing.
BUG=chrome-os-partner:23085
BRANCH=None
TEST=Built and partially booted with changes that use PUNIT
registers and individual byte en fields.
Change-Id: I929fb5c51d805c55c478cab884e3572254987fc7
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/171710
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Add the coreboot board files for samus
- Based on Bolt
- GPIO setup based on 0.91 schematic
- Support both memory types
- No HDA verb table for this platform
- Some GPIO interrupts are shared and need to be passed to OS
BUG=chrome-os-partner:22996
BRANCH=samus
TEST=emerge-samus chromeos-coreboot-samus
Change-Id: I8dbd7639456c631a0115b03a493d94b5e2361ab5
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/171694
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The mrc_wrapper.h was changed to protect against ABI differences
between the two sets of compilers and flags used. This requires
a prope shim for the console output funciton.
BUG=chrome-os-partner:23048
BRANCH=None
TEST=Built and booted successfully.
Change-Id: I976e692e66dcfc0eacadae6173abfd9b81e31137
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/171580
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Now that the tegra124 bootblock is compiled using ARMv4 code, this hack is no
longer necessary.
BUG=chrome-os-partner:23009
TEST=Built and booted into the bootblock on nyan. Built for link, snow, falco,
and pit.
BRANCH=None
Change-Id: I5b7fe5e45e15f878089542a04bd20d6c607b0f69
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/171403
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
The bootblock for the tegra124 runs on the AVP coprocessor which uses the
ARMv4 architecture. Switch it over to that architecture.
BUG=chrome-os-partner:23009
TEST=Built and booted into the bootblock on nyan. Built for link, snow, pit,
and falco.
BRANCH=None
Change-Id: Ie527bbff938e6148c58727d448f9c2e6862da872
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/171402
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
This is needed for the tegra124's bootblock and includes enough implementation
to support that use. No caching is supported, although there are function
prototypes and stub implementations to satisfy includes and linking.
BUG=chrome-os-partner:23009
TEST=Built and booted into the bootblock on nyan. Built for link, falco, pit
and snow.
BRANCH=None
Change-Id: Ib79dde8c30eda98b3e823cba2ff6115a610bb2e8
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/171401
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
We don't always want to use ARMv7 code when building for ARM, so we should
separate out the ARMv7 code so it can be excluded, and also make it possible
to include code for some other version of the architecture instead, all per
build component for cases where we need more than one architecture version
at a time.
The tegra124 bootblock will ultimately need to be ARMv4, but until we have
some ARMv4 code to switch over to we can leave it set to ARMv7.
BUG=chrome-os-partner:23009
TEST=Built for link, falco, pit, snow, and nyan. Built into the bootblock on
nyan.
Change-Id: Ia982c91057fac9c252397b7c866224f103761cc7
Reviewed-on: https://chromium-review.googlesource.com/171400
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
There are ARM systems which are essentially heterogeneous multicores where
some cores implement a different ARM architecture version than other cores. A
specific example is the tegra124 which boots on an ARMv4 coprocessor while
most code, including most of the firmware, runs on the main ARMv7 core. To
support SOCs like this, the plan is to generalize the ARM architecture so that
all versions are available, and an SOC/CPU can then select what architecture
variant should be used for each component of the firmware; bootblock,
romstage, and ramstage.
BUG=chrome-os-partner:23009
TEST=Built libpayload and coreboot for link, pit and nyan. Booted into the
bootblock on nyan.
BRANCH=None
Change-Id: I22e048c3bc72bd56371e14200942e436c1e312c2
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/171338
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
The driver is very similar to the 8250 driver, except it isn't in two parts,
and it also spaces its registers 4 bytes apart instead of having them directly
adjacent to each other.
Also, eliminate the UART test function in the bootblock. It's no longer needed
since the actual console output serves the same purpose.
Right now the clock divisor is fixed for now, and we'll want to actually
figure out what value to use at some point.
BUG=None
TEST=Built for link, pit, nyan and lumpy. Booted into the bootblock on nyan
and saw serial output on the console.
BRANCH=None
Change-Id: Idd659222901eb76b0ed8cbb986deb5124096f2f6
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/171337
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
The register indexes and bitfield masks were guarded by the UART8250 config
options, but it might be (is) necessary to use them in a driver that is
UART8250 like without actually using the 8250 driver itself. To avoid any name
collision with other drivers, also change the constant prefix from UART_ to
UART8250_.
BUG=None
TEST=Built for link, lumpy, pit, and nyan. With this and other changes, got
bootblock serial output on nyan.
BRANCH=None
Change-Id: Ie606d9e0329132961c3004688176204a829569dc
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/171336
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Make it include stdint.h instead of relying on that file having already been
included by something else.
BUG=None
TEST=Built for link, lumpy, nyan, pit.
BRANCH=None
Change-Id: Ia09abc890a5f6b12318aa4ae0897aa8a0baf3b13
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/171335
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
The hardcoded init in the test function in the bootblock is actually useful
generally because it doesn't belong in the UART driver itself but is necessary
for the UART to work. Until we have real implementations for the pinmux, etc.,
we can use that code to get the UART and console going.
BUG=None
TEST=Built and booted into the bootblock on nyan with and without the test
function enabled. When it was, saw the "!"s on the console.
BRANCH=None
Change-Id: I2efe0b571d8b022eb2a2e5569620558540b28373
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/171334
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
This is a no-op change for easier maintenance.
BUG=none
TEST=manual
. baitrail coreboot still builds and runs
Change-Id: I0c0bd78c6f361e8f81979f19cce148e7f51865ee
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/171002
The code to set the graphics translation table has been in the
mainboards,but should be in the northbridge support code.
Move the function, give it a better name, and enable support for > 4
GiB while we're at it, in the remote possibility that we get some 8
GiB haswell boards.
BUG=None
TEST=build and boot peppy in dev mode and see that graphics still works. Build falco to make sure we did not break that build.
BRANCH=None
Change-Id: I72b4a0a88e53435e00d9b5e945479a51bd205130
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://chromium-review.googlesource.com/171160
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Furquan Shaikh <furquan.m.shaikh@gmail.com>
Commit-Queue: Ronald Minnich <rminnich@chromium.org>
Tested-by: Ronald Minnich <rminnich@chromium.org>
The Exynos family and most ARM products are SoC, not just CPU.
We used to put ARM code in src/cpu to avoid polluting the code base for what was
essentially an experiment at the time. Now that it's past the experimental phase
and we're going to see more SoCs (including intel/baytrail) in coreboot.
BUG=none
TEST=emerge-daisy chromeos-coreboot-snow;
emerge-peach_pit chromeos-coreboot-peach_pit
Change-Id: I5ea1f822664244edf5f77087bc8018d7c535f81c
Reviewed-on: https://chromium-review.googlesource.com/170891
Tested-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Commit-Queue: Hung-Te Lin <hungte@chromium.org>
The compiler was emitting code compatible with armv7-a, but the bootblock was
running on a core which uses armv4t. By coincidence, it was emitting an
instruction which is unavailable on armv4t when checking the value of the
UART's LSR register. Now that the bootblock is compiled with more appropriate
flags, this code can be re-introduced.
BUG=None
TEST=Built into the bootblock on nyan and, with the test function enabled, saw
a stream of "!"s on the console.
BRANCH=None
Change-Id: I7ecada4138b0889b963d1a8b19a4bab8e0bb1add
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/170997
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
The bootblock on the tegra124 runs on the AVP which is uses the armv4t
architecture version.
BUG=None
TEST=With this option set, saw that the compiler no longer emitted
instructions which don't work on the AVP.
BRANCH=None
Change-Id: Ic9c8b34a353e291a02a714d18de0d01f1e3ab4d1
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/170996
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
The tegra124 AVP uses ARMv4 which doesn't support the barrier assembly
instructions. Unfortunately we assume that we can (and should) use those
during the bootblock and things don't build. In place of a more robust long
term solution, we can just chop those out on boards with the tegra124. This
is only supposed to be a short term, stop gap solution.
BUG=None
TEST=Built for pit, nyan. Booted into the bootblock on nyan.
BRANCH=None
Change-Id: Ifd0bfd3f7e30df6b5bcb1222c070922b81136b03
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/171151
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
This function spews characters on the console and, until we have a working
console, is an easy way to see whether the system boots to a particular point.
For some reason waiting for transmitter to be empty hangs, but transmitting
characters still works.
BUG=None
TEST=Enabled the function and saw the UART output.
BRANCH=None
Change-Id: I1622c8a58849f4b8bdcaa67500b81042d7346df4
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/171030
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
This implementation is the same as the general one except that it removes all
the things that don't work on an ARMv4.
BUG=None
TEST=Built for Nyan. With this and other changes, built and booted on Nyan and
verified that it was getting into the bootblock.
BRANCH=None
Change-Id: I1108a79cc656b26f7d48df20aef3016cf5ae3182
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/171019
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Tegra needs to use a custom bootblock implementation because it starts on a
coprocessor which uses ARMv4. It doesn't have the same control registers,
caches, etc., and the regular bootblock gets exceptions and dies.
BUG=None
TEST=Built for pit. With this and other changes, built and booted on nyan and
verified that it got into the bootblock.
BRANCH=None
Change-Id: Id197db2939bc840ad64244d6e2017fc5c89e0cbd
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/171018
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
The ARM Makefile was copied from x86 and then modified, and as a result it
was carrying a lot of baggage. On top of that, the extra complication made it
inflexible, and we need a lot of flexiblity in order to support the fact that
the Tegra124 starts on an ARMv4 coprocessor instead of one of the ARMv7 main
CPUs.
BUG=None
TEST=Built and booted on pit. With this and other changes, built and booted
into the bootblock on nyan.
BRANCH=None
Change-Id: Ia6ddc27619bdb51e152ad0c628ad6f3037c103ce
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/171017
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
The class flags are more specific than the generic CFLAGS flags and should be
after them so that they have a chance to override them. The class specific
flags weren't really used on anything but ARM so this should be a fairly safe
change even in the x86 Makefiles.
BUG=None
TEST=Built for link. Built and booted on nyan.
BRANCH=None
Change-Id: I7a949efbb1d2841f9f0d28433772092d9f95db36
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/171016
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Otherwise the stack ends up down at 0 and has 0 bytes.
BUG=None
TEST=Built for nyan with this and other changes and saw that the stack was set
up properly and that C code could run.
BRANCH=None
Change-Id: I0e3c80a0c5b0180d95819ab44829c2a0b527a54d
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/171015
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
A typo in a recent change broke the snow build.
BUG=None
TEST=Built successfully for snow.
BRANCH=None
Change-Id: I93074e68eb3d21510d974fd8e9c63b3947285afd
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/171014
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
These rules slip into the normal bootblock preperation process and use the
cbootimage utility to wrap it in a BCT.
BUG=None
TEST=Built for nyan and saw that the new rules were run, and that the BCT
which resulted had reasonable looking contents.
BRANCH=None
Change-Id: I8cf2a3fb6e9f1d792d536c533d4813acfb550cea
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/170924
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
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>
