Aaron Durbin (adurbin(a)google.com) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/9130
-gerrit
commit 8dde0c2d2dcaaf822402f870bd4a7a49f1960983
Author: Aaron Durbin <adurbin(a)chromium.org>
Date: Thu Mar 26 14:55:34 2015 -0500
x86: set smbios rom size based on CONFIG_ROM_SIZE
Instead of relying on the CBFS header's romsize field use
the CONFIG_ROM_SIZE Kconfig variable. That value is what is
used to create the rom file as it is. Therefore, just remove
the dependency.
Change-Id: If855d7378df20080061e27e4988e96aee233d1e0
Signed-off-by: Aaron Durbin <adurbin(a)chromium.org>
---
src/arch/x86/boot/smbios.c | 10 +---------
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/src/arch/x86/boot/smbios.c b/src/arch/x86/boot/smbios.c
index 4b96d61..4c3490d 100644
--- a/src/arch/x86/boot/smbios.c
+++ b/src/arch/x86/boot/smbios.c
@@ -28,7 +28,6 @@
#include <device/device.h>
#include <arch/cpu.h>
#include <cpu/x86/name.h>
-#include <cbfs_core.h>
#include <arch/byteorder.h>
#include <elog.h>
#include <memory_info.h>
@@ -258,14 +257,7 @@ static int smbios_write_type0(unsigned long *current, int handle)
vboot_data->vbt10 = (u32)t->eos + (version_offset - 1);
#endif
- {
- const struct cbfs_header *header;
- u32 romsize = CONFIG_ROM_SIZE;
- header = cbfs_get_header(CBFS_DEFAULT_MEDIA);
- if (header != CBFS_HEADER_INVALID_ADDRESS)
- romsize = ntohl(header->romsize);
- t->bios_rom_size = (romsize / 65535) - 1;
- }
+ t->bios_rom_size = (CONFIG_ROM_SIZE / 65535) - 1;
t->system_bios_major_release = 4;
t->bios_characteristics =
Aaron Durbin (adurbin(a)google.com) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/8943
-gerrit
commit cff4f48929bca85f8470e7e83dd7515b3171fcc1
Author: Aaron Durbin <adurbin(a)chromium.org>
Date: Tue Mar 24 09:20:45 2015 -0500
coreboot: differentiate on early reliable writable globals
There is a big difference between the boards supported in coreboot
and the properties they provide within each stage during the bootflow.
The leads to core infrastructure relying on supporting the least
common denominator when writing APIs.
Therefore, provide PLATFORM_HAS_EARLY_WRITABLE_GLOBALS which indicates
that the platform has reliable writable global variables in the early
stages of boot. For x86 that would be romstage, and for the other
architetures which have SRAM it would encompass bootblock and romstage.
Change-Id: I2cefeaee0551ee241e138fcee0d199679002c3be
Signed-off-by: Aaron Durbin <adurbin(a)chromium.org>
---
src/Kconfig | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/src/Kconfig b/src/Kconfig
index 7aee478..2625266 100644
--- a/src/Kconfig
+++ b/src/Kconfig
@@ -293,6 +293,25 @@ config SYSTEM_TYPE_LAPTOP
default n
bool
+config PLATFORM_HAS_EARLY_WRITABLE_GLOBALS
+ bool
+ default y if !ARCH_X86
+ help
+ This option signals to the rest of the infrastructure that
+ the platform supports writable globals in bootblock and
+ romstage. Fox traditional x86 systems without any SRAM this
+ would mean cache-as-ram globals are migrated correctly from
+ the CAR area once memory is trained. After the migration the
+ variables are accessible using the CAR API. This behavior
+ puts such x86 systems on par with ARM and MIPS systems.
+
+config PLATFORM_NO_EARLY_WRITABLE_GLOBALS
+ bool
+ default y if !PLATFORM_HAS_EARLY_WRITABLE_GLOBALS
+ help
+ This is just the opposite of PLATFORM_HAS_EARLY_WRITABLE_GLOBALS
+ to enable cleaner Makefiles.
+
menu "Chipset"
comment "CPU"