Age | Commit message (Collapse) | Author |
|
The pinmux register data structure describes a subset of the control module
registers, but the address which pointed to the base of the pinmux registers
was actually being set to the beginning of all the control module registers,
not just those having to do with the pinmux. With this address fixed, the UART
now works on the beaglebone black.
Change-Id: I7c99b6f37d7da359af074127cd0c1a86fda2d9a0
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3574
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
This patch is based on 'AMD S3: Program the flash in a bigger data packet'[1]
Some AMD south bridge can write bigger data when saving S3 info.
In this patch, I use config 'AMD_SB_SPI_TX_LEN' to contral data size.
AMD_SB_SPI_TX_LEN is defined in 'src/southbridge/amd/Kconfig'
and then can be overridden in the Kconfig for specific
southbridges that support larger size.
I have tested on AMD Parmer and Thatcher. We will release a new board
whose south bridge can transfer more than 4 bytes each time.
[1] http://review.coreboot.org/#/c/2306/
Change-Id: Id984955d46eae487e39d45979f1a90054aa9f54b
Signed-off-by: Siyuan Wang <SiYuan.Wang@amd.com>
Signed-off-by: Siyuan Wang <wangsiyuanbuaa@gmail.com>
Reviewed-on: http://review.coreboot.org/3413
Tested-by: build bot (Jenkins)
Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Non-S3 resume paths of sandy/ivybridge call cbmem_initialize()
more than once. Doing car_migrate_variables() more than twice caused
at least loss of some lines in CBMEM console.
Change-Id: Idd14aba9384984aa3a7d38937a4b3572aa5dc088
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3512
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
|
|
Change-Id: I74de250c69a57109362be1b2f00c0b4aa24a64e8
Signed-off-by: Andrew Wu <arw@dmp.com.tw>
Reviewed-on: http://review.coreboot.org/3473
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
I was unable to find documentation that said what mode numbers correspond
to what functionality, so I translated over what U-Boot does.
Change-Id: I34fab0f024fa2322d6bb66106aed75224e67354d
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3489
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Add support for the new q35 chipset emulation
added in qemu 1.4.
Change-Id: Iabfaa1310dc7b54c9d224635addebdfafe1fbfaf
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-on: http://review.coreboot.org/3430
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
memory reference
An uninitialized RAM value was used to select an MSR because a $ was forgotten
in front of `CPU_DM_CONFIG0`. It should be the constant value 0x1800, corresponding
to CPU_DM_CONFIG0 MSR defined in `src/include/cpu/amd/lxdef.h`.
Change-Id: Id53ca98b06cc4a9b55916fd8db23904f98008d45
Signed-off-by: Christopher Kilgour <techie@whiterocker.com>
Reviewed-on: http://review.coreboot.org/3478
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
|
|
With this patch, output on usbdebug also includes the section of
MTRR setups for every CPU. This makes usbdebug output almost identical
with that of serial port and CBMEM console.
Tested with model_206ax. Also tested previously on model_f2x which does
not have these disable/enable calls in model_f2x_init() without detected issues.
Change-Id: Idfd0e93439907b17255633658195d698feab3895
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3423
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
|
|
In function OemAgesaSaveMtrr of 'src/cpu/amd/agesa/s3_resume.c',
there are many code like this:
msr_data = rdmsr(0x258);
flash->write(flash, nvram_pos, 4, &msr_data.lo);
nvram_pos += 4;
flash->write(flash, nvram_pos, 4, &msr_data.hi);
nvram_pos += 4;
Add a function write_mtrr to do this.
Change-Id: Id6464e637db1758b07ac2d79d3be1375a8d49651
Signed-off-by: Siyuan Wang <SiYuan.Wang@amd.com>
Signed-off-by: Siyuan Wang <wangsiyuanbuaa@gmail.com>
Reviewed-on: http://review.coreboot.org/3410
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Change-Id: I7ecc394b1e5bc0b8b85a8afac22efc0befe2d36a
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/3395
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This reverts commit 0210119b4b95e84f954cfd6dc11aafbc187421af
Change-Id: I5be3f2a54394c592650a0dcd671e4a72ae796cb2
Reviewed-on: http://review.coreboot.org/3443
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Change-Id: If56f2cacc5f1b2ef9c7b6aea508d458a43dd1309
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/3397
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Add a struct for referencing UART registers. The layout is quite
strange on this chip, as the entire register space can take on three
different meanings depending on the line control settings (in the LCR
register) And to make things more confusing, some offsets reference
different registers depending on if a read or a write operation is
used.
Change-Id: Ie62af9c0e0edafd01b81686a0fe5c5c1d4fa06c4
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3319
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
The current method will treat hex values as 0 and would calculate the wrong
size. This change switches back to an earlier method which used shell syntax
to add the offset and size.
Change-Id: I9fb2d9b323f113cc56a5ad2e38b47d2d22084f08
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3432
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
The bootblock and ROM stages are the only ones that are really required to be
loaded in the quite limited on chip RAM during startup. Rather than load the
whole image which requires everything to be small, load just the bootblock and
the ROM stage, allowing the rest of the image to be arbitrarily large. Loading
a minimal amount of stuff should also improve boot performance a little bit.
Change-Id: I2fede63b8d3d8f0d880e4a692ae423021f8232b6
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3421
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Loading on an OMAP SOC requires that the first sector of the image have a
configuration header, and, when not an execute in place image, an additional
header which describes how big the image is and where it should be loaded.
This change adds some infrastructure to statically build that header using C
code, and to paste the header onto the front of coreboot.rom in a new top
level target file called MLO.
The configuration header we're using is as inert as possible, in line with
what U-Boot is doing. I think it could be used to give additional
configuration parameters to the built-in ROM on the SOC, but we don't need to
do that, and there didn't seem to be any actual documentation how to do that.
Because the header is built from C and is defined per CPU, it would be
possible to include extra settings in other CPUs if desired.
Adding a new top level build target is a bit disruptive, but should be
contained to the am335x directory and not interfere with other mainboards.
Change-Id: I06d346a4050c20963b3c7c6e8a152070bf2d145a
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3332
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
fam15 vendorcode (src/vendorcode/amd/agesa/f15tn) was licensed under the
AMD software license agreement. Change this license to 3-clause BSD.
Change-Id: I7cab09bb58ef7cd24602628e2278672d577214a2
Signed-off-by: Siyuan Wang <SiYuan.Wang@amd.com>
Signed-off-by: Siyuan Wang <wangsiyuanbuaa@gmail.com>
Reviewed-on: http://review.coreboot.org/3414
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
This patch adds a qemu x86 cpu chip. It has no initialization function
as this isn't needed on virtual hardware. A virtual machine can have
pretty much any CPU: qemu emulates a wide range of x86 CPUs (try 'qemu
-cpu ? for a list), also with 'qemu -cpu host' the guest will see a cpu
which is (almost) identical to the one on the host machine. So I've
added X86_VENDOR_ANY as wildcard match for the cpu_table.
Change-Id: Ib01210694b09702e41ed806f31d0033e840a863f
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-on: http://review.coreboot.org/3344
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
While we had support for updating microcode on the VIA Nano CPUs for a
while now, we never included the actual microcode. Unlike, Intel and
AMD CPUs, VIA microcode is not available for download, and was
extracted from the vendor BIOS. It was not included in coreboot since
we never had explicit permission to do so. I have just received
confirmation from VIA that we can distribute the microcode.
Change-Id: I4c15b090cd2713cfe5dc6b50db777ff89dbc0f19
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/3357
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
|
|
There were assumptions being made in the haswell
MP and SMM code which assumed the APIC id space
was 1:1 w.r.t. cpu number. When hyperthreading is
disabled the APIC ids of the logical processors
are all even. That means the APIC id space is sparse.
Handle this situation.
Change-Id: Ibe79ab156c0a171208a77db8a252aa5b73205d6c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3353
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Some settings in the am335x Kconfig weren't actually used for anything, some
where place holders, and some where left over from another CPU. The memory
addresses are in the internal RAM in the SOC as described in the reference
manual. The stack is put where the internal ROM had its stack, and the
bootblock is put at the bottom of that region as the manual suggests. The
ROM stage offset is set to 10K which is a bit bigger than the ~7.5K the
bootblock currently takes up.
Change-Id: I1a117d789a791d7e3db1118823f8216b3361433c
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3327
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
|
|
The following is an excerpt from serial log of the Bachmann OT200.
$ grep usec coreboot_log
clocks_per_usec: 500
Root Device init 48034 usecs
CPU_CLUSTER: 0 init 133251 usecs
PCI: 00:01.0 init 33376 usecs
PCI: 00:01.1 init 9930 usecs
PCI: 00:01.2 init 9929 usecs
PCI: 00:04.0 init 9929 usecs
PCI: 00:0f.0 init 185788 usecs
PCI: 00:0f.2 init 21473 usecs
PCI: 00:0f.3 init 9930 usecs
PCI: 00:0f.4 init 9930 usecs
PCI: 00:0f.5 init 9930 usecs
PCI: 00:0f.6 init 9930 usecs
PCI: 00:0f.7 init 9929 usecs
Change-Id: I4d0805c4cf8fcb25ec107615787fc6da0c945a30
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Reviewed-on: http://review.coreboot.org/3308
Tested-by: build bot (Jenkins)
|
|
Initial structure of Beaglebone port
Change-Id: Ia255ab207f424dcd525990cdc0d74953e012c087
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3279
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Thanks to Aaron Durbin coreboot provides monotonic timers. Select
the LAPIC monotonic timer for the AMD AGESA CPUs.
The following is an excerpt from serial log of the ASRock E350M1.
$ grep usec seriallog-20130502_100902.log
01.016: Root Device init 1578 usecs
01.029: CPU_CLUSTER: 0 init 112415 usecs
01.029: PCI: 00:00.0 init 3240 usecs
01.088: PCI: 00:01.0 init 104572 usecs
01.088: PCI: 00:01.1 init 1663 usecs
01.088: PCI: 00:11.0 init 1662 usecs
01.088: PCI: 00:14.0 init 1662 usecs
01.088: PCI: 00:14.3 init 8665 usecs
01.088: PCI: 00:14.4 init 1665 usecs
01.088: PCI: 00:18.0 init 1662 usecs
01.088: PCI: 00:18.1 init 1663 usecs
01.088: PCI: 00:18.2 init 1663 usecs
01.088: PCI: 00:18.3 init 1663 usecs
01.088: PCI: 00:18.4 init 1663 usecs
01.088: PCI: 00:18.5 init 1665 usecs
01.088: PCI: 00:18.6 init 1664 usecs
01.088: PCI: 00:18.7 init 1663 usecs
01.088: PNP: 002e.2 init 1576 usecs
01.088: PNP: 002e.5 init 1577 usecs
01.088: PNP: 002e.a init 1590 usecs
01.088: PNP: 002e.b init 30144 usecs
01.088: PCI: 03:00.0 init 1663 usecs
So the graphics device needs around 100 ms for being initialized.
The full serial log is in the Gerrit comments.
Change-Id: Ia7b3012e51fcf94b0f22290cdef2b4424295ad6d
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3172
Tested-by: build bot (Jenkins)
Reviewed-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
|
|
Commit »haswell: 24MHz monotonic time implementation« (c46cc6f1) [1]
added the Kconfig variable `MONOTONIC_TIMER_MSR` with a help text,
but only used one space instead of the suggested two spaces for
indentation. So add one space.
»Lines under a "config" definition are indented with one tab, while
help text is indented an additional two spaces.« [2]
[1] http://review.coreboot.org/3153
[2] https://www.kernel.org/doc/Documentation/CodingStyle
(Chapter 10: Kconfig configuration files)
Change-Id: I39cf356bfd54c66a2f1b837c6667dcc915e41f29
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3262
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
|
|
The haswell code allows for vboot ramstage verification.
However, that code path relies on accessing global cache-as-ram
variables after cache-as-ram is torn down. In order to avoid
that situation enable cache-as-ram migration.
cbmemc_reinit() no longer needs to be called from romstage
because it is invoked automatically by the cache-as-ram
migration infrastructure.
Change-Id: I08998dca579c167699030e1e24ea0af8802c0758
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3236
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
There are some boards that do a significant amount of
work after cache-as-ram is torn down but before ramstage
is loaded. For example, using vboot to verify the ramstage
is one such operation. However, there are pieces of code
that are executed that reference global variables that
are linked in the cache-as-ram region. If those variables
are referenced after cache-as-ram is torn down then the
values observed will most likely be incorrect.
Therefore provide a Kconfig option to select cache-as-ram
migration to memory using cbmem. This option is named
CAR_MIGRATION. When enabled, the address of cache-as-ram
variables may be obtained dynamically. Additionally,
when cache-as-ram migration occurs the cache-as-ram
data region for global variables is copied into cbmem.
There are also automatic callbacks for other modules
to perform their own migration, if necessary.
Change-Id: I2e77219647c2bd2b1aa845b262be3b2543f1fcb7
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3232
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
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>
|
|
Thread support is added for the x86 architecture. Both
the local apic and the tsc udelay() functions have a
call to thread_yield_microseconds() so as to provide an
opportunity to run pending threads.
Change-Id: Ie39b9eb565eb189676c06645bdf2a8720fe0636a
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3207
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Commit "romcc: Don't fail on function prototypes" (11a7db3b) [1]
made romcc not choke on function prototypes anymore. This
allows us to get rid of a lot of ifdefs guarding __ROMCC__ .
[1] http://review.coreboot.org/2424
Change-Id: Ib1be3b294e5b49f5101f2e02ee1473809109c8ac
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/3216
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Since this parameter is not used anymore, drop it from
all calls to copy_and_run()
Change-Id: Ifba25aff4b448c1511e26313fe35007335aa7f7a
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/3213
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Some entries still used spaces while others used tabulators[1]. Convert
spaces to tabs to uniformly use tabs.
---------------------- 8< -------------- 8< -----------------------------
For all of the Kconfig* configuration files throughout the source tree,
the indentation is somewhat different. Lines under a "config" definition
are indented with one tab, while help text is indented an additional two
spaces. [2]
---------------------- 8< -------------- 8< -----------------------------
[1] http://en.wikipedia.org/wiki/File:HollerithMachine.CHM.jpg
[2] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/CodingStyle?id=HEAD
Change-Id: Iee80ad4a90e95b925afbb0c6adc563fa3a6503cf
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3173
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
|
|
Since the TSC udelay() function can be used in SMM that means the
TSC can count up to whatever value. The current loop was not handling
TSC rollover properly. In most cases this should not matter as the TSC
typically starts ticking at value 0, and it would take a very long time
to roll it over. However, it is my understanding that this behavior is
not guaranteed. Theoretically the TSC could start or be be written to
with a large value that would cause the rollover.
Change-Id: I2f11a5bc4f27d5543e74f8224811fa91e4a55484
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3171
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
When the haswell MP/SMM code was developed it was using a coreboot
repository that did not contain the asmlinkage macro. Now that the
asmlinkage macro exists use it.
BUG=None
BRANCH=None
TEST=Built and booted.
Change-Id: I662f1b16d1777263b96a427334fff8f98a407755
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3203
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
We have the monotonic timer implemented on exynos now, and this
also enables helpful bootstage prints with timing info.
Change-Id: I3baa4c9d70d4b4d059abd5e05eddcabd5258dbfd
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3210
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
Some boards use the local apic for udelay(), but they also provide
their own implementation of udelay() for SMM. The reason for using
the local apic for udelay() in ramstage is to not have to pay the
penalty of calibrating the TSC frequency. Therefore provide a
TSC_CONSTANT_RATE option to indicate that TSC calibration is not
needed. Instead rely on the presence of a tsc_freq_mhz() function
provided by the cpu/board. Additionally, assume that if
TSC_CONSTANT_RATE is selected the udelay() function in SMM will
be the tsc.
Change-Id: I1629c2fbe3431772b4e80495160584fb6f599e9e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3168
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Instead of using the local apic timer for udelay() use the tsc.
That way SMM, romstage, and ramstage all use the same delay
functionality.
Change-Id: I024de5af01eb5de09318e13d0428ee98c132f594
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3169
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
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>
|
|
Commit
commit 825c78b5da98c7155ff6be3322cdaae0e5a060e8
Author: David Hubbard <david.c.hubbard+coreboot@gmail.com>
Date: Thu May 2 18:06:03 2013 -0600
mainboard/{asus/f2a85-m,amd/thatcher}: move UDELAY_LAPIC
Reviewed-on: http://review.coreboot.org/3178
adds `UDELAY_LAPIC` to `cpu/amd/agesa/family15tn/Kconfig`. This is
not needed, because since commit
commit e135ac5a7ea69b6edcb89345019212f5de412b1e
Author: Patrick Georgi <patrick.georgi@secunet.com>
Date: Tue Nov 20 11:53:47 2012 +0100
Remove AMD special case for LAPIC based udelay()
Reviewed-on: http://review.coreboot.org/1618
`select UDELAY_LAPIC` is present in `src/cpu/amd/agesa/Kconfig` which
applies also to AMD Family 15tn.
Therefore remove `select UDELAY_LAPIC` again from
`cpu/amd/agesa/family15tn/Kconfig`.
Change-Id: I98b783a97c4a1e45ecb29b776cb3d3877bad9c0f
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3179
Tested-by: build bot (Jenkins)
Reviewed-by: Peter Stuge <peter@stuge.se>
|
|
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)
|
|
Stefan Reinauer suggested 'select UDELAY_LAPIC' did not belong in
f2a85-m/Kconfig. It got there via copy-paste from thatcher/Kconfig
so this commit removes the 'select UDELAY_LAPIC' from both and puts
it in cpu/amd/agesa/family15tn/Kconfig
Since f2a85-m is the only Thatcher board coreboot supports right
now, this should not break any other boards.
Change-Id: I811b579c31f8d259a237d3a6724ad3b17f3a6c3e
Signed-off-by: David Hubbard <david.c.hubbard+coreboot@gmail.com>
Reviewed-on: http://review.coreboot.org/3178
Reviewed-by: Peter Stuge <peter@stuge.se>
Tested-by: build bot (Jenkins)
|
|
Implement the timer_monotonic_get() using the TSC.
Change-Id: I5118da6fb9bccc75d2ce012317612e0ab20a2cac
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3155
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Implement the timer_monotonic_get() functionality based off of
the local apic timer.
Change-Id: I1aa1ff64d15a3056d6abd1372be13da682c5ee2e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3154
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Haswell ULT devices have a 24MHz package-level counter. Use
this counter to provide a timer_monotonic_get() implementation.
Change-Id: Ic79843fcbfbbb6462ee5ebd12b39502307750dbb
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3153
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
On x86 systems there is a concept of cachings the ROM. However,
the typical policy is that the boot cpu is the only one with
it enabled. In order to ensure the MTRRs are the same across cores
the rom cache needs to be disabled prior to OS resume or boot handoff.
Therefore, utilize the boot state callbacks to schedule the disabling
of the ROM cache at the ramstage exit points.
Change-Id: I4da5886d9f1cf4c6af2f09bb909f0d0f0faa4e62
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3138
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
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>
|