Now that CONFIG_RELOCTABLE_RAMSTAGE is available support it on
Haswell-based systems. This patch is comprised of the following changes:
1. Ensure that memory is not preserved when a relocatable ramstage is
enabled. There is no need.
2. Pick the proper stack to use after cache-as-ram is torn down. When
the ramstage is relocatable, finding a stack to use before vectoring
into ramstage is impossible since the ramstage is a black box with an
unknown layout.
Change-Id: I2a07a497f52375569bae9c994432a8e7e7a40224
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2793
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The current ramstage code contains uses of symbols that cause issues
when the ramstage is relocatable. There are 2 scenarios resolved by this
patch:
1. Absolute symbols that are actually sizes/limits. The symbols are
problematic when relocating a program because there is no way to
distinguish a symbol that shouldn't be relocated and one that can.
The only way to handle these symbols is to write a program to post
process the relocations and keep a whitelist of ones that shouldn't
be relocated. I don't believe that is a route that should be taken
so fix the users of these sizes/limits encoded as absolute symbols
to calculate the size at runtime or dereference a variable in memory
containing the size/limit.
2. Absoulte symbols that were relocated to a fixed address. These
absolute symbols are generated by assembly files to be placed at a
fixed location. Again, these symbols are problematic because one
can't distinguish a symbol that can't be relocated. The symbols
are again resolved at runtime to allow for proper relocation.
For the symbols defining a size either use 2 symbols and calculate the
difference or provide a variable in memory containing the size.
Change-Id: I1ef2bfe6fd531308218bcaac5dcccabf8edf932c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2789
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Using the CPU microcode update script and
Intel's Linux* Processor Microcode Data File
from 2013-02-22
Change-Id: I853e381240b539b204c653404ca3d46369109219
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2846
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Using the CPU microcode update script and
Intel's Linux* Processor Microcode Data File
from 2013-02-22
Change-Id: I4585288905cf7374e671894ab37f125220ae535e
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2843
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
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>
There should be a fixed 10ms wait after sending an INIT IPI. The
previous implementation was just waiting up to 10ms for the IPI to
complete the send. That is not correct. The 10ms is unconditional
according to the documentation. No ill effects were observed with the
previous behavior, but it's important to follow the documentation.
Change-Id: Ib31d49ac74808f6eb512310e9f54a8f4abc3bfd7
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2780
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This patch parallelizes the AP startup for Haswell-based devices. It
does not touch the generic secondary startup code. Instead it provides
its own MP support matching up with the Haswell BWG. It seemed to be too
much trouble to support the old startup way and this new way. Because of
that parallel loading is the only thing supported.
A couple of things to note:
1. Micrcode needs to be loaded twice. Once before MTRR and caching is
enabled. And a second time after SMM relocation.
2. The sipi_vector is entirely self-contained. Once it is loaded and
written back to RAM the APs do not access memory outside of the
sipi_vector load location until a sync up in ramstage.
3. SMM relocation is kicked off by an IPI to self w/ SMI set as the
destination mode.
The following are timings from cbmem with dev mode disabled and recovery mode
enabled to boot directly into the kernel. This was done on the
baskingridge CRB with a 4-core 8-thread CPU and 2 DIMMs 1GiB each. The
kernel has console enabled on the serial port. Entry 70 is the device
initialization, and that is where the APs are brought up. With these two
examples it looks to shave off ~200 ms of boot time.
Before:
1:55,382
2:57,606 (2,223)
3:3,108,983 (3,051,377)
4:3,110,084 (1,101)
8:3,113,109 (3,024)
9:3,156,694 (43,585)
10:3,156,815 (120)
30:3,157,110 (295)
40:3,158,180 (1,069)
50:3,160,157 (1,977)
60:3,160,366 (208)
70:4,221,044 (1,060,677)
75:4,221,062 (18)
80:4,227,185 (6,122)
90:4,227,669 (484)
99:4,265,596 (37,927)
1000:4,267,822 (2,225)
1001:4,268,507 (685)
1002:4,268,780 (272)
1003:4,398,676 (129,896)
1004:4,398,979 (303)
1100:7,477,601 (3,078,621)
1101:7,480,210 (2,608)
After:
1:49,518
2:51,778 (2,259)
3:3,081,186 (3,029,407)
4:3,082,252 (1,066)
8:3,085,137 (2,884)
9:3,130,339 (45,202)
10:3,130,518 (178)
30:3,130,544 (26)
40:3,131,125 (580)
50:3,133,023 (1,897)
60:3,133,278 (255)
70:4,009,259 (875,980)
75:4,009,273 (13)
80:4,015,947 (6,674)
90:4,016,430 (482)
99:4,056,265 (39,835)
1000:4,058,492 (2,226)
1001:4,059,176 (684)
1002:4,059,450 (273)
1003:4,189,333 (129,883)
1004:4,189,770 (436)
1100:7,262,358 (3,072,588)
1101:7,263,926 (1,567)
Booted the baskingridge board as noted above. Also analyzed serial
messages with pcserial enabled.
Change-Id: Ifedc7f787953647c228b11afdb725686e38c4098
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2779
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This patch only applies to CONFIG_MICROCODE_IN_CBFS. The intel microcode
update routine would always walk the CBFS for the microcode file. Then
it would loop through the whole file looking for a match then load the
microcode. This process was maintained for intel_update_microcode_from_cbfs(),
however 2 new functions were exported:
1. const void *intel_microcode_find(void)
2. void intel_microcode_load_unlocked(const void *microcode_patch)
The first locates a matching microcode while the second loads that
mircocode. These new functions can then be used to cache the found
microcode blob w/o having to re-walk the CBFS.
Booted baskingridge board to Linux and noted that all microcode
revisions match on all the CPUs.
Change-Id: Ifde3f3e5c100911c4f984dd56d36664a8acdf7d5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2778
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The non-relocatable SMM code was changed to link against libgcc a while back
so that printk could use built-in division instead of a hand crafted div()
function. However, the relocatable SMM code was not adapted by mistake.
This patch links the relocatable SMM against libgcc, too, so we can enable it
for Haswell.
Change-Id: Ia64a78e2e62348d115ae4ded52d1a02c74c5cea4
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2727
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
There are changes coming to perform more complex tasks after cache-as-ram
has been torn down but before ramstage is loaded. Therefore, add the
romstage_after_car() function to call after cache-as-ram is torn down.
Its responsibility is for loading the ramstage and any other complex
tasks. For example, the saving of OS-controlled memory in the resume
path has now been moved into C instead of assembly.
Change-Id: Ie0c229cf83a9271c8995b31c534c8e5a696b164e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2757
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The save_mrc_data() was previously called conditionally
in the raminit code. The save_mrc_data() function was called
in the non-S3 wake paths. However, the common romstage_common()
code was checking cbmem initialization things on s3 wake. Between
the two callers cbmem_initialize() was being called twice in the
non-s3 wake paths. Moreover, saving of the mrc data was not allowed
when CONFIG_EARLY_CBMEM_INIT wasn't enabled.
Therefore, move the save_mrc_data() to romstage_common. It already has
the knowledge of the wake path. Also remove the CONFIG_EARLY_CBMEM_INIT
requirement from save_mrc_data() as well as the call to cbmem_initialize().
Change-Id: I7f0e4d752c92d9d5eedb8fa56133ec190caf77da
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2756
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Instead of hard coding the policy for the stack and MTRR values after
the cache-as-ram is torn down, allow for the C code to pass those
policies back to the cache-as-ram assembly file. That way, ramstage
relocation can use a different stack as well as different MTRR policies.
Change-Id: Ied024d933f96a12ed0703c51c506586f4b50bd14
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2755
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This commit pulls in all the common logic for romstage into
the Haswell cpu directory. The bits specific to the mainboard
still reside under their respective directories. The calling
sequence bounces from the cpu directory to mainboard then back
to the cpu directory. The reasoning is that Haswell systems use
cache-as-ram for backing memory in romstage. The stack is used to
allocate structures. However, now changes can be made to the
romstage for Haswell and apply to all boards.
Change-Id: I2bf08013c46a99235ffe4bde88a935c3378eb341
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2754
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
It was found that the Haswell reference code was smashing through the
stack into the reference code's heap implementation. The reason for this
is because our current CAR allocation is too small. Moreover there are
quite a few things to coordinate between 2 code bases to get correct.
This commit separates the CAR into 2 parts:
1. MRC CAR usage.
2. Coreboot CAR usage.
Pointers from one region can be passed between the 2 modules, but one
should not be able to affect the others as checking has been put into
place in both modules.
The CAR size has effectively been doubled from 0x20000 (128 KiB) to
0x40000 (256KiB). Not all of that increase was needed, but enforcing
a power of 2 size only utilizes 1 MTRR.
Old CAR layout with a single contiguous stack with the region starting
at CONFIG_DCACHE_RAM_BASE:
+---------------------------------------+ Offset CONFIG_DCACHE_RAM_SIZE
| MRC global variables |
| CONFIG_DCACHE_RAM_MRC_VAR_SIZE bytes |
+---------------------------------------+
| ROM stage stack |
| |
| |
+---------------------------------------+
| MRC Heap 30000 bytes |
+---------------------------------------+
| ROM stage console |
| CONFIG_CONSOLE_CAR_BUFFER_SIZE bytes |
+---------------------------------------+
| ROM stage CAR_GLOBAL variables |
+---------------------------------------+ Offset 0
There was some hard coded offsets in the reference code wrapper to start
the heap past the console buffer. Even with this commit the console
can smash into the following region depending on what size
CONFIG_CONSOLE_CAR_BUFFER_SIZE is.
As noted above This change splits the CAR region into 2 parts starting
at CONFIG_DCACHE_RAM_BASE:
+---------------------------------------+
| MRC Region |
| CONFIG_DCACHE_RAM_MRC_VAR_SIZE bytes |
+---------------------------------------+ Offset CONFIG_DCACHE_RAM_SIZE
| ROM stage stack |
| |
| |
+---------------------------------------+
| ROM stage console |
| CONFIG_CONSOLE_CAR_BUFFER_SIZE bytes |
+---------------------------------------+
| ROM stage CAR_GLOBAL variables |
+---------------------------------------+ Offset 0
Another variable was add, CONFIG_DCACHE_RAM_ROMSTAGE_STACK_SIZE,
which represents the expected stack usage for the romstage. A marker
is checked at the base of the stack to determine if either the stack
was smashed or the console encroached on the stack.
Change-Id: Id76f2fe4a5cf1c776c8f0019f406593f68e443a7
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2752
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Haswell's BCLK is fised at 100MHz like Sandy/Ivy. Add Haswell's model
to the switch statement.
Change-Id: Ib9e2afc04eba940bfcee92a6ee5402759b21cc45
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2747
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The SMM handler resides in the TSEG region which is far above
CONFIG_RAM_TOP (which is the highest cacheable address) before
MTRRs are setup. This means that calling initialize_cpus() before
performing MTRR setup on the BSP means the SMM handler is copied
using uncacheable accesses.
Improve the SMM handler setup path by enabling performing MTRR setup on
for the BSP before the call to initialize_cpus(). In order to do this
the haswell_init() function was split into 2 paths: BSP & AP paths.
There is a cpu_common_init() that both call to perform similar
functionality. The BSP path in haswell_init() then starts the APs using
intel_cores_init(). The AP path in haswell_init() loads microcode and
sets up MTRRs.
This split will be leveraged for future support of bringing up APs in
parallel as well as adhering to the Haswell MP initialization
requirements.
Change-Id: Id8e17af149e68d708f3d4765e38b1c61f7ebb470
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2746
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The configure_mca() function was hard coding the number of
banks the cpu supported. Query this dynamically so that it
no longer clears only 7 banks.
Change-Id: I33fce8fadc0facd1016b3295faaf3ae90e490a71
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2745
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This just moves the definiton of CORE_THREAD_COUNT_MSR so
that future code can utilize it.
Change-Id: I15a381090f21ff758288f55dc964b6694feb6064
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2744
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This commit adds support for using the SMM modules for haswell-based
boards. The SMI handling was also refactored to put the relocation
handler and permanent SMM handler loading in the cpu directory. All
tseg adjustment support is dropped by relying on the SMM module support
to perform the necessary relocations.
Change-Id: I8dd23610772fc4408567d9f4adf339596eac7b1f
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2728
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Haswell CPUs require a FIT table in the firmware. This commit
adds rudimentary support for a FIT table. The number of entries
in the table is based on a configuration option. The code only
generates a type 0 entry. A follow-on tool will need to be developed
to populate the FIT entries as well as checksumming the table.
Verified image has a FIT pointer and table when option is selected.
Change-Id: I3a314016a09a1cc26bf1fb5d17aa50853d2ef4f8
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2642
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The Link native graphics commit 49428d84 [1]
Add support for Google's Chromebook Pixel
was missing some of the higher level bits, and hence could not be
used. This is not new code -- it has been working since last
August -- so the effort now is to get it into the tree and structure
it in a way compatible with upstream coreboot.
1. Add options to src/device/Kconfig to enable native graphics.
2. Export the MTRR function for setting variable MTRRs.
3. Clean up some of the comments and white space.
While I realize that the product name is Pixel, the mainboard in the
coreboot tree is called Link, and that name is what we will use
in our commits.
[1] http://review.coreboot.org/2482
Change-Id: Ie4db21f245cf5062fe3a8ee913d05dd79030e3e8
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2531
Tested-by: build bot (Jenkins)
This adds microcode ffff000a and the CPUIDs for ULT.
Change-Id: I341c1148a355d8373b31032b9f209232bd03230a
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/2647
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
The IA32_ENERGY_PERFORMANCE_BIAS MSR can only be read or written
to if the CPU supports it. The support is indicated by ECX[3] for
cpuid(6). Without this guard, some Haswell parts would GP# fault
in this routine.
No more GP# while running on haswell CRBs.
Change-Id: If41e1e133e5faebb3ed578cba60743ce7e1c196f
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2639
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
Add support for SMM modules by leveraging the RMODULE lib. This allows
for easier dynamic SMM handler placement. The SMM module support
consists of a common stub which puts the executing CPU into protected
mode and calls into a pre-defined handler. This stub can then be used
for SMM relocation as well as the real SMM handler. For the relocation
one can call back into coreboot ramstage code to perform relocation in
C code.
The handler is essentially a copy of smihandler.c, but it drops the TSEG
differences. It also doesn't rely on the SMM revision as the cpu code
should know what processor it is supported.
Ideally the CONFIG_SMM_TSEG option could be removed once the existing
users of that option transitioned away from tseg_relocate() and
smi_get_tseg_base().
The generic SMI callbacks are now not marked as weak in the
declaration so that there aren't unlinked references. The handler
has default implementations of the generic SMI callbacks which are
marked as weak. If an external compilation module has a strong symbol
the linker will use that instead of the link one.
Additionally, the parameters to the generic callbacks are dropped as
they don't seem to be used directly. The SMM runtime can provide the
necessary support if needed.
Change-Id: I1e2fed71a40b2eb03197697d29e9c4b246e3b25e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2693
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The Haswell parts use a PCH code named Lynx Point (Series 8). Therefore,
the southbridge support is included as well. The basis for this code is
the Sandybridge code. Management Engine, IRQ routing, and ACPI still requires
more attention, but this is a good starting point.
This code partially gets up through the romstage just before training
memory on a Haswell reference board.
Change-Id: If572d6c21ca051b486b82a924ca0ffe05c4d0ad4
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2616
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The original code attempted to reserve a space in RAM for coreboot to
remain resident. This turns out not to be needed, and breaks things
for the kernel since the exynos5250-smdk5250 kernel device tree starts
RAM at 0x40000000.
(This patch was originally by Gabe, I'm just uploading it)
Change-Id: I4536edaf8785d81a3ea008216a2d57549ce5edfb
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2698
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
This enables branch prediction. We can probably find a better place
to do this, but for now we'll do it in snow's romstage main().
Change-Id: I86c7b6bc9e897a7a432c490fb96a126e81b8ce72
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2701
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
PS_HOLD gets set in exynos' power_init().
Change-Id: Ib08e0afcad23cbd07dc7e3727fd958a1bc868b5a
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2700
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Call the power_init() function. We appear to have forgotten about it
when deprecating lowlevel_init_subsystems(), but it didn't seem to
cause problems until we got to doing more interesting stuff recently.
There are some clean-ups to do from the original code, such as not
attempting to configure I2C from PMIC code, which we'll get around
to in follow-up patches.
(Credit to Gabe for spotting this)
Change-Id: I6a59379e9323277d0b61469de9abe6d651ac5bfb
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2699
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This eliminates the use of do_div() in favor of using libgcc
functions.
This was tested by building and booting on Google Snow (ARMv7)
and Qemu (x86). printk()s which use division in vtxprintf() look good.
Change-Id: Icad001d84a3c05bfbf77098f3d644816280b4a4d
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2606
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This adds an enum for GPIO ports on the Exynos5. To make them
useful, they are assigned the absolute MMIO address where a
s5p_gpio_bank struct can point to.
Change-Id: Ia539ba52d7393501d434ba8fecde01da37b0d8aa
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2602
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
These are essential functions for setting up the display port and
framebuffer, and also enable such things as aux channel
communications. We do some very simple initialization in romstage,
mainly set a GPIO so that the graphics is powering up, but the complex
parts are done in the ramstage. This mirrors the way in which graphics
is done in the x86 size.
I've added a first pass at a real device, and put it in the mainboard
Kconfig, hoping for corrections. Because startup is so complex,
depending on device type, I've created a 'displayport' device that
removes some of the complexity and makes the flow *much* clearer. You
can actually follow the flow by looking at the code, which is not true
on other implementations. Since display port is perhaps the main port
used on these chips, that's a reasonable compromise. All parameters of
importance are now in the device tree.
Change-Id: I56400ec9016ecb8716ec5a5dae41fdfbfff4817a
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2570
Tested-by: build bot (Jenkins)
OK, this is tl;dr. But I need to write this in hopes we make
sure we don't put code like this into coreboot. Ever.
Our excuse in this case is that it was imported, not obviously wrong,
and easily changed. It made sense to get it in, make it work, then
do a cleanup pass, because changing everything up front is almost
impossible to debug.
The exynos code has bunch of base register values, e.g.
These are base addresses of things that look like a memory-mapped
struct. To get these to a pointer, they created the following macro,
which creates an inline function.
static inline unsigned int samsung_get_base_##device(void) \
{ \
return cpu_is_exynos5() ? EXYNOS5_##base : 0; \
}
And then invoke it 31 times in a .h file, e.g.:
SAMSUNG_BASE(clock, CLOCK_BASE)
to create 31 functions.
And then use it:
struct exynos5_clock *clk =
(struct exynos5_clock *)samsung_get_base_clock();
OK, what's wrong with this? It's easier to ask what's right with it. Answer: nothing.
I have a long list of what's wrong, and I may leave some things out,
but here goes:
1. the "function" can return a NULL if we're not on exynos5. Most uses of the code
don't check the return value.
2. And why would this function be running, if we're not on an exynos5? Why compile it in?
3. Note the cast everywhere a samsung_get_base_xxx is used.
The function returns an untyped variable, requiring the *user* to get two
things right: the cast, and the function invocation. One can replace that _clock(); with
_power(); in the code above, and they will be referencing the wrong registers, and
they'll never get an error!
We have a C compiler; use it to type data.
4. You're generating 31 functions using cpp each and every time the file is included.
The C compiler has to parse these each time. It's not at all like a simple cpp
macro which is only generated on use.
5. You can't tags or etags this code
6. In fact, any kind of analysis tool will be unable to do anything with this cpp magic.
That's only a partial list.
So what's the right way to do it? Just make typed constants, viz:
Or, since I expect people will want the lower case function syntax, I've left
it that way:
Now we've got something that is efficient, and we don't even need to protect with
any more.
Hence this change. We've got something that is type checked, does not require users to
cast on each use, will catch simple programming errors, can be analyzed with standard tools,
and builds faster.
So if we make a mistake:
struct exynos5_clock *clk =
samsung_get_base_adc();
We'll see it:
src/cpu/samsung/exynos5250/clock.c: In function 'get_pll_clk':
src/cpu/samsung/exynos5250/clock.c:183:3: error: initialization from incompatible pointer type [-Werror]
which we would not have seen before.
As a minor benefit, it shaves most of a second off the compilation.
Change-Id: Ie67bc4bc038a8dd1837b977d07332d7d7fd6be1f
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2582
Tested-by: build bot (Jenkins)
In the file `COPYING` in the coreboot repository and upstream [1]
just one space is used.
The following command was used to convert all files.
$ git grep -l 'MA 02' | xargs sed -i 's/MA 02/MA 02/'
[1] http://www.gnu.org/licenses/gpl-2.0.txt
Change-Id: Ic956dab2820a9e2ccb7841cab66966ba168f305f
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2490
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
It's been on for all boards per default since several years now
and the old code path probably doesn't even work anymore. Let's
just have one consistent way of doing things.
Change-Id: I58da7fe9b89a648d9a7165d37e0e35c88c06ac7e
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2547
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The ARM CPUs we know of don't have CPU microcode updates,
so don't show the selection in Kconfig.
Also simplify (and fix) the microcode selection in the Makefile
that would try to include microcode even though none is available.
Change-Id: I502d9b48d4449c1a759b5e90478ad37eef866406
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2540
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
According to both Haswell and the SandyBridge/Ivybridge
BWGs the save state area actually starts at 0x7c00 offset
from 0x8000. Update the em64t101_smm_state_save_area_t
structure and introduce a define for the offset.
Note: I have no idea what eptp is. It's just listed in the
haswell BWG. The offsets should not be changed.
Change-Id: I38d1d1469e30628a83f10b188ab2fe53d5a50e5a
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2515
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Commit »AMD S3: Introduce Kconfig variable 'S3_DATA_SIZE'« (22ec9f9a) [1]
introduced a check throwing an error if S3_DATA_SIZE isn't big enough.
However without CONFIG_HAVE_ACPI_RESUME the variable S3_DATA_SIZE
isn't defined at all and compilation will fail if s3_resume.h is
included.
This patch makes it again possible turn off HAVE_ACPI_RESUME relatively
easily in Parmer/Thatcher/Persimmon's Kconfig if you don't care about S3
and don't want flash writes on every boot.
[1] http://review.coreboot.org/2383
Change-Id: I999e4b7634bf172d8380fd14cba6f7f03468fee3
Signed-off-by: Jens Rottmann <JRottmann@LiPPERTembedded.de>
Reviewed-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-by: Marc Jones <marcj303@gmail.com>
Reviewed-on: http://review.coreboot.org/2528
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
This reverts commit ca6e1f6c04.
The packet size changes ends up corrupting the flash when booting
Persimmon. I did figure out that the maximum number of bytes that
can be sent is actually 8 bytes according to the sb800 spec. There
must be additional problems beyond that since setting the packet
size to 8 still causes problems.
Change-Id: Ieb24247cf79e95bb0e548c83601dfddffbf6be59
Signed-off-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-on: http://review.coreboot.org/2509
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-by: Zheng Bao <zheng.bao@amd.com>
Currently the size of the volatile storage for S3 reserved in the
image is hardcoded to 32768 bytes. Make that configurable by
introducing the Kconfig 'S3_DATA_SIZE'.
As the storage space is needed for storing non-volatile, volatile and
MTRR data, add a check if the size is big enough.
Change-Id: I9152797cf0045c8da48109a9d760e417717686db
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/2383
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
For whatever reason tabs got inserted in the license header text.
Remove one occurrence of that with the following command [1].
$ git grep -l 'MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.'$'\t' | xargs sed -i 's,MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.[ ]*,MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.\ \ ,'
[1] http://sed.sourceforge.net/grabbag/tutorials/sedfaq.txt
Change-Id: Iaf4ed32c32600c3b23c08f8754815b959b304882
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2460
Tested-by: build bot (Jenkins)
Reviewed-by: Jens Rottmann <JRottmann@LiPPERTembedded.de>
Reviewed-by: Cristian Măgherușan-Stanciu <cristi.magherusan@gmail.com>
The SDRAM base is fixed in hardware. It makes no sense to make it configurable.
The TEXT start is a magic number that should also be fixed, not settable.
Change-Id: Ie44cc5c8da1dc38fc00eb602c4a295b045ca5364
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2465
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Payloads, by design, can return. There's lots of mechanism in the payload code
to support it, and the chooser payload relies on it. Hence, we should not mark
the function call in exit_stage as noreturn.
Not all ARM have unified caches, and it's not always easy to tell what
to do. So we are very paranoid. Before we call between stages, we
should carefully flush the dcache to memory and invalidate the icache.
This may be more than is necessary on all architectures but it
doesn't really hurt for the most part.
So compile cache management code into all stages, and call the
flush dcache/invalidate icache from all stages.
Change-Id: Ib9cc625c4dfd2d7d4b3c69a74686cc655a9d6484
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2462
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This adds necessary device operations to add CPU and RAM resources.
Change-Id: Ief8f66627ef37f4fa786bfc3f7899529d3e5b037
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2419
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
REQUIRES_BLOB assumes that all blob files come from the 3rdparty directory,
builds failed when all files were configured to point to other sources.
This change modifies the blob mechanism so that cbfs-files can be tagged as
"required" with some specification what is missing.
If the configured files can't be found (wrong path, missing file), the build
system returns a list of descriptions, then aborts.
Change-Id: Icc128e3afcee8acf49bff9409b93af7769db3517
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/2418
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marcj303@gmail.com>
S3_DATA_POS defines address where the whole S3 data is stored.
Change-Id: I4155a0821e74a3653caaead890e5fec5677637aa
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/2438
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-by: Marc Jones <marcj303@gmail.com>
At least not in menuconfig. Move it after the endchoice.
Change-Id: I87d2f70e7c1fbe539cd78cb602a39335b2886d8d
Signed-off-by: Jens Rottmann <JRottmann@LiPPERTembedded.de>
Reviewed-on: http://review.coreboot.org/2443
Tested-by: build bot (Jenkins)
Reviewed-by: Peter Stuge <peter@stuge.se>
According to spi.c in src/southbridge/amd/agesa/hudson
readwrite = (bytesin + readoffby1) << 4 | bytesout;
We can see that Hudson limits the SPI programming data
packet size as 15.
We used to write data to SPI in dword mode. It didn't
take full advantage of the data packet size. We need to
leverage that to speed up programming time.
Change-Id: I615e3c8e754e58702247bc26cfffbedaf5827ea8
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/2306
Tested-by: build bot (Jenkins)
Reviewed-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
