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 Rudolph has uploaded this change for review. ( https://review.coreboot.org/c/coreboot/+/39043 )
Change subject: [TESTME]lenovo/x220: Attempt to fix broken DRAM init
......................................................................
[TESTME]lenovo/x220: Attempt to fix broken DRAM init
Enable power on WWAN as it has SMBUS connected.
Might resolv an issue where DRAM init fails as no EEPROM is
found on the bus.
Untested.
Change-Id: Ia7a2ca370124ecf743b000998b56855d5ed8f573
Signed-off-by: Patrick Rudolph <patrick.rudolph(a)9elements.com>
---
M src/ec/lenovo/h8/Makefile.inc
M src/mainboard/lenovo/x220/early_init.c
2 files changed, 15 insertions(+), 0 deletions(-)
git pull ssh://review.coreboot.org:29418/coreboot refs/changes/43/39043/1
diff --git a/src/ec/lenovo/h8/Makefile.inc b/src/ec/lenovo/h8/Makefile.inc
index 51c11be..9c8687a 100644
--- a/src/ec/lenovo/h8/Makefile.inc
+++ b/src/ec/lenovo/h8/Makefile.inc
@@ -18,6 +18,8 @@
ramstage-y += panic.c
endif
+romstage += wwan.c
+
ramstage-y += h8.c
ramstage-y += bluetooth.c
ramstage-y += wwan.c
diff --git a/src/mainboard/lenovo/x220/early_init.c b/src/mainboard/lenovo/x220/early_init.c
index 3429c1b..ae16f0c 100644
--- a/src/mainboard/lenovo/x220/early_init.c
+++ b/src/mainboard/lenovo/x220/early_init.c
@@ -24,6 +24,7 @@
#include <southbridge/intel/bd82x6x/pch.h>
#include <southbridge/intel/common/gpio.h>
#include <cpu/x86/msr.h>
+#include <ec/lenovo/h8/h8.h>
void mainboard_fill_pei_data(struct pei_data *pei_data)
{
@@ -74,6 +75,18 @@
*pei_data = pei_data_template;
}
+void mainboard_early_init(int s3_resume)
+{
+ /*
+ * The WWAN slot has SMBUS connected. Turn on power to make sure
+ * SMBUS is usable and DRAM init will succeed.
+ * ramstage will turn it off, in case it's not needed.
+ * TODO: Does GPIO42 (SMB_3B_EN) help here?
+ */
+ if (h8_has_wwan())
+ h8_wwan_enable(true);
+}
+
void mainboard_get_spd(spd_raw_data *spd, bool id_only)
{
read_spd (&spd[0], 0x50, id_only);
--
To view, visit https://review.coreboot.org/c/coreboot/+/39043
To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings
Gerrit-Project: coreboot
Gerrit-Branch: master
Gerrit-Change-Id: Ia7a2ca370124ecf743b000998b56855d5ed8f573
Gerrit-Change-Number: 39043
Gerrit-PatchSet: 1
Gerrit-Owner: Patrick Rudolph <patrick.rudolph(a)9elements.com>
Gerrit-MessageType: newchange
Arthur Heymans has uploaded this change for review. ( https://review.coreboot.org/c/coreboot/+/36126 )
Change subject: Documentation: Add cache as ram documentation
......................................................................
Documentation: Add cache as ram documentation
This add documentation around coreboot's history of CAR usage.
The history is reconstructed from articles and git/svn history,
but should provide a good overview of the challenges and solutions
coreboot came up with to deal with early code execution on X86
platforms.
The technical details about CAr will come in follow-up patch and are
marked as TODO for now.
Change-Id: I964d59a6bd210f3d4d06220d2ec7166110ab2cf3
Signed-off-by: Arthur Heymans <arthur(a)aheymans.xyz>
---
A Documentation/cpu/index.md
A Documentation/cpu/x86/car.md
M Documentation/index.md
3 files changed, 171 insertions(+), 0 deletions(-)
git pull ssh://review.coreboot.org:29418/coreboot refs/changes/26/36126/1
diff --git a/Documentation/cpu/index.md b/Documentation/cpu/index.md
new file mode 100644
index 0000000..d9f063f
--- /dev/null
+++ b/Documentation/cpu/index.md
@@ -0,0 +1,5 @@
+# CPU-specific documentation
+
+This section contains documentation about coreboot on specific CPU.
+
+* [A gentle introduction to Cache-as-Ram on X86](x86/car.md)
diff --git a/Documentation/cpu/x86/car.md b/Documentation/cpu/x86/car.md
new file mode 100644
index 0000000..3d2983e
--- /dev/null
+++ b/Documentation/cpu/x86/car.md
@@ -0,0 +1,165 @@
+# A gentle introduction to Cache-as-Ram on X86
+
+This explains a bit of history on CAR in coreboot, how it works
+and then finally give a more in depth overview at the steps of
+how it is set up on Intel CPUs.
+
+## Glossary
+
+- Cache-as-RAM/CAR: Using not memory mapped CPU cache as execution
+ environment.
+- XIP: Execute in place on a memory mapped medium
+- SRAM: Static Random Access Memory, here: memory mapped memory
+ that needs no initialization.
+- ROMCC: A C compiler using only the CPU registers.
+
+## Cache-as-Ram, the basics
+
+When an X86 platforms boot, it starts in a pretty bare environment.
+The first instruction is fetched from the top of the boot medium,
+which on most x86 platforms is memory mapped below 4G (in 32bit
+protected mode). Not only do they start in 16bit 'real' mode,
+most of the hardware starts uninitialized. This includes the dram
+controller. Another thing about X86 platforms is that they generally
+don't feature SRAM, static RAM. SRAM for this purpose of this text is
+a small region of ram that is available without any initialization.
+Without RAM this leaves the system with just CPU registers and a
+memory mapped boot medium of which code can be executed in place (XIP)
+to initialize the hardware.
+
+For simple dram controllers that environment is just fine and
+initializing the dram controller in assembly code without using a
+stack is very doable. Modern systems however require complex
+initialization procedures and writing that in assembly would be either
+too hard or simply impossible. To overcome this limitation a technique
+called Cache-as-Ram exists. It allows to use the CPU's Cache-as-Ram.
+This in turn makes it possible to write the early initialization code
+in a higher level programming language compiled by a regular compiler,
+e.g. GCC. Typically only the stack is placed in Cache-as-Ram and the
+code is still executed in place, but copying code in the cache as ram
+and executing from there is also possible.
+
+For coreboot this means that with only a very small amount of assembly
+code to set up CAR, all the other code can written in C, which
+compared to writing assembly tremendously increases development speed
+and is much less error prone.
+
+## A bit of history on Cache-as-Ram in coreboot
+
+### Linux as a BIOS? The invention of romstage
+
+When LinuxBIOS, later coreboot, started out, the first naive attempt
+to run the Linux kernel instead of the legacy BIOS interface, was to
+jump straight to loading the kernel. This did not work at all, since
+dram was not working at that point. LinuxBIOS v1 therefore
+initialized the memory in assembly before it was able to load the
+kernel. This executed in place and would later become romstage. It
+turned that Linux needed other devices, like enumerated and have it's
+resources allocated, so yet another stage, ramstage, was called into
+life, but that's another story.
+
+### coreboot v2: romcc
+
+In 2003 AMD's K8 CPU's came out. Those CPU's featured an on die memory
+controller and also a new point to point BUS for CPU <-> CPU and
+CPU <-> IO controller (northbridge) devices. Writing support for
+these in assembly became difficult and a better solution was needed.
+This is where ROMCC came to the rescue in 2002. ROMCC is a 25K lines
+of code C compiler, written by Eric Biederman, that does not use a
+stack but uses CPU registers instead. Besides the 8 general purpose
+registers on x86 the MMX and SSE registers, respectively _%mm0_-_%mm7_
+and _%xmm0_-_%xmm7_, can be used to store data. ROMCC also converts
+all function calls to static inline functions. This has the
+disadvantage that a ROMCC compiled stage must be compiled in one go,
+linking is not possible. In practice you will see a lot of '#include
+_some_file.c_' which is quite unusual in C, because it makes the
+inclusion of files fragile. Given that limited amount
+'register-stack', it also imposes restrictions on how many levels of
+nested function can be achieved. One last issue with ROMCC is that
+no-one really dared touching that code, due to its size and complexity
+besides its original author.
+
+Coreboot used ROMCC in the following way: a bootblock written in both
+assembly to enter 32bit protected mode would use ROMCC compiled code
+to either jump to 'normal/romstage' or 'fallback/romstage' which in
+turn was also compiled with romstage.
+
+### Cache-as-Ram
+
+While ROMCC was eventually used for early initialization, prior to
+that development attempts were made to use the CPU's cache as RAM.
+This would allow to use regular GCC compiled and linked code to
+be used. The idea is to set up the CPU's cache to Write Back to a
+region, while disable cacheline filling or simply hope that no cache
+eviction or invalidation happens. Eric Biederman initially got CAR
+working, but with the advent of Intel Hyperthreading on the Pentium 4,
+on which CAR setup proved to be a little more difficult and he
+developed ROMCC instead.
+
+Around 2006 a lot was learned from coreboot v2 with its ROMCC usage
+and development on coreboot v3 was started. The decision was mode to
+not use ROMCC anymore and use Cache Memory for early stages. The
+results were good as init object code size is reduced by factor of
+four. So the code was smaller and faster at the same time.
+
+coreboot v4 sort of merged v2 and v3, so it was a mix of ROMCC compiled
+romstage and romstage with CAR.
+
+In 2014 Support for ROMCC compiled romstage was dropped.
+
+### Intel Apollolake, a new era: POSTCAR_STAGE and C_ENVIRONMENT_BOOTBLOCK
+
+In 2016 Intel released the ApolloLake architecture. This architecture
+is a weird duck in the X86 pool. It is the first Intel CPU to feature
+MMC as a boot medium and does not memory map it. It also features to
+the main CPU read only SRAM that is mapped right below 4G. The
+bootblock is copied to SRAM and executed. Given that the boot medium
+is not always memory mapped XIP is not an option. The solution is to
+set up CAR in the bootblock and copy the romstage in CAR. We call this
+C_ENVIRONMENT_BOOTBLOCK, because it runs GCC compiled code. Granted
+XIP is still possible on ApolloLake, but coreboot has to use Intel's
+blob, FSP-M, and it is linked to run in CAR, so a blob actually forced
+a nice feature in coreboot!
+
+Another issue arises with this setup. With romstage running from the
+read only boot medium, you can continue executing code (albeit without
+stack) to tear down the CAR and start executing code from 'real' RAM.
+On ApolloLake with romstage executing from CAR, tearing down CAR in
+there, would shooting in ones own foot, as our code would be gone
+in doing so. The solution was to tear down CAR in a separate stage,
+named 'postcar' stage. This provides a clean separation of programs
+and results in needing less linker scripts hacks in romstage. This
+solution was therefore adopted by many other platforms that still did
+XIP.
+
+### AMD Zen, 2019
+
+On AMD Zen the first CPU to come out of reset is the PSP and it
+initializes the dram before pulling out the main CPU out of reset.
+CAR won't be needed, nor used on this platform.
+
+### The future?
+
+For coreboot release 4.11, scheduled for october 2019, support for
+ROMCC in the bootblock will be dropped as will support for the messy
+tearing down of CAR in romstage as opposed to doing that in a separate
+stage.
+
+## In depth analysis
+
+### CAR setup
+
+TODO: MTRR, IPI/hyperthreaded, ROM Caching, Non-evict
+
+### Linker symbols
+
+TODO: sharing things over multiple CAR stages: car.ld
+
+### CAR teardown
+
+TODO: postcarstage, NO_CAR_GLOBAL_MIGRATION
+
+## References
+[2007, The Open Source BIOS is Ten An interview with the coreboot developers](http://www.h-online.com/open/features/The-Open-Source-BIOS-is-T…
+[A Framework for Using Processor Cache-as-Ram (CAR)](https://www.coreboot.org/images/6/6c/LBCar.pdf)
+[CAR: Using Cache-as-Ram in LinuxBIOS](https://www.coreboot.org/data/yhlu/cache_as_ram_lb_09142006.pdf)
diff --git a/Documentation/index.md b/Documentation/index.md
index 1c04ad3..85666cb 100644
--- a/Documentation/index.md
+++ b/Documentation/index.md
@@ -177,6 +177,7 @@
* [Display panel-specific documentation](gfx/display-panel.md)
* [Architecture-specific documentation](arch/index.md)
* [Platform independend drivers documentation](drivers/index.md)
+* [CPU-specific documentation](cpu/index.md)
* [Northbridge-specific documentation](northbridge/index.md)
* [System on Chip-specific documentation](soc/index.md)
* [Mainboard-specific documentation](mainboard/index.md)
--
To view, visit https://review.coreboot.org/c/coreboot/+/36126
To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings
Gerrit-Project: coreboot
Gerrit-Branch: master
Gerrit-Change-Id: I964d59a6bd210f3d4d06220d2ec7166110ab2cf3
Gerrit-Change-Number: 36126
Gerrit-PatchSet: 1
Gerrit-Owner: Arthur Heymans <arthur(a)aheymans.xyz>
Gerrit-MessageType: newchange
Hello Julius Werner, Angel Pons, Felix Held,
I'd like you to do a code review. Please visit
https://review.coreboot.org/c/coreboot/+/41848
to review the following change.
Change subject: Revert "src/Kconfig: enable USE_BLOBS by default"
......................................................................
Revert "src/Kconfig: enable USE_BLOBS by default"
This reverts commit a6b887e017f2310db79067b18b216036907b2d90.
It was brought to my attention that the 3rdparty/blobs/ repository
is full of licenses that don't adhere to our binary policy (that
demands unlimited redistribution rights). IANAL, but if the license
texts apply literally, it is not allowed to clone the blobs
repository without reading and agreeing to them.
Change-Id: I7079e23481eb96d1140f2fa5bc1abe7bd4b2bac8
Signed-off-by: Nico Huber <nico.h(a)gmx.de>
---
M src/Kconfig
M util/abuild/abuild
2 files changed, 1 insertion(+), 2 deletions(-)
git pull ssh://review.coreboot.org:29418/coreboot refs/changes/48/41848/1
diff --git a/src/Kconfig b/src/Kconfig
index 2a2a144..6a748db 100644
--- a/src/Kconfig
+++ b/src/Kconfig
@@ -214,7 +214,6 @@
config USE_BLOBS
bool "Allow use of binary-only repository"
- default y
help
This draws in the blobs repository, which contains binary files that
might be required for some chipsets or boards.
diff --git a/util/abuild/abuild b/util/abuild/abuild
index b6a6bfe..4d5ba35 100755
--- a/util/abuild/abuild
+++ b/util/abuild/abuild
@@ -715,7 +715,7 @@
shift;;
-B|--blobs) shift
customizing="${customizing}, blobs"
- configoptions="${configoptions}CONFIG_USE_AMD_BLOBS=y\nCONFIG_ADD_FSP_BINARIES=y\n"
+ configoptions="${configoptions}CONFIG_USE_BLOBS=y\nCONFIG_USE_AMD_BLOBS=y\nCONFIG_ADD_FSP_BINARIES=y\n"
;;
-A|--any-toolchain) shift
customizing="${customizing}, any-toolchain"
--
To view, visit https://review.coreboot.org/c/coreboot/+/41848
To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings
Gerrit-Project: coreboot
Gerrit-Branch: master
Gerrit-Change-Id: I7079e23481eb96d1140f2fa5bc1abe7bd4b2bac8
Gerrit-Change-Number: 41848
Gerrit-PatchSet: 1
Gerrit-Owner: Nico Huber <nico.h(a)gmx.de>
Gerrit-Reviewer: Angel Pons <th3fanbus(a)gmail.com>
Gerrit-Reviewer: Felix Held <felix-coreboot(a)felixheld.de>
Gerrit-Reviewer: Julius Werner <jwerner(a)chromium.org>
Gerrit-MessageType: newchange