... this is needed for libpayload to talk to USB devices.
Change-Id: I7eb19003c9e96efb5fa7a3f97c7b15f3ef332687
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3696
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Change-Id: I5cddffc2e524aae7a31a8f94f67e03a5b7e15c82
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3695
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Change-Id: I6b28bb95c7decbe3eed33b5b5a029bee48bbe403
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3691
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
For all other CPUs, we unconditionally include the CPU Kconfig
files in the CPU directory, not in the vendor directory. Do the
same thing for the Exynos CPUs. This allows us to make CPU dependent
changes in the directory of that CPU alone.
Also, drop some unused Kconfig variables from the Exynos Kconfig
files.
Change-Id: I4e4c22a0693988834e619dd33d121bf994ed57e8
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3683
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
We saw a problem on x86 last year in which setting direction, then value,
glitched the output and caused problems. Change this code to set the output,
then the direction.
Change-Id: I3e1e17ffe82ae270eea539530368a58c6cfe0ebe
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3679
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The pinmux code for the exynos5250 was all bundled into a single, large
function which contained a switch statement that would set up the pins for
different peripherals within the SOC. There was also a "flags" parameter, the
meaning of which, if any, depended on which peripheral was being set up.
There are several problems with that approach. First, the code is inefficient
in both time and space. The caller knows which peripheral it wants to set up,
but that information is encoded in a constant which has to be unpacked within
the function before any action can be taken. If there were a function per
peripheral, that information would be implicit. Also, the compiler and linker
are forced to include the entire function with all its cases even if most of
them are never called. If each peripheral was a function, the unused ones
could be garbage collected.
Second, it would be possible to try to set up a peripheral which that function
doesn't know about, so there has to be additional error checking/handling. If
each peripheral had a function, the fact that there was a function to call at
all would imply that the call would be understood.
Third, the flags parameter is fairly opaque, usually doesn't do anything, and
sometimes has to have multiple values embedded in it. By having separate
functions, you can have only the parameters you actually want, give them
names that make sense, and pass in values directly.
Fourth, having one giant function pretends to be a generic, portable API, but
in reality, the only way it's useful is to call it with constants which are
specific to a particular implementation of that API. It's highly unlikely that
a bit of code will need to set up a peripheral but have no idea what that
peripheral actually is.
Call sights for the prior pinmux API have been updated. Also, pinmux
initialization within the i2c driver was moved to be in the board setup code
where it really probably belongs. The function block that implements the I2C
controller may be shared between multiple SOCs (and in fact is), and those
SOCs may have different pinmuxes (which they do).
Other places this same sort of change can be made are the pinmux code for the
5420, and the clock configuration code for both the 5250 and the 5420.
Change-Id: Ie9133a895e0dd861cb06a6d5f995b8770b6dc8cf
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3673
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
It might be that you want an early console in romstage before RAM is up, but
you can't or don't want to support the console all the way back in the
bootblock. By making the console in those two different environments
configurable seperately that becomes possible.
On the 5250 console output as early as the bootblock works, but on the 5420 it
only starts working in the ROM stage after clocks have been initialized.
Change-Id: I68ae3fcb4d828fa8a328a30001c23c81a4423bb8
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3671
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Not all ARM systems need "BL1", and the layout of BL* and bootblock may be
different (ex, Exynos 5250 may use a new BL1 with variable length checksum
header).
To support that better, define the real base address (and ROM offset) of boot
block, and then we can post-processing ROM image file by filling data / checksum
and any other information.
Change-Id: I0e3105e52500b6b457371ad33a9aa546acf28928
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3664
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
If we clear the framebuffer and then flush it back to memory using cache
operations, the writes are going to be full cachelines at a time. If we make
it uncacheable first, the writes will be serialized writes of whatever sized
chunks memset uses, probably 4 bytes or less.
Change-Id: I1b81731cfed00ae091ba6357451ab186d16f559e
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3655
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
At one time it seemed to be necessary to disable and then re-enable the MMU
when setting the framebuffer to be uncache-able due to bugs in the MMU
management code. Since those bugs have been fixed, this is no longer
necessary.
Change-Id: I5f7b9bd14dc9929efe1834ec9a258d388b8c94e9
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3654
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The code that allocated space for the framebuffer was adding space for a
vestigial color map which was never used. It was also passing around a
structure which was used to calculate a single value which was already known
when that structure was put together. Eliminate the extra space, and pass the
single value instead of the structure.
Change-Id: Ia6a41cefdf8b29fe7d68f9596a156eced6eb5df8
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3652
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
These pins will be driven by the internal controller which shouldn't have pull
ups or downs in the pin fighting with them.
Change-Id: I579aed84ace45d8f5f1d3ca64c064d98de842b57
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3649
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
- Guard console_init() with CONFIG_EARLY_CONSOLE in bootblock
- Don't initialize console twice in the bootblock
- remove printk in memory init that would mess up the UART
- unconditionally run console_init() in romstage, as it is
also unconditionally run in the bootblock.
Change-Id: I8f0d60877433162367074d0e55e01f935fd81f8e
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3647
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The Exynos GPIO code has three different APIs that, unfortunately,
were widely used throughout the code base. This patch is cleaning
up the mess.
Change-Id: I09ccc7819fb892dbace9693c786dacc62f3f8eac
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3643
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
When starting the Exynos5250 port, a lot of unneeded u-boot code
was imported. This is an attempt to get rid of a lot of unneeded
code before the port is used as a basis for further ARM ports.
There is a lot more that can be done, including cleaning up the
5250's Kconfig file.
Change-Id: I2d88676c436eea4b21bcb62f40018af9fabb3016
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3642
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Change-Id: Ice28114e5f53f510d305cd85d095044e2f4bd7b2
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/3740
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: build bot (Jenkins)
It turns out that the exynos5-common code previously imported from
u-boot is not common code at all but very specific to the 5250 and
not compatible with the 5450. Hence, unify the directories exynos5250
and exynos5-common. We will try to factor out common code while
progressing with the 5450 port.
Change-Id: Iab595e66fcd01eda8365c96fb8bef896f7602f03
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3641
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This patch unfortunately incorporates a number of changes,
all of which are making future ARM ports easier.
- drop cruft that came in with u-boot
- move serial console from mainboard Kconfig to Exynos Kconfig
- factor out non-board specific wakeup code
- move generic bootblock code from mainboard to Exynos
- actually call arch_cpu_init()
- remove dead code
- fix up copyright messages
- remove snow_ prefix from a lot of code to reduce the noise
when creating a new mainboard based on that code.
Change-Id: Ic05326edf5a7e1a691c5ff841a604cb9e351b562
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3640
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
build-snow got broken when the snow makefile improved. So fix it.
While we're at it, create a script like the update-microcode
scripts that gets the bl1. I thought about making this a common
script but the various names and paths always evolve, leaving
me thinking it's not worth it. This script is just a
piece of the snow build script.
Change-Id: I65c0f8697a978c62fe12533c4f0152d14dbaefda
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/3238
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
This re-introduces 2fde966 (http://review.coreboot.org/#/c/3177/)
which was reverted due to unsatisfied dependencies.
time.h We Hardly Knew Ye.
This deprecates time.h which is currently only used by Exynos5250 and
Snow. The original idea was to try and unify some of the various timer
interfaces and has been supplanted by the monotonic timer API.
timer_us() is now obsolete. timer_start() is now mct_start() and
is exposed in exynos5250/clk.h.
Change-Id: I8e60105629d9da68ed622e89209b3ef6c8e2445b
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3201
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This goes thru various call sites where we used timer_us() and updates
them to use the new monotonic timer API.
udelay() changed substantially and now gracefully handles wraparound.
Change-Id: Ie2cc86a4125cf0de12837fd7d337a11aed25715c
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3176
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
This reverts commit 2fde9668b4
Somehow this got merged before its dependencies. 3190 must be merged first, followed by 3176. However 3190 will fail while this patch is in. So the situation can't correct itself.
Reverting this until the other two go in.
Change-Id: I176f37c12711849c96f1889eacad38c00a8142c4
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3195
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
time.h We Hardly Knew Ye.
This deprecates time.h which is currently only used by Exynos5250 and
Snow. The original idea was to try and unify some of the various timer
interfaces and has been supplanted by the monotonic timer API.
timer_us() is now obsolete. timer_start() is now mct_start() and
is exposed in exynos5250/clk.h.
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I14ebf75649d101491252c9aafea12f73ccf446b5
Reviewed-on: http://review.coreboot.org/3177
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This implements the new monotonic timer API using the global
multi-core timer (MCT).
Change-Id: Id56249ff5d3e0f85808f5754954c83c0bc75f1c1
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3175
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
This makes the intermediate rule visible so BL1 gets automatically
placed in the final image.
Change-Id: Iffb0268e5bbcbe135f2d39863ed64fa302409a22
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3141
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
The "wakeup" procedure will be shared by bootblock and romstage for different
types of resume processes.
Note, this commit does not include changes in romstage/bootblock to enable
suspend/resume feature. Simply adding functions to handle suspend/resume.
Verified by successfully building and booting Google/Snow firmware image.
Change-Id: I17a256afb99f2f8b5e0eac3393cdf6959b239341
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/3129
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
To support suspend/resume, PHY control must be reset only on normal boot
path. So add a new param "mem_reset" to specify that.
Verified to boot successfully on Google/Snow.
Change-Id: Id49bc6c6239cf71a67ba091092dd3ebf18e83e33
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/3128
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This adds support for display bring-up on Snow. It
includes framebuffer initialization and LCD enable functions.
Change-Id: I16e711c97e9d02c916824f621e2313297448732b
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3116
Tested-by: build bot (Jenkins)
This makes sure that the product ID (PRO_ID) register can be read
when the OS kernel is figuring out what kind of CPU it's running on.
For historical reference, the original U-Boot code seems to have
worked basically by accident here. The hardware has a quirk where by
reading the value before gating the IP block keeps the value
persistent. U-Boot reads the chip ID early on to distinguish between
chip family, but we do not mix code the same way so we do not read
the chip ID. Since the value has been read before the clock gating
happens, the value remains available for the kernel to use during the
decompression stage. We don't want to rely on that behavior when using
coreboot. Instead the kernel should gate unused IPs.
(credit to Gabe for finding symptom in the kernel)
Change-Id: Iaa21e6e718b9000b5558f568020f393779fd208e
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3121
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
This simple error led to corrupted graphics.
How annoying.
Change-Id: I2295c0df0f1d16014a603dc5d66bd4d72f3fb7c9
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/3120
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: build bot (Jenkins)
We neglected to copy xres and yres out; now we do.
Change-Id: Icc4a8eb35799d156b11274f71bcfb4a1d10e01e3
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/3111
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: build bot (Jenkins)
This updates the Exynos TMU code for coreboot:
- Remove dependency on device tree
- Add Makefile entries
Change-Id: I55e1b624d7c7b695b1253ec55f6ae3de8dc671bc
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3107
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
This moves the prototype for power_enable_hw_thermal_trip() to
a generic location so it can be used by generalized thermal
management code. The implementation will still be CPU-specific.
Change-Id: Iae449cb8c72c8441dedaf65b73db9898b4730cef
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3105
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
This gets rid of the clock-tick based sdelay in favor of udelay().
udelay() is more consistent and easier to work with, and this allows
us to carry one less variation of timers (and headers and sources...).
Every 1 unit in the sdelay() argument was assumed to cause a delay of
2 clock ticks (@1.7GHz). So the conversion factor is roughly:
sdelay(N) = udelay(((N * 2) / 1.7 * 10^9) * 10^6)
= udelay((N * 2) / (1.7 * 10^3))
The sdelay() periods used were:
sdelay(100) --> udelay(1)
sdelay(0x10000) --> udelay(78) (rounded up to udelay(100))
There was one instance of sdelay(10000), which looked like sort of a
typo since sdelay(0x10000) was used elsewhere. sdelay(10000) should
approximate to about 12us, so we'll stick with that for now and leave
a note.
Change-Id: I5e7407865ceafa701eea1d613bbe50cf4734f33e
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3079
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The types are (esp. int) are confusing at times as to size.
Make them definite as to size.
Change-Id: Id7808f1f61649ec0a3403c1afc3c2c3d4302b7fb
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/3103
Tested-by: build bot (Jenkins)
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Add a microsecond timer, its declaration, the function to start it,
and its usage. To start it, one calls timer_start(). From that point
on, one can call timer_us() to find microseconds since the timer was
started.
We show its use in the bootblock. You want it started very early.
Finally, the delay.h change having been (ironically) delayed, we
create time.h and have it hold one declaration, for the timer_us() and
timer_start() prototype.
We feel that these two functions should become the hardware specific
functions, allowing us to finally move udelay() into src/lib where it
belongs.
Change-Id: I19cbc2bb0089a3de88cfb94276266af38b9363c5
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/3073
Tested-by: build bot (Jenkins)
Properly use the chip settings when configuring the CPU,
at this point being purely graphics.
Change-Id: I9bc2d32c1037653837937b314e4041abc0024835
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/3054
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
This enables type checking for safety as to help prevent errors like
http://review.coreboot.org/#/c/3038/ . Now compilation fails if the
wrong type is passed into readb/readw/readl/writeb/writew/writel
or other macros in io.h.
This also deprecates readw/writew. The previous definition was 16-bits
which is incorrect since wordsize on ARMv7 is 32-bits and there was
only 1 instance of writew (#if 0'd anyway). Going forward we should
always use read{8,16,32} and write{8,16,32} where N specifies the
exact length rather than relying on ambiguous definition of wordsize.
Since many macros relied on __raw_*, which were basically the same
(minus data memory barrier instructions), this patch also gets rid
of __raw_*. There were parts of the code which ended up using these
macros consecutively, for example:
setbits_le32(®s->ch_cfg, SPI_CH_RST);
clrbits_le32(®s->ch_cfg, SPI_CH_RST);
In such cases the safe versions of readl() and writel() should be
used anyway.
Note: This also fixes two dubious casts as to avoid breaking
compilation.
Change-Id: I8850933f68ea3a9b615d00ebd422f7c242268f1c
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3045
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This adds a missing address-of operator. This was a subtle bug that
didn't seem to cause problems at first since the serial console
appeared to work. However it caused an imprecise external abort which
became apparent later on when aborts were unmasked in the kernel via
the CPSR_A bit.
(credit goes to Gabe Black for finding this)
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I80a33b147d92d559fa8fefbe7d5642235deb9aea
Reviewed-on: http://review.coreboot.org/3038
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This moves highly board-specific code out from the Exynos5250
power_init() into Snow's romstage.c. There's no reason the CPU-
specific code should care about which PMIC we are using and
which bus it is on.
Change-Id: I52313177395519cddcab11225fc23d5e50c4c4e3
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3034
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Display hardware is part of this SOC, and we need to be able
to set certain variables in devicetree.cb. This chip file
contains the initial things we think we need to set.
Change-Id: I16f2d4228c87116dbeb53a3c9f3f359a6444f552
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/3031
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: build bot (Jenkins)
This adds a new function to configure L2 cache for the
exynos5250 and deprecates the old function.
Change-Id: I9562f3301aa1e2911dae3856ab57bb6beec2e224
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2949
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Tested-by: build bot (Jenkins)
This moves the ram resource allocation into cpu_init() so that we
no longer rely on declaring a domain in devicetree.cb (which is kind
of weird for this platform). This does not cause any actual changes
to the coreboot memory table, and paves the way for further updates
to Snow's devicetree.
Change-Id: I141277f59b5d48288f409257bf556a1cfa7a8463
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2923
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This reverts commit 9427ca151e
Looks like we were a bit too anxious to see this one get in. The devicetree.cb change seems to have broken things.
coreboot memory table:
0. 0000000050000000-000000005000ffff: RESERVED
1. 00000000bff00000-00000000bfffffff: CONFIGURATION TABLES
2. 0000014004000000-00000140044007ff: RESERVED
Before this patch:
coreboot memory table:
0. 0000000040000000-00000000bfefffff: RAM
1. 00000000bff00000-00000000bfffffff: CONFIGURATION TABLES
Change-Id: I618e4f1976265d56cfd6a61d0c5736c55a0f3cec
Reviewed-on: http://review.coreboot.org/2914
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
This does NOT turn on the graphics.
The device tree has been changed enough so that, at the very least, the correct
functions are called at the correct time, with the correct paramaters. We
decided to yank the I2C entries as they did not obvious function and might
not even have been correct.
Not working, seemingly, but we need to add a 4M resource for
memory, and it seems it needs to be fixed at the address shown.
This address was chosen from current hardware.
We realized that the display code should be part of the cpu -- that's how
the hardware works!
Change-Id: Ied65a554f833566be817540702f79a02e7b6cb6e
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2615
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
This adds a new API for cache maintenance operations. The idea is
to be more explicit about operations that are going on so it's easier
to manage branch predictor, cache, and TLB cleans and invalidations.
Also, this adds some operations that were missing but required early
on, such as branch predictor invalidation. Instruction and sync
barriers were wrong earlier as well since the imported API assumed
we compield with -march=armv5 (which we don't) and was missing
wrappers for the native ARMv7 ISB/DSB/DMB instructions.
For now, this is a start and it gives us something we can easily use
in libpayload for doing things like cleaning and invalidating dcache
when doing DMA transfers.
TODO:
- Set cache policy explicitly before re-enabling. Right now it's left
at default.
- Finish deprecating old cache maintenance API.
- We do an extra icache/dcache flush when going from bootblock to
romstage.
Change-Id: I7390981190e3213f4e1431f8e56746545c5cc7c9
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2729
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The original code attempted to reserve a space in RAM for coreboot to
remain resident. This turns out not to be needed, and breaks things
for the kernel since the exynos5250-smdk5250 kernel device tree starts
RAM at 0x40000000.
(This patch was originally by Gabe, I'm just uploading it)
Change-Id: I4536edaf8785d81a3ea008216a2d57549ce5edfb
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2698
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
This enables branch prediction. We can probably find a better place
to do this, but for now we'll do it in snow's romstage main().
Change-Id: I86c7b6bc9e897a7a432c490fb96a126e81b8ce72
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2701
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
PS_HOLD gets set in exynos' power_init().
Change-Id: Ib08e0afcad23cbd07dc7e3727fd958a1bc868b5a
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2700
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Call the power_init() function. We appear to have forgotten about it
when deprecating lowlevel_init_subsystems(), but it didn't seem to
cause problems until we got to doing more interesting stuff recently.
There are some clean-ups to do from the original code, such as not
attempting to configure I2C from PMIC code, which we'll get around
to in follow-up patches.
(Credit to Gabe for spotting this)
Change-Id: I6a59379e9323277d0b61469de9abe6d651ac5bfb
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2699
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
OK, this is tl;dr. But I need to write this in hopes we make
sure we don't put code like this into coreboot. Ever.
Our excuse in this case is that it was imported, not obviously wrong,
and easily changed. It made sense to get it in, make it work, then
do a cleanup pass, because changing everything up front is almost
impossible to debug.
The exynos code has bunch of base register values, e.g.
These are base addresses of things that look like a memory-mapped
struct. To get these to a pointer, they created the following macro,
which creates an inline function.
static inline unsigned int samsung_get_base_##device(void) \
{ \
return cpu_is_exynos5() ? EXYNOS5_##base : 0; \
}
And then invoke it 31 times in a .h file, e.g.:
SAMSUNG_BASE(clock, CLOCK_BASE)
to create 31 functions.
And then use it:
struct exynos5_clock *clk =
(struct exynos5_clock *)samsung_get_base_clock();
OK, what's wrong with this? It's easier to ask what's right with it. Answer: nothing.
I have a long list of what's wrong, and I may leave some things out,
but here goes:
1. the "function" can return a NULL if we're not on exynos5. Most uses of the code
don't check the return value.
2. And why would this function be running, if we're not on an exynos5? Why compile it in?
3. Note the cast everywhere a samsung_get_base_xxx is used.
The function returns an untyped variable, requiring the *user* to get two
things right: the cast, and the function invocation. One can replace that _clock(); with
_power(); in the code above, and they will be referencing the wrong registers, and
they'll never get an error!
We have a C compiler; use it to type data.
4. You're generating 31 functions using cpp each and every time the file is included.
The C compiler has to parse these each time. It's not at all like a simple cpp
macro which is only generated on use.
5. You can't tags or etags this code
6. In fact, any kind of analysis tool will be unable to do anything with this cpp magic.
That's only a partial list.
So what's the right way to do it? Just make typed constants, viz:
Or, since I expect people will want the lower case function syntax, I've left
it that way:
Now we've got something that is efficient, and we don't even need to protect with
any more.
Hence this change. We've got something that is type checked, does not require users to
cast on each use, will catch simple programming errors, can be analyzed with standard tools,
and builds faster.
So if we make a mistake:
struct exynos5_clock *clk =
samsung_get_base_adc();
We'll see it:
src/cpu/samsung/exynos5250/clock.c: In function 'get_pll_clk':
src/cpu/samsung/exynos5250/clock.c:183:3: error: initialization from incompatible pointer type [-Werror]
which we would not have seen before.
As a minor benefit, it shaves most of a second off the compilation.
Change-Id: Ie67bc4bc038a8dd1837b977d07332d7d7fd6be1f
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2582
Tested-by: build bot (Jenkins)
In the file `COPYING` in the coreboot repository and upstream [1]
just one space is used.
The following command was used to convert all files.
$ git grep -l 'MA 02' | xargs sed -i 's/MA 02/MA 02/'
[1] http://www.gnu.org/licenses/gpl-2.0.txt
Change-Id: Ic956dab2820a9e2ccb7841cab66966ba168f305f
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2490
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
For whatever reason tabs got inserted in the license header text.
Remove one occurrence of that with the following command [1].
$ git grep -l 'MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.'$'\t' | xargs sed -i 's,MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.[ ]*,MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.\ \ ,'
[1] http://sed.sourceforge.net/grabbag/tutorials/sedfaq.txt
Change-Id: Iaf4ed32c32600c3b23c08f8754815b959b304882
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2460
Tested-by: build bot (Jenkins)
Reviewed-by: Jens Rottmann <JRottmann@LiPPERTembedded.de>
Reviewed-by: Cristian Măgherușan-Stanciu <cristi.magherusan@gmail.com>
The SDRAM base is fixed in hardware. It makes no sense to make it configurable.
The TEXT start is a magic number that should also be fixed, not settable.
Change-Id: Ie44cc5c8da1dc38fc00eb602c4a295b045ca5364
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2465
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Payloads, by design, can return. There's lots of mechanism in the payload code
to support it, and the chooser payload relies on it. Hence, we should not mark
the function call in exit_stage as noreturn.
Not all ARM have unified caches, and it's not always easy to tell what
to do. So we are very paranoid. Before we call between stages, we
should carefully flush the dcache to memory and invalidate the icache.
This may be more than is necessary on all architectures but it
doesn't really hurt for the most part.
So compile cache management code into all stages, and call the
flush dcache/invalidate icache from all stages.
Change-Id: Ib9cc625c4dfd2d7d4b3c69a74686cc655a9d6484
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2462
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This adds necessary device operations to add CPU and RAM resources.
Change-Id: Ief8f66627ef37f4fa786bfc3f7899529d3e5b037
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2419
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This cleans out some obsolete Kconfig variables pertaining to IRAM
usage.
Change-Id: Ie53f5f7204eadc3a3dddc739d2b4b6237242b198
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2417
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
This patch fixes up the usage of stack pointer and regions.
The current approach only works by coincidence, so this fixes a few
things at once to get it into a working state and allow us to use
checkstack() again:
- Add a STACK_SIZE Kconfig variable. Earlier on it was evaluated to 0.
- Assign _stack and _estack using CPU-specific Kconfig variables since
it may reside elsewhere in memory (not necessarily DRAM).
- Make the existing IRAM stack variables more useful in this context.
Change-Id: I4ca5b5680c9ea7e26b1b2b6b3890e028188b51c2
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2416
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
s5p-common mostly contained duplicate files, drop the whole directory
and merge the few pieces that we are using into exynos5-common.
Change-Id: I5f18e8a6d2379d719ab6bbbf817fe15bda70d17f
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2405
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
We don't need SHA in coreboot.
Change-Id: I1985d5e2c74fac39ff9dcdba4c23bb34fa857ec7
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2390
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: build bot (Jenkins)
This removes some files leftover from the initial port. Some are
leftover from U-Boot and some were leftover from the skeleton code
derived from x86.
There's a bit more that we'll get in another sweep.
Change-Id: I325793ecb902b3b9430dcf531714ce025d201de6
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2380
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
RAMBASE and RAMTOP are leftovers from the x86 port and do not apply
the same way on ARM platforms. On x86 they refer to the low memory
region where coreboot tables reside.
However on ARM we don't have such a region which is architecturally
defined. So instead we'll use the CPU-defined DRAM base address and
the mainboard-defined DRAM size.
This also has the pleasant side-effect of fixing the coreboot tables
to not clobber ramstage code...
Change-Id: I5548ecf05e82f9d9ecec8548fabdd99cc1e39c3b
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2351
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
For Exynos/snow, cpu_info and power modules and also some parts of
the GPIO API (which require timer and pwm modules) are not used in the
current bootblock. Clock init only needs to be used if early console
is enabled.
Now our bootblock is 22420 bytes with early serial console and 11192
bytes without. Those include the 8KB BL1 region.
Change-Id: I9c958dafb9cf522df0dcfbef373ce741aa162544
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2322
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This places the .id section toward the lower region of the coreboot
image, before the bootblock. It's easier for humans to find by dumping
the image and it also eliminates ID_SECTION_OFFSET which is currently
the upper bound on our image size.
Change-Id: I7d737b901dac659ddf9aa437cee5dc32f1080546
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2345
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The Kconfig variable indicates KB, but the number used was bytes.
Let's just assume KB is correct for now.
Change-Id: I910c126104f0222fc48b70a18df943f2afddeca3
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2341
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This adds a BL1_SIZE_KB config variable so that we can get rid of
some magic constants.
Change-Id: I9dbcfb407d3f8e367be5d943e95b032ce88b0ad0
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2332
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Use same console initialization procedure for all ARM stages (bootblock,
romstage, and ramstage):
#include <console/console.h>
...
console_init()
...
printk(level, format, ...)
Verified to boot on armv7/snow with console messages in all stages.
Change-Id: Idd689219035e67450ea133838a2ca02f8d74557e
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2301
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
For Exynos platforms, the UART component on pinmux must be first selected and
configured. This should be done as part of UART console initialization.
Note, that the current implementation hard-codes the device index as UART3,
while the base port can be assigned to different device in Kconfig. This will be
fixed later.
Verified to work on armv7/snow.
Change-Id: Ie63e76e2dac09fec1132573d1b0027fce55333a1
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2315
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
The power_init is not required on Exynos 5250 (snow) in bootblock stage. To get
a cleaner and faster bootblock, we can remove it.
Note, power_init internally calls max77686 and s3c24x0_i2c, so both files are
also removed.
Verified to boot on armv7/snow.
Change-Id: I5b15dfe5ac7bf4650565fea0afefc94a228ece29
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2317
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Remove duplicated / testing code and share more driver for bootblock, romstage
and ramstage.
The __PRE_RAM__ is now also defined in bootblock build stage, since bootblock is
executed before RAM is initialized.
Change-Id: I4f5469b1545631eee1cf9f2f5df93cbe3a58268b
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2282
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
"SPL" from U-Boot is deprecated by bootblock in coreboot/arm, so we don't need
it anymore.
Change-Id: Id16877075d0b870839a10160073ad70777a2af0a
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2297
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
For arm/snow, current bootblock is larger than previously assigned CBFS offset
and will fail to boot. To prevent this happening again in future, cbfstool now
checks if CBFS will overlap bootblock.
A sample error message:
E: Bootblock (0x0+0x71d4) overlap CBFS data (0x5000)
E: Failed to create build/coreboot.pre1.tmp.
arm/snow offset is also enlarged and moved to Kconfig variable.
Change-Id: I4556aef27ff716556040312ae8ccb78078abc82d
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2295
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
This patch moves ARM core and DRAM timing functions around to simplify
the dependencies for system_clock_init().
The original code was architected such that the system_clock_init()
function called other functions to obtain core and memory timings.
Due to the way memory timing information must be obtained on Snow,
which entails decoding platform-specific board straps, the bottom-
up approach resulted in having the low-level clock init code
implicitly depend on board and vendor-specific info:
main()
->system_clock_init()
-> get_arm_ratios()
-> CPU-specific code
-> clock_get_mem_timings()
-> board_get_revision()
-> read GPIOs (3-state logic)
-> Decode GPIOs in a vendor-specific manner
-> Choose memory timings from module-specific look-up table
...then proceed to init clocks
...come back to main()
The new approach gathers all board and vendor-specific info in a
more appropriate location and passes it into system_clock_init():
main()
-> get_arm_ratios()
-> CPU-specific code
-> get_mem_timings()
-> board_get_config()
-> read GPIOs (3-state logic)
-> Decode GPIOs in a vendor-specific manner
-> Choose memory timings from module-specific look-up table
-> system_clock_init()
...back to main()
Change-Id: Ie237ebff76fc2d8a4d2f4577a226ac3909e4d4e8
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2271
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This gets rid of a bunch of copy + pasted GPIO code.
Change-Id: I548b2b5d63642a9da185eb7b34f80cbebf9b124f
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2288
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Move the ID section again due to bootblock bloat. So long
as it's within the first 32K of our address space, we're good.
TODO:
1. Place ID section near start of ROM to avoid this issue.
2. Reduce bootblock bloat.
3. Make bootblock debugging a Kconfig option.
Change-Id: I3f0764a3345a8cbbafcc15e4d06c38cd6327758c
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2287
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This gets rid of a bunch of copy + pasted code from Exynos UART
files.
Change-Id: I9fbb6d79a40a338c9fdecd495544ff207909fd37
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2286
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
Some header content got duplicated during the initial porting
effort. This moves generic UART header stuff to exynos5-common
and leaves exynos5250 #defines in the AP-specific UART header.
Change-Id: Ifb6289d7b9dc26c76ae4dfcf511590b3885715a3
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2285
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This file has mostly (but not entirely) been replaced by coreboot
stage files. We'll keep it around for a bit longer as a reference,
but in the meantime we'll stop compiling it as to avoid comptilation
issues as we change other parts of the code.
Change-Id: I669fb1e5a1517f35979590957d581bd33df53d29
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2269
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This removes some duplicate code from Snow's mainboard bootblock
by utilizing the bootblock build class.
Change-Id: I153247370a8c5127260082dcdca3ebdc5e104fb8
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2270
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This adds a helper function to read only a single GPIO which uses
3-state logic. Examples of this typically include board straps which
are used to provide mainboard-specific information at the hardware-
level, such as board revision or configuration options.
This is part of a larger clean-up effort for Snow. We may want to
genericise this for other CPUs in the future.
Change-Id: Ic44f5e589cda89b419a07eca246847e9ce7dcd8d
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2266
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The cpu_is_exynos5() macro seems broken at the moment, so skip it.
The macro is superfluous and will probably be replaced eventually,
but at least this will un-break usage sites.
Change-Id: Ibd360cbfa18047ad8a3488d4f24c3fc4d7415eba
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2264
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
Discovering memory timings is a bit complicated due to the need
to obtain and decode board config. To make things worse, the imported
code makes a mess of dependencies. Hard-code the memory timings
for now to get us further along (the instability won't really matter
until we're loading depthcharge anyway).
Change-Id: I1f341ad597db0c31ed4ae6bc703fc22b6596a803
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2256
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This is a minor set of changes to get DDR3 going.
Move compilation of DDR3 startup to the romstage. Fix a prototype that
was missing a void. Remove a function that is overly flexible, and
even though it is overly flexible only actually can handle one type of
RAM. Mainboards only support one type of DRAM, so create a function
to explicitly initialize the type of DDR we have -- DDR3.
With these changes, and the previous changes, google snow is ready to run
the ramstage.
Change-Id: I37e0ab0d2dbc1dd121fb175386a46bc2fb1285e5
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2224
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Summary:
Isolate CBFS underlying I/O to board/arch-specific implementations as
"media stream", to allow loading and booting romstage on non-x86.
CBFS functions now all take a new "media source" parameter; use
CBFS_DEFAULT_MEDIA if you simply want to load from main firmware.
API Changes:
cbfs_find => cbfs_get_file.
cbfs_find_file => cbfs_get_file_content.
cbfs_get_file => cbfs_get_file_content with correct type.
CBFS used to work only on memory-mapped ROM (all x86). For platforms like ARM,
the ROM may come from USB, UART, or SPI -- any serial devices and not available
for memory mapping.
To support these devices (and allowing CBFS to read from multiple source
at the same time), CBFS operations are now virtual-ized into "cbfs_media". To
simplify porting existing code, every media source must support both "reading
into pre-allocated memory (read)" and "read and return an allocated buffer
(map)". For devices without native memory-mapped ROM, "cbfs_simple_buffer*"
provides simple memory mapping simulation.
Every CBFS function now takes a cbfs_media* as parameter. CBFS_DEFAULT_MEDIA
is defined for CBFS functions to automatically initialize a per-board default
media (CBFS will internally calls init_default_cbfs_media). Also revised CBFS
function names relying on memory mapped backend (ex, "cbfs_find" => actually
loads files). Now we only have two getters:
struct cbfs_file *entry = cbfs_get_file(media, name);
void *data = cbfs_get_file_content(CBFS_DEFAULT_MEDIA, name, type);
Test results:
- Verified to work on x86/qemu.
- Compiles on ARM, and follow up commit will provide working SPI driver.
Change-Id: Iac911ded25a6f2feffbf3101a81364625bb07746
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2182
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
At some point we did a lot of cleanup to replace bare 'unsigned'
with 'unsigned int'. Do that work for this imported code as well.
At some point, we may find we can shrink these 'int's to something
smaller, thought I very much doubt it's worth the trouble.
Change-Id: Ic3da491c0188c56c836f8b9c4c8f26a31b4b3573
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2223
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
It can be handy to have debug prints as DRAM is started up, so that
in the case of failure (does that ever happen?) you've got some
idea where it failed.
This patch adds some DEBUG_SPEW prints to the DDR3 code. I am doing this
as its own CL because we may find we want to revert it. That's unlikely
but it is not impossible if we skew the timing in some way.
This code works for some trivial DRAM tests.
Change-Id: I57e8d2a2d8df6b8ec8cd0d414681fc513e9999e3
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2222
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
The timing array is crucial to proper operation of DRAM.
Getting a valid pointer to it is hence very important. Unfortunately,
the constants chosen for the vendor were '1', and '2', (this in a
32-bit word) which in a debug print makes it almost impossible to tell
if you've got a misaligned pointer. Note: coreboot people did not
choose them :-)
So, give them values which are extremely unlikely to occur elsewhere
in the array (or in memory, for that matter).
Given the frequency with which this check occurs, i.e. once, I would
much prefer strings but I expect I'd get shouted down on that
one. Constants in this case are an almost useless optimization but
we'll go with them for now. Note no space is saved by not using
strings: there's an entire function somewhere devoted to mapping the
enum to a string!
Debug prints of pointers to structs in this array are now far more
useful than they were.
See snarky comment in the code (left there to make sure nobody gets
tempted to get fancy again). Comment now less snarky.
This is tested on google snow to the point that the DRAM works.
Change-Id: I30bc44719f321f791fd82ded60e29393399d9e3d
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2221
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: build bot (Jenkins)
The previous incarnation did not use all of mmu_setup, which meant
we did not carefully disable things before (possibly) changing them.
This code is tested and works, and it's a bit of a simplification.
Change-Id: I0560f9b8e25f31cd90e34304d6ec987fc5c87699
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2204
Reviewed-by: Peter Stuge <peter@stuge.se>
Tested-by: build bot (Jenkins)
This patch does a few things to get us into romstage:
- Add romstage as a stage (a later patch adds it as a binary, which
is probably wrong). The Makefile magic is complex enough that we
let it build the XIP file for now, but we no longer use it.
- Replace findstage with loadstage. Loadstage will find a stage,
load the code to memory, and zero the remaining part of memory.
Now we can link the romstage to go anywhere!
- Eliminate magic offsets from code/ldscripts and centralize Kconfig
variables in src/cpu/samsung/exynos5250/Kconfig.
- Tidy up code and serial output
Change-Id: Iae4d2f9e7f429cb1df15d49daf9a08b88d75d79d
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2174
Tested-by: build bot (Jenkins)
This is the bloated Snow bootblock which includes:
- SPI driver
- UART, including requisite I2C, Maxim PMIC, and clock config code.
- Adjustments for magic offsets (id section, stack pointer address)
This is just a temporary solution until we have romstage loading.
Once that happens, we'll rip out all but the code necessary for
copying SPI ROM content into SRAM.
Change-Id: I2a11e272eb9b6f626b5d9783eabb4a720a1d06be
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2170
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This adds a stub for bootblock_cpu_init() for exynos5250. It will
eventually contain code to copy ROM content from SPI to SRAM.
Change-Id: I26ee62a1e701013f38f76f200579faa680530860
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2138
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This lays out the groundwork for using a proper bootblock on ARM.
Currently we bypass the bootblock entirely and go straight to
romstage. However we want to utilize CBFS to maximize flexibility
of placing code without relying on a lot of magic numbers which
will break depending on the SoC in use.
Change-Id: I9cc2a8191d2db38b27b6363ba673e5a360de9684
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2118
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This is the first lowlevel init routine that gets called in romstage.
It's fugly and needs a lot of clean-up, but does the job for now.
Change-Id: Id54bf4f1c3753bcbed5f6b5eeb4b48bc3b41ce93
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2133
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This cannot be used until we get the BL1 mess sorted out.
Change-Id: I2490addb31256e27caa89ebb5b1501296e6903bd
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2132
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
