Bernardo Perez Priego has uploaded this change for review. ( https://review.coreboot.org/c/coreboot/+/37628 )
Change subject: soc/intel/common: Add romstage common stage file
......................................................................
soc/intel/common: Add romstage common stage file
This patch will ensures all intel soc is using common stage
files to make coreboot design flow align across all socs.
CPU, SA, PCH, MCH programming sequence might be different between
socs but the function call should route from same location across
all soc.
Signed-off-by: Bernardo Perez Priego <bernardo.perez.priego(a)intel.com>
Change-Id: I06d43ac29f5e87ce731a470e5e145adea07ece4c
---
M src/cpu/intel/car/romstage.c
A src/soc/intel/common/basecode/include/intelbasecode/romstage.h
A src/soc/intel/common/basecode/romstage/Makefile.inc
A src/soc/intel/common/basecode/romstage/romstage.c
4 files changed, 162 insertions(+), 6 deletions(-)
git pull ssh://review.coreboot.org:29418/coreboot refs/changes/28/37628/1
diff --git a/src/cpu/intel/car/romstage.c b/src/cpu/intel/car/romstage.c
index 1f8eb9a..55d3c9d 100644
--- a/src/cpu/intel/car/romstage.c
+++ b/src/cpu/intel/car/romstage.c
@@ -52,9 +52,6 @@
for (i = 0; i < num_guards; i++)
stack_base[i] = stack_guard;
- if (CONFIG(VBOOT_EARLY_EC_SYNC))
- vboot_sync_ec();
-
mainboard_romstage_entry();
/* Check the stack. */
@@ -64,9 +61,6 @@
printk(BIOS_DEBUG, "Smashed stack detected in romstage!\n");
}
- if (CONFIG(SMM_TSEG))
- smm_list_regions();
-
prepare_and_run_postcar(&early_mtrrs);
/* We do not return here. */
}
diff --git a/src/soc/intel/common/basecode/include/intelbasecode/romstage.h b/src/soc/intel/common/basecode/include/intelbasecode/romstage.h
new file mode 100644
index 0000000..0cebbbf
--- /dev/null
+++ b/src/soc/intel/common/basecode/include/intelbasecode/romstage.h
@@ -0,0 +1,37 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright 2019 Intel Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef SOC_INTEL_COMMON_BASECODE_ROMSTAGE_H
+#define SOC_INTEL_COMMON_BASECODE_ROMSTAGE_H
+
+#include <stddef.h>
+#include <stdint.h>
+#include <fsp/soc_binding.h>
+
+struct romstage_ops {
+ void (*soc_early_init)(void);
+ void (*soc_init)(void);
+ void (*pch_early_init)(void);
+ void (*pch_init)(void);
+ void (*cpu_early_init)(void);
+ void (*cpu_init)(void);
+ bool (*is_s3wake)(void);
+ void (*soc_mem_init_params)(FSP_M_CONFIG *mupd);
+};
+
+/* SoC Override function */
+struct romstage_ops *soc_get_ops(void);
+
+#endif
diff --git a/src/soc/intel/common/basecode/romstage/Makefile.inc b/src/soc/intel/common/basecode/romstage/Makefile.inc
new file mode 100644
index 0000000..29763fb
--- /dev/null
+++ b/src/soc/intel/common/basecode/romstage/Makefile.inc
@@ -0,0 +1 @@
+romstage-y += romstage.c
diff --git a/src/soc/intel/common/basecode/romstage/romstage.c b/src/soc/intel/common/basecode/romstage/romstage.c
new file mode 100644
index 0000000..55c4ab5
--- /dev/null
+++ b/src/soc/intel/common/basecode/romstage/romstage.c
@@ -0,0 +1,124 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2019 Intel Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <arch/early_variables.h>
+#include <romstage_common.h>
+#include <cpu/x86/pae.h>
+#include <intelbasecode/romstage.h>
+#include <intelblocks/systemagent.h>
+#include <soc/iomap.h>
+#include <soc/romstage.h>
+
+static const struct romstage_ops s_romstage_ops;
+
+__weak struct romstage_ops *soc_get_ops(void)
+{
+ return (struct romstage_ops *)&s_romstage_ops;
+}
+
+void romstage_early_init(void)
+{
+ struct romstage_ops *rs_ops = soc_get_ops();
+
+ rs_ops->soc_early_init();
+ rs_ops->pch_early_init();
+ rs_ops->cpu_early_init();
+}
+
+void romstage_init(void)
+{
+ struct romstage_ops *rs_ops = soc_get_ops();
+
+ rs_ops->soc_init();
+ rs_ops->pch_init();
+ rs_ops->cpu_init();
+}
+
+void romstage_cmn_soc_early_init(void)
+{
+ systemagent_early_init();
+ heci_init(HECI1_BASE_ADDRESS);
+}
+
+void romstage_cmn_soc_init(void)
+{
+}
+
+void romstage_cmn_pch_early_init(void)
+{
+}
+
+void romstage_cmn_cpu_early_init(void)
+{
+}
+
+void romstage_cmn_pch_init(void)
+{
+}
+
+void romstage_cmn_cpu_init(void)
+{
+}
+
+bool romstage_cmn_is_s3wake(void)
+{
+ struct chipset_power_state *ps = pmc_get_power_state();
+ return pmc_fill_power_state(ps) == ACPI_S3;
+}
+
+void romstage_cmn_soc_mem_init_param(FSP_M_CONFIG *m_cfg)
+{
+}
+
+static const struct romstage_ops s_romstage_ops = {
+ &romstage_cmn_soc_early_init,
+ &romstage_cmn_soc_init,
+ &romstage_cmn_pch_early_init,
+ &romstage_cmn_pch_init,
+ &romstage_cmn_cpu_early_init,
+ &romstage_cmn_cpu_init,
+ &romstage_cmn_is_s3wake,
+ &romstage_cmn_mb_mem_init_param,
+ &romstage_cmn_soc_mem_init_param
+};
+
+/*
+ Main romstage function
+*/
+asmlinkage void mainboard_romstage_entry(void)
+{
+ if (CONFIG(VBOOT_EARLY_EC_SYNC))
+ vboot_sync_ec(rs_ops->fill_power_state());
+
+ romstage_early_init();
+ romstage_init();
+ fsp_memory_init(rs_ops->is_s3wake());
+
+ if (CONFIG(SMM_TSEG))
+ smm_list_regions();
+}
+
+/*
+ Callback function for FSP memory initialization
+*/
+void platform_fsp_memory_init_params_cb(FSPM_UPD *mupd, uint32_t version)
+{
+ struct romstage_ops *rs_ops = soc_get_ops();
+
+ FSP_M_CONFIG *m_cfg;
+ rs_ops->soc_mem_init_params(m_cfg);
+ mainboard_memory_init_params(m_cfg);
+}
+
--
To view, visit https://review.coreboot.org/c/coreboot/+/37628
To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings
Gerrit-Project: coreboot
Gerrit-Branch: master
Gerrit-Change-Id: I06d43ac29f5e87ce731a470e5e145adea07ece4c
Gerrit-Change-Number: 37628
Gerrit-PatchSet: 1
Gerrit-Owner: Bernardo Perez Priego <bernardo.perez.priego(a)intel.com>
Gerrit-MessageType: newchange
Patrick Georgi has uploaded this change for review. ( https://review.coreboot.org/c/coreboot/+/37152 )
Change subject: util/kconfig: Uprev to Linux 5.3's kconfig
......................................................................
util/kconfig: Uprev to Linux 5.3's kconfig
This was originally several commits that had to be squashed into one
because the intermediate states weren't able to build coreboot:
- one to remove everything that wasn't our own code, leaving only
regex.[ch], toada.c, description.md and Makefile.inc
- one to copy in Linux 5.3's scripts/kconfig and adapt Makefile.inc
to make the original Makefile work again.
TODO:
- more commits that bring back our modifications, both directly in the
code and as a diff in a patches/ subdirectory.
Change-Id: Ia0e8fe4e9022b278f34ab113a433ef4d45e5c355
Signed-off-by: Patrick Georgi <pgeorgi(a)google.com>
---
M util/kconfig/Makefile
M util/kconfig/Makefile.inc
D util/kconfig/POTFILES.in
D util/kconfig/check.sh
M util/kconfig/conf.c
M util/kconfig/confdata.c
M util/kconfig/expr.c
M util/kconfig/expr.h
A util/kconfig/gconf-cfg.sh
M util/kconfig/gconf.c
M util/kconfig/images.c
A util/kconfig/images.h
D util/kconfig/kxgettext.c
A util/kconfig/lexer.l
M util/kconfig/list.h
M util/kconfig/lkc.h
M util/kconfig/lkc_proto.h
D util/kconfig/lxdialog/.gitignore
M util/kconfig/lxdialog/BIG.FAT.WARNING
D util/kconfig/lxdialog/check-lxdialog.sh
M util/kconfig/lxdialog/checklist.c
M util/kconfig/lxdialog/dialog.h
M util/kconfig/lxdialog/inputbox.c
M util/kconfig/lxdialog/menubox.c
M util/kconfig/lxdialog/textbox.c
M util/kconfig/lxdialog/util.c
M util/kconfig/lxdialog/yesno.c
A util/kconfig/mconf-cfg.sh
M util/kconfig/mconf.c
M util/kconfig/menu.c
A util/kconfig/merge_config.sh
A util/kconfig/nconf-cfg.sh
M util/kconfig/nconf.c
M util/kconfig/nconf.gui.c
M util/kconfig/nconf.h
R util/kconfig/parser.y
A util/kconfig/preprocess.c
A util/kconfig/qconf-cfg.sh
M util/kconfig/qconf.cc
M util/kconfig/qconf.h
A util/kconfig/streamline_config.pl
M util/kconfig/symbol.c
M util/kconfig/util.c
D util/kconfig/zconf.gperf
D util/kconfig/zconf.hash.c_shipped
D util/kconfig/zconf.l
D util/kconfig/zconf.lex.c_shipped
D util/kconfig/zconf.tab.c_shipped
48 files changed, 4,250 insertions(+), 8,203 deletions(-)
git pull ssh://review.coreboot.org:29418/coreboot refs/changes/52/37152/1
--
To view, visit https://review.coreboot.org/c/coreboot/+/37152
To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings
Gerrit-Project: coreboot
Gerrit-Branch: master
Gerrit-Change-Id: Ia0e8fe4e9022b278f34ab113a433ef4d45e5c355
Gerrit-Change-Number: 37152
Gerrit-PatchSet: 1
Gerrit-Owner: Patrick Georgi <pgeorgi(a)google.com>
Gerrit-MessageType: newchange
Patrick Georgi has uploaded this change for review. ( https://review.coreboot.org/c/coreboot/+/37643 )
Change subject: Documentation: Add proposal for firmware testing
......................................................................
Documentation: Add proposal for firmware testing
Change-Id: Icb9380050f8ff1aa13ecbb501079e2556e43ca06
Signed-off-by: Patrick Georgi <pgeorgi(a)google.com>
---
A Documentation/technotes/2019-12-firmware-testing.md
M Documentation/technotes/index.md
2 files changed, 176 insertions(+), 0 deletions(-)
git pull ssh://review.coreboot.org:29418/coreboot refs/changes/43/37643/1
diff --git a/Documentation/technotes/2019-12-firmware-testing.md b/Documentation/technotes/2019-12-firmware-testing.md
new file mode 100644
index 0000000..64838a7
--- /dev/null
+++ b/Documentation/technotes/2019-12-firmware-testing.md
@@ -0,0 +1,175 @@
+# Draft design of a firmware-aware integration test system
+
+## Problem statement
+
+Most full system test systems have assumptions baked in that make them
+unsuitable for firmware level testing. For example, both Chrome OS test
+runners assume that the DUT (Device Under Test) has an operational
+kernel + network + sshd. That's a useful assumption when covering
+userland testing, but not for firmware. Lava has its downsides as well
+(TODO: as reported by Philipp, need details).
+
+This document outlines a system that, when implemented, helps
+automatically test properties of firmware level code. It's _likely_
+also suitable for later stages (kernel and userland), but they're
+not the main concern: there's enough tooling out there for them.
+
+## Collecting requirements
+
+This project doesn't consider a test system running only on the DUT
+so it will require a test host that remains in control. Apart from
+that, the system should be useful at all ends of the problem space:
+hobbyists with little money to spare just the same as test labs
+running automated continuous testing.
+
+Beyond DUT and test host, the system requires some way for them to
+communicate, so we'll expect a bidirectional serial console connection
+between them (although we don't care much about how this connection
+looks like in practice).
+
+Such a bare-bone operation might require manual intervention directed
+by the test host (e.g. the host asking the user to reboot the DUT when
+it got stuck). It may also be augmented by additional circuitry that
+allows automating these steps.
+
+These constraints ensure that a test suite can be executed "one-off"
+by a developer with minimal hardware investment while also allowing
+automated systems to execute the tests without user intervention.
+
+So these are
+
+*Requirement 1*: The system must be usable with minimal investment for
+manual operation: a host, a DUT and a bidirectional serial connection
+between them.
+
+and
+
+*Requirement 2*: The system must be able to drive additional controls
+to support fully automated operation.
+
+There will be lots of different types of DUTs, and not all tests
+apply to all of them: There's no battery on a desktop board, so no
+need to test charging. A test for charging should be automatically
+skipped on such a DUT without counting as failure.
+
+*Requirement 3*: The system must allow to specify DUTs and their
+properties, as well as the properties that a test requires to be
+meaningful.
+
+Tests should be self-contained. This means that they should start
+from a flash cycle (that a tool like flashrom would optimize away to
+a no-op if flash is still in the expected state) and power-on.
+
+*Requirement 4*: Tests always start with the required firmware image
+to write and explicit power-on.
+
+Tests must be able to state that other tests must have succeeded before
+them: A test that exercises boot loader options doesn't fail when the
+boot process never gets to the options screen, it just shouldn't run.
+
+*Requirement 5*: Tests must be able to declare tests they depend on.
+
+State transitions should be well-defined: The DUT can move from the
+power-off state to the power-on state. It can also fail to do so and
+remain powered-off. These things need to be spelled out, together
+with the consequences that arise from each transition: it's expected
+that most transitions would be failures, but that should be noted down.
+
+And yet, this verbosity shouldn't mean that the tests become
+unreadable. Ideally they could be used by a human operator as "regular
+text" (with odd characters interspersed) outlining steps to execute
+manually, without a test runner.
+
+*Requirement 6*: It must be simple to state "Initiate action, success
+is W, X while failure is Y, Z".
+
+During the test, the host monitors the serial console and extracts
+events from it. Such events could be, for example, "coreboot enters
+ramstage". A test can expect events to appear on the stream and fail if
+unexpected events appear or no events appear within a given deadline.
+
+The observed events are reported to the user.
+
+*Requirement 7*: There's an event parser looking for things that
+happen on the DUT.
+
+The host can send characters to the DUT, for example in a boot loader
+or on a terminal provided by an OS that eventually boots.
+
+*Requirement 8*: Test must be able to run an expect-like language to
+drive complex interactions on the serial console.
+
+Some tests may be better run on the target system (e.g. to parse
+out tables in memory, or otherwise inspect boot states). They should
+have a minimal set of dependencies so they don't fail because the base
+system changed slightly, be portable across architectures and operating
+systems. The language should be popular and the implementation robust.
+
+*Requirement 9*: Implementation language must be popular, robust,
+portable and operate with minimal dependencies.
+
+## Implementation proposal
+
+The test system will be implemented in Go: it's reasonably popular
+(unlike Forth), robust (unlike shell scripts), its statically linked
+binaries have minimal dependencies on the host environment (unlike
+Python) and it supports multiple architectures and operating systems.
+
+The build creates a host side test runner (native OS/arch) and a
+variable number of DUT test runners (for all supported DUT OS/arch
+pairs) that are provided to the DUT on some storage medium (e.g. USB
+stick). In a fully automated environment this might require switching
+USB ports between host and DUT.
+
+There's a [liberally licensed implementation of expect][goexpect] that
+could be integrated for handling interactive consoles. It supports
+parallel execution which is useful to have a listener on the serial
+console (when not driven by expect).
+
+[goexpect]: https://github.com/google/goexpect
+
+The test runner is called with the names of a set of tests to execute
+(individually or as suites that tests can be assigned to) and the
+type of DUT to work with.
+
+From this, it knows how to drive the DUT. The "manual operation" mode
+would be just a special type of button driver that asks the user to
+conduct some operation and potentially to press Enter.
+
+Tests are defined in go packages, with per-package set up and tear
+down routines. The runner optimizes operations by telling the tear down
+routine if the next test will be from the same package (so the amount
+of tear down could be reduced). Setup isn't told about the previous
+state but should assume a random state. It's only allowed to assume
+that the tests it requires to execute earlier have passed. It can
+still optimize based on things it measures such as flashrom not writing
+unchanged blocks.
+
+### Flow
+
+```
+ DUT name
+ Tests to execute +--------------+
+ + +---->+Console driver|
+ | | +--------------+
+ | +---->+Button driver |
+ | | +--------------+
+ v v
+ +-----------+ +----------+
+ |Test runner+--------+DUT object+<+
+ +-----------+ +----------+ |
+ | executes |generates |
+ | v |
+ | sends+------------+ | control
+ +<-----+event stream| +----+
+ | +------------+ | |
+ | | |
+ | +----------+ |
+ +------------->+Host tests| |
+ | +----------+ |
+ | |
+ | +--------------+ call +------------------+
+ +------------->+Target tests +----------+Target test runner|
+ +--------------+ +------------------+
+```
+
diff --git a/Documentation/technotes/index.md b/Documentation/technotes/index.md
index 7c231fc..0df2a1b 100644
--- a/Documentation/technotes/index.md
+++ b/Documentation/technotes/index.md
@@ -2,3 +2,4 @@
* [Dealing with Untrusted Input in SMM](2017-02-dealing-with-untrusted-input-in-smm.md)
* [Rebuilding coreboot image generation](2015-11-rebuilding-coreboot-image-generation.md)
+* [firmware test runner](2019-12-firmware-testing.md)
--
To view, visit https://review.coreboot.org/c/coreboot/+/37643
To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings
Gerrit-Project: coreboot
Gerrit-Branch: master
Gerrit-Change-Id: Icb9380050f8ff1aa13ecbb501079e2556e43ca06
Gerrit-Change-Number: 37643
Gerrit-PatchSet: 1
Gerrit-Owner: Patrick Georgi <pgeorgi(a)google.com>
Gerrit-MessageType: newchange
Patrick Rudolph has uploaded this change for review. ( https://review.coreboot.org/c/coreboot/+/35739 )
Change subject: soc/intel/common/block: Update microcode for each core
......................................................................
soc/intel/common/block: Update microcode for each core
On Hyper-Threading enabled platform update the microcde only once
for each core, not for each thread.
Follow Intel Software Developer Guidelines as the added comment
also states.
Change-Id: I72804753e567a137a5648ca6950009fed332531b
Signed-off-by: Patrick Rudolph <patrick.rudolph(a)9elements.com>
---
M src/soc/intel/common/block/cpu/mp_init.c
1 file changed, 20 insertions(+), 1 deletion(-)
git pull ssh://review.coreboot.org:29418/coreboot refs/changes/39/35739/1
diff --git a/src/soc/intel/common/block/cpu/mp_init.c b/src/soc/intel/common/block/cpu/mp_init.c
index 2c5061f..e7689cf 100644
--- a/src/soc/intel/common/block/cpu/mp_init.c
+++ b/src/soc/intel/common/block/cpu/mp_init.c
@@ -26,6 +26,7 @@
#include <intelblocks/fast_spi.h>
#include <intelblocks/mp_init.h>
#include <intelblocks/msr.h>
+#include <cpu/intel/common/common.h>
#include <soc/cpu.h>
static const void *microcode_patch;
@@ -44,7 +45,24 @@
static void init_one_cpu(struct device *dev)
{
soc_core_init(dev);
- intel_microcode_load_unlocked(microcode_patch);
+
+ /*
+ * Update just on the first CPU in the core. Other siblings
+ * get the update automatically according to Document: 253668-060US
+ * Intel SDM Chapter 9.11.6.3
+ * "Update in a System Supporting Intel Hyper-Threading Technology"
+ * Intel Hyper-Threading Technology has implications on the loading of the
+ * microcode update. The update must be loaded for each core in a physical
+ * processor. Thus, for a processor supporting Intel Hyper-Threading
+ * Technology, only one logical processor per core is required to load the
+ * microcode update. Each individual logical processor can independently
+ * load the update. However, MP initialization must provide some mechanism
+ * (e.g. a software semaphore) to force serialization of microcode update
+ * loads and to prevent simultaneous load attempts to the same core.
+ */
+ if (!intel_ht_sibling()) {
+ intel_microcode_load_unlocked(microcode_patch);
+ }
}
static struct device_operations cpu_dev_ops = {
@@ -141,6 +159,7 @@
if (CONFIG(USE_INTEL_FSP_MP_INIT))
return;
+ /* Update microcode on BSP */
microcode_patch = intel_microcode_find();
intel_microcode_load_unlocked(microcode_patch);
--
To view, visit https://review.coreboot.org/c/coreboot/+/35739
To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings
Gerrit-Project: coreboot
Gerrit-Branch: master
Gerrit-Change-Id: I72804753e567a137a5648ca6950009fed332531b
Gerrit-Change-Number: 35739
Gerrit-PatchSet: 1
Gerrit-Owner: Patrick Rudolph <patrick.rudolph(a)9elements.com>
Gerrit-MessageType: newchange