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>
Add suport for verifying the ramstage with vboot
during romstage execution. Along with this support
select CACHE_RELOCATED_RAMSTAGE_OUTSIDE_CBMEM to
cache the relocated ramstage 1MiB below the
top end of the TSEG region.
BUG=chrome-os-partner:23249
BRANCH=None
TEST=Built and booted with CONFIG_VBOOT_VERIFY_FIRMWARE=y
selected.
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I355f62469bdcca62b0a4468100effab0342dc8fc
Reviewed-on: https://chromium-review.googlesource.com/172712
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
In the case of CONFIG_VBOOT_VERIFY_FIRMWARE not being
selected allow for calling vboot_verify_firmware()
with an empty implementation. This allows for one not to
clutter the source with ifdefs.
BUG=chrome-os-partner:23249
BRANCH=None
TEST=Built with a !CONFIG_VBOOT_VERIFY_FIRMWARE and non-guarded
call to vboot_verify_firmware().
Change-Id: I72af717ede3c5d1db2a1f8e586fefcca82b191d5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/172711
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Bay Trail has the following types of resets it supports:
- Soft reset (INIT# to cpu) - write 0x1 to I/O 0x92
- Soft reset (INIT# to cpu)- write 0x4 to I/0 0xcf9
- Cold reset (S0->S5->S0) - write 0xe to I/0 0xcf9
- Warm reset (PMC_PLTRST# assertion) - write 0x6 to I/O 0xcf9
- Global reset (S0->S5->S0 with TXE reset) - write 0x6 or 0xe to
0xcf9 but with ETR[20] set.
While these are documented this support currently provides support
for 2nd soft reset as well as cold and warm reset.
BUG=chrome-os-partner:23249
BRANCH=None
TEST=Built and booted.
Change-Id: I9746e7c8aed0ffc29e7afa137798e38c5da9c888
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/172710
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
While trying to make the The I2C constants unambiguous, I also made their
names very verbose. This CL reigns them in a bit and also consolidates _SHIFT
and _MASK constants for bit fields which have only one bit. A value with a one
in the right place can be used to test the field or set it to any of its legal
values.
BUG=None
TEST=Built and booted into the bootblock on nyan. Used test code to verify
that the main CPUs still start correctly.
BRANCH=None
Change-Id: Ia9a3da2d36e4f71ad8380c7d6efacb0c471eb522
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/172953
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
This will allow us to run the ROM stage on the main CPU0 instead of the AVP
coprocessor. In addition, this CL also fixes some problems in the clock init
function, and replaces the definition of the PMC register layout structure. I
originally implemented this new version by accident without realizing the
original existed, but since it's a bit more up to date we decided to use it
instead.
The procedure for bringing up the main CPUs happens in four broad phases.
1. Enable the external power for the CPU rail by talking to the PMIC over I2C.
2. Enable the internal power rail for the CPUs.
3. Un-gate power for the CPUs and associated bits and pieces.
4. Enable the CPU clocks and take CPU0 out of reset.
The reset address is stored in an memory location with the magical property
that the CPUs will use whatever address when they reset. No explanation is
given in the documentation why this location behaves that way, what other
values near it might do, etc., so we have to just follow the example of the
kernel and U-Boot and treat it the same way.
Some code still needs to be written which will call into the flow controller
and get it to shut down the AVP so that it isn't sitting there consuming power
while execution has moved on to the main CPU. In the mean time, the current
implementation is sufficient.
BUG=None
TEST=Built and booted into the bootblock on nyan. Wrote a small test function
which sets the stack pointer to an array allocated as a new stack and then
prints a hello world type message. Used that function and some code in earlier
parts of the bootblock to print the uP-Tag at address 0x60000000 from the CPU
and the AVP and verified that they were 0x55555555 and 0xaaaaaaaa, indicating
that the test function actually was running on the main CPU and not on the
AVP.
Change-Id: I9728f43155074ab6948853eb26879656feb6b8c0
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/172917
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
This patch changes the GPIO API once again, this time back to functions.
It introduces a new opaque type gpio_t that holds both the GPIO number
and the corresponding pinmux number and can be constructed with a macro
(e.g. 'gpio_output(GPIO(Q2), 1);' ). This makes the GPIO functions
convenient to use, but also allows passing GPIOs around in variables and
function parameters.
BUG=None
TEST=Made sure GPIOs still twiddle when commanded.
Change-Id: I519c32b872b0c912046a3aaa070ef4e9699856ee
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/172916
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Pull-ups and pull-downs can be active on functional pins. Add configs
for these options so they can be specified on board GPIO maps.
TEST=Manual on bayleybay. Verify that platform boots to payload load.
BUG=chrome-os-partner:22863
Change-Id: I0905dc94e4fcce87fd97be0e87c83aa5f2ae78b9
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/172766
Reviewed-by: <adurbin@chromium.org>
Now that CACHE_RELOCATED_RAMSTAGE_OUTSIDE_CBMEM is
an option the haswell boards need to be kept in line
to maintain their previous behavior. This commit
is separated from the actual implementation for
easier rebasing.
BUG=None
BRANCH=None
TEST=Built for falco.
CQ-DEPEND=CL:172602
Change-Id: Ic8b1c7f37ab4ac7b7d453e924c30f18a528f6eb6
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/172643
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Haswell was the original chipset to store the cache
in another area besides CBMEM. However, it was specific
to the implementation. Instead, provide a generic way
to obtain the location of the ramstage cache. This option
is selected using the CACHE_RELOCATED_RAMSTAGE_OUTSIDE_CBMEM
Kconfig option.
BUG=chrome-os-partner:23249
BRANCH=None
TEST=Built and booted with baytrail support. Also built for
falco successfully.
CQ-DEPEND=CL:172643
CQ-DEPEND=CL:*146397
CQ-DEPEND=CL:*146398
CQ-DEPEND=CL:*146435
CQ-DEPEND=CL:*146445
Change-Id: I70d0940f7a8f73640c92a75fd22588c2c234241b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/172602
Reviewed-by: Stefan Reinauer <reinauer@google.com>
The GPIO wrappers are already pretty nice, but you still end up writing
everything twice since you need to specify the pinmux register:
gpio_output(GPIO_Q2, PINMUX_GPIO_Q2, 1);
Calculating the pinmux index from the GPIO isn't easy, but luckily the
enums use a similar naming scheme. This patch changes the wrapper
functions to macros that generate the corresponding pinmux name
automatically.
BUG=None
TEST=Made sure code with GPIO macros compiles, twiddled some output
GPIOs to confirm that they work.
Change-Id: Id23855c5aec5f87b4201f22bac32503e72f83392
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/172731
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
This patch changes the order of GPIO and pinmux register accesses when
setting GPIOs to make the operations as atomic as possible, and avoid
output-to-output as well as special-function-to-input glitches under
some circumstances. It also sets the TRISTATE pinmux for input GPIOs,
since according to my understanding of the pinmux circuit this is the
right thing to do.
Also changed all uintXX_t types to uXX, since I think we agreed on
preferring that for all new code.
BUG=None
TEST=Twiddled some Servo-connected GPIOs and make sure they work.
Change-Id: I2e0156fbaa85e46e460b4494765a06e19f50d4e4
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/172730
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
This will make the PCIe slots and the onboard network interface
work.
BUG=none
BRANCH=none
TEST=Use onboard network interface
Change-Id: Ia65a5e2443883da75b6fff60748d25189c91aa64
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/172275
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
For graphics we need a chip.h in tegra124. Add it.
Set it in the nyan mainboard as a test.
BUG=None
TEST=build it
BRANCH=None
Change-Id: I1c5ccd5574d2e6b49bb4947035ccd10e99729458
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://chromium-review.googlesource.com/172773
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Ronald Minnich <rminnich@chromium.org>
Tested-by: Ronald Minnich <rminnich@chromium.org>
Add code which initializes the AS3722 PMIC based on the initialization
sequence U-Boot uses. I wasn't able to find documentation which said what each
register in the PMIC does, so the next best solution was to imitate another
implementation which presumably sets things up correctly.
The code is set up significantly differently than the U-Boot code, first
because it uses the i2c driver through it's external interface instead of
poking values into the controller's registers directly. The driver uses the
packet mode of the controller while the U-Boot code does not. Second, it uses
an array of register indices and values, a pattern established with Exynos,
instead of having a sequence of calls to the i2c_write function.
This change is also a practical test of the i2c driver's write capability.
BUG=None
TEST=Built and booted into the bootblock on nyan. Used a multimeter to measure
the voltage on capacitors connected to the CPU's power rail. When booting
U-Boot, the voltage across the capacitors is 1V. When booting coreboot before
this change, that rail stayed off and the rail stayed at 0V. After this change
it went to 1V.
BRANCH=None
Change-Id: Iab1f8d3b735b0737ce93ee3c9c7fdb2a1dcbbf8a
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/172585
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Set up the i2c controllers that are used on nyan.
BUG=None
TEST=Built and booted into the bootblock on nyan.
BRANCH=None
Change-Id: Ibdd5685e3effdd13ca560b8f18db25e9edadc07b
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/172584
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
There's generic clock initialization that needs to be done for any mainboard
using that soc. Other initialization depends on what peripherals are going to
be used and what rate they should run at and should be done in the mainboard
source.
BUG=None
TEST=Built and booted into the mainboard on nyan.
BRANCH=None
Change-Id: Idf79faac523bb99f3c7c29bac6947d2149fc3651
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/172583
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
We need somewhere to put mainboard specific bootblock initialization.
BUG=None
TEST=Built and booted into the bootblock on nyan.
BRANCH=None
Change-Id: Ief409baff5ae67871879291c7ff0533f19ea6e56
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/172582
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
We should seperate out the mainboard specific parts of the bootblock so that
they can be customized as necessary.
BUG=None
TEST=Built and booted into the bootblock on nyan.
BRANCH=None
Change-Id: Ia633a68521725f6e88341608ccdbedc4f1ce8223
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/172581
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
This uses the packet mode of the controller since that allows transfering more
data at a time.
BUG=None
TEST=Used the i2c driver to read registers in the PMIC. I wasn't able to find
documentation which said what values to expect, but the values I got were
consistent, seemed reasonable, and tracked which register I was reading.
BRANCH=None
Change-Id: I8329e5f915123cb55464fc28f7df9f9037b0446d
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/172402
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
I cleaned up the clk_rst struct: no need to have an array for the
source select because each thing is an individual entity.
There is a bit of a trick in here. I'm using macros to index arrays in the
clk_rst struct. Simple reason: if people use the constants we get compile-time
checking for simple errors.
init_pllx is fixed. The vendor table in u-boot was wrong.
BUG=None
TEST=builds. Amazing. Prints. Amazing.
BRANCH=None
Change-Id: I4429b3e5c14c200db6b4dd129eff14261fe1f326
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://chromium-review.googlesource.com/172106
Tested-by: Gabe Black <gabeblack@chromium.org>
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
We had brought this code in from the kernel but found it best to
use mainboard- or chipset specific versions. Firmware should
strive to be as non-generic as possible.
BUG=None
TEST=Builds and this code was not used anywhere
BRANCH=None
Change-Id: Ic1ca746cc52c3f9ea4de6895f2b32946229beada
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://chromium-review.googlesource.com/172625
Tested-by: Ronald Minnich <rminnich@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Ronald Minnich <rminnich@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Fix USB2 and USB3 port configuration for Beltino
BUG=none
BRANCH=none
TEST=Boot system, see front USB ports working.
Change-Id: I7b799e2a2d17a89bde7dd93b4e9149f19ae4e7ac
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/172274
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
