| Age | Commit message (Collapse) | Author |
|---|
|
The binary is taken from blobs, so the script should live over
there, too.
Change-Id: I3cc0aabc846c352ccf5cb348132b320a37f273a6
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: https://review.coreboot.org/12725
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
|
|
There's now room for other repositories under 3rdparty.
Change-Id: I51b02d8bf46b5b9f3f8a59341090346dca7fa355
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10109
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
To move 3rdparty to 3rdparty/blobs (ie. below itself
from git's broken perspective), we need to work around
it - since some git implementations don't like the direct
approach.
Change-Id: I1fc84bbb37e7c8c91ab14703d609a739b5ca073c
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10108
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The Exynos family and most ARM products are SoC, not just CPU.
We used to put ARM code in src/cpu to avoid polluting the code base for what was
essentially an experiment at the time. Now that it's past the experimental phase
and we're going to see more SoCs (including intel/baytrail) in coreboot.
Change-Id: I5ea1f822664244edf5f77087bc8018d7c535f81c
Reviewed-on: https://chromium-review.googlesource.com/170891
Tested-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Commit-Queue: Hung-Te Lin <hungte@chromium.org>
(cherry picked from commit c8bb8fe0b20be37465f93c738d80e7e43033670a)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6739
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Peppy had some issues with FUI. We decided it was time to create
peppy-specific gma.c and i915io.c files. Using yabel and the i915tool,
we generated a replay attack, then interpolated against the slippy
i915io.c to get something working.
Also, in preparation for moving code out of the mainboard gma.c to
generic driver code, we got rid of some hardcodes in the mainboard
gma.c that have no business being there. The worst were the
computation of gmch_[m,n] and it turns out that we had some
long-standing bugs related to confusion about 'bpp'. I've killed the
word bpp everywhere I could because there are at least 3 things that
correspond to bpp. We now have framebuffer, pipe, and panel bpp. The
names are long because I want to avoid all the mistakes we've all been
making in the last year :-) Sadly, that means a lot of changes not just
peppy-related, but they are simple and in a good cause.
The test pattern generation is driven by a global variable in
mainboard/peppy/gma.c. I've found in the past that it's very useful
to have a function like this available, as one can activate it while
using a jtag debugger: halt at the right place in ramstage, set the
variable to 1, continue. It's not enough code to worry about always
including.
The last hard-codes for M and N registers are gone, and the function
to set from generic intel_dp.c code works. To avoid screen trash on a
dev mode boot, which we liked but nobody else did :-), we now take the
time to put a pleasing background color that sort of doubles as a
power LED.
Rough timing is ramstage start is at 2.2, and dev setup is done at
3.3. These new platforms are depressingly slow to boot. Rom init alone
is taking 1.9 seconds. 13 years ago it was 3 seconds from power on to bash
prompt. These CPUs are at least 10x faster and take much longer to get going.
Future work, once we get this through, is to move more functions to the
intel driver, and combine the mainboard i915io.c into the mainboard gma.c.
That separation only existed because i915io.c was generated by a tool, and it
had lots of ugliness. Most ugliness is gone.
Old-Change-Id: I6a6295b423a41e263f82cef33eacb92a14163321
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: https://chromium-review.googlesource.com/170013
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Ronald Minnich <rminnich@chromium.org>
Tested-by: Ronald Minnich <rminnich@chromium.org>
Reviewed-by: Furquan Shaikh <furquan.m.shaikh@gmail.com>
(cherry picked from commit 8cdaf73e3602e15925859866714db4d5ec6c947d)
snow: Fix a typo in devicetree.cb that was breaking the snow build.
A typo in a recent change broke the snow build.
Old-Change-Id: I93074e68eb3d21510d974fd8e9c63b3947285afd
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/171014
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 154876c126a6690930141df178485658533096d2)
Squashed a fix into the initial patch and updated nehalem/gma.c
to have a non-static gtt_poll.
Change-Id: I2f4342c610d87335411da1d6d405171dc80c1f14
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6657
Tested-by: build bot (Jenkins)
|
|
The ARM Makefile was copied from x86 and then modified, and as a result it
was carrying a lot of baggage. On top of that, the extra complication made it
inflexible, and we need a lot of flexiblity in order to support the fact that
the Tegra124 starts on an ARMv4 coprocessor instead of one of the ARMv7 main
CPUs.
Change-Id: Ia6ddc27619bdb51e152ad0c628ad6f3037c103ce
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/171017
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 512d942788336c8d52470135b43ee4e6a1c95f6c)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6709
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
|
|
The INTERMEDIATE variable was used to hook dd-ing the BL1 into the image for
Exynos SOCs, but we can do that directly without having a special hook.
Change-Id: I434506b52ca4ea1d01e25a785cbfe66dfdea21c4
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/170921
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 8db03c387ad654227d064e2a7fa5ecf09d07e3c5)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6714
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
|
|
Trustzone needs to be initialized/disabled both on boot and on wake, so it
needs to be done before ramstage which doesn't run on wake. cpu.c isn't
compiled into romstage and fixing that causes other problems, so the trustzone
functions were split out.
Change-Id: I8fc630237ebec1f02a91600f8baf3d4e9ea66d0e
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/169817
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 055ed0e28476123b0bd666109af90baf40aadcee)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6666
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
The UART / serial console is put in retention state by kernel during suspend /
resume path, which caused Coreboot not able to print any messages during resume.
Sending values to the padret_uart_opt inside PMU may release UART, but that may
also cause unexpected output when kernel is back. However, it's still very
helpful when we are debugging suspend/resume inside Coreboot.
To get UART message on resume, call wakeup_enable_uart() in boot block or
romstage (before console_init).
Change-Id: Ib5759cb402c6e018d9dba14fad8b61f6a1b1a265
Reviewed-on: https://chromium-review.googlesource.com/170440
Tested-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Commit-Queue: Hung-Te Lin <hungte@chromium.org>
(cherry picked from commit 547fbbfe2eeb6da4e161f36be2caf8099f9eac9b)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6649
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
This patch adds support for the DesignWare3 USB 3.0 DRD controller and
PHY to the Exynos5250 and Exynos5420 CPUs. It also adds code to the
Google Snow and Pit boards to turn these controllers on where
applicable.
Change-Id: Idcca627363a69f1d65402e1acb9a62b439f077ff
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/169452
Reviewed-by: Stefan Reinauer <reinauer@google.com>
(cherry picked from commit e9809ae12ef8b8bd6cd61d3f604cb9e4718cf7eb)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6642
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Right now some console specific objects are included
in the bootblock even if CONFIG_BOOTBLOCK_CONSOLE is
disabled while others are not. Make all of them conditional
and also fix a preprocessor misuse in bootblock_simple.c
and a stray (useless) die() in the Exynos wakeup code that
made inclusion of those files necessary.
Change-Id: Ia7f9d17654466f199b0e13afbdc9e14c9706530f
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/168772
Reviewed-by: David Hendrix <dhendrix@chromium.org>
(cherry picked from commit 855da1f07b52898c7edcaffe5baabe9d485bbd83)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6637
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
|
|
Change-Id: I9a454c88c65e4e70d351f1ec781e75ba400ceb29
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/6664
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
|
|
timer initialization is the first thing happening in
the Exynos CPU's bootblock code. Hence we don't need
to keep track of it in several places, and we don't
need to do it over and over again (e.g. in each stage)
Change-Id: I7bd9a0b7930fc9c37faabd62e3eecc3e5614a879
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/168994
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
(cherry picked from commit 5a95bc2bcab5a92c5e6c144005861bf731f59de3)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6638
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
This patch cleans out a lot of unused variables in the
ARM Kconfig files and introduces CONFIG_RAMSTAGE_BASE
which is similar to CONFIG_RAMBASE on x86.
This gets rid of the hard coded assumption that on ARM
coreboot is always executed at the lowest DRAM address.
But in fact, this might not be true because we might want
coreboot to live at the end of RAM, or in SRAM
Change-Id: I03e992645f9eb730e39a521aa21f702959311f74
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/168645
Reviewed-by: David Hendrix <dhendrix@chromium.org>
Tested-by: David Hendrix <dhendrix@chromium.org>
(cherry picked from commit 15b87892eb2d5e27759c49dc6c8c7e626f651d77)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6634
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
All this samsung_get_base_address_of_device_with_a_really_long_name()
boilerplate makes my eyes bleed... I think there are so much cleaner
ways to do this. Unfortunately changing this ends up touching nearly
every Exynos5 file, but I hope you agree that it's worth it (and the
sooner we get it over with, the better... I can't bring myself to make
another device fit into that ugly scheme).
This also removes the redundant EXYNOS5 base address definitions from
the 5420 directory when there are EXYNOS5420 ones, to avoid complete
confusion. The new scheme tries to use EXYNOS5 for base addresses and
exynos5 for types that are common between the two processors, and
EXYNOS5420/exynos5420 for things that have changes (although I probably
didn't catch all differences).
Change-Id: I87e58434490ed55a9bbe743af1f9bf2520dec13f
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/167579
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: ron minnich <rminnich@chromium.org>
(cherry picked from commit 66c87693352c248eec029c1ce83fb295059e6b5b)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6632
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
This patch moves around some of the existing Exynos5 USB 2.0 PHY code
to make it cleaner in preparation of the 3.0 PHYs. It moves the VBUS
GPIOs (which are completely board-specific) into the mainboard code and
makes sure to only initialize PHYs on the boards that actually need
them. It also removes the USB 3.0 PLL hack that was needed on Snow from
the Pit and Kirby boards (which do not have that PLL anymore).
Change-Id: Ia35f47a765acff60481f0907f7448ec4f78e0937
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/66887
Reviewed-by: Stefan Reinauer <reinauer@google.com>
(cherry picked from commit c3b1a8b687b535f4d5ac1b3bd2a4760151698fdb)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6609
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Apparently the IROM doesn't like data caches... the recently added
dcache-in-bootblock makes A-A booting fail, and flushes/invalidations
alone don't seem to fix it. It's pretty fast anyway, so we just disable
the cache again for the duration of the IROM call.
Also removes a superfluous invalidation line from the bootblock code...
dcache_mmu_enable/disable already take care of that.
Old-Change-Id: I35580d15664c7b4197d4ed14028720147adbf918
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/66602
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit e9c28a6a7a88c8286e62764ee5ad2694da2e822f)
exynos5: Implement booting from SDMMC media
This patch augments the alternative CBFS media source implementation for
Exynos5250 and Exynos5420 to allow booting from SDMMC devices (such as
an SD or uSD card reader, if available). It also moves MMC
initialization for the Snow, Pit and Kirby boards from romstage to
ramstage (mainboard_init) to prevent it from interfering with the IROM
during SDMMC boot.
Old-Change-Id: Ic4adef80c28262d084a53c28ec59aa7ac3af50c8
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/66154
(cherry picked from commit 08de13b72432c076e3327c048df93d89d52b0ecc)
snow and pit: turn on FET4 (for SD card) at bootup
Explictly enable FET4 on Snow and Pit.
Historically we haven't needed to do this because:
* On snow there's a bypass around FET4 which effectively eliminates
it. Even if we don't turn on FET4 the SD card is still powered.
Turning on FET4 doesn't hurt though and is technically correct.
* On pit the EC turns on FET4 on cold bootup.
On pit we run into a problem if the kernel turns off FET4 like in
<https://gerrit.chromium.org/gerrit/#/c/65332/> and then we get a
software reset or warm reset. In this case the EC won't know to turn
it back on.
This was ported from: https://gerrit.chromium.org/gerrit/#/c/65673
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Old-Change-Id: I57337f12b38889e6afee8577cf8807ec4c41e91c
Reviewed-on: https://gerrit.chromium.org/gerrit/66786
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
(cherry picked from commit e910117047d898b6b1d0dc965ef2ec0237d17646)
Squashed three commits for alternate cbfs SD support.
Change-Id: Idbd1fd4776cbf8cb20d03e6b691104cd8540a1ec
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6530
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The source file reset.c, present in both the exynos5250 and 5420 directories,
is not being built for either SOC. Let's get rid of the clutter.
Change-Id: Iab4c7982a271d08cbaf3207b6f5431f0ef52697e
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/170402
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: David Hendrix <dhendrix@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 0ce3898276ff49d171a0d8a650806f0305c0576f)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6542
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
|
|
This patch ports the USB A-A firmware upload functionality from
exynos5250 over to exynos5420. Essentially just like a conflictless
cherry-pick of 9e69421f5f0eebf88c09913dee90082feab2856c. It also fixes
the exact same bug with SPI initialization for Pit and Kirby.
Old-Change-Id: Ief0ed54c0beb2701e51201041f9bc426b2167747
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/65751
Reviewed-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit 5dff43f929478f83939221df13b961a69f89b132)
exynos5: Fix trivial style nits
A few curly braces on the wrong line.
Old-Change-Id: I4ddac4476c6509dc1716e8c1915fbdb67d346786
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/66153
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
(cherry picked from commit 41e3fd9eaafe36433723f4e96a6d94c04e5fbafb)
Squashed two related commits.
Change-Id: I22d579693b5e7270aacb45bbe3557e40893dd1f8
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6500
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
|
|
This improves firmware boot time substantially. Because cbmem isn't available
yet, we need to allocate some space in sram for the ttb. Doing cache
initialization in the bootblock means we can implement this once per CPU
instead of once per mainboard.
Old-Change-Id: Iad339de24df8ec2e23f91fe7bf57744e4cc766c5
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/65938
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit c32b9b32ad933e627b9ea98434b392239b1fea73)
exynos5420: flush caches and disable MMU in resume path
This patch flushes the caches and disables the MMU before resuming.
c32b9b3 ("Set up caching in the bootblock.") had a bug where the
dcache and MMU remained enabled in the resume path. This caused
the machine to hang on resume. However, other bugs were preventing
us from testing this properly earlier on so it went unnoticed until
now.
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Old-Change-Id: Ib1774f09d286a4d659da9fc2dad1d7a6fc1ebe5e
Reviewed-on: https://chromium-review.googlesource.com/67007
Reviewed-by: ron minnich <rminnich@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit 4fdf9763d25f70fd1e3591f6ff9785f78dd6170d)
Squashed two related commits.
Change-Id: Ibd42b28bb06930159248130e5ceaddb3b4b6cc2a
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6511
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
|
|
Change-Id: I1144e9d6d6c4278842fdd36743c8a88555f81707
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/65912
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
(cherry picked from commit 95b518877edc88347ce9725ffee32f3aed0de7dc)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6505
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
We set up L2 cache early in romstage now so the old
function is now redundant.
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Old-Change-Id: Icec93810ddd7feb48286d4b600cb2d58af38b7ef
Reviewed-on: https://gerrit.chromium.org/gerrit/65428
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit bb91f1078ea55a7c8bdc19336cef2ec9a5f4511f)
exynos: stack size: Increase the stack size to 16KB.
The lzma decoding function in the RAM stage allocates nearly 16KB on the stack
which is shared between the bootblock, rom stage, and ram stage. The stack had
been much too small and needed to be expanded.
Old-Change-Id: I1b74fff9b54e506320d58956b779b3a102e66868
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/65937
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 243d8a80f68dd257ecc5b4e19614bc7f0f5d398b)
exynos: gpio: add a bigger delay when reading board strappings
Z-state pins were not reading reliably with a 5us delay, so increase
it to 15us.
This is ported from https://gerrit.chromium.org/gerrit/64338
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Old-Change-Id: Ife6ea2ef5989e1a4c17913278ab972f0fd7f7f35
Reviewed-on: https://gerrit.chromium.org/gerrit/65727
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Tested-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit 76f0f8203f1af3f461745cefcc94e97c422d9084)
exynos5420: enable DMC internal clock gating
lets enable memory controller internal clock gating for ddr3.
with these bits enabled we save some power out of ddr3.
This is ported from https://gerrit.chromium.org/gerrit/#/c/60774
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Old-Change-Id: I2f9b0d78483b3ea7441f54a715c7c1e42eda3f7f
Reviewed-on: https://gerrit.chromium.org/gerrit/65728
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit 022a81c44e655a9f81e974e730c0cecc1f048781)
exynos5420: Correct the 600MHz PMS value
In UM ver0.02, 600MHz clock PMS values differs from what is programed
currently. Though this also results in 600MHz clock, but it is better to
match what UM says. This patch chnage this as per UM
This is ported from https://gerrit.chromium.org/gerrit/#/c/65106/3
(Note: we already used the correct 600MHz value for KPLL)
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Old-Change-Id: I6786815ab33427a23436e6ee37295f6c37dcd3d5
Reviewed-on: https://gerrit.chromium.org/gerrit/65726
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Tested-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit ceabf57ca78449fa6e9cfd212bdf4774706de92f)
Squashed five commits pertaining to exynos.
Change-Id: I3fd894aed15b8cd161c30904a46dac7e07eb8992
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6425
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
|
|
Otherwise there's no good way to create an absolute timer structure without
fiddling with its internal structure or assuming a zero initialized structure
has a value of zero.
Old-Change-Id: Iffe3b6b25ed7963fcfb66f749c531ea445ea4aeb
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/65301
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
(cherry picked from commit e2e5c1ef3bb2df95fdf0e33cb2d975a990d07a4a)
exynos: Simplify the monotonic timer implementation.
The previous implementation was overly complicated, and when used in the
timestamp implementation produced some weird and broken results.
Old-Change-Id: I3048028ddea0657b01b0c94f312764b38d1397e4
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/65302
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
(cherry picked from commit 6a3fde9a5b80cdac76d79c65d20d7dd1f1d9e557)
Squashed two closely related commits.
Change-Id: Ifc32d773f4f93d34275a81781001d080357fe8ef
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6406
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
|
|
The objective here is to tighten coreboot up a bit by not repeating
common helpers. This makes the code base more consistent and
unified/tight.
Change-Id: Ia163eae68b4a84a00ed118125e70308fab1cea0c
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/6215
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
Change-Id: I9004f34ba0c13b4489b26ac8c1476d00a6c6d01d
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/6207
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
|
|
Make all three coreboot stages (bootblock, romstage and ramstage) aware of the
architecture specific to that stage i.e. we will have CONFIG_ARCH variables for
each of the three stages. This allows us to have an SOC with any combination of
architectures and thus every stage can be made to run on a completely different
architecture independent of others. Thus, bootblock can have an x86 arch whereas
romstage and ramstage can have arm32 and arm64 arch respectively. These stage
specific CONFIG_ARCH_ variables enable us to select the proper set of toolchain
and compiler flags for every stage.
These options can be considered as either arch or modes eg: x86 running in
different modes or ARM having different arch types (v4, v7, v8). We have got rid
of the original CONFIG_ARCH option completely as every stage can have any
architecture of its own. Thus, almost all the components of coreboot are
identified as being part of one of the three stages (bootblock, romstage or
ramstage). The components which cannot be classified as such e.g. smm, rmodules
can have their own compiler toolset which is for now set to *_i386. Hence, all
special classes are treated in a similar way and the compiler toolset is defined
using create_class_compiler defined in Makefile.
In order to meet these requirements, changes have been made to CC, LD, OBJCOPY
and family to add CC_bootblock, CC_romstage, CC_ramstage and similarly others.
Additionally, CC_x86_32 and CC_armv7 handle all the special classes. All the
toolsets are defined using create_class_compiler.
Few additional macros have been introduced to identify the class to be used at
various points, e.g.: CC_$(class) derives the $(class) part from the name of
the stage being compiled.
We have also got rid of COREBOOT_COMPILER, COREBOOT_ASSEMBLER and COREBOOT_LINKER
as they do not make any sense for coreboot as a whole. All these attributes are
associated with each of the stages.
Change-Id: I923f3d4fb097d21071030b104c372cc138c68c7b
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: http://review.coreboot.org/5577
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@gmail.com>
|
|
CONFIG_ARCH is a property of the cpu or soc rather than a property of the
board. Hence, move ARCH_* from every single board to respective cpu or soc
Kconfigs. Also update abuild to ignore ARCH_ from mainboards.
Change-Id: I6ec1206de5a20601c32d001a384a47f46e6ce479
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: http://review.coreboot.org/5570
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
|
|
Correct selection of UART depends of board layout, not the CPU
internals, so default setting should originate from mainboard.
Change-Id: Ibf0ab0847ccce73c22704e86983dbe3d24ebc8a0
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5618
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
We have means to easily disable a specific console in romstage if
necessary, so this global option makes little sense.
The option was initially introduced as a work-around for build issues
around CACHE_AS_RAM, ROMCC and ARCH_ARMV7 dependencies for UARTs.
Change-Id: I797bdd11a48ddd813d3ee7ccef9a0c050f16f669
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5607
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
The port for console remains to be a compile time constant.
The Kconfig option is changed to select an UART port with index
to avoid putting map of UART base addresses in Kconfigs.
With this change it is possible to have other than debug console
on different UART port.
Change-Id: Ie1845a946f8d3b2604ef5404edb31b2e811f3ccd
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5342
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
Option DRIVERS_UART builds with support for UART hardware.
Option CONSOLE_SERIAL enables the console output for UART.
Those x86 boards that do not have serial port on SuperIO should select
NO_UART_ON_SUPERIO to disable 8250 UART for the default configuration.
Removes:
CONSOLE_SERIAL_UART
HAVE_UART_IO_MAPPED
HAVE_UART_MEMORY_MAPPED
Renames:
CONSOLE_SERIAL8250 -> DRIVERS_UART_8250IO
CONSOLE_SERIAL8250MEM -> DRIVERS_UART_8250MEM
Change-Id: Id3afa05f85c0d6849746886db8b6c2ed6c846b61
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5311
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
Also fixes the reported baudrate to take get_option() into account.
Change-Id: Ieadad70b00df02a530b0ccb6fa4e1b51526089f3
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5310
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
Prepare low-level register access to take UART base address as a
parameter. This is done to support a list of base addresses defined
in the platform.
Change-Id: Ie630e55f2562f099b0ba9eb94b08c92d26dfdf2e
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5309
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
UARTs now have unified prototypes and can use a single entry
in the list of drivers for ramstage.
Change-Id: I315daaf9a83cfa60f1a270146c729907a1d6d45b
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5308
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Do not pull in console hw-specific prototypes everywhere
with console.h as those are not needed for higher levels.
Move prototypes for UARTs next to other consoles.
Change-Id: Icbc9cd3e5bdfdab85d7dccd7c3827bba35248fb8
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5232
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Account for possible use of get_option() when baudrate is no longer
compile-time constant.
Change-Id: Ib45acd98e55c5892dbce9903830665aefeda5be0
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5288
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The calculations for static allocation are no longer valid.
Change-Id: I6740cdcec789abddf78485a0edaf24882ef8c2a5
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/4569
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
|
|
This patch implements the basic infrastructure required to use the USB
A-A firmware upload feature on Exynos5 processors with Coreboot. It will
require a corresponding host-side script that activates the feature and
uploads the correct image parts in the correct order to harcoded target
addresses, as described in the comments of alternate_cbfs.c.
Also fixes a bug in the Google Snow mainboard where it would not
correctly initialize the pinmux configuration for the SPI flash bus.
During a normal SPI boot the IROM would already do that for you, but
when booting from USB you have to do it yourself.
Change-Id: I40a39f8f5d1d70b58dbf258015c1653a27097d67
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/64875
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/4456
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
Switch ARM clock source when changing the APLL frequency to avoid
stability issues.
This is ported from https://gerrit.chromium.org/gerrit/#/c/64189/5
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I923107555e6d3287b3694cbf9e4bb548d3e5f4a8
Reviewed-on: https://gerrit.chromium.org/gerrit/64838
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/4442
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
This bus is hooked up on snow and, as it's the only bus hooked up on some
other boards, having it available in firmware to test is handy.
Change-Id: Icb48b9af4a67d382bd6fbce1e4c6a320d811d365
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/64877
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/4438
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
The memory corruption problem in Exynos suspend/resume process is caused by two
things together: PHY_RESET and MRS command.
After stop sending MRS on resume, we can now remove the workaround of skipping
PHY_RESET.
Change-Id: I64acc27c1d2bb549ae6ad7d32ecda94b0355972c
Reviewed-on: https://gerrit.chromium.org/gerrit/64736
Tested-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/4433
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
The kernel assumes that trust zone is disabled.
Change-Id: Ia8d6fa69adcb812a747d8b89eb77e57144423eaa
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/64722
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Ronald G. Minnich <rminnich@chromium.org>
Tested-by: Ronald G. Minnich <rminnich@chromium.org>
Reviewed-on: http://review.coreboot.org/4431
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
A previous change removed init_timer from timer_monotonic_get because its old
implementation set up the PWM based timer which was going away. It would still
be a good idea to initialize the timer at that point, just not the pwm.
Change-Id: I4816710ec2c9d5ca53b704c6b9397bcfac183fdc
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/64160
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/4419
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
... In order to do this, the graphics memory has to move into
the resource allocator and out of CBMEM.
Change-Id: I7396da4a7068404b0d2e4d308becab4dd6ea59bb
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/59326
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/4390
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
This code was left over from U-Boot and was superceded by the MCT.
Change-Id: Ia85e3b7281dcdd4740238dddd0dfc6f0ba2c94da
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/63778
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/4401
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
The code generally intended to make the pointer const instead of the thing it
pointed at, but it had const backwards. Sometimes both the pointer and the
data could be const, but sometimes there were writes where only the pointer
should be.
Change-Id: Ifcd5495769b86b47d7b583cce63ed5c2158bec4e
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/63775
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/4397
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Tested-by: build bot (Jenkins)
|
|
SYS_TEXT_BASE is not used by any one. To prevent confusion when changing memory
layout, remove it from current configurations.
Change-Id: I15012b864bbb9c12003843b9b24ea64c91f4578b
Reviewed-on: https://gerrit.chromium.org/gerrit/61853
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Hung-Te Lin <hungte@chromium.org>
Tested-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/4371
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
The 5250 DRAM code is *really* chatty. That's not a great
idea in time critical code, and DRAM init is generally
very sensitive about such things.
Finally, for those things that are errors, print them
at an error level, not a debug level.
Change-Id: Ifa86b019dfd5f8ae6c8a1da2a35b5d0808dc3623
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/60100
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Commit-Queue: Ronald G. Minnich <rminnich@chromium.org>
Tested-by: Ronald G. Minnich <rminnich@chromium.org>
Reviewed-on: http://review.coreboot.org/4359
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
The name "LPDDR3PHY_CTRL_PHY_RESET_OFF" is not appropriate because the real
phy-reset is a low-active pin, so "off(0)" will trigger "start to reset".
To prevent confusion, we should rename the constants to "RESET_ENABLE" and
"RESET_DISABLE".
Change-Id: Iccba5ef3a2e992f877dea90741f0308c161758c9
Reviewed-on: https://gerrit.chromium.org/gerrit/61081
Tested-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/4357
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Change-Id: I69c46648de0689e9bed84c7726906024ad65e769
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/3729
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Data is intended to be a byte array, so it should be described by a type which
has a fixed size equal to an 8 bit byte. Also, the data passed to write
shouldn't be modified and can be const.
Change-Id: I6466303d962998f6c37c2d4006a39c2d79a235c1
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3721
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Some initialization / shutdown commands should be paired correctly in a SPI I/O
session. For example, setting CS should be enabled and disabled in each read;
and the bus width (byte or word) should be configured only when opening /
closing the SPI device.
Change-Id: Ie56b1c3a6df7d542f7ea8f1193ac435987f937ba
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3706
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Wait for UART FIFO to be ready.
(Credit to dhendrix for finding the bits to test with.)
Change-Id: Ib6733e422cbc1c61b942bd90d85f88a3f412d6ff
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3698
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
... 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 2fde9668b47e74d1bfad2f1688a4481e6b966d04
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>
|
|
content.
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)
|
|
descriptor
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 9427ca151e44644238b1b52138894195a9f5175f
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)
|
