Age | Commit message (Collapse) | Author |
|
When rmodule is loaded CPU stack alignment is only guaranteed
to 4kiB. Implementation of cpu_info() requires that each
CPU sees its stack aligned to CONFIG_STACK_SIZE.
Add one spare CPU for the stack reserve, such that alignment can
be enforced runtime.
Change-Id: Ie04956c64df0dc7bb156002d3d4f2629f92b340e
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/26302
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This function returns APIC id for respective cpu core.
BUG=b:74436746
BRANCH=none
TEST=mp_get_apic_id() can be accessed in other files now.
Change-Id: I5c5eda8325f941ab84d8a3fe0dae64be71c44855
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/25620
Reviewed-by: Aamir Bohra <aamir.bohra@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: I801849fb31fe6958e3d9510da50e2e2dd351a98d
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/29304
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
A stack overrun has been observed on AMD64 CPUs during the SMM module
relocation process. Change the assumed required size from equaling the
save structure's size to a Kconfig symbol.
A value of 0x400 doubles the size used by AMD64 systems and maintains
the size used by EM64T.
BUG=b:118420852
TEST=S3 on Grunt and verify 0x2f000-0x30000 uncorrupted
Change-Id: Ib1d590ee4afb06ca649afd6ad253cdfd969ae777
Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-on: https://review.coreboot.org/29277
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Richard Spiegel <richard.spiegel@silverbackltd.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
Its spreading copies got out of sync. And as it is not a standard header
but used in commonlib code, it belongs into commonlib. While we are at
it, always include it via GCC's `-include` switch.
Some Windows and BSD quirk handling went into the util copies. We always
guard from redefinitions now to prevent further issues.
Change-Id: I850414e6db1d799dce71ff2dc044e6a000ad2552
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/28927
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Within procedure save_bsp_msrs, the structure pointer "msr_entry" is updated
every time procedure save_msr() is called. However, after the last call of
save_msr(), "msr_entry" is not used, thus causing a static analysis error.
Add a "(void)msr_entry;" at the end to avoid the static analysis error.
BUG=b:112253891
TEST=Build and boot grunt.
Change-Id: If0fb336fbf49eec3da255fadbe38b3a38768d0cf
Signed-off-by: Richard Spiegel <richard.spiegel@silverbackltd.com>
Reviewed-on: https://review.coreboot.org/27956
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
In procedure allocate_cpu_devices(), if structure pointer new is null skip
using the pointer. Add a "continue;" to skip using the pointer.
The issue was found by static analysis tool.
BUG=b:112253891
TEST=Build and boot grunt.
Change-Id: I7011fbfa0725f22a6dfbca6752e668eddac3463c
Signed-off-by: Richard Spiegel <richard.spiegel@silverbackltd.com>
Reviewed-on: https://review.coreboot.org/27951
Reviewed-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
BUG=none
TEST=none
Change-Id: Ic2d7bf5f5335894ede98dc7e6cc6a65e4897e487
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Reviewed-on: https://review.coreboot.org/27811
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Stoneyridge is running into a stack overflow in the SMM handler.
BUG=b:80539294
TEST=built on grunt
Change-Id: I94e385497bd93c3638c69fb08d9b843c3bbb55ce
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Reviewed-on: https://review.coreboot.org/27034
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Name the CPU device structure as per processor brand string.
Before logs use to look like:
APIC: 01 (unknown)
Now logs looks like(depending on CPU on which it is tested):
APIC: 01 (Intel(R) Core(TM) m3-7Y30 CPU @ 1.00GHz)
BUG=None
BRANCH=None
TEST= Build & boot Soraka.
Change-Id: I6af0e29bbbdb59406baeae32f7874ff9036a9c81
Signed-off-by: Naresh G Solanki <naresh.solanki@intel.com>
Reviewed-on: https://review.coreboot.org/26740
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This patch ensures that user can select a specific AP to run
a function.
BUG=b:74436746
BRANCH=none
TEST=Able to run functions over APs with argument.
Change-Id: Iff2f34900ce2a96ef6ff0779b651f25ebfc739ad
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/26034
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This patch ensures that user can pass a function with given argument
list to execute over APs.
BUG=b:74436746
BRANCH=none
TEST=Able to run functions over APs with argument.
Change-Id: I668b36752f6b21cb99cd1416c385d53e96117213
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/25725
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
In order to extend the MP callback infrastructure prepare for
easier changes by making the AP callback get signalled by a
single pointer to a local variable on the signaller's stack.
When the APs see the callback they will copy the structure
to a local variable and then set the acknowledgement by
clearing out the slot.
The reading and writing to the slots were implemented using inline
assembly which forces a memory access and a compiler barrier.
BUG=b:74436746
Change-Id: Ia46133a49c03ce3ce0e73ae3d30547316c7ec43c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/26043
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Now that __aligned is around, take advantage of it.
Change-Id: I93cdbe108d752088f34d3f5722dce5d9b90bcdc3
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/26022
Reviewed-by: Justin TerAvest <teravest@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
barrier_wait_timeout() was not used anywhere in the code. The
remaining two functions, barrier_wait() and release_barrier(), are
not used anywhere but the mp code.
Change-Id: If09991f95306becc68b6008ae6448695fb4a2dca
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/26021
Reviewed-by: Justin TerAvest <teravest@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
There might be certain requirement in user function where user
might not want to pass any timeout value, in those cases
run_ap_work() should consider infinity as timeout and perform
all APs initialization as per specification.
Set expire_us <= 0 to specify an infinite timeout.
BRANCH=none
BUG=b:74436746
TEST=run_ap_work() is running successfully with 0 expire_us.
Change-Id: Iacd67768c8a120f6a01baaa6817468f6b9a3b764
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/25622
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change f43adf0 (intel/common/block/cpu: Change post_cpus_init after
BS_DEV RESOURCES) moved post_cpus_init to BS_OS_RESUME for S3
path. This results in BSP timing out waiting for APs to be
parked. This change increases the time out value for APs to be parked
to 250ms. This value was chosen after running suspend-resume stress
test and capturing the maximum time taken for APs to be parked for
100 iterations. Typical values observed were ~150ms. Maximum value
observed was 152ms.
BUG=b:76442753
TEST=Verified for 100 iterations that suspend-resume does not run into
any AP park time out.
Change-Id: Id3e59db4fe7a5a2fb60357b05565bba89be1e00e
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/25422
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
|
|
Since the timeout in bsp_do_flight_plan is bumped up to 1 second, this
change adds a print to indicate the amount of time it takes for all the
APs to check-in.
TEST=Verified on Nami that it prints:
"bsp_do_flight_plan done after 395 msecs."
Change-Id: I4c8380e94305ed58453ed18b341b3b923949d7a8
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/25044
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Currently, the AP check-in time-out in bsp_do_flight_plan is set to
100ms. However, as the number of APs increases, contention could
increase especially for resource like UART. This led to MP record
time-out issues on KBL platform with 7 APs and serial-console enabled
BIOS image.
This change increases the time-out value to 1 second to be on the safer
side and let APs check-in before continuing boot.
BUG=b:74085891
TEST=Verified that MP record time-out is not observed anymore on Nami.
Change-Id: I979c11a10e6888aef0f71b5632ea803a67bbb0ff
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/24965
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
AMD's fixed MTRRs have RdDram and WrDram bits that route memory
accesses to DRAM vs. MMIO. These are typically hidden for normal
operation by clearing SYS_CFG[19] (MtrrFixDramModEn). According to
BKDGs and AMD64 Programmer's Manual vol 2, this bit is clear at
reset, should be set for configuration during POST, then cleared for
normal operation.
Attempting to modify the RdDram and WrDram settings without unhiding
them causes a General Protection Fault. Add functions to enable and
disable MtrrFixDramModEn. Unhide/hide as necessary when copying or
writing the fixed MTRRs.
Finally, modify sipi_vector.S to enable the bits prior to writing
the fixed MTRRs and disable when complete.
This functionality is compiled out on non-AMD platforms.
BUG=b:68019051
TEST=Boot Kahlee, check steps with HDT
Change-Id: Ie195131ff752400eb886dfccc39b314b4fa6b3f3
Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-on: https://review.coreboot.org/23722
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Not all SMM save state sizes equate to having enough stack in the
permanent SMM handler. Therefore, ensure 1KiB of stack is available for
each cpu's stack. Intel's save state size is 1KiB, but AMD's save state
size is only 512. Therefore, decouple save state size from the per
cpu stack size.
BUG=b:70027919
Change-Id: I54b9e6f3cc0ad6ca3d7b60b2b422b5dc5a78a552
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/22950
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Justin TerAvest <teravest@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
The original purpose of adjust_cpu_apic_entry() was to set
up an APIC map. That map was effectively only used for mapping
*default* APIC id to CPU number in the SMM handler. The normal
AP startup path didn't need this mapping because it was whoever
won the race got the next cpu number. Instead of statically
calculating (and wrong) just initialize the default APIC id
map when the APs come online. Once the APs are online the SMM
handler is loaded and the mapping is utilized.
Change-Id: Idff3b8cfc17aef0729d3193b4499116a013b7930
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/21452
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
|
|
Also unify __attribute__ ((..)) to __attribute__((..)) and
handle ((__packed__)) like ((packed))
Change-Id: Ie60a51c3fa92b5009724a5b7c2932e361bf3490c
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: https://review.coreboot.org/15921
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
With the do while loop, it can be avoided do use an infinite loop with a
break condition inside.
Change-Id: I030f6782ad618b55112a2f0bac8dda08b497a9f1
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-on: https://review.coreboot.org/20269
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The previous implementation was using a for loop. By it's
very definition the last statement in the for loop declaration
is done at the end of the loop. Therefore, if the conditional for
breaking out of the for loop because of a timeout would always
see a value of 0 for the number of APs accepted. Correct this
by changing to a while loop with an explicit timeout condition
at the end of the loop.
Change-Id: I503953c46c2a65f7e264ed49c94c0a46d6c41c57
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/20225
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
In case something goes wrong on one of the
cpus, add the ability to use a barrier with
timeout so that other cpus don't wait forever.
Remove static from barrier wait and release.
BUG=chrome-os-partner:59875
BRANCH=reef
TEST=None
Change-Id: Iab6bd30ddf7632c7a5785b338798960c26016b24
Signed-off-by: Bora Guvendik <bora.guvendik@intel.com>
Reviewed-on: https://review.coreboot.org/18107
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Fix the following warnings detected by checkpatch.pl
WARNING: braces {} are not necessary for single statement blocks
WARNING: braces {} are not necessary for any arm of this statement
WARNING: else is not generally useful after a break or return
TEST=Build and run on Galileo Gen2
Change-Id: I2d6b22c66d52f5f2d24b15270ad4b52894adebc2
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://review.coreboot.org/18842
Tested-by: build bot (Jenkins)
Reviewed-by: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Fix the following error and warning detected by checkpatch.pl:
ERROR: code indent should use tabs where possible
WARNING: please, no spaces at the start of a line
TEST=Build and run on Galileo Gen2
Change-Id: Ie6e4dd4c3eb0d2c44ecd008740dfc348d496fe78
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://review.coreboot.org/18841
Tested-by: build bot (Jenkins)
Reviewed-by: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
There are circumstances where the APs need to run a piece of
code later in the boot flow. The current MP init just parks
the APs after MP init is completed so there's not an opportunity
to target running a piece of code on all the APs at a later time.
Therefore, provide an option, PARALLEL_MP_AP_WORK, that allows
the APs to perform callbacks.
BUG=chrome-os-partner:60657
BRANCH=reef
Change-Id: I849ecfdd6641dd9424943e246317cd1996ef1ba6
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/17745
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Lijian Zhao <lijian.zhao@intel.com>
|
|
Change-Id: I82e0736dc6b44cfcc57cdfdc786c85c4b6882260
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/16276
Tested-by: build bot (Jenkins)
Reviewed-by: Omar Pakker
|
|
Change-Id: I58d5c16de796a91fa14d8db78722024266c09a94
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/15934
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@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 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>
|
|
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>
|
|
The error informing the user that the CPU device cannot be
allocated has a typo incorrectly spelling "allocate" as
"allocte".
TEST=Compiled
Change-Id: I2a6bad56133e375e2fd6a670593791414bf0dc2c
Signed-off-by: Jacob Laska <jlaska91@gmail.com>
Reviewed-on: https://review.coreboot.org/13030
Tested-by: build bot (Jenkins)
Reviewed-by: Ben Frisch <bfrisch@xes-inc.com>
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
It encourages users from writing to the FSF without giving an address.
Linux also prefers to drop that and their checkpatch.pl (that we
imported) looks out for that.
This is the result of util/scripts/no-fsf-addresses.sh with no further
editing.
Change-Id: Ie96faea295fe001911d77dbc51e9a6789558fbd6
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/11888
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
We use UNDERSCORE_CASE. For the MTRR macros that refer to an MSR,
we also remove the _MSR suffix, as they are, by definition, MSRs.
Change-Id: Id4483a75d62cf1b478a9105ee98a8f55140ce0ef
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11761
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
|
|
As per discussion with lawyers[tm], it's not a good idea to
shorten the license header too much - not for legal reasons
but because there are tools that look for them, and giving
them a standard pattern simplifies things.
However, we got confirmation that we don't have to update
every file ever added to coreboot whenever the FSF gets a
new lease, but can drop the address instead.
util/kconfig is excluded because that's imported code that
we may want to synchronize every now and then.
$ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, *MA[, ]*02110-1301[, ]*USA:Foundation, Inc.:" {} +
$ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin Street, Suite 500, Boston, MA 02110-1335, USA:Foundation, Inc.:" {} +
$ find * -type f -exec sed -i "s:Foundation, Inc., 59 Temple Place[-, ]*Suite 330, Boston, MA *02111-1307[, ]*USA:Foundation, Inc.:" {} +
$ find * -type f -exec sed -i "s:Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.:Foundation, Inc.:" {} +
$ find * -type f
-a \! -name \*.patch \
-a \! -name \*_shipped \
-a \! -name LICENSE_GPL \
-a \! -name LGPL.txt \
-a \! -name COPYING \
-a \! -name DISCLAIMER \
-exec sed -i "/Foundation, Inc./ N;s:Foundation, Inc.* USA\.* *:Foundation, Inc. :;s:Foundation, Inc. $:Foundation, Inc.:" {} +
Change-Id: Icc968a5a5f3a5df8d32b940f9cdb35350654bef9
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/9233
Tested-by: build bot (Jenkins)
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
|
|
This patch creates a new mechanism to define the static memory layout
(primarily in SRAM) for a given board, superseding the brittle mass of
Kconfigs that we were using before. The core part is a memlayout.ld file
in the mainboard directory (although boards are expected to just include
the SoC default in most cases), which is the primary linker script for
all stages (though not rmodules for now). It uses preprocessor macros
from <memlayout.h> to form a different valid linker script for all
stages while looking like a declarative, boilerplate-free map of memory
addresses to the programmer. Linker asserts will automatically guarantee
that the defined regions cannot overlap. Stages are defined with a
maximum size that will be enforced by the linker. The file serves to
both define and document the memory layout, so that the documentation
cannot go missing or out of date.
The mechanism is implemented for all boards in the ARM, ARM64 and MIPS
architectures, and should be extended onto all systems using SRAM in the
future. The CAR/XIP environment on x86 has very different requirements
and the layout is generally not as static, so it will stay like it is
and be unaffected by this patch (save for aligning some symbol names for
consistency and sharing the new common ramstage linker script include).
BUG=None
TEST=Booted normally and in recovery mode, checked suspend/resume and
the CBMEM console on Falco, Blaze (both normal and vboot2), Pinky and
Pit. Compiled Ryu, Storm and Urara, manually compared the disassemblies
with ToT and looked for red flags.
Change-Id: Ifd2276417f2036cbe9c056f17e42f051bcd20e81
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: f1e2028e7ebceeb2d71ff366150a37564595e614
Original-Change-Id: I005506add4e8fcdb74db6d5e6cb2d4cb1bd3cda5
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/213370
Reviewed-on: http://review.coreboot.org/9283
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Tauner <stefan.tauner@gmx.at>
Reviewed-by: Aaron Durbin <adurbin@google.com>
|
|
We relocate GDT to CBMEM, this can be done late in ramstage.
Note: We currently do this for BSP CPU only.
Change-Id: I626faaf22f846433f25ca2253d6a2a5230f50b6b
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/7858
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
|
|
Change-Id: Id88bb4367d6045f6fbf185f0562ac72c04ee5f84
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: http://review.coreboot.org/7146
Tested-by: build bot (Jenkins)
|
|
Change-Id: I9004f34ba0c13b4489b26ac8c1476d00a6c6d01d
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/6207
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
|
|
In order for the cpu code to start SMM relocation 2 new
functions are added to be shared:
- void smm_initiate_relocation_parallel()
- void smm_initiate_relocation()
The both initiate an SMI on the currently running cpu.
The 2 variants allow for parallel relocation or serialized
relocation.
BUG=chrome-os-partner:22862
BRANCH=None
TEST=Built and booted rambi using these functions.
Change-Id: I325777bac27e9a0efc3f54f7223c38310604c5a2
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/173982
Reviewed-on: http://review.coreboot.org/4891
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
|
|
Provide a common entry point for bringing up the APs
in parallel. This work is based off of the Haswell one
which can be moved over to this in the future. The APs
are brought up and have the BSP's MTRRs duplicated in
their own MTRRs. Additionally, Microcode is loaded before
enabling caching. However, the current microcode loading
support assumes Intel's mechanism.
The infrastructure provides a notion of a flight plan
for the BSP and APs. This allows for flexibility in the
order of operations for a given architecture/chip without
providing any specific policy. Therefore, the chipset
caller can provide the order that is required.
BUG=chrome-os-partner:22862
BRANCH=None
TEST=Built and booted on rambi with baytrail specific patches.
Change-Id: I0539047a1b24c13ef278695737cdba3b9344c820
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/173703
Reviewed-on: http://review.coreboot.org/4888
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
|