Łukasz Siudut has uploaded this change for review. ( https://review.coreboot.org/c/coreboot/+/32905
Change subject: RFC: smbios: allow setting BIOS-version string from VPD variable
......................................................................
RFC: smbios: allow setting BIOS-version string from VPD variable
As in the title. Such approach allows for convenient setting of the
firmware version and keep it in partition that is easily readable
from both - coreboot binary and already running operating system.
vpd_find is used directly as it returns pointer to vpd value which,
by spec, is terminated by 0x00 (VPD_TYPE_TERMINATOR) anyway. This
way we avoid copying string around and coming up with temporary
buffer.
Change-Id: If0e9d90ed0941c4e76e3e48cdcccf830ef789458
Signed-off-by: Lukasz Siudut <lsiudut(a)gmail.com>
---
M src/arch/x86/smbios.c
1 file changed, 12 insertions(+), 0 deletions(-)
git pull ssh://review.coreboot.org:29418/coreboot refs/changes/05/32905/1
diff --git a/src/arch/x86/smbios.c b/src/arch/x86/smbios.c
index 589f4f0..2ffd2dd 100644
--- a/src/arch/x86/smbios.c
+++ b/src/arch/x86/smbios.c
@@ -30,6 +30,9 @@
#include <memory_info.h>
#include <spd.h>
#include <cbmem.h>
+#if CONFIG(VPD)
+#include <drivers/vpd/vpd.h>
+#endif
#if CONFIG(CHROMEOS)
#include <vendorcode/google/chromeos/gnvs.h>
#endif
@@ -347,6 +350,15 @@
const char *__weak smbios_mainboard_bios_version(void)
{
+#if CONFIG(VPD)
+ /* size is unused for now */
+ int size;
+ const char *coreboot_vpd_version = vpd_find("version", &size, VPD_RO);
+
+ /* if found, vpd value will be terminated by 0x00 (VPD_TYPE_TERMINATOR) */
+ if(coreboot_vpd_version)
+ return coreboot_vpd_version;
+#endif
if (strlen(CONFIG_LOCALVERSION))
return CONFIG_LOCALVERSION;
else
--
To view, visit https://review.coreboot.org/c/coreboot/+/32905
To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings
Gerrit-Project: coreboot
Gerrit-Branch: master
Gerrit-Change-Id: If0e9d90ed0941c4e76e3e48cdcccf830ef789458
Gerrit-Change-Number: 32905
Gerrit-PatchSet: 1
Gerrit-Owner: Łukasz Siudut
Gerrit-MessageType: newchange
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
Branden Waldner has uploaded this change for review. ( https://review.coreboot.org/c/coreboot/+/35530 )
Change subject: mb/asus/p2-99: add Asus P2-99 as a variant of Asus P2B
......................................................................
mb/asus/p2-99: add Asus P2-99 as a variant of Asus P2B
Squash add Asus P2-99 as clone of Asus P2B and convert clone to variant
Change-Id: I78bd3e215c9c35d272919850f52feac135d06ed8
---
M src/mainboard/asus/p2b/Kconfig
M src/mainboard/asus/p2b/Kconfig.name
2 files changed, 11 insertions(+), 2 deletions(-)
git pull ssh://review.coreboot.org:29418/coreboot refs/changes/30/35530/1
diff --git a/src/mainboard/asus/p2b/Kconfig b/src/mainboard/asus/p2b/Kconfig
index f34b4dd..0c77779 100644
--- a/src/mainboard/asus/p2b/Kconfig
+++ b/src/mainboard/asus/p2b/Kconfig
@@ -12,7 +12,7 @@
## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
## GNU General Public License for more details.
##
-if BOARD_ASUS_P2B
+if BOARD_ASUS_P2B || BOARD_ASUS_P2_99
config BOARD_SPECIFIC_OPTIONS
def_bool y
@@ -28,12 +28,18 @@
string
default asus/p2b
+config VARIANT_DIR
+ string
+ default "p2-99" if BOARD_ASUS_P2_99
+ default "p2b" if BOARD_ASUS_P2B
+
config MAINBOARD_PART_NUMBER
string
+ default "P2-99" if BOARD_ASUS_P2_99
default "P2B"
config IRQ_SLOT_COUNT
int
default 6
-endif # BOARD_ASUS_P2B
+endif # BOARD_ASUS_P2B || BOARD_ASUS_P2_99
diff --git a/src/mainboard/asus/p2b/Kconfig.name b/src/mainboard/asus/p2b/Kconfig.name
index 60d6028..a299a35 100644
--- a/src/mainboard/asus/p2b/Kconfig.name
+++ b/src/mainboard/asus/p2b/Kconfig.name
@@ -1,2 +1,5 @@
config BOARD_ASUS_P2B
bool "P2B"
+
+config BOARD_ASUS_P2_99
+ bool "P2-99"
--
To view, visit https://review.coreboot.org/c/coreboot/+/35530
To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings
Gerrit-Project: coreboot
Gerrit-Branch: master
Gerrit-Change-Id: I78bd3e215c9c35d272919850f52feac135d06ed8
Gerrit-Change-Number: 35530
Gerrit-PatchSet: 1
Gerrit-Owner: Branden Waldner <scruffy99(a)gmail.com>
Gerrit-MessageType: newchange