2e9e50142f
There are some boards that do a significant amount of work after cache-as-ram is torn down but before ramstage is loaded. For example, using vboot to verify the ramstage is one such operation. However, there are pieces of code that are executed that reference global variables that are linked in the cache-as-ram region. If those variables are referenced after cache-as-ram is torn down then the values observed will most likely be incorrect. Therefore provide a Kconfig option to select cache-as-ram migration to memory using cbmem. This option is named CAR_MIGRATION. When enabled, the address of cache-as-ram variables may be obtained dynamically. Additionally, when cache-as-ram migration occurs the cache-as-ram data region for global variables is copied into cbmem. There are also automatic callbacks for other modules to perform their own migration, if necessary. BUG=chrome-os-partner:19342 BRANCH=none TEST=Built and booted. Noted that CAR values are not read incorrectly. Change-Id: Ie0104a6e24cc6430a575ee3691671900c36db0d9 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/51386 Reviewed-by: Stefan Reinauer <reinauer@google.com>
41 lines
1.7 KiB
Makefile
41 lines
1.7 KiB
Makefile
################################################################################
|
|
## Subdirectories
|
|
################################################################################
|
|
subdirs-y += amd
|
|
subdirs-y += armltd
|
|
subdirs-y += intel
|
|
subdirs-y += samsung
|
|
subdirs-y += via
|
|
subdirs-y += x86
|
|
|
|
################################################################################
|
|
## Rules for building the microcode blob in CBFS
|
|
################################################################################
|
|
|
|
# External microcode file, or are we generating one ?
|
|
ifeq ($(CONFIG_CPU_MICROCODE_CBFS_EXTERNAL), y)
|
|
cbfs-files-y += cpu_microcode_blob.bin
|
|
cpu_microcode_blob.bin-type = 0x53
|
|
cpu_microcode_blob.bin-file = $(call strip_quotes,$(CONFIG_CPU_MICROCODE_FILE))
|
|
endif
|
|
|
|
ifeq ($(CONFIG_CPU_MICROCODE_CBFS_GENERATE), y)
|
|
cbfs-files-y += cpu_microcode_blob.bin
|
|
cpu_microcode_blob.bin-type = 0x53
|
|
cpu_microcode_blob.bin-file = $(obj)/cpu_microcode_blob.bin
|
|
endif
|
|
|
|
# In case we have more than one "source" (cough) files containing microcode, we
|
|
# link them together in one large blob, so that we get all the microcode updates
|
|
# in one file. This makes it easier for objcopy in the final step.
|
|
# The --entry=0 is just here to suppress the LD warning. It does not affect the
|
|
# final microcode file.
|
|
$(obj)/cpu_microcode_blob.o: $$(cpu_microcode-objs)
|
|
@printf " LD $(subst $(obj)/,,$(@))\n"
|
|
$(LD) -static --entry=0 $< -o $@
|
|
|
|
# We have a lot of useless data in the large blob, and we are only interested in
|
|
# the data section, so we only copy that part to the final microcode file
|
|
$(obj)/cpu_microcode_blob.bin: $(obj)/cpu_microcode_blob.o
|
|
@printf " MICROCODE $(subst $(obj)/,,$(@))\n"
|
|
$(OBJCOPY) -j .data -O binary $< $@
|