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 cleans up a few minor things (mostly #defines) of the memory code
for exynos5420, pit, and kirby. Specifically:
- CONCONTROL.empty is read-only, so don't try to set it and also
get rid of the unneeded DMC_CONCONTROL_EMPTY_ENABLE #define.
- MEMBASECONFIG* overlaps members of the mem_timings struct and
are mainboard-dependent anyway, so get rid of 'em.
- DMC_MEMCONTROL_TP_DISABLE corresponds to a reserved bit. It may
have been deprecated.
- Same with TIMING* #defines.
- Clarify DDR_MODE_* usage and use mem->mem_type when appropriate.
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: Ideb21efcc97b24f7e115e90051c20daef4480f17
Reviewed-on: https://chromium-review.googlesource.com/167500
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: ron minnich <rminnich@chromium.org>
(cherry picked from commit 650dba32cb217414c422907398f68e784e5720e8)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6614
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
membaseconfig0/1 are utterly dependent on the mainboard's particular
DRAM setup. This defines their values in the mem_timings struct for
pit.
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Old-Change-Id: Ifd782d1229b2418f8ddbf0bcb3f45cc828ac34b0
Reviewed-on: https://chromium-review.googlesource.com/167488
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: ron minnich <rminnich@chromium.org>
(cherry picked from commit 80eebd5bc0dbb9fabf81f46c25dcd5c5d5747579)
exynos5420: necessary updates for DRAM
This updates DRAM usage for Exynos5420 so that we can actually
use 3.5GB:
- Memory chips used with Exynos5420 may have 16 row address lines.
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Old-Change-Id: I86d1a96d0d1a028587f7655f8de5a2e52165e9d2
Reviewed-on: https://chromium-review.googlesource.com/167489
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: ron minnich <rminnich@chromium.org>
(cherry picked from commit 04bbaf5d8e125166dd689f656d5b37776be01fb1)
Squashed two related commits.
Change-Id: I4e45bc8a446715897ec21b0160701152fa6b226b
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6613
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This changes the number of chip selects that we configure from 2 to 1.
On current setups with (x16 memory 4Gbit chips) that means that we're
at 2GByte.
Technically we should add a second setting in the ares_ddr3_timings
and select between the two of the based on board strappings. That
would make the CONFIG_RUN_TIME_BANK_NUMBER work properly. I've
changed the ddr3_mem_ctrl_init() so it should handle that, but I'm not
actually doing the board strapping read right now.
This change means that accesses to 0xA0000000 - 0xFFFFFFFF on 2G
systems will no longer put the system in a messed up state (leading to
a hang). It also prevents some of the weird boot behavior that we've
seen that comes and goes depending on U-Boot alignment. See
<http://crosbug.com/p/20577>.
This patch was ported from: https://gerrit.chromium.org/gerrit/66117
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: Ib4cfe420aac30bd817438f06d01e8671afc4a27d
Reviewed-on: https://chromium-review.googlesource.com/167210
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: ron minnich <rminnich@chromium.org>
(cherry picked from commit 0ea574243058068702e3f6bc7355098745d16880)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6612
Tested-by: build bot (Jenkins)
Fine tuning DDR timings value for better stability
* Changed Data Driver Strength from 34 ohms to 30 ohms, expected to
enhance signal integrity.
* Changed DQ signal from 0xf to 0x1f000f, to keep default value safe.
* Changed mrs[2] and added new mrs direct command for setting WL/RL
without resetting DLL.
* Added explicit reset value write in phy_con0 instead of just setting
a bit, to ensure that reset happens.
* Added DREX automatic control for ctrl_pd in none read memory state.
This is ported from: https://gerrit.chromium.org/gerrit/61405
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I59e96e6dede7b49c6572548aca664d82ad110bb1
Reviewed-on: https://chromium-review.googlesource.com/66995
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 ec34b711c6d270672c56d45c370ca14c0aa27ca3)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6611
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
This patch intends to remove all code which enables hardware read
leveling. We need to disable h/w read leveling because new ASV table
is merged in kernel (which is based on the new characterization
condition) and new characterization environment has h/w read leveling
disabled, so we should also disable this. Also, disabling h/w read
leveling improves the MIF LVcc value (LVcc value is the value at which
DDR will fail to work properly), improve LVcc means we have enough
voltage margin for MIF. When h/w leveling is enabled, we have almost
zero volatge margin.
This was ported from: https://gerrit.chromium.org/gerrit/66070
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: Id0a2d77e6214325f226d51ae08464b39424cea83
Reviewed-on: https://chromium-review.googlesource.com/66994
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit d29add98f52876aaed4fee2b76edf6b4591e66e8)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6610
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: build bot (Jenkins)
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>
As per hardware recommendation, CKE PAD retention release must
happen just before gate leveling enable and only in case of resume.
Hence, this patch moves pad retention release from dmc_common.c to
dmc_init_ddr3_exynos5420.c. In addition to this we are providing
125 (+3 extra being safe) times auto refresh to DRAM by sending
REFA direct command. This is required because when CKE PAD retention
release happens, self refresh mode of DDR3 is disabled.
Hence, auto refresh 125 times.
This is ported from https://gerrit.chromium.org/gerrit/#/c/65573
Note: Since WAKEUP_DIRECT does not go thru memory init, it should be
safe to move CKE PAD retention out of bootblock.c.
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: Idec5d6fbbe3c6344d47401ba7203079c52a9b866
Reviewed-on: https://gerrit.chromium.org/gerrit/66788
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 96cbcb09245d4df92d3e1998704ab440be42df25)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6604
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
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>
Provide functionality to create dynamic classes based on program name and
architecture for which the program needs to be compiled/linked. define_class
takes program_name and arch as its arguments and adds the program_name to
classes-y to create dynamic class. Also, compiler toolset is created for the
specified arch. All the files for this program can then be added to
program_name-y += .. Ensure that define_class is called before any files are
added to the class. Check subdirs-y for order of directory inclusion.
One such example of dynamic class is rmodules. Multiple rmodules can be used
which need to be compiled for different architectures. With dynamic classes,
this is possible.
Change-Id: Ie143ed6f79ced5f58c200394cff89b006bc9b342
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: http://review.coreboot.org/6426
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
We were running this loop 100 times with 5 ms delays. Change it
to run 500 times with 1 ms delays, which gives us the same
overall timeout but lets us bail out a bit sooner -- in practice,
at most, 4 ms sooner but every bit counts. Note, however, that
the tighter timing does reduce opportunities for threading. There
is a non-obvious set of tradeoffs on timeouts.
Change-Id: I4af671c2a791aa92e446e66ac2fe5710d1e6aa4c
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: https://chromium-review.googlesource.com/167387
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: ron minnich <rminnich@chromium.org>
Tested-by: ron minnich <rminnich@chromium.org>
(cherry picked from commit 575e910127dc74416018f182ef27ef223e61daef)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6543
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
This patch enhances the armv7 exception handlers in Coreboot and
libpayload to show the correct SP and LR registers from the aborted
context, and also dump a part of the current stack. Since we cannot
access the banked registers of SVC mode from a different exception mode,
it changes Coreboot (and its payloads) to run in System mode instead. As
both modes can execute all privileged instructions, this should not have
any noticeable effect on firmware operation (please correct me if I'm
wrong!).
Change-Id: I0e04f47619e55308f7da4a3a99c9cae6ae35cc30
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170045
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
(cherry picked from commit d0db2f5e938200e3f5899c5e1f1606ab2dd5b334)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6538
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Lets try not to play games with the Lexer with fancy ASCII art. Doxygen
has a more well defined and useful syntax for annotations.
Change-Id: I6f6c58971f509064ae1e28a1740e50e2ae721513
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/6550
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
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>
On x86, cpu_info lives at the top of stack. Make the arm do that as
well, as the threading model needs that and so will multicore support.
As part of this change, make the stack size a power of 2.
Also make it much smaller -- 2048 bytes is PLENTY for ram stage.
Note that the small stack size is counterintuitive for rom stage. How
can this work in rom stage, which needs a HUGE stack for lzma? The
main use of STACK_SIZE has always been in ram stage; since 2002 or so
it was to size per-core stacks (see, e.g.,
src/arch/x86/lib/c_start.S:.space CONFIG_MAX_CPUS*CONFIG_STACK_SIZE
and, more recently, thread stacks. So, we define the STACK_TOP for rom
and ram stage, but the STACK_SIZE has no real effect on the ROM stage
(no hardware red zones on the stack) and hence we're ok with actually
defining the "wrong" stack size. In fact, the coreboot_ram ldscript
for armv7 sizes the stack by subtracting CONFIG_STACK_BOTTOM from
CONFIG_STACK_TOP, so we replicate that arithmetic in bootblock.inc
Observed stack usage in ramstage:
BS: BS_PAYLOAD_LOAD times (us): entry 1 run 153887 exit 1
Jumping to boot code at 23104044
CPU0: stack: 02072800 - 02073000, lowest used address 020728d4, stack used: 1836 bytes
entry = 23104044
Which means we do need 2K, not 1K.
Change-Id: I1a21db87081597efe463095bfd33c89eba1d569f
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/66135
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Tested-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Ronald G. Minnich <rminnich@chromium.org>
(cherry picked from commit f011097e9f2bfb2f4c1109d465be89a79a65ba3e)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6501
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
If power_limit_1_time > 129 is false then power_limit_1_time can have a
value of up to 129 leading to an out-of-bounds illegal read indexing the
power_limit_time_sec_to_msr[] array. Thankfully all call sites have been
doing the right thing up until now so the issue has not been visible.
Change-Id: Ic029d1af7fe43ca7da271043c2b08fe3088714af
Found-by: Coverity Scan
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/6478
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
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>
This adds the CPU initialization pieces for Intel's Atom C2000 processor
(Formerly Rangeley).
Change-Id: I77d69f42c959bbc294784f044b7b0dcc2e30f30c
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: http://review.coreboot.org/6368
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Found by Cppcheck 1.65. Fixes:
(warning) Variable 'processor_name_string' is reassigned a value before the old one has been used. 'break;' missing?
(warning) Variable 'rsize' is reassigned a value before the old one has been used. 'break;' missing?
Change-Id: I4a5c947fd5cc5797eb026475ec7036bc5eaf58db
Signed-off-by: Daniele Forsi <dforsi@gmail.com>
Reviewed-on: http://review.coreboot.org/6372
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
The only remaining purpose for get_bus_conf() was to fill in obscure
bus_sb800 (etc.) arrays containing partial PCI bus enumeration. Complete
enumeration is available in devicetree and PCI configuration space so
discard these arrays.
Change-Id: I733115940afba3a50c58aedb9a04ecf5082b1234
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/6360
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
