| Age | Commit message (Collapse) | Author |
|---|
|
Verified boot needs hard_reset() now, so offer a dummy implementation
for the Imagination chip. Sorry, I don't have the specs for this chip
anymore to make a real implementation, but I would like to keep this
code from bit rotting.
Change-Id: I15aa47f7d248b99901a2ac0e65a46b43d7718717
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: https://review.coreboot.org/12723
Tested-by: build bot (Jenkins)
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
|
|
It encourages users from writing to the FSF without giving an address.
Linux also prefers to drop that and their checkpatch.pl (that we
imported) looks out for that.
This is the result of util/scripts/no-fsf-addresses.sh with no further
editing.
Change-Id: Ie96faea295fe001911d77dbc51e9a6789558fbd6
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/11888
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Currently coreboot expects the loader to clear the bss section
for all stages. i.e. stages don't clear their own bss. On ARM
SoCs the BootROM would be responsible for this. To do that
one needs to include the bss section data (all zeros) in the
bootblock.bin file. This was previously being attempted by
keeping the .bss info in the .data section because objcopy
happened zero out non-file allocated data section data.
Instead go back to linking bootblock with the bss section
but mark the bss section as loadable allocatable data. That
way it will be included in the binary properly when objcopy
-O binary is emplyed. Also do the same for the data section
in the case of no non-zero object values are in the data
section.
Without this change the trick of including .bss in .data
was not working when there wasn't a non-zero value object
in the data section.
BUG=None
BRANCH=None
TEST=Built emulation/qemu-armv7 and noted bootblock.bin contains
the cleared bss.
Change-Id: I94bd404c2c4a8b9332393e6224e98940a9cad4a2
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11680
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Initialization for the Winbond W631GG6KB part using Synopsys
DDR uMCTL and DDR Phy.
This code adds a separate function for DDR3 initialization
and moves all the necessary defines in a separate header file.
The programming procedure that is executed at power up to bring
up the uMCTL, PHY and memories into a state where reads and
writes to the memory can be performed is the following:
1. uPCTL (Universal DDR protocol controller) initialization
The timining registers TOGCNT1U, TINIT, TOGCNT100N and TRSTH
needed for driving the memory power-up sequence are programmed
as a function of the internal timers clock frequency.
Organization (memory chip specific) values are set
(column/bank/row address width and number of ranks), together
with other static values (latency, timing, power up configuration).
All these values are static, provided by the datasheet,
being determined by the memory type, size and frequency.
2. PHY initialization
The PHY is programmed with datasheet provided values,
specifying the initialization values for it to send to the
external memory (timing parameters).
Also, delay lines (DLL) and strength of drive pads are
calibrated (based on external conditions: temperature,
voltage, noise) and locked. After that, the PHY goes
through a trainig process (also dependent on the
current conditions at boot time) to establish precise
timing configuration between the DDR clock and DQS (data strobe)
and between DQS and DQ (data).
3. Memory power up
4. Switch from configuration state to access state.
It was tested on Pistachio bring up board where DDR was initialized
properly and ramstage executed correctly
Change-Id: I3bcbce2044327a22fce09b184d85ee11228a6b2b
Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com>
Reviewed-on: http://review.coreboot.org/10529
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
As per discussion with lawyers[tm], it's not a good idea to
shorten the license header too much - not for legal reasons
but because there are tools that look for them, and giving
them a standard pattern simplifies things.
However, we got confirmation that we don't have to update
every file ever added to coreboot whenever the FSF gets a
new lease, but can drop the address instead.
util/kconfig is excluded because that's imported code that
we may want to synchronize every now and then.
$ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, *MA[, ]*02110-1301[, ]*USA:Foundation, Inc.:" {} +
$ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin Street, Suite 500, Boston, MA 02110-1335, USA:Foundation, Inc.:" {} +
$ find * -type f -exec sed -i "s:Foundation, Inc., 59 Temple Place[-, ]*Suite 330, Boston, MA *02111-1307[, ]*USA:Foundation, Inc.:" {} +
$ find * -type f -exec sed -i "s:Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.:Foundation, Inc.:" {} +
$ find * -type f
-a \! -name \*.patch \
-a \! -name \*_shipped \
-a \! -name LICENSE_GPL \
-a \! -name LGPL.txt \
-a \! -name COPYING \
-a \! -name DISCLAIMER \
-exec sed -i "/Foundation, Inc./ N;s:Foundation, Inc.* USA\.* *:Foundation, Inc. :;s:Foundation, Inc. $:Foundation, Inc.:" {} +
Change-Id: Icc968a5a5f3a5df8d32b940f9cdb35350654bef9
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/9233
Tested-by: build bot (Jenkins)
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
|
|
This change switches all SOC vendors and southbridges
to be autoincluded by Makefile.inc, rather than having to be
mentioned explicitly in soc/Makefile.inc or in
soc/<vendor>/Makefile.inc.
This means, vendor and SOC directories are now "drop
in", e.g. be placed in the coreboot directory hierarchy
without having to modify any higher level coreboot files.
The long term plan is to enable out of tree components to be
built with a given coreboot version (given that the API did not
change).
Change-Id: Iede26fe184b09c53cec23a545d04953701cbc41d
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/9799
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
This is the intialization code specific to the Winbond
W972GG6JB-25 part using Synopsys DDR uMCTL and DDR Phy.
This is DDR2 initialization code only (currently present
on the bring up board). DDR3 initialization code will follow
for boards having DDR3 memory.
The programming procedure that is executed at power up to bring
up the uMCTL, PHY and memories into a state where reads and
writes to the memory can be performed is the following:
1. uPCTL (Universal DDR protocol controller) initialization
The timining registers TOGCNT1U, TINIT, TOGCNT100N and TRSTH
needed for driving the memory power-up sequence are programmed
as a function of the internal timers clock frequency.
Organization (memory chip specific) values are set
(column/bank/row address width and number of ranks), together
with other static values (latency, timing, power up configuration).
All these values are static, provided by the datasheet,
being determined by the memory type, size and frequency.
2. PHY initialization
The PHY is programmed with datasheet provided values,
specifying the initialization values for it to send to the
external memory (timing parameters).
Also, delay lines (DLL) and strength of drive pads are
calibrated (based on external conditions: temperature,
voltage, noise) and locked. After that, the PHY goes
through a trainig process (also dependent on the
current conditions at boot time) to establish precise
timing configuration between the DDR clock and DQS (data strobe)
and between DQS and DQ (data).
3. Memory power up
4. Switch from configuration state to access state.
BUG=chrome-os-partner:31438, chrome-os-partner:37087
TEST=tested on Pistachio bring up board -> DDR initialized
properly and ramstage executed correctly
DDR2 is also tested during chip sort.
Corner cases (performace of DDR in different conditions)
will be tested after the chip reaches a stable state.
BRANCH=none
Change-Id: I0093dc175d064aad03052d5281679b008c1bf012
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 3d0bacea0fd5bd3b12008b47e80de8398f447785
Original-Change-Id: I8437db6c84d77c4c51a3ee2b09cd3d14913c0d16
Original-Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/241424
Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Commit-Queue: Vadim Bendebury <vbendeb@chromium.org>
Original-Tested-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/9769
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
|
|
Set elements:
- UART1 clock dividers and MFIOs
- SPIM1 clock dividers and MFIOs
- USB clock dividers
- System clock divider
- System PLL
- MIPS CPU PLL
BUG=chrome-os-partner:31438
TEST=tested on Pisachio bring up board; UART, SPI NOR, SPI NAND, and USB
have proper functionality.
BRANCH=none
Change-Id: Ib01186a652fd59295a4cafc3ca99b94aa9564f74
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 65e68d82f34bb40ef3cfb397ecf5df0c83201151
Original-Change-Id: Ia2c31bbbfc020dc4fd71c72b877414adfdfc42a8
Original-Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/241423
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9662
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
With this descriptor added ramstage properly allocates memory
resources and creates entries in coreboot table. This also allows to
proceed to booting depthcharge, as it now can be loaded into the
existing memory.
BRANCH=none
BUG=chrome-os-partner:31438
TEST=with the set of patches applied the firmware properly finds
depthcharge in CBFS, uncompresses it and attempts to start:
...
Booting payload fallback/payload from cbfs
Loading segment from rom address 0x9b000058
code (compression=1)
New segment dstaddr 0x80124020 memsize 0x2099a0 srcaddr 0x9b000090 filesize 0xbbe
Loading segment from rom address 0x9b000074
Entry Point 0x80124038
Loading Segment: addr: 0x0000000080124020 memsz: 0x00000000002099a0 filesz: 0x0000000000000bbe
lb: [0x0000000080000000, 0x0000000080013858)
Post relocation: addr: 0x0000000080124020 memsz: 0x00000000002099a0 filesz: 0x0000000000000bbe
using LZMA
[ 0x80124020, 8012596c, 0x8032d9c0) <- 9b000090
Clearing Segment: addr: 0x000000008012596c memsz: 0x0000000000208054
dest 80124020, end 8032d9c0, bouncebuffer 8ffd4f50
Loaded segments
BS: BS_PAYLOAD_LOAD times (us): entry 129 run 34579421 exit 129
Jumping to boot code at 80124038
ERROR: dropped a timestamp entry
CPU0: stack: 9a00c800 - 9a00d800, lowest used address 9a00d498, stack used: 872 bytes
entry = 80124038
Change-Id: I15809e146407d66b04f2a97c47c961fdccb8e175
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: a1577c5532a064426a3ea88b6f7f30ccdae24eaf
Original-Change-Id: Ifed5550f2c18430e9ae06ad1ecacaa13191b5995
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/232571
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9192
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
C0_COUNT register is a free running counter clocked by the CPU
frequency divided by two. On the FPGA board it results in 25 MHz, on
real SOCs it will have to be figured out later.
Some magic addresses and numbers are used to find out if the code is
running on the FPGA board.
timestamp_get() and timer_monotonic_get() are kept in the same file.
The CPU initialization makes sure that CO COUNT is in fact enabled and
starts from zero.
BRANCH=none
BUG=chrome-os-partner:33595,chrome-os-partner:31438
TEST=with timer enabled, the startup code properly initializes UART
and prints the coreboot bootblock banner message on the serial
console.
Change-Id: I98fe330b961f677448b222917ab7d586494ed4b7
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: a7324221c1d856ac72fa2b0ab586b5ea8cab3a05
Original-Change-Id: I2d518213de939e91a35f8aea174aed76d297dd72
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/227888
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9188
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
This patch aligns pistachio to the new SoC header include scheme.
Also alphabetized headers in affected files since we touch them anyway.
BUG=None
TEST=Tested with whole series. Compiled Urara.
Change-Id: I0609b307695ba6a922384ac34dd604bffcb20692
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 0a577918babf26adf10baa0f56a7065f5659d285
Original-Change-Id: I3ed405a3efdeec28965538d19a22f2b5b8204f01
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/224503
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9335
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This patch creates a new mechanism to define the static memory layout
(primarily in SRAM) for a given board, superseding the brittle mass of
Kconfigs that we were using before. The core part is a memlayout.ld file
in the mainboard directory (although boards are expected to just include
the SoC default in most cases), which is the primary linker script for
all stages (though not rmodules for now). It uses preprocessor macros
from <memlayout.h> to form a different valid linker script for all
stages while looking like a declarative, boilerplate-free map of memory
addresses to the programmer. Linker asserts will automatically guarantee
that the defined regions cannot overlap. Stages are defined with a
maximum size that will be enforced by the linker. The file serves to
both define and document the memory layout, so that the documentation
cannot go missing or out of date.
The mechanism is implemented for all boards in the ARM, ARM64 and MIPS
architectures, and should be extended onto all systems using SRAM in the
future. The CAR/XIP environment on x86 has very different requirements
and the layout is generally not as static, so it will stay like it is
and be unaffected by this patch (save for aligning some symbol names for
consistency and sharing the new common ramstage linker script include).
BUG=None
TEST=Booted normally and in recovery mode, checked suspend/resume and
the CBMEM console on Falco, Blaze (both normal and vboot2), Pinky and
Pit. Compiled Ryu, Storm and Urara, manually compared the disassemblies
with ToT and looked for red flags.
Change-Id: Ifd2276417f2036cbe9c056f17e42f051bcd20e81
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: f1e2028e7ebceeb2d71ff366150a37564595e614
Original-Change-Id: I005506add4e8fcdb74db6d5e6cb2d4cb1bd3cda5
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/213370
Reviewed-on: http://review.coreboot.org/9283
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Tauner <stefan.tauner@gmx.at>
Reviewed-by: Aaron Durbin <adurbin@google.com>
|
|
The console interface changed in upstream, and the
driver didn't reflect that yet.
This wasn't obvious because the driver wasn't compiled
at all.
Change-Id: Id18391e62e7ebd8f5fc929838ce27bf414e364f9
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/9165
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
|
|
The Serial Peripheral Flash Interface (SPFI) block allows
communication with various devices over the SPI bus.
It uses a configurable transaction interface and it clocks
the bus according to the configured command, address, gap (aka
dummy) and data lengths.
This controller requires the SPI_ATOMIC_SEQUENCING flag set
(write and read done in the same transaction) as it cannot
directly control CS and will assert/de-assert CS at the
beginning/end of a transaction itself.
Note that the size of any transfer cannot be greater than
64KB - 1, as this is configured in a 16-bit field.
The SOC has 2 SPFI interfaces each of them providing 5 slave select
lines. SPFI 0 supports single and dual modes, SPFI 1 supports
single, dual and quad modes.
For SPFI interface 0:
- The block needs the system PLL and the following top level
SPI clock registers to be set:
- CR_cr_top_spi0clkinternal_CTRL[2:0] with division value
- CR_MIPS_CLOCK_GATE[19]: bit cr_top_SPI0CLKOUT_MIPS set
- CR_cr_top_SPI0CLKOUT_CTRL[6:0] with division value
- The following MFIO configuration parameters are also required:
Signal name Pad name MFIO mode
spim0_d0_txd MFIO_MIPS_10 0
spim0_d1_rxd MFIO_MIPS_9 0
spim0_mclk MFIO_MIPS_8 0
spim0_cs0 MFIO_MIPS_2 1
spim0_cs1 MFIO_MIPS_1 1
spim0_cs2 MFIO_MIPS_55 1
MFIO_MIPS_28 1
spim0_cs3 MFIO_MIPS_56 1
MFIO_MIPS_29 1
spim0_cs4 MFIO_MIPS_57 1
MFIO_MIMPS_30 1
For SPFI interface 1:
- The block needs the system PLL and the following top level
SPI clock registers to be set:
- CR_cr_top_spi1clkinternal_CTRL[2:0] with division value
- CR_MIPS_CLOCK_GATE[20]: bit cr_top_SPI1CLKOUT_MIPS set
- CR_cr_top_SPI1CLKOUT_CTRL[6:0] with division value
- The following MFIO configuration parameters are also required:
Signal name Pad name MFIO mode
spim1_d0_txd MFIO_MIPS_5 0
spim1_d1_rxd MFIO_MIPS_4 0
spim1_mclk MFIO_MIPS_3 0
spim1_d2 MFIO_MIPS_6 0
spim1_d3 MFIO_MIPS_7 0
spim1_cs0 MFIO_MIPS_0 0
spim1_cs1 MFIO_MIPS_1 0
MFIO_MIPS_58 1
spim1_cs2 MFIO_MIPS_2 0
MFIO_MIPS_55 2
MFIO_MIPS_31 1
spim1_cs3 MFIO_MIPS_56 2
spim1_cs4 MFIO_MIPS_57 2
BUG=chrome-os-partner:31438, chrome-os-partner:32441
TEST=Tested as bare-metal driver on Pistachio FPGA
Change-Id: I3b3e4475976e6fba58cef93b12d997ec5cb26341
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 621849942e27f7d6cf2c8ade7f2c4d18d2318b91
Original-Change-Id: Ib257eb6236bd2895281175871b4ab979660f1239
Original-Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/217320
Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/9049
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Danube has become Pistachio, let's rename all instances where this SOC
is mentioned.
BUG=none
TEST=board urara still builds
Change-Id: Iea91419121eb6ab5665c2f9f95e82f461905268e
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 58696cc7c77a70dca2bfd512d695d143e1097a78
Original-Change-Id: Ie5ede401c4f69ed5d832a9eabac008eeac6db62d
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/220401
Original-Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-on: http://review.coreboot.org/9048
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
