This patch changes the ENTRY() macro in asm.h to create a new section
for every assembler function, thus providing dcache_clean/invalidate_all
and friends with the same --gc-sections goodness that our C functions
have. This requires a few minor changes of moving around data (to make
sure it ends up in the right section) and changing some libgcc functions
(which apparently need to have two names?), but nothing serious.
(You may note that some of our assembly functions have data, sometimes
even writable, within the same .text section. This has been this way
before and I'm not looking to change it for now, although it's not
totally clean. Since we don't enforce read-only sections through paging,
it doesn't really hurt.)
BUG=None
TEST=Nyan and Snow still boot. Confirm dcache_invalidate_all is not
output into any binary anymore since no one actually uses it.
Original-Change-Id: I247b29d6173ba516c8dff59126c93b66f7dc4b8d
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/183891
(cherry picked from commit 4a3f2e45e06cc8592d56c3577f41ff879f10e9cc)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: Ieaa4f2ea9d81c5b9e2b36a772ff9610bdf6446f9
Reviewed-on: http://review.coreboot.org/7451
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commment out nonessential timer services and modify the source code to
cleanly build in coeboot environment. Do not remove dead code just
yet, these functions might be necessary later.
Need to rename the soc timer.h to prevent collisions with timer.h in
the top level include directory.
Currently build timer code for ramstage only.
BUG=chrome-os-partner:27784
TEST='emerge-storm coreboot' still succeeds
Original-Change-Id: Ib10133ccb42697840708845a8ea6d75ceeaeb3d5
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/194067
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit 987ce95220953c16216d1e1d70d5a941d05fc9bc)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: Ia9cf175da11c70709354def5e51bf79df4fda2fe
Reviewed-on: http://review.coreboot.org/7269
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
The SBL3 currently seems to be preventing the bootblock from being
loaded into the IMEM. As a temporary measure, map bootblock into DRAM
(as it is available after SBL2 finished running) and specify the
correct stack space.
BUG=chrome-os-partner:27784
TEST=not much testing yet, just verify 'emerge-storm coreboot' still succeeds.
Original-Change-Id: Ibe9d4911ad22ada1bbd01af54a2ef80009df3a28
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/196168
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit 950323d6091c3b795034c24a08b6c176f56f0e0f)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: Ib3ec21f2cb4058b3e3cc82864de89dadf3b6aa84
Reviewed-on: http://review.coreboot.org/7268
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
The sbl blobs could not yet be published, they have been moved to a
private location. Update coreboot to pick up the blobs at the correct
place.
BRANCH=None
CQ-DEPEND=CL:195003
BUG=chrome-os-partner:28059
TEST=manual
$ emerge-storm coreboot succeeds
Original-Change-Id: I8c4163bc978307e41c156ef9f7f2a211d57db7a8
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/194997
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit 1a1848b00acfc2f58990559e824ea9c13c3c239c)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: If597ebbfd348039d578c99cd7a8e3c4bcbf60c10
Reviewed-on: http://review.coreboot.org/7267
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
The divider for the I2C clocks works differently than for other IP blocks and
needs to be set up to reflect that. There's also a large internal divider which
means you have to do extra calculations to determine what the frequency of the
bus itself will be based on the I2C controller clock. The new macro takes the
desired frequency of the bus itself and figures everything else out.
BUG=chrome-os-partner:25467
TEST=Built and booted on nyan rev1 using this function to set up the i2c
busses.
BRANCH=None
Original-Change-Id: Ib62a5659bcc0d0e15de41887514ae8efb8c8129a
Original-Signed-off-by: Gabe Black <gabeblack@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/189014
Original-Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Tested-by: Gabe Black <gabeblack@chromium.org>
Original-Commit-Queue: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 24714399a9a89cf33ad20ee43da87e9b04ba394c)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I9a1eabb16fdb27fb813fe6bc56cdcc593eca166e
Reviewed-on: http://review.coreboot.org/7417
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
There were some missing parenthesis and some extra semicolons which this
change adds and removes, respectively.
BUG=chrome-os-partner:25467
TEST=Built and booted on nyan rev1. Verified that the same frequency calculated
differently results in the same settings. Before operator precedence would
pull apart the frequency calculation and use the pieces in the wrong order.
BRANCH=None
Original-Change-Id: I843d4ae9f7a2ae362926d94b6b77ef31d350a329
Original-Signed-off-by: Gabe Black <gabeblack@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/189013
Original-Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Original-Reviewed-by: Tom Warren <twarren@nvidia.com>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Commit-Queue: Gabe Black <gabeblack@chromium.org>
Original-Tested-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 462e61ad898a4d6a99c1d161d77bde245c5b1f5c)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: Ifce3aac262cf5e2ec0496c5b3ad894bf6f0f9a46
Reviewed-on: http://review.coreboot.org/7416
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
PLLP is configured to 408MHz by hardware on T124. Init PLLP is needed only when
to configure it other than 408MHz.
BUG=none
TEST=build nyan and boot kernel.
Original-Change-Id: I8b1abf510ab886e7fddea8864a6d36f12529880e
Original-Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/188849
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
(cherry picked from commit d32124cb7562cbce1bb929c3e5f238b13a27b752)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I617f77444a8dd97b20763b50066a1298d3b97724
Reviewed-on: http://review.coreboot.org/7415
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
A PLL (Phase-Locked Loop) clock must be locked before it is assigned
as clock source. Otherwise, this clock is unreliable.
Before:
c base(60006080): 48003201, misc(6000608c): 03000000
x base(600060e0): 40009e01, misc(600060e4): 00000000
p base(600060a0): 40002201, misc(600060ac): 00000200
u base(600060c0): 40005001, misc(600060cc): 00000300
d base(600060d0): 48011b0c, misc(600060dc): 40400800
dp base(60006590): 58305a01, misc(60006594): 40000000
After:
c base(60006080): 48003201, misc(6000608c): 03000000
x base(600060e0): 48009e01, misc(600060e4): 00040000
p base(600060a0): 5801980c, misc(600060ac): 00040800
u base(600060c0): 48005001, misc(600060cc): 00400300
d base(600060d0): 48011b0c, misc(600060dc): 40400800
dp base(60006590): 58305a01, misc(60006594): 40000000
BUG=None
TEST=build nyan and boot
Original-Change-Id: I7e5a2eeb5b17f761e0c462ec68a8b221f327fedc
Original-Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/188447
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
(cherry picked from commit 7e8e2854b2b7d1ed20d74891c3d19b6c3dd41c55)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: Ief9efa6937af26fe1a10a7b360fc2f5477416b97
Reviewed-on: http://review.coreboot.org/7414
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Add a missing "~" so that we mask off just OSC_XOFS field and not the
rest of the register.
BUG=chrome-os-partner:26326
TEST=XHCI sometimes works after LP0.
BRANCH=none
Original-Change-Id: I2df2387dbad6920d36aa2ae5e6cd91e9ec42fa08
Original-Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/188897
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
(cherry picked from commit bdbe9ead46fa883618a4acedd1feaf676e2eb29b)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: Ic853e737fc106527eb3bb15c25bf801a36bbff57
Reviewed-on: http://review.coreboot.org/7412
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Fix the PLLU parameters to match the recommended values from the TRM,
and the values used by the kernel and LP0 blob. This includes adding
support for setting an LFCON value. It appears that changing the PLLU
parameters across suspend/resume causes XHCI stability issues after
resume.
BUG=chrome-os-partner:26326
TEST=XHCI works after LP0 suspend/resume on Nyan.
BRANCH=none
Original-Change-Id: Ia4af12fefeebe607803e7f2f03ee4802367b82c3
Original-Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/188752
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-by: Tom Warren <twarren@nvidia.com>
(cherry picked from commit bbc8d92eb462e165c2378bcb3055a3a74b47a19b)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I687d1709befc2f5dec094ee423f2ff824412996e
Reviewed-on: http://review.coreboot.org/7411
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
The PLLX provides the clock for the main cores which can run at different max
frequencies depending on the specific model of Tegra124. This change makes it
possible to select a model which will, in turn, select a frequency for PLLX.
The default is 2GHz which is the lowest maximum frequency.
BUG=chrome-os-partner:25467
TEST=Booted on nyan rev1. Verified that the selected PLLX frequency was 2GHz.
With a change that selects the right model for nyan, verified that the
corresponding frequency was selected.
BRANCH=None
Original-Change-Id: Iee3a615083dee97ad659ff41cbf867af2a0c325d
Original-Signed-off-by: Gabe Black <gabeblack@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/188602
Original-Reviewed-by: Gabe Black <gabeblack@chromium.org>
Original-Commit-Queue: Gabe Black <gabeblack@chromium.org>
Original-Tested-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 1282015048420a518e6c6959ce982be70378211a)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I448a830f3184ad1afeadbd1c2974c7a27b03a923
Reviewed-on: http://review.coreboot.org/7409
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
This patch brings in ipq806x source files from the vendor's u-boot
tree as it was published in the 'cs_banana' release.
The following files are being copied:
arch/arm/cpu/armv7/ipq/clock.c => src/soc/qualcomm/ipq806x/clock.c
arch/arm/cpu/armv7/ipq/gpio.c => src/soc/qualcomm/ipq806x/gpio.c
arch/arm/cpu/armv7/ipq/timer.c => src/soc/qualcomm/ipq806x/timer.c
arch/arm/include/asm/arch-ipq806x/clock.h => src/soc/qualcomm/ipq806x/clock.h
arch/arm/include/asm/arch-ipq806x/gpio.h => src/soc/qualcomm/ipq806x/gpio.h
arch/arm/include/asm/arch-ipq806x/gsbi.h => src/soc/qualcomm/ipq806x/gsbi.h
arch/arm/include/asm/arch-ipq806x/iomap.h => src/soc/qualcomm/ipq806x/iomap.h
arch/arm/include/asm/arch-ipq806x/timer.h src/soc/qualcomm/ipq806x/timer.h
arch/arm/include/asm/arch-ipq806x/uart.h => src/soc/qualcomm/ipq806x/uart.h
board/qcom/ipq806x_cdp/ipq806x_cdp.c => src/mainboard/google/storm/cdp.c
board/qcom/ipq806x_cdp/ipq806x_cdp.h => src/soc/qualcomm/ipq8064/cdp.h
drivers/serial/ipq806x_uart.c => src/console/ipq806x_console.c
Note that local timer.c gets overwritten with the original version. To
prevent a build breakage some shortly to be reverted modifications had
to be made to src/soc/qualcomm/ipq806x/Makefile.inc and
src/soc/qualcomm/ipq806x/cbfs.c.
BRANCH=none
BUG=chrome-os-partner:27784
TEST='emerge-storm coreboot' still succeeds
Original-Change-Id: I3f50bfbec2e18a3b5d2c640cff353a26f88c98c1
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/193722
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit 3c9c2ede7e97e330cad2c2f3e557cc9bcdaecdcc)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: Ia7bc66cecfc16f1dd4a9f3cb9840cbe91878adf4
Reviewed-on: http://review.coreboot.org/7263
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
We want the coreboot build produce an image which can be run on the
target, even if the remaining parts of the bootprom (recovery path,
read-write stages, gbb, etc.) are not available yet.
This is achieved by including the Qualcomm SBLs blob in the bootblock.
CQ-DEPEND=CL:193518
BRANCH=None
BUG=chrome-os-partner:27784
TEST=manual
. run the following commands inside chroot to confirm expected image
layout (no actual code is executed on the target yet):
$ emerge-storm coreboot
$ \od -Ax -t x1 -v /build/storm/firmware/coreboot.rom 2>/dev/null | head -1
000000 d1 dc 4b 84 34 10 d7 73 15 00 00 00 ff ff ff ff
$ \od -Ax -t x1 -v /build/storm/firmware/coreboot.rom | grep 220000
220000 05 00 00 00 03 00 00 00 00 00 00 00 00 00 01 2a
Original-Change-Id: I10e8b81c7bd90e4550a027573ad3a26c38c3808a
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/193540
(cherry picked from commit 64e193974ee448f78e0a5775a440094901590afb)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: Idbdbeb9d229eff94a7a94af5dc4844a295458200
Reviewed-on: http://review.coreboot.org/7262
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Once SECURITY_MODE fuse is burned, JTAG is disabled by default.
To reenable JTAG, besides chip unique id and SecureJtagControl need
to be built into BCT, Jtag enable flag is also needed to be set.
BUG=None
TEST=Burn SECURITY_MODE fuse, build chip specific BCT, coreboot
comes up and jtag hooks up fine.
Original-Change-Id: Ic6b61be2c09b15541400f9766d486a4fcef192a8
Original-Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/186031
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
(cherry picked from commit ff962b81f424c840ef171d4287a65ab79b018a28)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I14b496932dbc0ed184a2212a5b33d740e1f34a4e
Reviewed-on: http://review.coreboot.org/7403
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Repurpose config->pwm to mean the particular PWM device (we use PWM1 on
nyan), and add code to program the PWM device.
BUG=none
TEST=emerge-nyan chromeos-coreboot-nyan, regenerate bootimage, and boot.
See that the backlight comes up in the bootloader, and brightness can be
adjusted via pwm_bl driver in the kernel.
Original-Change-Id: I2db047e5ef23c0e8fb66dd05ad6339d60918d493
Original-Signed-off-by: Andrew Chew <achew@nvidia.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/185772
Original-Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
(cherry picked from commit 0dee98dd0c8510ecd630b5c6cb9ea49724dc8b55)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: Ie53610f3afa30b2d8f484685fb0e8c0b12cd8241
Reviewed-on: http://review.coreboot.org/7402
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Add some defines and structs that describe what the PWM registers look like.
BUG=none
TEST=emerge-nyan chromeos-coreboot-nyan
Original-Change-Id: Ie10589e4cbf5292e543d205ac8a1c6b09a0f76d0
Original-Signed-off-by: Andrew Chew <achew@nvidia.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/185771
Original-Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
(cherry picked from commit fbbd2a5e148c1142aee100dbcde17c865b06b2bd)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: If4dc40c1dcdf1723e05923e2fea42ccc47766699
Reviewed-on: http://review.coreboot.org/7401
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
It seems that someone just stuck the PM3 function for all of the potential
PWM pins. Fix this to be more specific to the particular PWM (of which
there are four).
BUG=none
TEST=emerge-nyan chromeos-coreboot-nyan
Original-Change-Id: Ic61a7321fbe28953b22007a1d0b522c3ca8714ad
Original-Signed-off-by: Andrew Chew <achew@nvidia.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/185739
Original-Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
(cherry picked from commit f19f897fe11a582cc240d98de88c5e2d4dc4e364)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: Ie10173413a5f00e06f5b1803fd93d6cb322cee3d
Reviewed-on: http://review.coreboot.org/7399
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
The Tegra PWM base address was missing, so add it.
BUG=none
TEST=emerge-nyan chromeos-coreboot-nyan
Original-Change-Id: Iebf687c6644290e05ee72794cde697658ab6d7cb
Original-Signed-off-by: Andrew Chew <achew@nvidia.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/185738
Original-Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
(cherry picked from commit b62843f6cfbf870451f658e6df1a3b48256fa4e1)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: Ibb8578a130d5995345592caa610c57c1d7f28573
Reviewed-on: http://review.coreboot.org/7398
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
We'd been putting some data structures like the framebuffer and the cbmem at
the end of memory, but that may not actually be addressable as identity mapped
memory. This change clamps the addresses those structures are placed at so
they stay below 4GB.
BUG=None
TEST=Booted on nyan. Went into recovery mode and verified that there was a
recovery screen. Forced memory size to be 4GB and verified that the recovery
screen still shows up.
BRANCH=None
Original-Change-Id: I9e6b28212c113107d4f480b3dd846dd2349b3a91
Original-Signed-off-by: Gabe Black <gabeblack@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/185571
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Original-Commit-Queue: Gabe Black <gabeblack@chromium.org>
Original-Tested-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 63ea1274a838dc739d302d7551f1db42034c5bd0)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I970c1285270cb648bc67fa114d44c0841eab1615
Reviewed-on: http://review.coreboot.org/7397
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Tested-by: build bot (Jenkins)
This patch changes several cache-related pieces to be cleaner, faster or
more correct. The largest point is removing the old
arm_invalidate_caches() function and surrounding bootblock code to
initialize SCTLR and replace it with an all-assembly function that takes
care of cache and SCTLR initialization to bring the system to a known
state. It runs without stack and before coreboot makes any write
accesses to be as compatible as possible with whatever state the system
was left in by preceeding code. This also finally fixes the dreaded
icache bug that wasted hundreds of milliseconds during boot.
Old-Change-Id: I7bb4995af8184f6383f8e3b1b870b0662bde8bd4
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/183890
(cherry picked from commit 07a35925dc957919bf88dfc90515971a36e81b97)
nyan_big: apply cache-related changes from nyan
This applies the same changes from 07a3592 that were applied to nyan.
Old-Change-Id: Idcbe85436d7a2f65fcd751954012eb5f4bec0b6c
Reviewed-on: https://chromium-review.googlesource.com/184551
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit 4af27f02614da41c611aee2c6d175b1b948428ea)
Squashed the followup patch for nyan_big into the original patch.
Change-Id: Id14aef7846355ea2da496e55da227b635aca409e
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
(cherry picked from commit 4cbf25f8eca3a12bbfec5b015953c0fc2b69c877)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/6993
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Ipq8064 SBLs initialize the hardware to prepare it to run an arbitrary
user provided bootloader. The only bootloader requirements imposed by
the SBLs are that it is concatenated with the SBL chunks in the
bootprm AND it uses MBN encapsulation (mostly to specify the size and
load address).
This patch adds configuration options to specify the location of the
SBL blobs and to require MBN encapsulation of the bootblock.
BRANCH=none
BUG=chrome-os-partner:27784
TEST=manual
- the below demonstrates added encapsulation, no code run attempts
have been made yet:
$ FEATURES=noclean emerge-storm coreboot
$ cd /build/storm/tmp/portage/sys-boot/coreboot-9999/work/coreboot-9999
$ \od -t x4 build/cbfs/fallback/bootblock.bin | head -3
0000000 00000005 00000003 00000000 2a010000
0000020 00000be0 00000be0 2a010be0 00000000
0000040 2a010be0 00000000 e32bf0df e59f0030
Original-Change-Id: Iae30ad08059e2b35c434ac25a410ac2017752957
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/193511
(cherry picked from commit bf16ea915c723ab124d817e3b0d950282e3cf1c1)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I53c71d382ec1d826f530d7afb545f64ec4eaf96b
Reviewed-on: http://review.coreboot.org/7261
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This patch switches every last part of Coreboot on ARM over to Thumb
mode: libpayload, the internal libgcc, and assorted assembly files. In
combination with the respective depthcharge patch, this will switch to
Thumb mode right after the entry point of the bootblock and not switch
back to ARM until the final assembly stub that jumps to the kernel.
The required changes to make this work include some new headers and
Makefile flags to handle assembly files (using the unified syntax and
the same helper macros as Linux), modifying our custom-written libgcc
code for 64-bit division to support Thumb (removing some stale old files
that were never really used for clarity), and flipping the general
CFLAGS to Thumb (some more cleanup there as well while I'm at it).
BUG=None
TEST=Snow and Nyan still boot.
Original-Change-Id: I80c04281e3adbf74f9f477486a96b9fafeb455b3
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/182212
Original-Reviewed-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 5f65c17cbfae165a95354146ae79e06c512c2c5a)
Conflicts:
payloads/libpayload/include/arm/arch/asm.h
src/arch/arm/Makefile.inc
src/arch/arm/armv7/Makefile.inc
*** There is an issue with what to do with ramstage-S-ccopts, and
*** will need to be covered in additional ARM cleanup patches.
Change-Id: I80c04281e3adbf74f9f477486a96b9fafeb455b3
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/6930
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Change-Id: I1cf87b3c73d8bf8846e5870b19b089f85c299567
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/7241
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Bring code inline to be consistent with the rest of coreboot.
See standard - c99std (n1256) 6.3.2.1p4 - to paraphrase,
'expressions that refer to functions get converted to pointers to
those functions'
Change-Id: I63a7bed5efade37dd7076dbfc9c85d420cf6c92b
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/7290
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
- The hotplug register doesn't work in the way we describe. Just leave
it at default.
- The backlight registers will be configured by the OS driver.
BUG=chrome-os-partner:27304
TEST=Manual on Rambi. Boot system in both dev and normal mode, verify
that display comes up. Also verify that display functions after warm
reboot and suspend / resume.
BRANCH=rambi+squawks
Change-Id: I5559c131f41c4a14e64e5cec66e18d3a4a46092c
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193830
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit 3f287cc31e41fabef755c37361e2e65ca413c88c)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/7217
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Provide the option to embed MRC as an ELF file and not just
binary blob. This allows for MRC to be relocated.
BUG=chrome-os-partner:27654
BRANCH=rambi
TEST=Built and booted rambi.
Change-Id: I2e177c155a3074e4e1d450b1a73b7299aebd5286
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/192893
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
(cherry picked from commit 89c97d5e2023b8c5cc780e1b1d532d0a586512f9)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/7214
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Tested-by: build bot (Jenkins)
Moving the cache-as-ram base address to 0xfe000000 will
provide more breathing room in the physical address space.
It will also allow for larger SPI roms in the future.
BUG=chrome-os-partner:27045
BRANCH=baytrail
CQ-DEPEND=CL:*157278
TEST=Built and booted. Suspended and resumes. Vboot works, MRC
settings are being saved as well.
Change-Id: I618c069e504f545e02de5ac54e057566f0b5d6c9
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/190700
Reviewed-by: Bernie Thompson <bhthompson@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
(cherry picked from commit 73c07a319d678f3e9be2fac64599c94f91c9ad9c)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/7212
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Implement vboot_get_sw_write_protect, which returns the FW SPI ROM SW WP
status.
BUG=chrome-os-partner:26777
TEST=Manual on Rambi with all patches in sequence:
`crossystem sw_wpsw_boot` prints 0
`flashrom --wp-enable` + reboot
`crossystem sw_wpsw_boot` prints 1
BRANCH=Rambi
Original-Change-Id: I5da35c1b2d25b8679bf0084af65d08de224387f8
Original-Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/190097
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit 5bba447654417c42952c49542ed047b4867d04d1)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I739cbb8fca5f02462cf78c81f9b364aabfd3fe86
Reviewed-on: http://review.coreboot.org/7211
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The reg_script functionality is only used by specific chipsets so have
it selected instead of defaulting to y for ARCH_X86.
Change-Id: I8fb9466e148eed7896ca8ed80755c77ba1190583
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/7006
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
nyan_big: Add 204MHz BCT for bringup, use 1.2V for VDD_CPU
Reviewed-on: https://chromium-review.googlesource.com/183939
(cherry picked from commit a6df76afb5342b805baca749abb8265e15748dc1)
nyan_big: Add initial 792MHz BCT
Reviewed-on: https://chromium-review.googlesource.com/183975
(cherry picked from commit 61d0122fdce6dc9479666bb0a5bc079c6389f78a)
nyan_big: use RAM_CODE[3:2] for ram code
Reviewed-on: https://chromium-review.googlesource.com/184076
(cherry picked from commit 35e5c5e473f871cdc897473a31586afbececd716)
tegra124: support tri-state Board Id
Reviewed-on: https://chromium-review.googlesource.com/183855
(cherry picked from commit 1a9d1bd73aa2cd0c36203b247976ad0d00a360e4)
nyan*: Fix SPI pinmux configuration
Reviewed-on: https://chromium-review.googlesource.com/184281
(cherry picked from commit ac4106b673c285af66d72392bd4a8522aba98489)
nyan_big: Add 4GB 204/792MHz BCTs
Reviewed-on: https://chromium-review.googlesource.com/184159
(cherry picked from commit 5ff002d09f8db0543b58962f6c0d24627fb0937e)
tegra124: Add function for obtaining DRAM size via MC regs
Reviewed-on: https://chromium-review.googlesource.com/184535
(cherry picked from commit d4580c46de649903a266a99eb11c9126ba385b48)
tegra124/nyan*: Obtain DRAM size dynamically
Reviewed-on: https://chromium-review.googlesource.com/184431
(cherry picked from commit a7db71744771decc04cf1966efba70bf4897cfa3)
tegra124: Rearrange iRAM layout to allow more space for romstage
Reviewed-on: https://chromium-review.googlesource.com/184240
(cherry picked from commit 6bdaabbc068146a4516c724b71d31bb777dabcfc)
tegra124: Fix MemoryType field name in SDRAM parameters.
Reviewed-on: https://chromium-review.googlesource.com/185113
(cherry picked from commit 9caccd1e86a8c683402fab87d9f3a49b87496e97)
nyan_big: Initialize SDRAM without BootROM.
Reviewed-on: https://chromium-review.googlesource.com/183624
(cherry picked from commit a1cbc00aa80ec1ea52e833a8e31c8e4b27160e70)
tegra124: move FB_SIZE_MB to a more appropriate location
Reviewed-on: https://chromium-review.googlesource.com/184930
(cherry picked from commit ddea486fd4410394417c4e59039d46a324918bdc)
nyan: Initialize SDRAM without BootROM.
Reviewed-on: https://chromium-review.googlesource.com/185114
(cherry picked from commit 1ff51b580b28553919f91b11b443251b048cf26b)
tegra124: Save SDRAM parameters to PMC registers for LP0
Reviewed-on: https://chromium-review.googlesource.com/182928
(cherry picked from commit 7476b4bd0ecdc312476cce871d22f57915a0bd86)
tegra124: Rewrite SDRAM parameter saving code to be more efficient
Reviewed-on: https://chromium-review.googlesource.com/184388
(cherry picked from commit 25084bd0407624e4b2ff82388c32af1198c501a6)
nyan: Slightly change the way SDRAM parameter files are set up
Reviewed-on: https://chromium-review.googlesource.com/185286
(cherry picked from commit a31887b804f23e031c395113db582cd71f3d1b6d)
Squashed 16 commits for SDRAM support on nyan and nyan_big.
Change-Id: I07419985376277083d62400dd14fe8273f6d5ca8
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6949
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Most of the code related to the mc146818 is not related to the RTC and is
really for managing the CMOS storage. Since we intend to add a generic API
for RTC drivers it's inconvenient for those functions to have an rtc_ prefix.
This CL renames those functions so they start with cmos_ instead. There are
some places where rtc_init was called with a comment that says something about
starting the RTC. That wasn't correct before (the RTC is always running), but
it looks a little odd now that the function is called cmos_init.
This CL also opportunistically cleans up some style problems in this file.
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/197794
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 9a9ad24888b185fb58965457704e326bb508d788)
Removed the addition of stdint.h to mc146818rtc.h since
types.h is now included. Changed rtc_init to cmos_init for
fsp_bd82x6x, fsp_rangeley, fsp_baytrail, ibexpeak, vortex86ex.
Change-Id: Id4b9f6bea93e8bd5eaef2cb17f296adb9697114c
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6977
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
broadwell: Add romstage usbdebug support
Reviewed-on: https://chromium-review.googlesource.com/199412
(cherry picked from commit 1050e7d3be6ec1e4fe5aa2df408f4bb6d33a42b5)
broadwell: Add romstage code to configure PCH UART for console
Reviewed-on: https://chromium-review.googlesource.com/199807
(cherry picked from commit ecebda4eb5d6fe58473d25c2898ba1a2eac0f39a)
broadwell: Expand the PCI device convenience macros
Reviewed-on: https://chromium-review.googlesource.com/199891
(cherry picked from commit f8c54c70f136cd2cb8f977bc25661974d7e529ad)
broadwell: Add ramstage driver for ADSP
Reviewed-on: https://chromium-review.googlesource.com/199892
(cherry picked from commit e8e986b0ba52bbfc9923d71009fbd31e749ca43f)
broadwell: Update ACPI devices
Reviewed-on: https://chromium-review.googlesource.com/201080
(cherry picked from commit 2446b35578eb36e0009415bec340059135751549)
broadwell: Reserve DPR region
Reviewed-on: https://chromium-review.googlesource.com/201081
(cherry picked from commit 8ecd9d2096db2bded6f27ef6ee9a9b39ce2dfec6)
broadwell: Remove old pei_data and add cpu function for romstage
Reviewed-on: https://chromium-review.googlesource.com/201690
(cherry picked from commit d206c9cdd69519d502a90bb0595f0e3a7cb50274)
broadwell: Fixes for graphics without executing VBIOS
Reviewed-on: https://chromium-review.googlesource.com/202356
(cherry picked from commit 0c031df1ce92c875e95ddfd3f026f649c342c7fa)
broadwell: Fix compilation failure when loglevel is lowered
Reviewed-on: https://chromium-review.googlesource.com/202357
(cherry picked from commit 708ce78b2bfae5664b1238e17b086c88cac55bdc)
broadwell: Disable GPIO controller interrupt
Reviewed-on: https://chromium-review.googlesource.com/203645
(cherry picked from commit 2d17e98eded5958258ba5c0abf600284d8d03af9)
broadwell: Add support for E0 stepping
Reviewed-on: https://chromium-review.googlesource.com/205160
(cherry picked from commit 802e9d371418cc7a7fc7af131d7e5dda0ae5b273)
broadwell: misc updates for CPU driver
Reviewed-on: https://chromium-review.googlesource.com/205161
(cherry picked from commit ea1d403817ee193648f2c119fd45894e32e57e97)
broadwell: Read power state earlier and store in romstage params
Reviewed-on: https://chromium-review.googlesource.com/208151
(cherry picked from commit b2198d71084ad3c1360a0bfedc46c8dd3825bd0e)
broadwell: Add parameters to pei_data structure
Reviewed-on: https://chromium-review.googlesource.com/208153
(cherry picked from commit 423fbf67e497a907fbc8e12caf2929d4951858af)
broadwell: Move platform report output after power state is read
Reviewed-on: https://chromium-review.googlesource.com/208213
(cherry picked from commit acedf4146bf9377133433046dae1fa9c8bc69d78)
Squashed 15 commits for broadwell support.
Change-Id: I87e320d3d5376b84dd9c146b0b833e5ce53244aa
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6982
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
This broadwell implementation will support Haswell ULT in
addition to broadwell CPUs. Add the latest available microcode
for the broadwell C0 and D0 parts as well as Haswell ULT.
Change-Id: I1beb71e0e28af3508e2260751b6fdfe47d53d90d
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/198742
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit 69d5b7c834a4f52656ab14562ea913477418e588)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6965
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
This is common code for Intel SOC that can be shared.
Change-Id: Ic703f36f56a8238d5cc1248b353d8c3a49827a9a
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/196264
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit 3a9057b9616c54a8404eee55511743d2492dbc28)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6968
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
This common code can be shared across Intel SOCs.
Change-Id: Id9ec4ccd3fc81cbab19a7d7e13bfa3975d9802d0
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/196263
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit f9919e2551b02056b83918d2e7b515b25541c583)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6967
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
baytrail: Change all GPIO related pull resistors from 10K to 20K
Reviewed-on: https://chromium-review.googlesource.com/187570
(cherry picked from commit 762e99861dd1ae61ddcf1ebdec8e698ede54405e)
baytrail: workaround kernel using serial console on resume
Reviewed-on: https://chromium-review.googlesource.com/188011
(cherry picked from commit b0da3bdb5b6b417ad6cab0084359d4eae1cb4469)
baytrail: allow dirty cache line evictions for SMRAM to stick
Reviewed-on: https://chromium-review.googlesource.com/188015
(cherry picked from commit 50fb1e6a844e1db05574c92625da23777ad7a0ca)
baytrail: Optionally pull up TDO and TMS to avoid power loss in S3.
Reviewed-on: https://chromium-review.googlesource.com/188260
(cherry picked from commit e240856609b4eed5ed44ec4e021ed385965768d6)
rambi: always load option rom
Reviewed-on: https://chromium-review.googlesource.com/188721
(cherry picked from commit d8a1d108548d20755f8683497c215e76d513b7a9)
baytrail: use new chromeos ram oops API
Reviewed-on: https://chromium-review.googlesource.com/186394
(cherry picked from commit f38e6969df9b5453b10d49be60b5d033d38b4594)
rambi: always show dev/rec screens on eDP connected panel
Reviewed-on: https://chromium-review.googlesource.com/188731
(cherry picked from commit 7d8570ac52f68492a2250fa536d55f7cbbd9ef95)
baytrail: stop e820 reserving default SMM region
Reviewed-on: https://chromium-review.googlesource.com/189084
(cherry picked from commit 6fce823512f5db5a09a9c89048334c3524c69a24)
baytrai: update MRC wrapper header
Reviewed-on: https://chromium-review.googlesource.com/189196
(cherry picked from commit 36b33a25b6603b6a74990b00d981226440b68970)
rambi: Put LPE device into ACPI mode
Reviewed-on: https://chromium-review.googlesource.com/189371
(cherry picked from commit 5955350cd57fd1b3732b6db62911d824712a5413)
baytrail: DPTF: Enable mainboard-specific PPCC
Reviewed-on: https://chromium-review.googlesource.com/189576
(cherry picked from commit 27fae3e670244b529b7c0241742fc2b55d52c612)
baytrail: Add config option for PCIe wake
Reviewed-on: https://chromium-review.googlesource.com/189994
(cherry picked from commit 1cc31a7c021ec84311f1d4e89dd3e57ca8801ab5)
rambi: Enable PCIe wake
Reviewed-on: https://chromium-review.googlesource.com/189995
(cherry picked from commit c98ae1fee54cfb2b3d3c21a19cdbbf56a0bfa1e6)
Squashed 13 commits for baytrail/rambi.
Change-Id: I153ef5a43e2bede05cfd624f53e24a0013fd8fb4
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6957
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
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>
