Age | Commit message (Collapse) | Author |
|
This patch introduces two new CBFS API functions which are equivalent to
cbfs_map() and cbfs_load(), respectively, with the difference that they
always operate on the read-only CBFS region ("COREBOOT" FMAP section).
Use it to replace some of the simple cases that needed to use
cbfs_locate_file_in_region().
Change-Id: I9c55b022b6502a333a9805ab0e4891dd7b97ef7f
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39306
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Currently the decision of whether or not to use mrc_cache in recovery
mode is made within the individual platforms' drivers (ie: fsp2.0,
fsp1.1, etc.). As this is not platform specific, but uses common
vboot infrastructure, the code can be unified and moved into
mrc_cache. The conditions are as follows:
1. If HAS_RECOVERY_MRC_CACHE, use mrc_cache data (unless retrain
switch is true)
2. If !HAS_RECOVERY_MRC_CACHE && VBOOT_STARTS_IN_BOOTBLOCK, this
means that memory training will occur after verified boot,
meaning that mrc_cache will be filled with data from executing
RW code. So in this case, we never want to use the training
data in the mrc_cache for recovery mode.
3. If !HAS_RECOVERY_MRC_CACHE && VBOOT_STARTS_IN_ROMSTAGE, this
means that memory training happens before verfied boot, meaning
that the mrc_cache data is generated by RO code, so it is safe
to use for a recovery boot.
4. Any platform that does not use vboot should be unaffected.
Additionally, we have removed the
MRC_CLEAR_NORMAL_CACHE_ON_RECOVERY_RETRAIN config because the
mrc_cache driver takes care of invalidating the mrc_cache data for
normal mode. If the platform:
1. !HAS_RECOVERY_MRC_CACHE, always invalidate mrc_cache data
2. HAS_RECOVERY_MRC_CACHE, only invalidate if retrain switch is set
BUG=b:150502246
BRANCH=None
TEST=1. run dut-control power_state:rec_force_mrc twice on lazor
ensure that memory retraining happens both times
run dut-control power_state:rec twice on lazor
ensure that memory retraining happens only first time
2. remove HAS_RECOVERY_MRC_CACHE from lazor Kconfig
boot twice to ensure caching of memory training occurred
on each boot.
Change-Id: I3875a7b4a4ba3c1aa8a3c1507b3993036a7155fc
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46855
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Remove unnecessary arrays, use unsigned types for non-negative values
and constify where possible. Also define NUM_CHANNELS and NUM_SLOTS.
Change-Id: Ie4eb79d9c48194538c0ee41dca48ea32798ad8c6
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46363
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Do not use `System Agent version` to refer to the MRC version, which is
what the register being printed contains under normal circumstances. Use
the code from Broadwell, which also happens to be indented with tabs.
Change-Id: I03b24a8e0e8676af7c5297dc3fc7bf60b9bbb088
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46371
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
Commit c2ee680 (sandybridge: Use calls rather than asm to call to MRC.)
did it for Sandy Bridge, and this commit does it for Haswell.
Tested on Asrock B85M Pro4, still boots with MRC.
Change-Id: Ic915ae2a30f99805b2c87df8f9a9586a74a40c29
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46370
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
Jenkins complains about it.
Change-Id: I20abdd01ca2b93e8a4de31664ff48651e7268d25
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46368
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
This allows using the macro in a loop, for instance.
Change-Id: Ice43e5db9b4244946afb7f3e55e0c646ac1feffb
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46362
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
Reading MAD_CHNL has no effect, so there's no need to read it here.
Change-Id: I8d2aa4787de7f54f49d161f61c9c0abaa811cb83
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46361
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
Create two new functions to fetch mrc_cache data (replacing
mrc_cache_get_current):
- mrc_cache_load_current: fetches the mrc_cache data and drops it into
the given buffer. This is useful for ARM platforms where the mmap
operation is very expensive.
- mrc_cache_mmap_leak: fetch the mrc_cache data and puts it into a
given buffer. This is useful for platforms where the mmap operation
is a no-op (like x86 platforms). As the name mentions, we are not
freeing the memory that we allocated with the mmap, so it is the
caller's responsibility to do so.
Additionally, we are replacing mrc_cache_latest with
mrc_cache_get_latest_slot_info, which does not check the validity of
the data when retrieving the current mrc_cache slot. This allows the
caller some flexibility in deciding where they want the mrc_cache data
stored (either in an mmaped region or at a given address).
BUG=b:150502246
BRANCH=None
TEST=Testing on a nami (x86) device:
reboot from ec console. Make sure memory training happens.
reboot from ec console. Make sure that we don't do training again.
Signed-off-by: Shelley Chen <shchen@google.com>
Change-Id: I259dd4f550719d821bbafa2d445cbae6ea22e988
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44006
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Fill in the maximum DRAM capacity and slot count read from CAPID0_A
registers on Sandy Bridge and Haswell.
While the register isn't part of the Core Series datasheet, it can be
found in the corresponding "Intel Open Source Graphics Programmer's
Reference" datasheets.
Note that the values for DDRSZ (maximum allowed memory size per channel)
need to be halved when only one DIMM per channel is supported. On mobile
platforms, all but quad-core processors are subject to this restriction.
Tested on Lenovo X230:
On Linux, verify that `dmidecode -t 16` reports the actual maximum
capacity (16 GiB) instead of the currently-installed capacity (4 GiB) or
the max capacity assuming two DIMMs per channel is possible (32 GiB).
Change-Id: I6e2346de1ffe52e8685276acbdbf25755f4cc162
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43971
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
|
|
Change-Id: Ice91a20470c107f7db0ac83301488ae5afed5a8b
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43584
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
Stefan thinks they don't add value.
Command used:
sed -i -e '/file is part of /d' $(git grep "file is part of " |egrep ":( */\*.*\*/\$|#|;#|-- | *\* )" | cut -d: -f1 |grep -v crossgcc |grep -v gcov | grep -v /elf.h |grep -v nvramtool)
The exceptions are for:
- crossgcc (patch file)
- gcov (imported from gcc)
- elf.h (imported from GNU's libc)
- nvramtool (more complicated header)
The removed lines are:
- fmt.Fprintln(f, "/* This file is part of the coreboot project. */")
-# This file is part of a set of unofficial pre-commit hooks available
-/* This file is part of coreboot */
-# This file is part of msrtool.
-/* This file is part of msrtool. */
- * This file is part of ncurses, designed to be appended after curses.h.in
-/* This file is part of pgtblgen. */
- * This file is part of the coreboot project.
- /* This file is part of the coreboot project. */
-# This file is part of the coreboot project.
-# This file is part of the coreboot project.
-## This file is part of the coreboot project.
--- This file is part of the coreboot project.
-/* This file is part of the coreboot project */
-/* This file is part of the coreboot project. */
-;## This file is part of the coreboot project.
-# This file is part of the coreboot project. It originated in the
- * This file is part of the coreinfo project.
-## This file is part of the coreinfo project.
- * This file is part of the depthcharge project.
-/* This file is part of the depthcharge project. */
-/* This file is part of the ectool project. */
- * This file is part of the GNU C Library.
- * This file is part of the libpayload project.
-## This file is part of the libpayload project.
-/* This file is part of the Linux kernel. */
-## This file is part of the superiotool project.
-/* This file is part of the superiotool project */
-/* This file is part of uio_usbdebug */
Change-Id: I82d872b3b337388c93d5f5bf704e9ee9e53ab3a9
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41194
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
vboot_recovery_mode_enabled() was recently changed to assert() when it
is called before vboot logic has run, because we cannot determine
whether we're going to be in recovery mode at that point and we wanted
to flush out existing uses that pretended that we could. Turns out there
are a bunch of uses like that, and there is some code that is shared
across configurations that can and those that can't.
This patch cleans them up to either remove checks that cannot return
true, or add explicit Kconfig guards to clarify that the code is shared.
This means that using a separate recovery MRC cache is no longer
supported on boards that use VBOOT_STARTS_IN_ROMSTAGE (this has already
been broken with CB:38780, but with this patch those boards will boot
again using their normal MRC caches rather than just die). Skipping the
MRC cache and always regenerating from scratch in recovery mode is
likewise no longer supported for VBOOT_STARTS_IN_ROMSTAGE.
For FSP1.1 boards, none of them support VBOOT_STARTS_IN_BOOTBLOCK and
that is unlikely to change in the future so we will just hardcode that
fact in Kconfig (otherwise, fsp1.1 raminit would also have to be fixed
to work around this issue).
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I31bfc7663724fdacab9955224dcaf650d1ec1c3c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39221
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Done with sed and God Lines. Only done for C-like code for now.
Change-Id: Id2cb642baa764fd69543460ba869cd822ab5acad
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40056
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
|
|
They're listed in AUTHORS and often incorrect anyway, for example:
- What's a "Copyright $year-present"?
- Which incarnation of Google (Inc, LLC, ...) is the current
copyright holder?
- People sometimes have their editor auto-add themselves to files even
though they only deleted stuff
- Or they let the editor automatically update the copyright year,
because why not?
- Who is the copyright holder "The coreboot project Authors"?
- Or "Generated Code"?
Sidestep all these issues by simply not putting these notices in
individual files, let's list all copyright holders in AUTHORS instead
and use the git history to deal with the rest.
Change-Id: I89b10076e0f4a4b3acd59160fb7abe349b228321
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39611
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
- Reformat some lines of code
- Put names to all used MCHBAR registers
- Move MCHBAR registers into a separate file, for future expansion
- Rewrite several comments
- Use C-style comments for consistency
- Rewrite some hex constants
- Use HOST_BRIDGE instead of PCI_DEV(0, 0, 0)
Tested, it does not change the binary of Asrock B85M Pro4.
Change-Id: I926289304acb834f9b13cd7902801798f8ee478a
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38434
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: I7dd6dd8e8debe1b6419625fca38670be375ef581
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39328
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
There are no symmetrical headerfiles for other arch/ and
after ROMCC_BOOTBLOCK and walkcbfs() removal this file
ended up empty.
Change-Id: Ice3047630ced1f1471775411b93be6383f53e8bb
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37886
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
|
|
Tested on Lenovo ThinkPad T440p.
Change-Id: I54b0c9dbb64819f0f502783b632470d27ed0b2b1
Signed-off-by: Iru Cai <mytbk920423@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34358
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: I4e7f74f67f03131fae205a93dae3d61eca9cc0c7
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32895
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Add a new post code POST_INVALID_VENDOR_BINARY, used when coreboot fails
to locate or validate a vendor supplied binary.
BUG=b:124401932
BRANCH=sarien
TEST=build coreboot for sarien and arcada platforms
Change-Id: Ib1e359d4e8772c37922b1b779135e58c73bff6b4
Signed-off-by: Keith Short <keithshort@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32772
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
|
|
Change-Id: I52ace93ae6f802723823955ac349ed54dc064aaa
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32784
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
|
|
Change-Id: I2f142cc80692e60eb0f81f57339a247f6ef4a524
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32611
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
Use already defined system_reset() function.
Change-Id: I436f62c4402736fb74c59d8b359d0b3963f0e659
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32494
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
Change-Id: Icae59721db530572d76035975a4e90686bf4fa65
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/30195
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
Change-Id: I6c77f4289b46646872731ef9c20dc115f0cf876d
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/29161
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This binary needs to be at a specific offset and will therefore always
be located in the COREBOOT fmap region.
This is needed when VBOOT_SEPARATE_VERSTAGE is selected.
Change-Id: Ia73d468ab23932f92331ef40b8e8066cef55af2c
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/26883
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Change-Id: Ib2bb6cc80ac2bdc389c60c7ffac4bba937f0fca8
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/26461
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
This driver uses an fmap region for the MRC cache instead of a CBFS
file which makes it easier to manage if one wants to write protect
it.
Change-Id: Iaa6b9f87c752088d70882fd05cb792e61a091391
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/23464
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
This commit just moves the vboot sources into
the security directory and fixes kconfig/makefile paths.
Fix vboot2 headers
Change-Id: Icd87f95640186f7a625242a3937e1dd13347eb60
Signed-off-by: Philipp Deppenwiese <zaolin@das-labor.org>
Reviewed-on: https://review.coreboot.org/22074
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
DIMMB's DDR width is in bit 20, not bit 19.
Change-Id: I48866d9243c2a576a02519724429801ae47c5644
Signed-off-by: Ryan Salsamendi <rsalsamendi@hotmail.com>
Reviewed-on: https://review.coreboot.org/20445
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
Maybe we could go on, but cbmem_add() failing is a very bad sign.
Should fix coverity CID 1376384 (Null pointer dereferences
(NULL_RETURNS)).
Change-Id: I330cee6db3540c6a9c408d56da43105de5d075f7
Found-by: Coverity Scan #1376384
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/20280
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
|
|
Populate a memory_info struct with PEI and SPD data,
in order to inject the CBMEM_INFO table necessary to
populate a type17 SMBIOS table.
On Broadwell, this is done by the MRC binary, but the older
Haswell MRC binary doesn't populate the pei_data struct with
all the info needed, so we have to pull it from the SPD.
Some values are hardcoded based on platform specifications.
Change-Id: Iea837d23f2c9c1c943e0db28cf81b265f054e9d1
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/19958
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
With VBOOT_VERIFY_FIRMWARE separated from CHROMEOS, move recovery and
developer mode check functions to vboot. Thus, get rid of the
BOOTMODE_STRAPS option which controlled these functions under src/lib.
BUG=chrome-os-partner:55639
Change-Id: Ia2571026ce8976856add01095cc6be415d2be22e
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/15868
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Remove code duplication and use the common function
store_current_mrc_cache instead.
No functionality is changed.
Tested on Sandybridge Lenovo T520.
Change-Id: I4aa5463f1b1d5e1afbe44b4bfc659524d86204db
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/15074
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
|
|
The mrc_cache definition and the struct mrc_container are the same
over all intel platforms.
Change-Id: I128a4b5693d27ead709325c597ffe68a0cc78bab
Signed-off-by: Alexander Couzens <lynxis@fe80.eu>
Reviewed-on: https://review.coreboot.org/13998
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
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>
|
|
A new CBFS API is introduced to allow making CBFS access
easier for providing multiple CBFS sources. That is achieved
by decoupling the cbfs source from a CBFS file. A CBFS
source is described by a descriptor. It contains the necessary
properties for walking a CBFS to locate a file. The CBFS
file is then decoupled from the CBFS descriptor in that it's
no longer needed to access the contents of the file.
All of this is accomplished using the regions infrastructure
by repsenting CBFS sources and files as region_devices. Because
region_devices can be chained together forming subregions this
allows one to decouple a CBFS source from a file. This also allows
one to provide CBFS files that came from other sources for
payload and/or stage loading.
The program loading takes advantage of those very properties
by allowing multiple sources for locating a program. Because of
this we can reduce the overhead of loading programs because
it's all done in the common code paths. Only locating the
program is per source.
Change-Id: I339b84fce95f03d1dbb63a0f54a26be5eb07f7c8
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9134
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
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>
|
|
In commit 72a8e5e751a7fa97c9d198f68cad49f9d9851669 the
Makefile's were updated to use named types for cbfs
file addition. However, the call sites were not checked to
ensure the types matched. Correct all call sites to use the
named types.
Change-Id: Ib9fa693ef517e3196a3f04e9c06db52a9116fee7
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9195
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
|
|
Change-Id: I8486e70615f4c404a342cb86963b5357a934c41d
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/7606
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
|
|
There is only one bit for memory width reporting, either x16 or
other. With x32 memory this code is reporting it as x8 so instead
report "x8 or x32" in this condition.
BUG=chrome-os-partner:23449
BRANCH=samus
TEST=emerge-samus chromeos-coreboot-samus
Change-Id: I2a7c49bcb8de19084947b9dc42b93140641886fc
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174120
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/6008
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
Move the implementation for recovery and developer modes from
vendorcode/google/chromes to lib/.
Change-Id: I33335fb282de2c7bc613dc58d6912c47f3b5c06c
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/4308
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
|
|
This gives us completely transparent low-level function to transmit
data.
Change-Id: I706791ff43d80a36a7252a4da0e6f3af92520db7
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5336
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
Only have one definition of get_top_of_ram() function and compile
it using __SIMPLE_DEVICE__ for both romstage and ramstage.
Implemented like this on intel/northbridge/gm45 already.
This also adds get_top_of_ram() to i945 ramstage.
Change-Id: Ia82cf6e47a4c929223ea3d8f233d606e6f5bf2f1
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3993
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
|
|
Change-Id: I5b93e5321e470f19ad22ca2cfdb1ebf3b340b252
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4659
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Tested-by: build bot (Jenkins)
|
|
If the firwmare is flashed and the MRC cache is blown away
then it is not possible to resume.
Right now this can be inferred from the event log but it can
be made very clear by adding a unique post code for this event.
1) boot falco
2) flash firmware
3) suspend and then resume
4) check for post code 0xef in log
0 | 2013-08-08 16:27:47 | Log area cleared | 4096
1 | 2013-08-08 16:27:47 | ACPI Enter | S3
2 | 2013-08-08 16:27:55 | System boot | 48
3 | 2013-08-08 16:27:55 | Last post code in previous boot | 0xef | Resume Failure
4 | 2013-08-08 16:27:55 | System Reset
5 | 2013-08-08 16:27:55 | ACPI Wake | S5
Change-Id: I7602d9eef85d3b764781990249ae32b84fe84134
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/65259
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4458
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
It is expected this will always be a casted get_top_of_ram() call
on x86, no reason to do that under chipset.
Change-Id: I3a49abe13ca44bf4ca1e26d1b3baf954bc5a29b7
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3972
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
|
|
Convert the existing haswell code to support reloctable ramstage
to use dynamic cbmem. This patch always selects DYNAMIC_CBMEM as
this option is a hard requirement for relocatable ramstage.
Aside from converting a few new API calls, a cbmem_top()
implementation is added which is defined to be at the begining of the
TSEG region. Also, use the dynamic cbmem library for allocating a
stack in ram for romstage after CAR is torn down.
Utilizing dynamic cbmem does mean that the cmem field in the gnvs
chromeos acpi table is now 0. Also, the memconsole driver in the kernel
won't be able to find the memconsole because the cbmem structure
changed.
Change-Id: I7cf98d15b97ad82abacfb36ec37b004ce4605c38
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2850
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Here's the great news: From now on you don't have to worry about
hitting the right io.h include anymore. Just forget about romcc_io.h
and use io.h instead. This cleanup has a number of advantages, like
you don't have to guard device/ includes for SMM and pre RAM
anymore. This allows to get rid of a number of ifdefs and will
generally make the code more readable and understandable.
Potentially in the future some of the code in the io.h __PRE_RAM__
path should move to device.h or other device/ includes instead,
but that's another incremental change.
Change-Id: I356f06110e2e355e9a5b4b08c132591f36fec7d9
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2872
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>
|
|
This structure is not used nor the variable being instantiated on the
stack. Remove them.
Change-Id: If3abe2dd77104eff49665dd33570b07179bf34f5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2753
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
There was a mix of setup code sprinkled across the various components:
southbridge code in the northbridge, etc. This commit reorganizes the
code so that northbridge code doesn't initialize southbridge components.
Additionally, the calling dram initialization no longer calls out to ME
code. The main() function in the mainboard calls the necessary ME
functions before and after dram initialization.
The biggest change is the addition of an early_pch_init() function
which initializes the BARs, GPIOs, and RCBA configuration. It is also
responsible for reporting back to the caller if the board is being
woken up from S3. The one sequence difference is that the RCBA config
is performed before claling the reference code.
Lastly the rcba configuration was changed to be table driven so that
different board/configurations can use the same code. It should be
possible to have board/configuration specific gpio and rcba
configuration while reusing the romstage code.
Change-Id: I830e41b426261dd686a2701ce054fc39f296dffa
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2681
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
The reference code sends the dram init done command to the ME.
Therefore, there is no need for coreboot to do this.
Change-Id: I6837d6c50bbb7db991f9d21fc9cdba76252c1b7b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2633
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
The intel-framework code has an updated pei_data structure.
Use the new structure and revision. Also, remove the scrambler
seed saving in CMOS since that appears to be handled in the saved
data from the reference code.
Change-Id: Ie09a0a00646ab040e8ceff922048981d055d5cd2
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2630
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>
|