BUG=chrome-os-partner:29778
TEST=Build coreboot
Change-Id: I23af280764eb28d3f6b215ab32553fe42ee73272
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: abf5c14c8b32573107d2a1c73a752e740264db7e
Original-Change-Id: I46257cc71cc3cd1e867edf589ddf09f7990d6784
Original-Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Original-Signed-off-by: huang lin <hl@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/209462
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Original-Commit-Queue: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/8863
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
BUG=chrome-os-partner:29778
TEST=Build coreboot
Change-Id: I74b30ecfe40c039855b835db0dfd0cd25adf960e
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: a30378a3152c930029a5b170cc6bf46180b5c7b8
Original-Change-Id: I5105e5277b8072c06bb41b39479373697ef81c67
Original-Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/209468
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Tested-by: Lin Huang <hl@rock-chips.com>
Original-Commit-Queue: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/8860
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
With CONFIG_RETURN_FROM_VERSTAGE false, the verstage loads the romstage over
the bootblock, then exits to the romstage. this is necessary for some SOC
(e.g. tegra124) which runs the bootblock on a different architecture.
With CONFIG_RETURN_FROM_VERSTAGE true, the verstage returns to the bootblock.
Then, the bootblock loads the romstage over the verstage and exits to the
romstage. this is probably necessary for some SOC (e.g. rockchip) which does not
have SRAM big enough to fit the verstage and the romstage at the same time.
BUG=none
TEST=Built Blaze with USE=+/-vboot2. Ran faft on Blaze.
BRANCH=none
Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Change-Id: I673945c5e21afc800d523fbb25d49fdc83693544
Original-Reviewed-on: https://chromium-review.googlesource.com/212365
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Note: This purposefully is probably broken in vendorcode/google/chromeos
as I'm just trying to set a base for dropping more patches in. The vboot
paths will have to change from how they are currently constructed.
(cherry picked from commit 4fa17395113d86445660091413ecb005485f8014)
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I9117434ce99695f9b7021a06196d864f180df5c9
Reviewed-on: http://review.coreboot.org/8881
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
this change reduces the code duplication of the bootblock and the romstages for
Nyans.
BUG=none
TEST=Built Nyan, Big, and Blaze. Ran faft on Blaze.
BRANCH=none
Original-Signed-off-by: dnojiri@chromium.org (Daisuke Nojiri)
Original-Change-Id: Ieb9dac3b061a2cf46c63afb2f31eb67ab391ea1a
Original-Reviewed-on: https://chromium-review.googlesource.com/214050
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Commit-Queue: Daisuke Nojiri <dnojiri@chromium.org>
Original-Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
(cherry picked from commit f3413d39458f03895fe4963a41285f71d81bcf5f)
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I912f63b12321aa26a7add302fc8a6c4e607330ef
Reviewed-on: http://review.coreboot.org/8880
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This code ports antirollback module and tpm library from platform/vboot_reference.
names are modified to conform to coreboot's style.
The rollback_index module is split in a bottom half and top half. The top half
contains generic code which hides the underlying storage implementation.
The bottom half implements the storage abstraction.
With this change, the bottom half is moved to coreboot, while the top half stays
in vboot_reference.
TEST=Built with USE=+/-vboot2 for Blaze. Built Samus, Link.
BUG=none
Branch=none
Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Change-Id: I77e3ae1a029e09d3cdefe8fd297a3b432bbb9e9e
Original-Reviewed-on: https://chromium-review.googlesource.com/206065
Original-Reviewed-by: Randall Spangler <rspangler@chromium.org>
Original-Reviewed-by: Luigi Semenzato <semenzato@chromium.org>
(cherry picked from commit 6b66140ac979a991237bf1fe25e0a55244a406d0)
Change-Id: Ia3b8f27d6b1c2055e898ce716c4a93782792599c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/8615
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Add implementation of the GPIO API defined in src/include/gpiolib.h.
Also, clean up the GPIO driver, make it use pointers instead of
integers for register address.
This requires a touch in the SPI driver, where the CS GPIO is toggled
and in the board function where it enables USB interface.
BUG=chrome-os-partner:30489
TEST=tested with the following patches, observed proto0 properly read
the board ID.
Original-Change-Id: I0962947c6bb32a854ca300752d259a48e9e7b4eb
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/210115
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit e951f735001509d135cc61530ed0eecb5fc31a85)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I8a612dce000931835054086c1b02ebfc43dc57d2
Reviewed-on: http://review.coreboot.org/8718
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Some platforms use tertiary interpretation of GPIO input state to
increase number of distinct values represented by a limited number of
GPIOs. The three states are
- external pull down (interpreted as 0)
- external pull up (1)
- not connected (2)
This has been required by Nvidia devices so far, but Exynos and
Ipq8086 platforms need this too.
This patch moves the function reading the tertiary state into the
library and exposes the necessary GPIO API functions in a new include
file. The functions are still supposed to be provided by platform
specific modules.
The function interpreting the GPIO states has been modified to allow
to interpret the state either as a true tertiary number or as a set
two bit fields.
Since linker garbage collection is not happening when building x86
targets, a new configuration option is being added to include the new
module only when needed.
BUG=chrome-os-partner:30489
TEST=verified that nyan_big still reports proper revision ID.
Change-Id: Ib55122c359629b58288c1022da83e6c63dc2264d
Original-Change-Id: I243c9f43c82bd4a41de2154bbdbd07df0a241046
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/209673
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit c79ef1c545d073eaad69e6c8c629f9656b8c2f3e)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/8717
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Bootblock stack on Danube should be SRAM and defined separately from
the rest of the coreboot stack. The actual coreboot stack will be
defined later.
The top of the stack should be above the bottom, as the stack grows
towards lower addresses.
BUG=chrome-os-partner:31438
TEST=ran bootblock on simulator under codescape, observed stack
properly initialized.
Change-Id: I43d2bae5f85a09a95ca0103b253399bd92555aef
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: e02724cb4b30990ebaa631dabb45917af29d6437
Original-Change-Id: I3c37c8b5a1c0e7fd19411558a8f6d899fc283191
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/218732
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8767
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Actual timer support is not yet available for Danube, it will be added
soon. For now, just to make the target build, modify it to use
GENERIC_UDELAY and HAVE_MONOTONIC_TIMER configuration option.
BUG=none
TEST=the target builds again
Change-Id: Iad1ceb966d5dbc8687b966be4d2506c8f92eba5a
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 261837539fb5a31f96e682edbcbbbc0e588f2750
Original-Change-Id: Ie3289eace9d2baadd01bd641b5dffc635ac80c0f
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/220395
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8765
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Romstage initialization code does not need to be board specific, keep
it in the SOC directory. Should there be a need for the board specific
code, it can be added later.
BUG=chrome-os-partner:31438
TEST=with upcoming patches, the urara board coreboot builds fine
Change-Id: Ib619fa9313d463ded13e9259e50bb5aeaab4fb05
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 2c08977aaa5e9b5da29359d1920d7d8b61ce86d3
Original-Change-Id: I27e2d225bd36c42ccd29128d0ea9a970566c02af
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/215992
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8764
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Iniitialize I2C bus required for TPM operation. Problem observed was that if
frequency is raised above 20KHz, TPM starts responding with NAKs either for
address or for data. Need to look into that.
BUG=None
BRANCH=None
TEST=Compiles successfully and TPM success messages seen while booting.
Original-Change-Id: I9e1b4958d2ec010e31179df12a099277e6ce09e0
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/210001
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Queue: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit 01e87ae35431147f442e3f3e531537b8f0de1c9d)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I7dddc39d77f9a726fa51dd58ea9b7712c9a6fae2
Reviewed-on: http://review.coreboot.org/8715
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
There was an empty udelay() implementation result in 0 waits.
Provide an actual implementation.
BUG=None
BRANCH=None
TEST=Built and ran through to depthcharge on rush.
Change-Id: Ia7060566a71c36bb7e4543c2fe4ee49d168518c7
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: c8832e73de238358ea801ccd7c2330de35a7b40e
Original-Change-Id: I201f2fdc4e4f5c88d48e4002839b03e808a5a1bc
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/210827
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/8830
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Instead of using rela_time use the stopwatch API as the
semantics fit perfectly with the expiration usage.
BUG=None
BRANCH=None
TEST=Built, but similar usage tested on tegra132.
Change-Id: I1147f2bed84b93d1b776205df9ae04d1db9c98a5
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: c38e054dd166d5eb53f692833b5ce88a230816e3
Original-Change-Id: I6d3f3da4e035e872890d8b67947b17a981673dba
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/219712
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/8819
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
These modules are necessary to resolve external names when building
the board image. These are just skeletons for now which will be filled
later.
BUG=chrome-os-partner:31438
TEST=when config is enabled, emerge-urara coreboot succeeds. more
extensive testing to come later
Change-Id: I0fcb5d33187172ecac77041425402b33e89e8944
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 94ec79b0ab872f5c5fe7db5bef5fdabf77d6b3b6
Original-Change-Id: I69cc178976a910ebf8031ed9ac9ad67b4cc0878a
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/215678
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8763
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Add build infrastructure and basic support code for the ImgTec Danube
SoC. This support is sufficient to run on a simulator.
BUG=chrome-os-partner:31438
TEST=none yet
Change-Id: I59e36589765bf06b075fd4850215a0ef71246bb1
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 881278d7fbb8e6803bc8f6f9e84c64640b097401
Original-Change-Id: Ia7ed7288b13085db7ff37b5ad75d978b6137f958
Original-Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/207974
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8762
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Instead of sprinkling the cbfs calls around (as well as getting
return values incorrect) use the common run_romstage() to perform
the necessary work to load and run romstage.
Change-Id: Id59f47febf5122cb3ee60f9741cfb58cb60ccab5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8711
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The GCC 4.9.2 update showed that the boot_state_init_entry
structures were being padded and assumed to be aligned in to an
increased size. The bootstate scheduler for static entries,
boot_state_schedule_static_entries(), was then calculating the
wrong values within the array. To fix this just use a pointer to
the boot_state_init_entry structure that needs to be scheduled.
In addition to the previous issue noted above, the .bs_init
section was sitting in the read only portion of the image while
the fields within it need to be writable. Also, the
boot_state_schedule_static_entries() was using symbol comparison
to terminate a loop which in C can lead the compiler to always
evaluate the loop at least once since the language spec indicates
no 2 symbols can be the same value.
Change-Id: I6dc5331c2979d508dde3cd5c3332903d40d8048b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8699
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The current spi_xfer() function sets the count in hardware and then
loops while waiting for the requested number of bytes to be sent or
received. However, the number of bytes to be transferred may exceed
the maximum count that can be programmed into the controller.
This patch re-factors spi_xfer() to split the low-level FIFO handling
portions for transmit/receive into their own functions to be called
by loops in spi_xfer() which will break large transfers into smaller
ones.
BUG=chrome-os-partner:30904
BRANCH=storm
TEST=built and booted with a >64KB payload on Storm
Original-Change-Id: I70743487996cf08cfc602449f2181a7fcd99bfa4
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/209838
Original-Reviewed-by: Trevor Bourget <tbourget@codeaurora.org>
Original-Tested-by: Trevor Bourget <tbourget@codeaurora.org>
(cherry picked from commit 5ec28de11f12c2438356f45ce978a17fbb603bf7)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I0033e0dd96006cfd30a7a4f5e5a052f677e05108
Reviewed-on: http://review.coreboot.org/8676
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Since CCLK_BURST_POLICY and SUPER_CCLK_DIVIDER are not accesible
from AVP, the first place that can change CPU clock is after CPU
has been brought up, ie, ramstage in this case.
CPU initial clock source is set to PLLP by MTS.
BUG=None
TEST=Norrin64 and A44
Original-Change-Id: I525bb2fa2be0afba52837bc0178950541535fd22
Original-Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/209698
Original-Reviewed-by: Tom Warren <twarren@nvidia.com>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit ba77e26508bb4a50a08d07ad15632ff1ba501bfa)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: Icf2458c491b4b3a553d3e01f88c6f25b25639e89
Reviewed-on: http://review.coreboot.org/8677
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Provide functionality to create dynamic classes based on program name and the
architecture for which the program needs to be compiled/linked. define_class
takes program_name and arch as its arguments and adds the program_name to
classes-y to create dynamic class and compiler toolset is created for the
specified arch. All the files for this program can then be added to
program_name-y += .. Ensure that define_class is called before any files are
added to the class. Check subdirs-y for order of directory inclusion.
One such example of dynamic class is rmodules. Multiple rmodules can be used
which need to be compiled for different architectures. With dynamic classes,
this is possible.
BUG=chrome-os-partner:30784
BRANCH=None
TEST=Compiles successfully for nyan, rush and link.
Original-Change-Id: I3e3aadbe723d432b9b3500c44bcff578c98f5643
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/209379
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Queue: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit 242bb90d7476c2ee47d60c50ee18785edeb1a295)
Some of this cherry-pick had already been committed here:
commit 133096b6dc
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I9f5868d704c4b3251ca6f54afa634588108a788c
Reviewed-on: http://review.coreboot.org/8672
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Most things still needs to be filled in, but this will allow us to build boards which use this SOC.
BUG=chrome-os-partner:29778
TEST=emerge-veyron coreboot
Original-Change-Id: If643d620c5fb8951faaf1ccde400a8e9ed7db3bc
Original-Signed-off-by: jinkun.hong <jinkun.hong@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/205069
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Original-Commit-Queue: David Hendricks <dhendrix@chromium.org>
Original-Tested-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit 2f72473a8c2b3fe21d77b351338e6209035878fb)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I53fd0ced42f6ef191d7bf80d8b823bb880344239
Reviewed-on: http://review.coreboot.org/8653
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This patch removes a chunk of romstage code from Tegra and all Nyan
boards that was supposed to enable some LCD power rails early, but never
really worked. The dev_find_slot() function can only find PCI devices,
which the CPU cluster is not. Since we're done with Nyan-RO and the
ramstage display code is fine as it is, there is no point in trying to
fix this... but we should remove it from ToT lest someone uses it as a
blueprint to add more dead code to future boards.
BRANCH=None
BUG=None
TEST=None
Original-Change-Id: I6eee256873299429d4e3934fe7d454120390f34d
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/207720
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit a3df62a3bcefcc20ae59648f5d1f0a01db3c02c6)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I8deedea5e9787848aae3064509c611bc349313cc
Reviewed-on: http://review.coreboot.org/8638
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Stop running AVP at the end of romstage until event conditions are met (JTAG,
GIC_IRQ or LIC_IRQ).
BUG=chrome-os-partner:30831
BRANCH=None
TEST=Compiles successfully and boots till last known good checkpoint.
Original-Change-Id: Ia221f08b27ac0c60a66d588e351677144cc6a322
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/209424
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
(cherry picked from commit df4e8b4c8a1002443a936bd0563fbc9e0710f489)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I59f7702bd50a1039b8723e9cb12b8d714e353d37
Reviewed-on: http://review.coreboot.org/8651
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The SPI controller operates on packets which can be variable
length up to 32-bit packets. It also has the ability to be
put in packed or unpacked mode w.r.t each packet. i.e. does
a single fifo register hold >= 1 packet. The current programming
uses 8-bit packets in unpacked mode which means 4 fifo slots
are used for a 32-bit DMA transfter. As the AHB can only operate
on a minimum of 32-bit bursts the triggers need to be programmed
correctly so that there is room for a full 32-bit DMA transaction.
Previously faster SPI clocks just made things magically work.
BUG=chrome-os-partner:30779
BRANCH=None
TEST=Built and booted through coreboot with 20MHz SPI clock.
Original-Change-Id: I3f1cd4dddcea9514327b2363ed450a527db7e1fe
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/208862
Original-Reviewed-by: Tom Warren <twarren@nvidia.com>
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
(cherry picked from commit d9864228a2479e412d7e0d2221fe536f78329acd)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I61c145f35e1f889d4f83f3dfea049bfd347c1196
Reviewed-on: http://review.coreboot.org/8649
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
The Trust Zone carveout registers are only accessible using
a secure access mode. The AVP runs as non-secure all the time.
In EL3 the CPU is in secure mode, but when the MMU is enabled
the page tables dictate if accesses to certain regions are
secure or not. However, ramstage is currently being loaded
into non-secure memory and the page tables will live in
non-secure memory as well. Therefore, handle all these
cases by providing global state which mirrors the TZ
register.
BUG=chrome-os-partner:30782
BRANCH=None
TEST=Built and ran through ramstage with the MMU enabled
Resources are read and set accordingly.
Original-Change-Id: Ib76b2641497a29ef2adb75934b2df55ecf0b3e78
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/209061
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
(cherry picked from commit 0bcbdc56978f6ebe3e7d1b74ed2fd861e03bb562)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I9c1beed443a48870ba190427e87caf90caf4ff6b
Reviewed-on: http://review.coreboot.org/8648
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Add support for mmu initialization and enabling caches. mmu_operations provides
functions to add mmap_regions using memrange library and then calls mmu_init for
armv8.
BUG=chrome-os-partner:30688
BRANCH=None
TEST=Compiles rush successfully and boots until depthcharge load. Goes past
all the earlier alignment errors.
Original-Change-Id: I57c2be80427fa77239093c79ece73e31fd319239
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/208762
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
(cherry picked from commit a6141d13d40cfa5a493bde44e69c588dda97e8fd)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I33bf4b2e28b85a3117b566cb8497f2bd5aabb69b
Reviewed-on: http://review.coreboot.org/8647
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
With this memory resource, the payload loading code should be
able to create a bounce buffer and load the payload successfully.
Adapted from tegra124 soc.c
BUG=None
BRANCH=None
TEST=Built and booted to ramstage on rush.
Original-Change-Id: I2e336ce93c1b0236104e63d3785f0e3d7d76bb01
Original-Signed-off-by: Tom Warren <twarren@nvidia.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/208121
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit 20765da0b15ee8c35a5bbfe532331fc6b1cef502)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I267ced473ad0773b52f889dfa83c65562444c01f
Reviewed-on: http://review.coreboot.org/8644
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Once LPDDR3 init is supported in the ryu romstage, this can
be reverted. Note that this 528MHz BCT has been pre-qualed
by NVIDIA AE's, but will be updated as more tuning is done.
BUG=none
BRANCH=none
TEST=Builds, BCT is in binary, but I have no HW here to test on
Original-Change-Id: I315a9a5d56290bb5f51863b15053d2171db7b1e4
Original-Signed-off-by: Tom Warren <twarren@nvidia.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/208384
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
(cherry picked from commit 660e40cb473d47ce763e79d6061367bf381a1c48)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I29ad31fc83f45ca8f92809a7dc252cf984c8c6fe
Reviewed-on: http://review.coreboot.org/8643
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
The address map code was originally assuming all carveouts would
be packed together in the upper end of the physical memory
address space. However, the trust zone carveout is always in the
32-bit address space. Therefore, one needs to query memory ranges
by above and below 4GiB with the assumption of carveouts being
packed at the top of *each* resulting range.
BUG=chrome-os-partner:30572
BRANCH=None
TEST=Built and ran through coreboot on rush.
Original-Change-Id: Iab134a049f3726f1ec41fc6626b1a6683d9f5362
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/208101
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
(cherry picked from commit 8d5795fbff36e91906384e10774a32541d358324)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: If15ff48d5a4c81731eb364980b30c8086deb1cca
Reviewed-on: http://review.coreboot.org/8641
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
The default CBFS size configuration setting is incorrect in case of
Qualcomm SOC targets, as the coreboot blob is much smaller than the
actual bootprom. Note that this size also must match the board fmap
defined in the appropriate depthcharge board directory.
BUG=chromium:394068
TEST=manual
. previously failing to boot coreboot image does not fail to load
depthcharge anymore.
Original-Change-Id: I1b178970b1deee05705490542e4a0c57500379dd
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/208146
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit 01f3561fdee7b5547534e20d423fbbb1b490532c)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: If573bbc6254cf6786e75970eae3ad2b327a7ecfe
Reviewed-on: http://review.coreboot.org/8640
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Provide a default Trust Zone region size of 1MiB, and
correctly account for it in the AVP and the arm64 cores.
The different path between the arm64 cores and the AVP
is because the AVP cannot access the Trust Zone region
registers. Therefore the AVP needs to account for the
Trust Zone region.
BUG=chrome-os-partner:30572
BRANCH=None
TEST=Built and ran. Noted Trust Zone region being accounted for.
Original-Change-Id: Ie0f117ec7a5ff8519c39778d3cdf88c3eee57ea5
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/208062
Original-Reviewed-by: Tom Warren <twarren@nvidia.com>
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
(cherry picked from commit 22f2fa05c009c58f53b99b9ebe1b6d01fdac5ba7)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I28506b4401145d366b56126b2eddc4c3d3db7b44
Reviewed-on: http://review.coreboot.org/8639
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
There is nothing platform specific in retrieving S3 resume state from
romstage_handoff structure. Boards without EARLY_CBMEM_INIT update
acpi_slp_type from ACPI power-management block or scratchpad registers.
Change-Id: Ifc3755f891a0810473b3216c1fec8e45908fc1ab
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/8188
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
BUG=chrome-os-partner:31424
BRANCH=none
TEST=build only, due to I don't have broadwell system with wifi to test
need somebody help me to verify
Change-Id: I52360176e135ea7f01cc67a926be4870265f57d1
Signed-off-by: Kane Chen <kane.chen@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/220743
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/8448
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
At some point the license text for a file was incorrectly
changed. That license was then copied and pasted. I'm sure it
was myself. Anyhow, fix the bustedness.
Change-Id: I276083d40ea03782e11da7b7518eb708a08ff7cd
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8620
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
In order to make sharing of the location of MTS microcode easier
provide a Kconfig option that is the path to the files.
BUG=chrome-os-partner:30569
BRANCH=None
TEST=Built rush coreboot.
Original-Change-Id: I36775d0018fc8591d5e77c2943e28a51381713f5
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/207839
Original-Reviewed-by: Tom Warren <twarren@nvidia.com>
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
(cherry picked from commit 6f1de0e7fd312c1d6798e65d4b43d586f0994337)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I660cb9d8bd13c765c89b54b0807b5b3ee836e807
Reviewed-on: http://review.coreboot.org/8614
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
The preboot MTS microcode needs to be supplied within the
bct so the BootROM can load it. The size of the bootblock
space in SPI needed to be extended to accomodate the extra
length.
BUG=chrome-os-partner:29059
BUG=chrome-os-partner:29060
BRANCH=None
TEST=Built rush with updated cbootimage with t132 support.
Original-Change-Id: Iafc1837cd81cc1165a9be5da6ec7425cec2e2ffc
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/204940
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
(cherry picked from commit 22e054496465c74fc12afd865d14b87c5858d889)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I5e46c408a7215ecc789b0a0f35070ef9036a7d11
Reviewed-on: http://review.coreboot.org/8466
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
