We had lots of casts that caused warnings when compiling on RISCV.
Clean them up.
Change-Id: I46fcb33147ad6bf75e49ebfdfa05990e8c7ae4eb
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/7066
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The offset of the device_nvs in the gnvs struct is expected to be
0x1000. It is actually 0x100 so padding is needed to move device_nvs
to the expected location. ACPI references to device_nvs objects will
be correct with the padding.
This was tested using a Micro Industries customized Baytrail-I board
based on the Intel Bayley Bay CRB. In intel/baytrail/nvs.h, there's
a Google customized structure located at 0x0100-0x0FFF that is
removed from the fsp_baytrail/nvs.h which explains the mismatch here.
Change-Id: I4721a79b53b5b3345ff9b0c053bdd31d2cf9cb61
Signed-off-by: Scott Radcliffe <sradcliffe@microind.com>
Reviewed-on: http://review.coreboot.org/7038
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
ACPI globalnvs.asl expects the gnvs memory area size to be 0x2000.
Padding has been added to device_nvs struct to reserve the full
0x2000 bytes for gnvs usage.
No known issues are caused by having the GNVS area shorter than
what ACPI thinks. Since there's nothing defined in this area,
O/S shouldn't try to access it. Only problem might be if O/S
notices the SSDT is located within the GNVS defined area.
I verified that the next table written to memory (SSDT) is 0x2000
past GNVS start using a custom-designed Baytrail-I motherboard
based on the Intel Bayley Bay CRB.
Change-Id: I9792954c7a3403eba6f37d7e53ea4a9ed3a2e4ac
Signed-off-by: Scott Radcliffe <sradcliffe@microind.com>
Reviewed-on: http://review.coreboot.org/7039
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Zero out the GNVS area so that uninitialized portions are defined.
Tests using Microsoft Windows (XP/7/8) gave a bluescreen bugcheck: A5
(ACPI_BIOS_ERROR) with the first parameter (0x00001000)
(ACPI_BIOS_USING_OS_MEMORY). Some ACPI enumerated devices use the
GNVS area to define whether they're enabled and their MMIO regions.
On my custom baytrail-based board and build, these devices were
disabled but GNVS had uninitialized data indicating the devices
were enabled with improper MMIO regions.
Should investigate further to see where the GNVS device values are
set if enabled and make sure they're set to valid values even when
the devices are disabled via the mainboard/devicetree.cb.
Change-Id: I2b575c65bfaab58ae6206ac6f457c259c27a7d97
Signed-off-by: Scott Radcliffe <sradcliffe@microind.com>
Reviewed-on: http://review.coreboot.org/7040
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Fix the error 'implicit declaration of function
"southcluster_smm_save_gpio_route"', when SMM module is added.
Change-Id: Ia050ab7e2b036541537b645d3fe4dc747cd1dff8
Signed-off-by: Kayalvizhi Dhandapani <kayalvizhid@ami.com>
Reviewed-on: http://review.coreboot.org/7024
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <gaumless@gmail.com>
With SMM enabled the boot stopped while patching up global NVS in DSDT.
The cause is that both CPUs are assigned the same SMBASE address.
So update the "cpu_smm_do_relocation()" function so that each
CPU gets a different SMBASE address
Based on rmodule work that wasn't propagated to the FSP
version: commit 3eb8eb7eba
Change-Id: I77cd27d3a4f207411a689b5be572b4406a03f16b
Signed-off-by: Kayalvizhi Dhandapani <kayalvizhid@ami.com>
Reviewed-on: http://review.coreboot.org/7026
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Tested-by: build bot (Jenkins)
This adds S3 Suspend / Resume support to Intel's Bay Trail FSP
It is based on the "src/soc/intel/baytrail/romstage/romstage.c"
implementation.
Change-Id: If0011068eb7290d1b764c5c4b12c17375fb69008
Signed-off-by: Mohan D'Costa <mohan@ndr.co.jp>
Reviewed-on: http://review.coreboot.org/6937
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins)
libgcc/macros.h contains some useful assembly macros that are common in
Linux kernel code and facilitate things such as unified ARM/THUMB
assembly. This patch moves it to a more general place where it can be
used by other code as well.
Change-Id: If68e8930aaafa706c54cf9a156fac826b31bb193
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182178
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
(cherry picked from commit a780670def94a969829811fa8cf257f12b88f085)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6917
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
This patch adds a new static assertion macro that can be used to check
the offsets in structures that overlay register sets at compile time. It
uses the _Static_assert() declaration from the new ISO C11 standard,
which is supported (even without -std=c11) by GCC after version 4.6.
(There is supposedly also support in clang, although I haven't tried
it... let's deal with compiler issues when/if they turn up.)
I've added it to all structures for our current ARM SoCs for now, and I
think every new register overlay we add going forward should use them
(at least for the last member, but feel free to add more if you think
it's useful).
Change-Id: If32510e7049739ad05618d363a854dc372d64386
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179412
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
(cherry picked from commit cef5fa13c31375a316ca4556c0039b17c8ea7900)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6905
Tested-by: build bot (Jenkins)
Showed up as an error when '--gc-sections' was added as a flag to the
compiler.
Change-Id: I214d3e16a72fca0becc677d7af66097464d64247
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6926
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Add a Kconfig variable so that driver code knows whether
or not to use dual-output reads.
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Old-Change-Id: I31d23bfedd91521d719378ec573e33b381ebd2c5
Reviewed-on: https://chromium-review.googlesource.com/177834
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit de6869a3350041c6823427787971efc9fcf469b8)
tegra124: implement x2 mode for SPI transfers on CBFS media
This implements x2 mode when reading CBFS media over SPI.
In theory this effectively doubles our throughput, though the initial
results were almost negligibly better. Using a logic analyzer we see
a pattern of 12 clocks, ~70ns delay, 4 clocks, ~310ns delay. So if we
want to see further gains here then we'll probably need to tune AHB
arbitration and utilization to eliminate bubbles/stalls when copying
from APB DMA.
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Old-Change-Id: I33d6ae30923fc42b4dc7103d029085985472cf3e
Reviewed-on: https://chromium-review.googlesource.com/177835
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit 29289223362b12e84da5cbb130f285c6b9d314cc)
nyan: turn on dual-output reads for SPI flash
Nyan's SPI chip is capable of dual-output reads, so let's use it.
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Old-Change-Id: I51a97c05aa25442d8ddcc4e3e35a2507d91a64df
Reviewed-on: https://chromium-review.googlesource.com/177836
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit 62de0889a9cfc5686800645d05e21e272e4beb5c)
Squashed three commits to enable dual output spi reads for nyan.
Also fixed the spi_xfer interface that has been updated to use bytes
instead of bits.
Change-Id: I750a177576175b297f61e1b10eac6db15e75aa6e
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6909
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Patch 12b121f3fe introduced an off-by-one error in the offsets of the
PMU register struct, which put both the newly added register and the
PSHOLD that comes after it in the wrong place. This patch corrects the
offsets (5420 had already been correct).
Change-Id: I1d9d31a6a73ee91890824e94fbd247d5feb4f6ae
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179411
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 5fdc74bc18bcb1066a0ce3ba94829af1b175173b)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6892
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This patch adds stub implementations of exception_init() to all archs
so that it can be called from src/lib/hardwaremain.c. It also moves/adds
all other invocations of exception_init() (which needs to be rerun in
every stage) close to console_init(), in the hopes that it will be less
likely overlooked when creating future boards. Also added (an
ineffective) one to the armv4 bootblock implementations for consistency
and in case we want to implement it later.
Change-Id: Iecad10172d25f6c1fc54b0fec8165d7ef60e3414
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/176764
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit 2960623f4a59d841a13793ee906db8d1b1c16c5d)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6884
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
The bootblock and romstage UART consoles were being built in based only on
whether or not the bootblock and romstage consoles were selected, ignoring
whether serial console support was compiled in generally.
Change-Id: I3866519c422a990c44ced66885108eff24894563
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/172580
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit a4f2dd4902a05884693e6e350b6be29276d16981)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6862
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The pins for the UART had been configured manually using hardcoded offsets and
values. Now that we have pinmux functions for that sort of thing, we should
use that instead. This also provides a very simple test for the pinmux code.
Ultimately this code should be wrapped in a function which handles setting up
any of the UARTs which is appropriately parameterized and which would be
called from the bootblock main instead of being in it, but for now this is
sufficient.
Old-Change-Id: I69e36fa5fc9b6f3f5ef7f1be3e9f18cdbfdd7fe9
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/171807
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit d29e655b68143e86199ab1d74f89e125b16b67cc)
tegra124: Call the set_avp_clock_to_clkm function in the bootblock.
We had a hardcoded version of the set_avp_clock_to_clkm function in the
bootblock, and we had to use it until now because the real version uses
udelay, and until now that hadn't been implemented. Also, replace the delay
loop in the hacky_hardcoded_uart_setup_function with a call to the real thing.
Old-Change-Id: I6df9421bcad484e0855c67649683d474d78e4883
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/172045
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 4c6dd4c7cade7d922a258e0371e43972bce77249)
Squashed two tegra124 bootblock related commits.
Change-Id: I0ce6321a04b11b7f1250ef3816fe46732777988d
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6861
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
The TPM driver expects to call i2c_read with zero address length. The i2c
driver wasn't prepared to handle that particularly in the case of reads
because it expected to send an address before switching over to read mode for
the data. This change also fixes up the read and write calls to consistently
be read32 and write32 instead of readl and writel.
Change-Id: I33dee89b83d4cd9d3e1b90e84b40e761bb8d4de4
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/175966
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit cf686269424ea938d6f953d0f76103182eb71297)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6857
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Add rules for building the nvidia-cbootimage utility and add dependencies
to the tegra124 platform.
Change-Id: Ia9f26981bccd217fe79e1b5dd432ee7da868d22a
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6851
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
This just updates a comment which refers to "board_init_f". We use
bootblock main() in coreboot.
Change-Id: I4cb6b3c11f163b67fe48de495d13dce88710efc0
Reviewed-on: https://chromium-review.googlesource.com/172095
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit 65139f29682cedca8dfb58b3dfe67eab64299064)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6791
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Tested-by: build bot (Jenkins)
Install the BL1 and set up the checksum in the Makefile instead of relying on
post processing. Import the exynos checksum script, split it in two and
simplify it significantly. Stop putting the CBFS header in the midst of the
bootblock so that it can be checksummed before CBFS is put together. Stop
saving space for it and leaving an anchor in the bootblock which nobody looks
for.
Change-Id: Icbb5a5914ece60b2827433b6dc29d80db996ea6c
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/179229
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit aa3a416705517c0a6ddfdeb19905ac8cafb33df1)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6834
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The bootblock for the tegra124 runs on the AVP coprocessor which uses the
ARMv4 architecture. Switch it over to that architecture.
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>
(cherry picked from commit c1aa76b7607ee40ff848628971a97eea5393aebe)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6784
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Tested-by: build bot (Jenkins)
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.
Old-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>
(cherry picked from commit 8423a41529da0ff67fb9873be1e2beb30b09ae2d)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
ARM: Split out ARMv7 code and make it possible to have other arch versions.
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.
Old-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>
(cherry picked from commit 799514e6060aa97acdcf081b5c48f965be134483)
Squashed two related patches for splitting ARM support into general
ARM support and ARMv7 specific pieces.
Change-Id: Ic6511507953a2223c87c55f90252c4a4e1dd6010
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6782
Tested-by: build bot (Jenkins)
tegra124: Add a test function which spams exclamation points on the UART.
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.
Old-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>
(cherry picked from commit e0059181958cfe8afec2f3a7ea732e81f5d55e5d)
tegra124: Re-enable waiting for the transmitter to empty in the test function.
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.
Old-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>
(cherry picked from commit 2a0adceb5029c8ee633d17c82dbb11e48d30349d)
tegra124: Seperate out the non-UART specific hardcoded init in the bootblock.
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.
Old-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>
(cherry picked from commit ae7d4d890be1936cc86dc15adeb33f3b46a51ae5)
tegra124: Implement and enable serial console support for tegra124.
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.
Old-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>
(cherry picked from commit 86f5e2875b18901b349283cfbcd4f8cc88b7a019)
Squashed 4 commits related to uart support for tegra124. Modified the
new uart.c to look like the uart.c for exynos5420.
Change-Id: I490cba014a43d58c30c48ca9ddcae2b00095b7a6
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6764
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
The exynos directories had been moved from src/cpu to src/soc, but the name
of the chip_operations structure wasn't updated properly. That meant that the
SOCs never installed their memory resources and the ram stage would fail to
load the payload.
Change-Id: Ib60489b6d3434e3ebd13827a804452f762747f1b
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/172400
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 9100d475ebcc4dae23184583a6cc0162577e70d1)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6781
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
This minor refactoring patch changes the signature of all limited cache
invalidation functions in coreboot and libpayload from unsigned long to
void * for the address argument, since that's really what you have in
95% of the cases and I think it's ugly to have casting boilerplate all
over the place.
Change-Id: Ic9d3b2ea70b6aa8aea6647adae43ee2183b4e065
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/167338
(cherry picked from commit d550bec944736dfa29fcf109e30f17a94af03576)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6623
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This implementation is the same as the general one except that it removes all
the things that don't work on an ARMv4.
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>
(cherry picked from commit d1436288d3b025af27a8d28ba94b589940ead504)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6713
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
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.
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>
(cherry picked from commit c8bb8fe0b20be37465f93c738d80e7e43033670a)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6739
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
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.
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>
(cherry picked from commit 512d942788336c8d52470135b43ee4e6a1c95f6c)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6709
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
This uses the packet mode of the controller since that allows transfering more
data at a time.
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>
(cherry picked from commit 4444cd626a55c8c2486cda6ac9cfece4e53dd0d3)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6703
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The pins on tegra are controlled by three different units, the pinmux, the
pin group controls, and the GPIO banks. Each of these units controls some
aspect of the pins, and they layer together and interact in interesting ways.
By default, the GPIOs are configured to pass through the special purpose IO
that the pinmux is configured to and so can be ignored unless a GPIO is needed.
The pinmux controls which special purpose signal passes through, along with
pull ups, downs, and whether the output is tristated. The pingroup controls
change the parameters of a group of pins which all have to do with a related
function unit.
The enum which holds constants related to the pinmux is relatively involved
and may not be entirely complete or correct due to slightly inconsistent,
incomplete, or missing documentation related to the pinmux. Considerable
effort has been made to make it as accurate as possible. It includes a
constant which is the index into the pinmux control registers for that pin,
what each of the functions supported by that pin are, and which GPIO it
corresponds to. The GPIO constant is named after the GPIO and is the pinmux
register index for the pin for that GPIO. That way, when you need to turn on
a GPIO, you can use that constant along with the pinmux manipulating functions
to enable its tristate and pull up/down mode in addition to setting up the
GPIO controls.
Also, while in general I prefer not to use macros or the preprocessor when
writing C code, in this case the set of constants in the enums was too large
and cumbersome to manage without them. Since they're being used to construct
a table in a straightforward way, hopefully their negative aspects will be
minimized.
In addition to the low level functions in each driver, the GPIO code also
includes some high level functions to set up input or output GPIOs since that
will probably be a very common thing to want to do.
Old-Change-Id: I48efa58d1b5520c0367043cef76b6d3a7a18530d
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/171806
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 5cd9f17fe0196d13c1e10b8cde0f2d3989b5ae1a)
tegra124: Add base address for the pinmux and pingroup registers.
There weren't any constants for the pinmux or pingroup registers in the
address map header.
Old-Change-Id: I52b9042c7506cab0bedd7a734f346cc9fe4ac3fe
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/172081
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 79b61016bfd702b0ea5221658305d8bd359f4f62)
Squashed two related commits.
Change-Id: Ifeb6085128bd53f0ef5f82c930eda66a2b59499b
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6702
Tested-by: build bot (Jenkins)
If these aren't set, the rom and ram stages will attempt to load at address
zero which doesn't work.
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>
(cherry picked from commit 6ac5cea39d423bfcf5bbd53c2cc6228ab89f08b2)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6704
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
A problem with including the tegra124 directory directly in the include path
is that it makes all headers in that directory first level headers available
everywhere including places that have nothing to do with the SOC, even headers
which were only intended for local use by tegra124 code. This change modifies
things a bit to be more like the way the arch headers are chosen. In the
tegra124 directory, there's an include directory which has an soc subdirectory
in it. That include directory is added to the include path, making it possible
to have headers private to the tegra124. When files specific to whatever tegra
is being built for are needed, you can include <soc/foo.h> and get the version
specific to that particular soc.
Also, the soc.h header file was overhauled to use enums instead of defines, to
consistently name things as far as their prefix (the less cryptic TEGRA instead
of NV_PA) and suffixes like "BASE", and to get rid of values which were
specific to U-Boot which we don't need. Since the only thing in the file were
address constants, I also renamed the file addressmap.h. It would be included
as:
<soc/addressmap.h>
which I think is easy to remember, does what you'd think it does from the
name, and won't conflict with other header files just minding their own
business in some other directory.
Change-Id: I6a1be1ba28417b7103ad8584e6ec5024a7ff4e55
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/172080
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 2c554f58f9ee18e151e824f01c03eb3f0e907858)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6659
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The initial commit for tegra124 (396b072) was not updated for the new ARCH settings.
Change-Id: I147bdf289e91031bd0c0a61e6da43e9c1a438f84
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6658
Tested-by: build bot (Jenkins)
Stop polluting first screen of all boards.
Change-Id: I1ab88075722f7f0d63550010e7c645281603c9c3
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/6548
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This change shows the source structure for nvidia Tegra and Tegra124
SOC. The problem we are trying to solve is that there is a large
amount of common code in the form of .c and .h files across many
different Tegra SOCs. The solution is to provide common code in a
single directory, but not to compile in the common code directory;
rather, we compile in a directory for a given SOC. Different SOCs
will sometimes need different bits of code from the common directory.
Tegra common code lives in tegra/, but there is no makefile there: if
a Tegra common file is needed in a SOC, it is referenced via a
Makefile in a specific Tegra SOC.
Another issue is includes. Include files in the common directory might be
accessed by a piece of code in an SOC directory. More problematically,
code in the common directory might require a file in an SOC directory.
We don't want to put the SOC name in an #include path, e.g.
in a C file in tegra/ is very undesirable, since we might be compiling
for a tegra114.
On some systems this is solved by a pre-pass which creates a set of
symbolic links; on others with nested #ifdef in the common code
which include different .h files depending on CPP variables.
In previous years, both LinuxBIOS and coreboot have tried these
solutions and found them inconvenient and error-prone.
We choose to solve it by requiring explicit naming of part of the path
of files that are in the common directory. This requirement, coupled
with two -I directives in the Makefile.inc, allows common and SOC
C code to incorporate both common and SOC .h files.
.c and .h files -- SOC or common -- name include
files in the common directory with the prefix tegra/, e.g.
SOC files will be included from the SOC directory if they have no prefix:
The full patch of clock.h will depend on what SOC is being compiled, which
is desirable.
In this way, a common file can pick up a specific SOC file without
creating symlinks or other such tricky magic.
We show this usage with one file, soc/nvidia/tega124/clock.c. This compiles.
The last question is where to put the prototype for the function
defined in this file -- soc.h?
Change-Id: Iecb635cec70f24a5b3e18caeda09d04a00d29409
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: https://chromium-review.googlesource.com/171569
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 53e3bed868953f3da588ec90661d316a6482e27e)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6621
Tested-by: build bot (Jenkins)
It turns out there's a register in tegra which automatically counts at 1us
increments. It's primarily intended for hardware to use (I think to drive
other timers) but we can read it ourselves since a 1us timer is exactly what
we need to support the monotonic timer API.
Change-Id: I68e947944acec7b460e61f42dbb325643a9739e8
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/172044
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 161a39c53404ea0125221bbd54e54996967d6855)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6620
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
Otherwise the stack ends up down at 0 and has 0 bytes.
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>
(cherry picked from commit 3e69a477474697bcbc40762ec166e8a515d8b0c2)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6619
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
These rules slip into the normal bootblock preperation process and use the
cbootimage utility to wrap it in a BCT.
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>
(cherry picked from commit cf4a9b0712c21b885bb59310671fb87e38abb665)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6618
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
irq_helper.h intentionally gets included into irqroute.asl twice - once
for pic mode and once for apic mode. Since people are used to seeing
guard statements on the .h files, add the guards to irqroute.h and add
a comment to irq_helper.h explaining why they aren't there. Add a
time.
Change-Id: I882cbbff0f73bdb170bd0f1053767893722dc60a
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/6572
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
