Age | Commit message (Collapse) | Author |
|
Hardcoding the microcode filenames into the makefiles is great when
the microcode is in the blobs directory. When the microcode isn't
posted to the blobs directory, we need some method of supplying the
microcode binary into the build. This can of course be done manually
after the build has completed, as can be done with everything that
we're including in the ROM image. Instead of making life hard for
everyone though, let's just add a way to specify where the microcode
rom comes from.
BUG=chrome-os-partner:53013
Change-Id: I7c5127234809e8515906efa56c04af6005eecf0b
Signed-off-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://review.coreboot.org/16386
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Omar Pakker
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
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>
|
|
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>
|
|
The sequence to inject microcode updates is virtually the same for all
Intel CPUs. The same function is used to inject the update in both CBFS
and hardcoded cases, and in both of these cases, the microcode resides in
the ROM. This should be a safe change across the board.
The function which loaded compiled-in microcode is also removed here in
order to prevent it from being used in the future.
The dummy terminators from microcode need to be removed if this change is
to work when generating microcode from several microcode_blob.c files, as
is the case for older socketed CPUs. Removal of dummy terminators is done
in a subsequent patch.
Change-Id: I2cc8220cc4cd4a87aa7fc750e6c60ccdfa9986e9
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/4495
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@gmail.com>
|
|
This patch aims to improve the microcode in CBFS handling that was
brought by the last patches from Stefan and the Chromium team.
Choices in Kconfig
- 1) Generate microcode from tree (default)
- 2) Include external microcode file
- 3) Do not put microcode in CBFS
The idea is to give the user full control over including non-free
blobs in the final ROM image.
MICROCODE_INCLUDE_PATH Kconfig variable is eliminated. Microcode
is handled by a special class, cpu_microcode, as such:
cpu_microcode-y += microcode_file.c
MICROCODE_IN_CBFS should, in the future, be eliminated. Right now it is
needed by intel microcode updating. Once all intel cpus are converted to
cbfs updating, this variable can go away.
These files are then compiled and assembled into a binary CBFS file.
The advantage of doing it this way versus the current method is that
1) The rule is CPU-agnostic
2) Gives user more control over if and how to include microcode blobs
3) The rules for building the microcode binary are kept in
src/cpu/Makefile.inc, and thus would not clobber the other makefiles,
which are already overloaded and very difficult to navigate.
Change-Id: I38d0c9851691aa112e93031860e94895857ebb76
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/1245
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
When microcode storage in CBFS is enabled, the make system is supposed
to generate the microcode blob and place it into the generated ROM
image as a CBFS component.
The microcode source representation does not change: it is still an
array of 32 bit constants. This new addition compiles the array into a
separate object file and then strips all sections but data.
The raw data section is then included into CBFS as a file named
'microcode_blob.bin' of type 0x53, which is assigned to microcode
storage.
Change-Id: I84ae040be52f520b106e3471c7e391e64d7847d9
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/1295
Tested-by: build bot (Jenkins)
|
|
at the same time let the user specify sources instead
of object files:
- objs becomes ramstage-srcs
- initobjs becomes romstage-srcs
- driver becomes driver-srcs
- smmobj becomes smm-srcs
The user servicable parts are named accordingly:
ramstage-y, romstage-y, driver-y, smm-y
Also, the object file names are properly renamed now, using
.ramstage.o, .romstage.o, .driver.o, .smm.o suffixes consistently.
Remove stubbed out via/epia-m700 dsdt/ssdt files - they didn't
easily fit in the build system and aren't useful anyway.
Signed-off-by: Patrick Georgi <patrick.georgi@coresystems.de>
Acked-by: Stefan Reinauer <stepan@coreystems.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5886 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
|
|
Works on Kontron, qemu, and serengeti.
Signed-off-by: Patrick Georgi <patrick.georgi@coresystems.de>
tested on abuild only.
Acked-by: Ronald G. Minnich <rminnich@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4534 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
|