Arthur Heymans has uploaded this change for review. ( https://review.coreboot.org/c/coreboot/+/36564 )
Change subject: [TESTONLY]cpu/intel/socket_mPGA604: Run romstage from CAR
......................................................................
[TESTONLY]cpu/intel/socket_mPGA604: Run romstage from CAR
With a pentium 4 CPU running WP XIP is not possible. To speed up
execution copying romstage to CAR might work?
TEST: does it boot? is it faster?
Change-Id: I4c35d09b87b545944a4465ff695953d1e8a811e4
Signed-off-by: Arthur Heymans <arthur(a)aheymans.xyz>
---
M src/arch/x86/memlayout.ld
M src/cpu/intel/car/p4-netburst/cache_as_ram.S
M src/cpu/intel/socket_mPGA604/Kconfig
3 files changed, 20 insertions(+), 3 deletions(-)
git pull ssh://review.coreboot.org:29418/coreboot refs/changes/64/36564/1
diff --git a/src/arch/x86/memlayout.ld b/src/arch/x86/memlayout.ld
index 9fd9889..ed89894 100644
--- a/src/arch/x86/memlayout.ld
+++ b/src/arch/x86/memlayout.ld
@@ -39,7 +39,7 @@
#elif ENV_ROMSTAGE
/* The 1M size is not allocated. It's just for basic size checking.
* Link at 32MiB address and rely on cbfstool to relocate to XIP. */
- ROMSTAGE(CONFIG_ROMSTAGE_ADDR, 1M)
+ ROMSTAGE(CONFIG_ROMSTAGE_ADDR, CONFIG_DCACHE_ROMSTAGE_SIZE)
#include EARLY_MEMLAYOUT
#elif ENV_VERSTAGE
diff --git a/src/cpu/intel/car/p4-netburst/cache_as_ram.S b/src/cpu/intel/car/p4-netburst/cache_as_ram.S
index 2cd0c5e..fdb5ddc 100644
--- a/src/cpu/intel/car/p4-netburst/cache_as_ram.S
+++ b/src/cpu/intel/car/p4-netburst/cache_as_ram.S
@@ -23,9 +23,17 @@
.set ap_sipi_vector_in_rom, 0xff
#endif
-#define CACHE_AS_RAM_SIZE CONFIG_DCACHE_RAM_SIZE
+#define CACHE_AS_RAM_SIZE (CONFIG_DCACHE_RAM_SIZE + CONFIG_DCACHE_ROMSTAGE_SIZE)
#define CACHE_AS_RAM_BASE CONFIG_DCACHE_RAM_BASE
+#if (CACHE_AS_RAM_BASE & (CACHE_AS_RAM_SIZE - 1))
+#error "CONFIG_DCACHE_RAM_BASE is not aligned!"
+#endif
+
+#if ((CACHE_AS_RAM_SIZE & (CACHE_AS_RAM_SIZE - 1)) != 0)
+#error "Cache-as-Ram size must be a power of 2!"
+#endif
+
#if CONFIG(C_ENVIRONMENT_BOOTBLOCK)
#if ((CONFIG_C_ENV_BOOTBLOCK_SIZE & (CONFIG_C_ENV_BOOTBLOCK_SIZE - 1)) != 0)
#error "CONFIG_C_ENV_BOOTBLOCK_SIZE must be a power of 2!"
diff --git a/src/cpu/intel/socket_mPGA604/Kconfig b/src/cpu/intel/socket_mPGA604/Kconfig
index 4ec46e0..5f9eb9c 100644
--- a/src/cpu/intel/socket_mPGA604/Kconfig
+++ b/src/cpu/intel/socket_mPGA604/Kconfig
@@ -15,6 +15,7 @@
select C_ENVIRONMENT_BOOTBLOCK
select CPU_INTEL_COMMON
select CPU_INTEL_COMMON_TIMEBASE
+ select NO_XIP_EARLY_STAGES
# mPGA604 are usually Intel Netburst CPUs which should have SSE2
# but the ramtest.c code on the Dell S1850 seems to choke on
@@ -25,7 +26,7 @@
config DCACHE_RAM_BASE
hex
- default 0xfefc0000
+ default 0xfef0000
config DCACHE_RAM_SIZE
hex
@@ -35,4 +36,12 @@
hex
default 0x2000
+config DCACHE_ROMSTAGE_SIZE
+ hex
+ default 0xc000
+
+config ROMSTAGE_ADRR
+ hex
+ default 0xfef4000
+
endif # CPU_INTEL_SOCKET_MPGA604
--
To view, visit https://review.coreboot.org/c/coreboot/+/36564
To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings
Gerrit-Project: coreboot
Gerrit-Branch: master
Gerrit-Change-Id: I4c35d09b87b545944a4465ff695953d1e8a811e4
Gerrit-Change-Number: 36564
Gerrit-PatchSet: 1
Gerrit-Owner: Arthur Heymans <arthur(a)aheymans.xyz>
Gerrit-MessageType: newchange
Hello Aaron Durbin, Patrick Rudolph, Arthur Heymans, Michael Niewöhner, Duncan Laurie, David Wu, Furquan Shaikh,
I'd like you to do a code review. Please visit
https://review.coreboot.org/c/coreboot/+/36328
to review the following change.
Change subject: [RFC, scratch] Documentation/fsp: Start discussion around FSP-S issues
......................................................................
[RFC, scratch] Documentation/fsp: Start discussion around FSP-S issues
To get some discussion started, list some heavy issues with FSP(-S).
I've copy pasted some things together, and added a few words on top
and bottom. Not sure yet, where this should lead. To convince Intel
to contribute open-source code on their own, we might want to add
a list of initialization steps, that should be open.
Feel free to amend this commit in any way :)
Change-Id: Ied0d8ad60fa487272a05fc73b16a7c343cc4d993
Signed-off-by: Nico Huber <nico.huber(a)secunet.com>
---
A Documentation/fsp/fsp-s_discussion.md
1 file changed, 165 insertions(+), 0 deletions(-)
git pull ssh://review.coreboot.org:29418/coreboot refs/changes/28/36328/1
diff --git a/Documentation/fsp/fsp-s_discussion.md b/Documentation/fsp/fsp-s_discussion.md
new file mode 100644
index 0000000..7ac649a
--- /dev/null
+++ b/Documentation/fsp/fsp-s_discussion.md
@@ -0,0 +1,165 @@
+Introduction
+============
+
+*FSP* is an ABI that allows silicon vendors to provide pre-compiled
+binaries of their silicon-initialization code for the integration
+into firmware frameworks such as coreboot. Current, 2.x versions
+of *FSP* describe three binaries with rough responsibilities:
+
+* `FSP-T`: Sets up a temporary RAM environment (usually some sort
+ of Cache as RAM, CAR) among other things.
+
+* `FSP-M`: Initializes the memory (DRAM) controller, among other
+ things.
+
+* `FSP-S`: Performs various silicon-initialization steps left.
+
+However, what operations these binaries perform exactly and what
+operations are left to the firmware framework, is neither specified
+nor documented.
+
+Historically, all these responsibilities were left to coreboot.
+Later, pre-compiled reference code for the memory-controller
+initialization was introduced, then for other silicon init, and
+finally there are attempts to replace coreboot's CAR setup with
+FSP-T.
+
+While the FSP-M integration saves coreboot developers time, because
+of the complex nature of the memory-controller initialization, the
+integration of FSP-S turns out to be harder than implementing the
+necessary code natively in coreboot. We'll discuss why that is the
+case and provide an incomplete list of issues with current FSP-S
+binaries.
+
+
+Bug Fixing
+----------
+
+Many companies rely on the pre-built FSP binaries. Yet, there is
+no common procedure to get bugs fixed or even acknowledged. This
+leads to an increase of workarounds in firmware frameworks,
+especially for older hardware generations.
+
+
+Lack of Documentation
+---------------------
+
+Many of the initialization steps performed by FSP-S are merely
+translating mainboard-specific configuration into register settings.
+This is reflected by a list of hundreds of configuration options of
+FSP-S. While these steps are quite simple, the additional translation
+from FSP options to register values heavily increases the integration
+costs. Not only are the register settings usually much better documented
+than their FSP counterparts, but FSP also uses different terms so that
+the existing hardware documentation often can't assist developers when
+dealing with FSP.
+
+FSP-S also performs locking of several registers so that they can't
+be written anymore afterwards. It is not documented what locks are
+set by FSP. This creates heavy security issues for multiple reasons:
+
+* One either has to assume that FSP doesn't perform any locking
+ and do it redundantly in the firmware framework, or expensively
+ test what is locked and keep doing so for every new FSP revision.
+
+* Some registers may be locked before they are configured in a
+ secure manner. This may result in workarounds in the firmware
+ framework to configure things early. Sometimes it's even
+ impossible to do so, because relevant information isn't
+ available yet.
+
+This shows that no matter the many options that are implemented in
+FSP-S, there will always be things that must be controlled by the
+firmware framework. Locking should either be a separate, last step
+in FSP, or be left entirely to the firmware framework. And most of
+all, the locking has to be documented.
+
+
+Arbitrary Interface Changes
+---------------------------
+
+Within coreboot, we try to keep code-compatibility with older hardware
+generations. The FSP ABI isn't stable, however. Even when the hardware
+doesn't change between minor platform updates, the configuration
+settings of FSP are sometimes adapted without backwards compatibility
+in mind. This increases costs, just to translate configuration data
+from one representation to another only to let FSP translate it again.
+In such cases, directly configuring registers from coreboot, would
+save two layers of indirection.
+
+Another problem is the disappearance of options in newer FSP releases.
+See [SpiFlashCfgLockDown UPD vanished after KBL]
+(https://github.com/IntelFsp/FSP/issues/25), for instance. Current
+coreboot code seems to still rely on this option. It boots, though,
+only security assumptions are broken. Which again shows, locking
+shouldn't be part of FSP, or at least optional.
+
+
+FSP Switches SAI
+----------------
+
+A problem that multiplies with the lack of documentation is that FSP-S
+switches to `POSTBOOT_SAI` on newer platforms. While it probably tries
+to achieve the opposite, this undermines firmware quality and security.
+
+* In some firmware frameworks FSP may run long before End-of-Post, this
+ means most of the framework runs with `POSTBOOT_SAI`.
+
+* In the EDS, implications of the SAI switch are _not_ documented.
+ Virtually for every register, it is unknown if it is still accessible
+ after the SAI switch. This seems to be a problem for developers both
+ inside and outside of Intel.
+
+* The SAI switch seems to force the firmware framework to do some things
+ in SMM. However, the use of SMM as a more privileged execution mode is
+ generally discouraged. This means FSP forces firmware development to
+ go backwards.
+
+Especially the lack of documentation leads to many bugs in firmware.
+Even Intel developers working on coreboot don't seem to know the
+implications of the SAI switch or lack the resources to re-evaluate
+all code wrt. the SAI switch.
+
+
+FSP Creates Legal Uncertainty
+-----------------------------
+
+Many companies sell coreboot together with FSP as part of their products.
+Especially, the function pointers to GPL code that were introduced with
+FSP 2.1 seem unprecedented. However, they could be compared with runtime
+linking which seems troubling.
+
+
+Mitigations
+-----------
+
+None of the listed issues would exist if FSP were open-source and the
+initialization steps could be integrated into coreboot, like they were
+before. An open-source approach would not only cut costs heavily but
+might also decrease time-to-market if the whole coreboot community
+could work together on new platforms.
+
+However, in the absence of such a firmware-development utopia, there
+may be more realistic approaches. As mentioned earlier, not all of FSP
+has a negative impact on development performance. FSP-M, for instance,
+rarely causes trouble. And due to its complex nature, it is no surprise
+if memory-controller initialization is kept secret. The configuration
+done by FSP-S, on the other hand, overlaps with many of coreboot's
+responsibilities. The few lines of code in FSP-S that help to get a
+mainboard running, don't outweigh the damage it does. However, one
+can't have the cherries without taking the whole menu, which takes
+years to digest.
+
+One approach could be to split FSP-S further up and identify parts
+that are necessarily closed source and parts that could as well be
+reimplemented in coreboot. However, if parts that are left closed
+source change the state of the execution environment (e.g. switch
+SAI), finalize any settings or raise legal concerns, the ABI would
+have to change to solve all aforementioned issues.
+
+Another approach could be to align older platforms with open-source
+coreboot, step by step. Currently, everything from Skylake on relies
+on FSP-S. However, it seems Intel has already abandoned development
+for this platform (while the coreboot integration was never finished).
+It would seem reasonable to release abandoned code to the public, or
+at least clear existing documentation for older platforms from NDAs.
--
To view, visit https://review.coreboot.org/c/coreboot/+/36328
To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings
Gerrit-Project: coreboot
Gerrit-Branch: master
Gerrit-Change-Id: Ied0d8ad60fa487272a05fc73b16a7c343cc4d993
Gerrit-Change-Number: 36328
Gerrit-PatchSet: 1
Gerrit-Owner: Nico Huber <nico.h(a)gmx.de>
Gerrit-Reviewer: Aaron Durbin <adurbin(a)chromium.org>
Gerrit-Reviewer: Arthur Heymans <arthur(a)aheymans.xyz>
Gerrit-Reviewer: David Wu <david_wu(a)quantatw.com>
Gerrit-Reviewer: Duncan Laurie <dlaurie(a)chromium.org>
Gerrit-Reviewer: Furquan Shaikh <furquan(a)google.com>
Gerrit-Reviewer: Michael Niewöhner
Gerrit-Reviewer: Patrick Rudolph <siro(a)das-labor.org>
Gerrit-MessageType: newchange
junaid has uploaded this change for review. ( https://review.coreboot.org/c/coreboot/+/30798
Change subject: for review d945gclf/Kconig and devicetree.cb . these files are modified according to the superIO chip Winbond w83627DHG
......................................................................
for review d945gclf/Kconig and devicetree.cb . these files are modified according to the superIO chip Winbond w83627DHG
Change-Id: I1449d9351bd1b76ecad16e6d81c501c1d4dd80f5
Signed-off-by: junaid <junaidimpex(a)gmail.com>
---
M src/mainboard/intel/d945gclf/Kconfig
M src/mainboard/intel/d945gclf/devicetree.cb
2 files changed, 37 insertions(+), 38 deletions(-)
git pull ssh://review.coreboot.org:29418/coreboot refs/changes/98/30798/1
diff --git a/src/mainboard/intel/d945gclf/Kconfig b/src/mainboard/intel/d945gclf/Kconfig
index 70fa848..906dd01 100644
--- a/src/mainboard/intel/d945gclf/Kconfig
+++ b/src/mainboard/intel/d945gclf/Kconfig
@@ -20,7 +20,8 @@
select NORTHBRIDGE_INTEL_I945
select NORTHBRIDGE_INTEL_SUBTYPE_I945GC
select SOUTHBRIDGE_INTEL_I82801GX
- select SUPERIO_SMSC_LPC47M15X
+## changed as per Advantech SOM 4461
+ select SUPERIO_WINBOND_W83627DHG
select HAVE_OPTION_TABLE
select HAVE_CMOS_DEFAULT
select HAVE_PIRQ_TABLE
diff --git a/src/mainboard/intel/d945gclf/devicetree.cb b/src/mainboard/intel/d945gclf/devicetree.cb
index 90c517f..864775a 100644
--- a/src/mainboard/intel/d945gclf/devicetree.cb
+++ b/src/mainboard/intel/d945gclf/devicetree.cb
@@ -65,44 +65,42 @@
device pci 1d.1 on end # USB UHCI
device pci 1d.2 on end # USB UHCI
device pci 1d.3 off end # USB UHCI
- device pci 1d.7 on end # USB2 EHCI
- device pci 1e.0 on end # PCI bridge
- device pci 1e.2 off end # AC'97 Audio
+ device pci 1d.7 on end # USB2 EHCI
+ device pci 1e.0 on end # PCI bridge
+ device pci 1e.2 off end # AC'97 Audio
device pci 1e.3 off end # AC'97 Modem
device pci 1f.0 on # LPC bridge
- chip superio/smsc/lpc47m15x
- device pnp 2e.0 off # Floppy
- end
- device pnp 2e.3 off # Parport
- end
- device pnp 2e.4 on
- io 0x60 = 0x3f8
- irq 0x70 = 4
- end
- device pnp 2e.5 on
- io 0x60 = 0x2f8
- irq 0x70 = 3
- irq 0xf1 = 4 # set IRMODE 0 # XXX not an irq
- end
- device pnp 2e.7 on # Keyboard+Mouse
- io 0x60 = 0x60
- io 0x62 = 0x64
- irq 0x70 = 1
- irq 0x72 = 12
- irq 0xf0 = 0x82 # HW accel A20.
- end
- device pnp 2e.8 on # GAME
- # all default
- end
- device pnp 2e.a on # PME
- end
- device pnp 2e.b on # MPU
- end
- end
- end
+ chip superio/winbond/w83627dhg
+ device pnp 2e.0 off end # Floppy
+ device pnp 2e.1 off end # Parallel Port
+ device pnp 2e.2 on # COM1
+ io 0x60 = 0x3f8
+ irq 0x70 = 4
+ end
+ device pnp 2e.3 on # COM2
+ io 0x60 = 0x2f8
+ irq 0x70 = 3
+ end
+ device pnp 2e.5 on # Keyboard,Mouse
+ io 0x60 = 0x60
+ io 0x62 = 0x64
+ irq 0x70 = 1
+ irq 0x72 = 12
+ end
+ #device pnp 2e.6 off end # SPI
+ device pnp 2e.307 off end # GPIO6
+ device pnp 2e.8 off end # WDTO, PLED
+ device pnp 2e.009 off end # GPIO2
+ device pnp 2e.109 off end # GPIO3
+ device pnp 2e.209 off end # GPIO4
+ device pnp 2e.309 off end # GPIO5
+ device pnp 2e.A off end # ACPI
+ device pnp 2e.B off end # HW Monitor
+ end # w83627dhg
+ end
device pci 1f.1 off end # IDE
- device pci 1f.2 on end # SATA
- device pci 1f.3 on end # SMBus
- end
- end
+ device pci 1f.2 on end # SATA
+ device pci 1f.3 on end # SMBus
+ end
+ end
end
--
To view, visit https://review.coreboot.org/c/coreboot/+/30798
To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings
Gerrit-Project: coreboot
Gerrit-Branch: master
Gerrit-Change-Id: I1449d9351bd1b76ecad16e6d81c501c1d4dd80f5
Gerrit-Change-Number: 30798
Gerrit-PatchSet: 1
Gerrit-Owner: junaid <junaidimpex(a)gmail.com>
Gerrit-MessageType: newchange
Keith Hui has uploaded this change for review. ( https://review.coreboot.org/c/coreboot/+/40962 )
Change subject: superio/*: Standardise config state entry/exit prototype in pnp_ops.h
......................................................................
superio/*: Standardise config state entry/exit prototype in pnp_ops.h
pnp_{entry,exit}_conf_state() is declared and implemented under each
super I/O with not that much variation. Place them to a central
location along with other pre-RAM pnp functions.
This provides a standard pre-RAM PNP API, with the eventual goal of
consolidating all implementations, with only one implementation
per actual known config state entry/exit sequence.
Remove the prototype from winbond/common. All code that use pre-RAM
pnp include pnp_ops.h and all basic functions will be brought in. The
correct implementation is selected at compile time via Makefile.inc.
Change-Id: If4e742edb17ca73c01ff7b552e00e18acc6779dd
Signed-off-by: Keith Hui <buurin(a)gmail.com>
---
M src/include/device/pnp_ops.h
M src/superio/fintek/common/fintek.h
M src/superio/winbond/common/winbond.h
3 files changed, 3 insertions(+), 6 deletions(-)
git pull ssh://review.coreboot.org:29418/coreboot refs/changes/62/40962/1
diff --git a/src/include/device/pnp_ops.h b/src/include/device/pnp_ops.h
index 93a5dc8..f43cb33 100644
--- a/src/include/device/pnp_ops.h
+++ b/src/include/device/pnp_ops.h
@@ -10,6 +10,9 @@
#if ENV_PNP_SIMPLE_DEVICE
+void pnp_enter_conf_state(pnp_devfn_t dev);
+void pnp_exit_conf_state(pnp_devfn_t dev);
+
static __always_inline void pnp_write_config(
pnp_devfn_t dev, uint8_t reg, uint8_t value)
{
diff --git a/src/superio/fintek/common/fintek.h b/src/superio/fintek/common/fintek.h
index 81e8e67..915c148 100644
--- a/src/superio/fintek/common/fintek.h
+++ b/src/superio/fintek/common/fintek.h
@@ -9,7 +9,4 @@
void fintek_enable_serial(pnp_devfn_t dev, u16 iobase);
-void pnp_enter_conf_state(pnp_devfn_t dev);
-void pnp_exit_conf_state(pnp_devfn_t dev);
-
#endif /* SUPERIO_FINTEK_COMMON_PRE_RAM_H */
diff --git a/src/superio/winbond/common/winbond.h b/src/superio/winbond/common/winbond.h
index 58297e5..9816db0 100644
--- a/src/superio/winbond/common/winbond.h
+++ b/src/superio/winbond/common/winbond.h
@@ -11,7 +11,4 @@
void winbond_set_pinmux(pnp_devfn_t dev, uint8_t offset, uint8_t mask, uint8_t state);
void winbond_set_clksel_48(pnp_devfn_t dev);
-void pnp_enter_conf_state(pnp_devfn_t dev);
-void pnp_exit_conf_state(pnp_devfn_t dev);
-
#endif /* SUPERIO_WINBOND_COMMON_PRE_RAM_H */
--
To view, visit https://review.coreboot.org/c/coreboot/+/40962
To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings
Gerrit-Project: coreboot
Gerrit-Branch: master
Gerrit-Change-Id: If4e742edb17ca73c01ff7b552e00e18acc6779dd
Gerrit-Change-Number: 40962
Gerrit-PatchSet: 1
Gerrit-Owner: Keith Hui <buurin(a)gmail.com>
Gerrit-Reviewer: Felix Held <felix-coreboot(a)felixheld.de>
Gerrit-MessageType: newchange
Michał Żygowski has uploaded this change for review. ( https://review.coreboot.org/c/coreboot/+/43395 )
Change subject: cpu/x86/16bit/entry16.inc: Stop PBET timer on Boot Guard platforms
......................................................................
cpu/x86/16bit/entry16.inc: Stop PBET timer on Boot Guard platforms
PBET timer has to be stopped before APs are launched and initialized.
Otherwise the platform will reset. The PBET expiration time may be very
low so stop timer as quickly as possible. The expiration time is defined
in Boot Guard manifests.
Signed-off-by: Michał Żygowski <michal.zygowski(a)3mdeb.com>
Change-Id: I545a36d60597fe37a30b8207336ae7fa7831674d
---
M src/cpu/x86/16bit/entry16.inc
1 file changed, 9 insertions(+), 0 deletions(-)
git pull ssh://review.coreboot.org:29418/coreboot refs/changes/95/43395/1
diff --git a/src/cpu/x86/16bit/entry16.inc b/src/cpu/x86/16bit/entry16.inc
index babed02..c555c5c 100644
--- a/src/cpu/x86/16bit/entry16.inc
+++ b/src/cpu/x86/16bit/entry16.inc
@@ -29,6 +29,7 @@
#include <cpu/x86/post_code.h>
#define BOOTGUARD_SACM_INFO 0x13a
+#define BOOTGUARD_PBEC 0x139
/* Symbol _start16bit must be aligned to 4kB to start AP CPUs with
* Startup IPI message without RAM.
@@ -118,6 +119,14 @@
andl $0x7FFAFFD1, %ebx /* PG,AM,WP,NE,TS,EM,MP = 0 */
orl $0x60000001, %ebx /* CD, NW, PE = 1 */
#if CONFIG(INTEL_BOOTGUARD)
+ /*
+ * Stop PBET timer. It is recommended to stop the PBET timer
+ * regardless of Boot Guard status.
+ */
+ movl $BOOTGUARD_PBEC, %ecx
+ movl $0, %edx
+ movl $1, %eax
+ wrmsr
/* DO NOT disable cache if Intel BootGuard is supported */
movl $BOOTGUARD_SACM_INFO, %ecx
--
To view, visit https://review.coreboot.org/c/coreboot/+/43395
To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings
Gerrit-Project: coreboot
Gerrit-Branch: master
Gerrit-Change-Id: I545a36d60597fe37a30b8207336ae7fa7831674d
Gerrit-Change-Number: 43395
Gerrit-PatchSet: 1
Gerrit-Owner: Michał Żygowski <michal.zygowski(a)3mdeb.com>
Gerrit-Reviewer: Martin Roth <martinroth(a)google.com>
Gerrit-Reviewer: Patrick Georgi <pgeorgi(a)google.com>
Gerrit-MessageType: newchange
Michał Żygowski has uploaded this change for review. ( https://review.coreboot.org/c/coreboot/+/43401 )
Change subject: program layout: align to 64 bytes when Boot Guard is enabled
......................................................................
program layout: align to 64 bytes when Boot Guard is enabled
FIT entries for IBB segmnets have 64 byte granularity. Enforce the
64 bytes alignment on all programs and FIT table to ensure the
entires for IBB will be added correctly.
Signed-off-by: Michał Żygowski <michal.zygowski(a)3mdeb.com>
Change-Id: I3ce09e24d716fe9845104205bc934bd2a0efc9cb
---
M src/arch/x86/memlayout.ld
M src/cpu/intel/fit/fit.S
M src/lib/program.ld
3 files changed, 24 insertions(+), 0 deletions(-)
git pull ssh://review.coreboot.org:29418/coreboot refs/changes/01/43401/1
diff --git a/src/arch/x86/memlayout.ld b/src/arch/x86/memlayout.ld
index 3659cc9..605ed24 100644
--- a/src/arch/x86/memlayout.ld
+++ b/src/arch/x86/memlayout.ld
@@ -47,3 +47,8 @@
#include <cpu/intel/fit/fit.ld>
#endif
#endif /* ENV_BOOTBLOCK */
+
+/* Each program stage needs to be 64 bytes aligned to be added as FIT entry */
+#if CONFIG_INTEL_BOOTGUARD
+. = ALIGN(64);
+#endif
diff --git a/src/cpu/intel/fit/fit.S b/src/cpu/intel/fit/fit.S
index 3b7396c..037918a 100644
--- a/src/cpu/intel/fit/fit.S
+++ b/src/cpu/intel/fit/fit.S
@@ -9,7 +9,15 @@
.previous
.section .text
+#if CONFIG(INTEL_BOOTGUARD)
+/*
+ * FIT must be excluded from IBB with BootGuard. As the IBB segments have 64
+ * byte granularity, align the FIT to 64 bytes.
+ */
+.align 64
+#else
.align 16
+#endif
.global fit_table
.global fit_table_end
fit_table:
@@ -28,5 +36,12 @@
/* Checksum byte - must add to zero. */
.byte 0x7d
.fill CONFIG_CPU_INTEL_NUM_FIT_ENTRIES*16
+#if CONFIG(INTEL_BOOTGUARD)
+/*
+ * Just in case the FIT does not end on 64 byte aligned address, maintain the
+ * 64 byte boundaries of IBB segments.
+ */
+.align 64
+#endif
fit_table_end:
.previous
diff --git a/src/lib/program.ld b/src/lib/program.ld
index 88a3126..ee105e3 100644
--- a/src/lib/program.ld
+++ b/src/lib/program.ld
@@ -48,6 +48,10 @@
*(.rodata);
*(.rodata.*);
. = ALIGN(ARCH_POINTER_ALIGN_SIZE);
+#if CONFIG_INTEL_BOOTGUARD
+/* Each program stage needs to be 64 bytes aligned to be added as FIT entry */
+ . = ALIGN(64);
+#endif
_etext = .;
} : to_load
--
To view, visit https://review.coreboot.org/c/coreboot/+/43401
To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings
Gerrit-Project: coreboot
Gerrit-Branch: master
Gerrit-Change-Id: I3ce09e24d716fe9845104205bc934bd2a0efc9cb
Gerrit-Change-Number: 43401
Gerrit-PatchSet: 1
Gerrit-Owner: Michał Żygowski <michal.zygowski(a)3mdeb.com>
Gerrit-Reviewer: Julius Werner <jwerner(a)chromium.org>
Gerrit-Reviewer: Patrick Rudolph <siro(a)das-labor.org>
Gerrit-MessageType: newchange