Having CFLAGS with -Os disables -falign-function, for
unlucky builds this may delay entry to ramstage by 600ms.
Build the low-level IO functions aligned with -O2 instead.
Change-Id: Ice6781666a0834f1e8e60a0c93048ac8472f27d9
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/14414
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Allow the platform to override the input clock for the UART by
implementing the routine uart_platform_refclk and setting the Kconfig
value UART_OVERRIDE_REFCLK. Provide a default uart_platform_refclk
routine which is disabled when UART_OVERRIDE_REFCLK is selected. This
works around ROMCC not supporting weak routines.
Testing on Galileo:
* Edit the src/mainboard/intel/galileo/Makefile.inc file:
* Add "select ADD_FSP_PDAT_FILE"
* Add "select ADD_FSP_RAW_BIN"
* Add "select ADD_RMU_FILE"
* Place the FSP.bin file in the location specified by CONFIG_FSP_FILE
* Place the pdat.bin files in the location specified by
CONFIG_FSP_PDAT_FILE
* Place the rmu.bin file in the location specified by CONFIG_RMU_FILE
* Build EDK2 CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc to generate
UEFIPAYLOAD.fd
* Testing is successful when CorebootPayloadPkg is able to properly
initialize the serial port without using built-in values.
Change-Id: If4afc45a828e5ba935fecb6d95b239625e912d14
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/14612
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Previously, the XIP_ROM_SIZE Kconfig variable is used globally on
x86 platforms with the assumption that all chipsets utilize this
value. For the chipsets which do not use the variable it can lead
to unnecessary alignment constraints in cbfs for romstage. Therefore,
allow those chipsets a path to not be burdened by not passing
'-P $(XIP_ROM_SIZE)' to cbfstool when adding romstage.
Change-Id: Id8692df5ecec116a72b8e5886d86648ca959c78b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14625
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
There used to be a need for an empty smm_init() function
because initialize_cpus() called it even though nothing
called initialize_cpus(). However, garbage collection at
link time is implemented so there's no reason to provide an
empty function to satisfy a symbol that is completely culled
during link. Remove it.
Change-Id: Ic13c85f1d3d57e38e7132e4289a98a95829f765a
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14605
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@google.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
With all users converted to using the mp_ops callbacks there's
no need to expose that surface area. Therefore, keep it all
within the mp_init compilation unit.
Change-Id: Ia1cc5326c1fa5ffde86b90d805b8379f4e4f46cd
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14598
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@google.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
In order to reduce duplication of code use the common MP and SMM
initialization flow.
Change-Id: I80b5b94b62bdd001581eb56513a0d532fffb64e8
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14596
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@google.com>
In order to reduce code duplication provide a common flow
through callback functions that performs the multiprocessor
and optionally SMM initialization. The existing MP flight
records are utilized but a common flow is provided such
that the chipset/cpu only needs to provide a mp_ops
structure which has callbacks to gather info and provide
hooks at certain points in the sequence.
All current users of the MP code can be switched over to
this flow since there haven't been any flight records that
are overly complicated and long. After the conversion
has taken place most of the surface area of the MP
API can be hidden away within the compilation unit proper.
Change-Id: I6f70969631012982126f0d0d76e5fac6880c24f0
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14557
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Unconditionally provide the backup default SMM area API. There's no
reason to guard the symbols behind anything since linker garbage
collection is implemented. A board or chipset is free to use the
code or not without needing to select an option.
Change-Id: I14cf1318136a17f48ba5ae119507918190e25387
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14561
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
The SMM module loader code was guarded by CONFIG_SMM_TSEG,
however that's not necessary. It's up to the chipset to take
advantage of the SMM module loading. It'll get optimized out
if the code isn't used anyway so just expose the declarations.
Change-Id: I6ba1b91d0c84febd4f1a92737b3d7303ab61b343
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14560
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
The BSP and AP callback declarations both had an optional argument
that could be passed. In practice that functionality was never used
so drop it.
Change-Id: I47fa814a593b6c2ee164c88d255178d3fb71e8ce
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14556
Tested-by: build bot (Jenkins)
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Leroy P Leahy <leroy.p.leahy@intel.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Enable caching of BIOS region with variable MTRR. This is most
useful if enabled early such as in bootblock.
Change-Id: I39f33ca43f06fce26d1d48e706c97f097e3c10f1
Signed-off-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-on: https://review.coreboot.org/14480
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
The delay_tsc.c compilation unit used the C preprocessor
to conditionally compile different code paths. Instead of
guarding large blocks of code allow the compiler to optimize
out unreachable code.
Change-Id: I660c21d6f4099b0d7aefa84b14f1e68d6fd732c3
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14302
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
The delay_tsc.c code took different paths depending
__PRE_RAM__ being defined or not. Also, timer_monotonic_get()
was only compiled in a !__PRE_RAM__ environment. Clean up
the code paths by employing CAR_GLOBAL for the global state
which allows the same code to be used in all stages.
Lastly, handle apollolake fallout now that init_timer() is
not needed in placeholders.c.
Change-Id: Ia769fa71e2c9d8b11201a3896d117097f2cb7c56
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14301
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
The current code in delay_tsc.c uses globals and is heavily
guarded by a lot of preprocessor macros. In order to remove
__PRE_RAM__ constraints one needs to use CAR_GLOBAL for the
global variables. Therefore, abstract away direct access to
the globals such that CAR_GLOBAL can be easily employed.
Change-Id: I3350d1a762120476926c8d9f5f5a7aba138daf5f
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14300
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
It's not selected by any path so it's a dead option with
associated dead code. Remove the config option as well as
the code paths that were never used any longer.
Change-Id: Ie536eee54e5c63bd90192f413c69e0dd2fea9171
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14299
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-by: Myles Watson <mylesgw@gmail.com>
Add code for manipulating the GPIOs on the am335x. The API is patterned after
the one used for the Exynos SOCs.
Change-Id: I275317304bd0682f348f72f1c77ed5613065af3f
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: https://review.coreboot.org/3942
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
To avoid having to read/write raw addresses with magic constants,
this change adds data structures which represent the clock module
registers and some constants for how the clock module is used
currently.
Change-Id: I955dae39bbdabccf048a086e706a48c58f620ad4
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: https://review.coreboot.org/3941
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
The lint-stable-004-style-labels check tries to verify that labels in c
and asm files start at the first column, and don't have whitespace in
front of them.
This fixes the 2 actual violations of the lint check.
Change-Id: Ia11a90d7301e62a116c7a9ef9b4c2bc3f982b308
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/14193
Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins)
Certain chipsets don't have a memory-mapped boot media
so their code execution for stages prior to DRAM initialization
is backed by SRAM or cache-as-ram. The postcar stage/phase
handles the cache-as-ram situation where in order to tear down
cache-as-ram one needs to be executing out of a backing
store that isn't transient. By current definition, cache-as-ram
is volatile and tearing it down leads to its contents disappearing.
Therefore provide a shim layer, postcar, that's loaded into
memory and executed which does 2 things:
1. Tears down cache-as-ram with a chipset helper function.
2. Loads and runs ramstage.
Because those 2 things are executed out of ram there's no issue
of the code's backing store while executing the code that
tears down cache-as-ram. The current implementation makes no
assumption regarding cacheability of the DRAM itself. If the
chipset code wishes to cache DRAM for loading of the postcar
stage/phase then it's also up to the chipset to handle any
coherency issues pertaining to cache-as-ram destruction.
Change-Id: Ia58efdadd0b48f20cfe7de2f49ab462306c3a19b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14140
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Instead of hard-coding var mtrr numbers in code, use this function to
identify the first available variable mtrr. If no such mtrr is
available, the function will return -1.
Change-Id: I2a1e02cdb45c0ab7e30609641977471eaa2431fd
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/14115
Tested-by: build bot (Jenkins)
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
In order to make this work earlymtrr.c needed to be removed
from intel/truxton/romstage.c. It's not a ROMCC board so
there's no reason to be including .c files.
Change-Id: If4f5494a53773454b97b90fb856f7e52cadb3f44
Signed-off-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-on: https://review.coreboot.org/14094
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
I see no user of any of this code. Remove it.
Change-Id: I776cd3d9ac6578ecb0fe6d98f15611e4463afb7a
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14098
Tested-by: build bot (Jenkins)
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
The Intel i3100 northbridge code is the only user of
cache_ramstage(). Therefore, place it next to the sole
consumer.
Change-Id: If15fb8d84f98dce7f4de9e089ec33035622d8f74
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14097
Tested-by: build bot (Jenkins)
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Use UDELAY_IO selected by CPU_VIA_C7, so no manual inclusion
(or secondary UDELAY implementation) is needed
Change-Id: Ib086a1bfe8ffca5757bf553c5a62a45da7a410b6
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: https://review.coreboot.org/13782
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Instead of manually including udelay_io.c in each romstage,
select UDELAY_IO for all i440BX boards in the chipset.
Change-Id: I411191927f3fba1d0749edcf79378e8013fb195a
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: https://review.coreboot.org/13781
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
For all the chipsets which were performing the following sequence:
x86_setup_fixed_mtrrs();
x86_setup_var_mtrrs(cpuid_eax(0x80000008) & 0xff, 2);
Replace that with x86_setup_mtrrs_with_detect() since it is equivalent.
Change-Id: I9f362dbf38942d675f615d22b9e5770ce65e5a08
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/13936
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
UDELAY_IO is defined in src/cpu/x86/Kconfig, so it does
not need to be redefined in the AMD cpu or board Kconfigs.
Change-Id: I6676881c0ba5d1634230fc3d3c37da3afbc6fceb
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: https://review.coreboot.org/13780
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
The current MTRR API doesn't allow one to detect variable MTRRs
along with handling fixed MTRRs in one function call. Therefore,
add x86_setup_mtrrs_with_detect() to perform the same actions
as x86_setup_mtrrs() but always do the dynamic detection.
Change-Id: I443909691afa28ce11882e2beab12e836e5bcb3d
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/13935
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins)
Attempt to better document the symbol usage in car.ld for
cache-as-ram usage. Additionally, add _car_region_[start|end]
that completely covers the entire cache-as-ram region. The
_car_data_[start|end] symbols were renamed to
_car_relocatable_data_[start|end] in the hopes of making it
clearer that objects within there move. Lastly, all these
symbols were added to arch/symbols.h.
Change-Id: I1f1af4983804dc8521d0427f43381bde6d23a060
Signed-off-by: Andrey Petrov <andrey.petrov@intel.com>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/13804
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Instead of keeping track of all the combinations of entry points
depending on the stage and other options just use _start. That way,
there's no need to update the arch/header.ld for complicated cases
as _start is always the entry point for a stage.
Change-Id: I7795a5ee1caba92ab533bdb8c3ad80294901a48b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/13882
Tested-by: build bot (Jenkins)
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
In order to align the entry points for the various stages
on x86 to _start one needs to rename the reset_vector symbol.
The section is the same; it's just a symbol change.
Change-Id: I0e6bbf1da04a6e248781a9c222a146725c34268a
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/13881
Tested-by: build bot (Jenkins)
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
In order to avoid collisions with other _start symbols while
grepping and future ones be explicit about which _start this
one is: the 16-bit one only used by the reset vector in the
bootblock.
Change-Id: I6d7580596c0e6602a87fb158633ce9d45910cec2
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/13880
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
It's helpful to see the reset vector in objdump output. Without
it being marked executable it doesn't get displayed.
Change-Id: I85cb72ea0727d3f3c2186ae20b9c5cfe5d23aeed
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/13879
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
Patrick at least indicated this jump after the reset
vector jump was a remnant from some construct used long
ago in the project. It's not longer used (nor could I find
where it was). Therefore, remove it.
Change-Id: I31512c66a9144267739b08d5f9659c4fcde1b794
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/13878
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
Change-Id: I17ba5a85fecf08ab9970a57c7696525287bbc5a8
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/13745
Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
These license headers were either not compliant with the coreboot
standard or were missing completely.
Change-Id: I0c46ad9ba7f3d950b3eff96ee6e9c36acbf1a3a5
Signed-off-by: Damien Roth <yves.r.roth@gmail.com>
Reviewed-on: https://review.coreboot.org/13288
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
These licence headers were not compliant with the coreboot standard.
Change-Id: I85bb5f971ab1f8ac3e9589f712370fbf09716b67
Signed-off-by: Damien Roth <yves.r.roth@gmail.com>
Reviewed-on: https://review.coreboot.org/13287
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
This is needed in a follow-on patch to enable udelay() handling on
apollolake, which is a dependency for the console code.
Change-Id: I7da6a060a91b83f3b32c5c5d269c102ce7ae3b8a
Signed-off-by: Alexandru Gagniuc <alexandrux.gagniuc@intel.com>
Reviewed-on: https://review.coreboot.org/13302
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The previous usage of the intel microcode support supported using
the library under ROMCC and ramstage. Allow for microcode support
to be used in normal C-based romstage as well by:
1. Only using walkcbfs when ROMCC is defined.
2. Only using spinlocks if !__PRE_RAM__
The header file now unconditionally exposes the declarations
of the supporting functions.
Change-Id: I903578bcb4422b4c050903c53b60372b64b79af1
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/13611
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
On certain systems and CPUs Core Performance Boost (CPB) may cause
sporadic system lockups. This issue is also somewhat known on the
various proprietary BIOSes, therefore it seems to be a hardware
incompatibility when present.
Allow the user to disable CBP if needed.
Change-Id: Id6395d067d48963f6c084ad0bf79e23419af24d8
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/13172
Tested-by: build bot (Jenkins)
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Kyösti Mälkki