Provide a common entry point for bringing up the APs
in parallel. This work is based off of the Haswell one
which can be moved over to this in the future. The APs
are brought up and have the BSP's MTRRs duplicated in
their own MTRRs. Additionally, Microcode is loaded before
enabling caching. However, the current microcode loading
support assumes Intel's mechanism.
The infrastructure provides a notion of a flight plan
for the BSP and APs. This allows for flexibility in the
order of operations for a given architecture/chip without
providing any specific policy. Therefore, the chipset
caller can provide the order that is required.
BUG=chrome-os-partner:22862
BRANCH=None
TEST=Built and booted on rambi with baytrail specific patches.
Change-Id: I0539047a1b24c13ef278695737cdba3b9344c820
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/173703
All USB ports need to be routed through XHCI, so
remove UHCI and EHCI stacks (will also reduce binary size
of depthcharge)
BUG=chrome-os-partner:23396
TEST=Boot into dev mode screen, use keyboard and see that it works.
BRANCH=none
Change-Id: I05c56657f16c459294c0e9ceff339fe7a8e03ca2
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/173579
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
There's some baked in assumptions internal to coreboot
that the BSP's cpu device exists in the device tree. Therefore
provide one in the device tree.
BUG=chrome-os-partner:22862
BRANCH=None
TEST=Compiled and booted with other changes.
Change-Id: I22ba10964760ee8efbc5bbd5d4ce65daf31b3839
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/173702
The CPSR isn't set up in the bootblock like it normally would be since the
bootblock executes on the AVP and not the main CPUs like the remainder of the
firmware.
BUG=None
TEST=Built and booted into depthcharge on nyan.
BRANCH=None
Change-Id: I5b2fa460b6be6b212418de381e92de9b2fad70cb
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/173775
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
cpu.h uses standard int types but doesn't include stdint.h, getting by because
the including files apparently had included stdint.h before including cpu.h.
BUG=None
TEST=Built and booted into depthcharge on nyan.
BRANCH=None
Change-Id: Ibaf2e66c936184464cd31f4bb53abac7765ed473
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/173774
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
The bits in the mask are wrong now that we're using the #defines
with all the bits shifted into place already (before it was just
a number that needed shifting).
BUG=none
BRANCH=none
TEST=built and booted on nyan, which isn't saying much since we
aren't having FIFO issues. Still, this is a pretty obvious fix.
Change-Id: Iddd52be8bf0f801afeb731a06befb5c9612ec8b1
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/173738
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
These are attached to the SD card and the EMMC on nyan.
BUG=None
TEST=Built and booted into depthcharge on nyan. With changes that configure
these controllers there, saw the driver attempt (and fail) to read data from
the device instead of just hanging.
BRANCH=None
Change-Id: Idf82adc9e8708388d2ad77fca00e224af0fe7661
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/173793
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
We need to enable the CHROMEOS option in order to put GPIO information in the
coreboot tables, and that turns on other code which expects to be able to talk
to the ChromeOS EC.
BUG=None
TEST=Built and booted into depthcharge on nyan.
BRANCH=None
Change-Id: Ie2e1276f661e392841899231f3f22e158614bfa1
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/173792
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
This file isn't used yet, but it will be turned on when the CONFIG_CHROMEOS
kconfig option is enabled.
BUG=None
TEST=With this and other changes, built and booted into depthcharge and saw
that it could find GPIO related information in the coreboot tables.
BRANCH=None
Change-Id: I92fa7f3c2602e3946ddeb8e6cdf3a09b7bfcf58a
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/173791
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
The CONFIG_CHROMEOS kconfig option brings some source files into the rom and
ram stages which rely on other functions in other source files. Build those in
preemptively so that CONFIG_CHROMEOS can be turned on cleanly.
BUG=None
TEST=Built and booted into depthcharge on nyan.
BRANCH=None
Change-Id: Ib8bd88ae526be3ad7a9186973d37af67fe3c59ce
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/173790
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
These functions support even more facets of the SPI API which are used by the
EC communication layer.
BUG=None
TEST=Built and booted into depthcharge on nyan.
BRANCH=None
Change-Id: If9ea65388ba8df0e1f6beac014adf625b7be4c01
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/173789
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
BUG=None
TEST=With this and other changes, built and booted into depthcharge on nyan
with the GPIO table configured.
BRANCH=None
Change-Id: I83c6209efbdcf09a095b5366b6759b2ad9a60a2c
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/173788
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
The coreboot tables were moved but this wasn't updated, breaking all payloads.
BUG=None
TEST=Booted with this fix and saw that depthcharge starts again.
BRANCH=None
Change-Id: Id85d24cf936fac3eae82c20f61fe912b7ca8d185
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/173794
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
These are going to be needed for graphics.
BUG=None
TEST=Builds, has no other impact
BRANCH=None
Change-Id: I4583c119cfa355e5fd83e1d52746fd28bf29c31d
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://chromium-review.googlesource.com/173772
Commit-Queue: Ronald Minnich <rminnich@chromium.org>
Tested-by: Ronald Minnich <rminnich@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
This controller is used to communicate with the EC on nyan.
BUG=None
TEST=Built and booted into depthcharge on nyan. With this and other changes,
saw that basic communication with the EC over the SPI bus was possible,
although it didn't work perfectly.
BRANCH=None
Change-Id: I6f487a97b299d4aff4b00e43d8005ded29d8204b
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/173787
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
It's time to start cleaning up the falco graphics code, but it needs
to have its own files, not slippy's.
BUG=None
TEST=Builds
BRANCH=None
Change-Id: I7dbe27eafbf247b5c7806819bf0059d8b10e842c
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://chromium-review.googlesource.com/172501
Tested-by: Ronald Minnich <rminnich@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
This adds delay logic to the SPI driver which will calculate
delays based on the SPI clock speed (currently hard-coded at max
value) and the number of bytes remaining to be transferred.
The delay is used whenever bytes are being transmitted over the
SPI bus itself. Copying between memory and SPI FIFO is assumed
to be fast enough to just busy wait.
TODO: Calculate SPI speed properly.
BUG=none
BRANCH=none
TEST=built and booted on nyan
Change-Id: I8a74e5cacdae83de18fce084cf3b81f911508bd9
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/173648
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
This re-factors the SPI driver to be more pedantic about spotting
errors and reporting them.
BUG=none
BRANCH=none
TEST=tested on nyan
Change-Id: Ice51ff67b15c677826a201f2e35afe9707708b03
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/173681
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
This moves the math involved in splitting apart a large request from
tegra_spi_cbfs_read() to spi_xfer() with the intention of making the
logic more generic for other possible uses.
BUG=none
BRANCH=none
TEST=built and booted on Nyan
Change-Id: Ice05f1cd9ab1699b656f44b9dd8a2e18c03c583b
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/173680
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Display support for tegra and nyan. This gets pretty far and most values are filled in.
The vendor was able to provide a few more settings so we're almost there.
The only GPIO we don't use is not applicable.
Now includes reserved area for graphics, top 32M.
BUG=None
TEST=Builds and boots and gets to jumping to depth charge. The numbers for the display look right. No display.
BRANCH=None
Change-Id: I680d313f0bc4fb86f1954363427712153174d7e3
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://chromium-review.googlesource.com/173622
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Commit-Queue: Ronald Minnich <rminnich@chromium.org>
Tested-by: Ronald Minnich <rminnich@chromium.org>
Forgot an asterisk and everything goes to hell. Sorry about that.
BUG=chrome-os-partner:23396
TEST=Make sure keyboards work in depthcharge.
Change-Id: I6b2503ca3ea0f80d4e4e5d8b8c0e986fec5db2c9
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/173587
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: David James <davidjames@chromium.org>
This addresses comments made in the first round of code reviews
for the DMA driver.
BUG=none
BRANCH=none
TEST=built and booted on nyan
Change-Id: I4254b7ce9d6559b6507c074f2493f15179f8f15d
Reviewed-on: https://chromium-review.googlesource.com/173598
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: David James <davidjames@chromium.org>
This patch does a few things:
- Add send/receive functions that use the FIFO instead of DMA
- Split DMA send/receive functions out
- Do not ignore FIFO overrun/underrun errors
Aside from making the spi_xfer() function less unwieldy, the main
motivation for this is to avoid buffer overruns. It turns out
that the DMA engine will always try to work with 4-byte aligned words,
so if a input buffer is 5 bytes the DMA engine will clobber the 3
bytes beyond the buffer and cause an Rx underrun.
BUG=none
BRANCH=none
TEST=built and booted on Nyan, no more FIFO overrun errors
Change-Id: I696712b44a0a9f41758e89d53d2169de33cfc66f
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/173639
Commit-Queue: David James <davidjames@chromium.org>
BUG=none
BRANCH=none
TEST=used in SPI driver
Change-Id: I2b348660f38fb181c5a4dcf23091c9740af8b042
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/173638
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Tested-by: Ronald Minnich <rminnich@chromium.org>
Commit-Queue: David James <davidjames@chromium.org>
This addresses comments made in the first round of code reviews
for the SPI driver and does a few minor clean-up tasks.
It also adds better error handling in tegra_spi_cbfs_read() for
the first transfer (sending the read command and address).
BUG=none
BRANCH=none
TEST=built and booted on nyan
Change-Id: I8ee85a6e815e4a65a6e3beb4fb51d7660bed2ff8
Reviewed-on: https://chromium-review.googlesource.com/173599
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: David James <davidjames@chromium.org>
Minor style changes to the way GPIO pull-ups are specified in
board-specific GPIO maps. Intent is to allow calls to GPIO_FUNC macro
from such maps.
BUG=chrome-os-partner:22863
TEST=Manual. Build + boot on bayleybay.
Change-Id: I80134b65d22d3ad8a049837dccc0985e321645da
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/173748
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: David James <davidjames@chromium.org>
Still working on getting it all, but this is a start.
BUG=None
TEST=Builds
BRANCH=None
Change-Id: I0e3eedd45bb056644a92c85405fde5f2ac748252
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://chromium-review.googlesource.com/173684
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Tested-by: Ronald Minnich <rminnich@chromium.org>
Commit-Queue: Ronald Minnich <rminnich@chromium.org>
PCIECLOCK-2 is used for LAN, -3 for WIFI and -4 for the NGFF slot.
Hence only disable PCIECLOCK-1 and -5. Also fix coding style for
pcie_port_coalesce.
BRANCH=none
TEST=See WIFI and LAN devices in lspci
BUG=none
Change-Id: I72a2aa8355137aa06e597913e47d5ffb37908a4f
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/173582
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Commit-Queue: David James <davidjames@chromium.org>
The RTL8111 used on Beltino does not come with a preprogrammed
MAC address, so nobody will talk to it on the network. This patch
sets the MAC address from a value set in VPD. To set a VPD address
use the ChromeOS vpd command:
# vpd -s ethernet_mac=C8:D7:19:D8:07:01
BUG=none
BRANCH=none
TEST=boot ChromeOS after setting MAC address and observe ethernet
port is working reliably.
Change-Id: I9561cdd264d9fceaf9b89c9a76644824565f4c09
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/173581
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Commit-Queue: David James <davidjames@chromium.org>
Add all GPIOs from the schematics. This makes the two front USB ports
and the MiniPCIe slot work.
BUG=none
BRANCH=none
TEST=Boot ChromeOS on Beltino, use USB ports in the front
Change-Id: I23c056bdfcd83c23e7358ad1c8732e603d53e4df
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/172931
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Commit-Queue: David James <davidjames@chromium.org>
right now there are still a lot of traces of Chrome EC
code in the beltino board. Remove them and replace them
with the SuperIO code from Stumpy.
BUG=none
BRANCH=none
TEST=boot on Beltino
Change-Id: I2e4f342c5c88b3a0a3abd003a8033d1e100a1397
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/172930
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Commit-Queue: David James <davidjames@chromium.org>
These are all the video settings we think we will need.
BUG=None
TEST=Builds, hard to imagine it won't boot.
BRANCH=None
Change-Id: I05000ca707aee5ec2236865ed4130a6641334b91
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://chromium-review.googlesource.com/173600
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Tested-by: Ronald Minnich <rminnich@chromium.org>
While nyan's serial hardware is essentially the same as the 8250, it's
registers are spaced 4 bytes apart.
CQ-DEPEND=CL:173492
BUG=None
TEST=With a corresponding change in depthcharge which adds an alternative
serial driver, got console output from depthcharge.
BRANCH=None
Change-Id: I43c040c175d08cfb1bde8002a89254dce9e36b7b
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/173545
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Tested-by: Ronald Minnich <rminnich@chromium.org>
Commit-Queue: Ronald Minnich <rminnich@chromium.org>
This range needs to be adjusted because there isn't any space reserved for the
framebuffer yet on nyan.
BUG=None
TEST=With this and other changes, got console output from depthcharge.
BRANCH=None
Change-Id: I41e85713ba28200e3b38e0efaea58a0de02b7aad
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/173544
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Tested-by: Ronald Minnich <rminnich@chromium.org>
Commit-Queue: Ronald Minnich <rminnich@chromium.org>
With this memory resource, the payload loading code can allocate a bounce
buffer and load the payload successfully. Depthcharge still doesn't start, but
that's probably because it's not finding the coreboot tables for some reason.
BUG=None
TEST=Built and booted to the payload on nyan.
BRANCH=None
Change-Id: I12f1d3d14c40776698077aab383dfd4b22054441
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/173543
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Tested-by: Ronald Minnich <rminnich@chromium.org>
Commit-Queue: Ronald Minnich <rminnich@chromium.org>
BUG=None
TEST=Built and booted into ramstage on nyan. After this change, ramstage gets
past setting up cbmem and fails when trying to load a payload.
BRANCH=None
Change-Id: I65403ecb65c7e1a45d61b1ead9460a73d85f750a
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/173542
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Tested-by: Ronald Minnich <rminnich@chromium.org>
Commit-Queue: Ronald Minnich <rminnich@chromium.org>
When starting the main CPUs, their register state hasn't been initialized in
any way. This is different from how the ROM stage typically starts since it
usually follows the bootblock on the same CPU, and is usually entered with a
branch, link and exchange instruction generated as part of the stage_exit
function. If we were to jump directly into code on the newly enabled CPUs,
especially thumb code, things will go badly.
To fix that, this change adds a small assembly stub which sets the stack
pointer to be the start of the stack used in the bootblock, zeroes out the
link register, and then uses a branch and exchange instruction, bx, to jump to
the actual first instruction.
The stub is compiled using the compiler flags of the bootblock, but that's ok
for two reasons. First, since it's already in assembly, the compiler doesn't
have much choice as far as what to emit. Second, all of the instructions used
are available on both an ARMv4 and ARMv7 CPU and so will assemble correctly
for the AVP and run correctly on the main CPUs.
BUG=None
TEST=Built and booted into the ROM stage and then RAM stage on nyan.
BRANCH=None
Change-Id: Idac59d76d44d2dd00f142382de2068f4d3e4aec8
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/173541
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Tested-by: Ronald Minnich <rminnich@chromium.org>
Commit-Queue: Ronald Minnich <rminnich@chromium.org>
If these aren't set, the rom and ram stages will attempt to load at address
zero which doesn't work.
BUG=None
TEST=Built and booted into the bootblock on nyan. Verified that the rom and
ram stages had valid starting addresses.
BRANCH=None
Change-Id: I0b9b37d6363e6b208248d8a1af6ebee4db602486
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/173540
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Tested-by: Ronald Minnich <rminnich@chromium.org>
Commit-Queue: Ronald Minnich <rminnich@chromium.org>
This adds a basic SPI driver for reading SPI flash content. It uses
the DMA engine, albeit in a sub-optimal manner for now with the
intention of future optimizations to shave a few dozen milliseconds
off boot time.
BUG=none
BRANCH=none
TEST=read SPI flash on Nyan
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: Ic68348add093f014a6b3f08ace5719de035629be
Reviewed-on: https://chromium-review.googlesource.com/172952
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Commit-Queue: Ronald Minnich <rminnich@chromium.org>
Tested-by: Ronald Minnich <rminnich@chromium.org>
This adds basic DMA support. The actual code in this patch does very
little since DMA transfers are pretty well intertwined with the
module's usage. Perhaps in the future we'll add some helper functions
so module code doesn't modify the DMA registers directly...
BUG=none
BRANCH=none
TEST=Successfully used DMA to transmit data over SPI
Change-Id: I3a76ec8350a71e24aac920beaf52b499fef271ec
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/172951
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Commit-Queue: Ronald Minnich <rminnich@chromium.org>
Tested-by: Ronald Minnich <rminnich@chromium.org>
The clock constants were not consistently named and not consistently
commented. There were also structures which didn't really fit the registers
they were overlaid on, or don't really go together. This change straightens
out these problems, and also consolidate writes to the reset and enable
registers.
BUG=None
TEST=Built and booted into the bootblock on nyan. Verified that we can still
start up the main CPU and run code on it.
BRANCH=None
Change-Id: I21961caebc0c556da9a939649093e23246dc98fe
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/172954
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
This updates the APB addresses for the SPI controller and gets rid of
the obsolete SLINK nomenclature.
BUG=none
BRANCH=none
TEST=tested in upcoming Tegra124 SPI driver patches
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I6e7507518eb0531af8bf7865d6e31a8c22283c3d
Reviewed-on: https://chromium-review.googlesource.com/173322
Tested-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
The currently used Bay Trail devices comply with eMMC 4.51
specification and as such require the appropriate GPIOs to be
configured for func3.
Note that the CMD line termination requires 2K, otherwise when driven
by the eMMC device the front slope of the pulse in unacceptably
gentle.
BUG=chrome-os-partner:22580
TEST=manual
. with u-boot SDHCI driver implemented, the eMMC device on the
Bayley Bay CRB can be initialized and mounted
Change-Id: Ib53b6e42d8558c9ca2dff4b6bbf3bcf6fd22e136
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/173241
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
The ram_id[2:0] signals have stuffing options for pull up/down
with values of 10K. However, the default pulldown values for these
pads are 20K. Therefore, one can't read a high value because of
the high voltage threshold is 0.65 * Vref. Therefore the high
signals are marginal at best.
Fix this issue by disabling the internal pull for the pads connected
to ram_id[2:0].
BUG=chrome-os-partner:23350
BRANCH=None
TEST=Built and checked that ram_id[2:0] is properly read now.
Change-Id: Ib414d5798b472574337d1b71b87a4cf92f40c762
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/173211
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-by: Bernie Thompson <bhthompson@chromium.org>
The original documentation was incorrect. Fix the pci
device for the MMC port to reflect reality.
MMC is at 00:17.0 with a device id of 0x0f50.
BUG=None
BRANCH=None
TEST=Built.
Change-Id: Ic18665b7dda5f386e72d1a5255e4e57d5b631eb0
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/172772
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Despite some references to a fixed bclk in some of the
docs the bclk is variable per sku. Therefore, perform
the calculation according to the BSEL_CR_OVERCLOCK_CONTROL
msr which provides the bclk for the cpu cores in Bay Trail.
BUG=chrome-os-partner:23166
BRANCH=None
TEST=Built and booted B3. correctly says: clocks_per_usec: 2133
Change-Id: I55da45d42e7672fdb3b821c8aed7340a6f73dd08
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/172771
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
After running the MRC blob print out some information
on the training: MRC version, number channels, DDR3
type, and DRAM frequency.
Example output:
MRC v0.90
2 channels of DDR3 @ 1066MHz
Apparently there are two dunit IOSF ports -- 1 for each
channel. However, certain registers really on live in
channel 0. Thus, there was some changes to dunit support
in the iosf area.
BUG=chrome-os-partner:22875
BRANCH=None
TEST=Built and booted bayleybay in different configs.
Change-Id: Ib306432b55f9222b4eb3d14b2467bc0e7617e24f
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/172770
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
If a payload is compiled to use SSE instructions it will
fault with an undefined opcode because SSE instructions weren't
enabled. Therefore enable SSE instructions at runtime.
BUG=chrome-os-partner:22991
BRANCH=None
TEST=Built and booted with SSE enabled payload. No exceptions seen.
Change-Id: I919c1ad319c6ce8befec5b4b1fd8c6343d51ccc1
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/172642
Reviewed-by: Stefan Reinauer <reinauer@google.com>
These configs were previously living in the private
repo. There's no reason to live in there. Therefore,
bring in those configs to simplify config changes in
a single CL. Lastly, select CONFIG_VBOOT_VERIFY_FIRMWARE=y
for both bayleybay and rambi.
If wanting to bypass talking to a TPM build with
MOCK_TPM=1.
BUG=chrome-os-partner:23249
BRANCH=None
TEST=Built and booted on bayley bay.
CQ-DEPEND=CL:*146399
CQ-DEPEND=CL:*146436
Change-Id: Ic8bac07ec05541edf0c7b3f8f140cd7daae99a68
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/172713
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
