the following patch was just integrated into master:
commit c7667f09adac55950a007b0a2162417ff3e05780
Author: WANG Siyuan <wangsiyuanbuaa(a)gmail.com>
Date: Tue Jun 23 22:28:17 2015 +0800
AMD binary PI: add southbridge support for fan control
1. Add functions to support fan control.
2. When IMC firmware is added, the current firmwares' layout
cause build error. There is not enough space to add some firmwares,
so HUDSON_PSP_OFFSET is added to fix this problem.
Change-Id: Ie470a88cb9da256d9f72ea56bf268c15df195784
Signed-off-by: WANG Siyuan <wangsiyuanbuaa(a)gmail.com>
Signed-off-by: WANG Siyuan <SiYuan.Wang(a)amd.com>
Reviewed-on: http://review.coreboot.org/10720
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones(a)se-eng.com>
See http://review.coreboot.org/10720 for details.
-gerrit
the following patch was just integrated into master:
commit 3f95f1d62139e28df680e07116a6ea76815cec37
Author: WANG Siyuan <wangsiyuanbuaa(a)gmail.com>
Date: Tue Jun 23 22:14:33 2015 +0800
AMD binary PI: add vendorcode support for fan control
Binary PI doesn't provide fan control lib.
HwmLateService.c and ImcLib.c are ported from Kabini PI.
I have tested on AMD Bettong. The two files work.
Change-Id: Ia4d24650d2a5544674e9d44c502e8fd9da0b55d3
Signed-off-by: WANG Siyuan <wangsiyuanbuaa(a)gmail.com>
Signed-off-by: WANG Siyuan <SiYuan.Wang(a)amd.com>
Reviewed-on: http://review.coreboot.org/10719
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones(a)se-eng.com>
See http://review.coreboot.org/10719 for details.
-gerrit
Martin Roth (gaumless(a)gmail.com) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/11074
-gerrit
commit bf65c9c16574bb9b527ff5250fd8088f0fe194ac
Author: Martin Roth <martinroth(a)google.com>
Date: Wed Jul 29 14:55:18 2015 -0700
Add cscope/ctags generation for the current project
Use the dependency files to generate ctags or cscope data for the
current project instead of the entire coreboot tree.
This isn't completely working for every platform at this point -
while it finds all of the code in the coreboot/src tree, it doesn't
find the code in 3rdparty right now.
Change-Id: Ie8aabcf46c8a69f718940c9e0fd7e7b05c9ce1fb
Signed-off-by: Martin Roth <martinroth(a)google.com>
---
Makefile | 19 ++++++++++++++++++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index 3a1b83a..421e919 100644
--- a/Makefile
+++ b/Makefile
@@ -251,6 +251,19 @@ ifndef NOMKDIR
$(shell mkdir -p $(KCONFIG_SPLITCONFIG) $(objk)/lxdialog $(additional-dirs) $(alldirs))
endif
+$(obj)/project_filelist.txt: all
+ find $(obj) -name "*.d" -exec cat {} \; | \
+ sed 's/[:\\]/ /g' | sed 's/ /\n/g' | sort | uniq | \
+ grep -v '\.o$$' > $(obj)/project_filelist.txt
+
+#works with either exuberant ctags or ctags.emacs
+ctags-project: clean-ctags $(obj)/project_filelist.txt
+ cat $(obj)/project_filelist.txt | \
+ xargs ctags -o tags
+
+cscope-project: clean-cscope $(obj)/project_filelist.txt
+ cat $(obj)/project_filelist.txt | xargs cscope -b
+
cscope:
cscope -bR
@@ -274,7 +287,11 @@ clean: clean-for-update clean-target
clean-cscope:
rm -f cscope.out
-distclean: clean
+clean-ctags:
+ rm -f tags
+
+distclean: clean clean-ctags clean-cscope
rm -f .config .config.old ..config.tmp .kconfig.d .tmpconfig* .ccwrap .xcompile
.PHONY: $(PHONY) clean clean-for-update clean-cscope cscope distclean doxygen doxy doxygen_simple
+.PHONY: ctags-project cscope-project clean-ctags
the following patch was just integrated into master:
commit a7ff45309020118cb88fae98ffe9da5c856f83e2
Author: Rizwan Qureshi <rizwan.qureshi(a)intel.com>
Date: Thu Jul 23 22:40:53 2015 +0530
skylake: Update microcode reload in ramstage.
For Skylake, Microcode is being loaded from FIT, Skylake supports
the PRMRR/SGX feature. If This is supported the FIT microcode
load will set the msr (0x08b) with the Patch id one less than the
id in the microcode binary. This results in Microcode getting
reloaded again in bootclock and ramstage (MP init).
Avoid the microcode reload by checking for PRMRR support.
BUG=chrome-os-partner:42046
BRANCH=None TEST=Built for glados and tested on RVP3
CQ-DEPEND=CL:287513
Change-Id: Ic5dbf4d14dc1441e5b5acead589a418687df7dca
Signed-off-by: Patrick Georgi <pgeorgi(a)chromium.org>
Original-Commit-Id: c599714b2aef476297eeaad5da8975731b12785a
Original-Change-Id: Id3a387aa2d8fd2fd69052bfc7b4e88a7ec277a72
Original-Signed-off-by: Rizwan Qureshi <rizwan.qureshi(a)intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/287674
Original-Reviewed-by: Aaron Durbin <adurbin(a)chromium.org>
Reviewed-on: http://review.coreboot.org/11056
Reviewed-by: Stefan Reinauer <stefan.reinauer(a)coreboot.org>
Tested-by: build bot (Jenkins)
See http://review.coreboot.org/11056 for details.
-gerrit
the following patch was just integrated into master:
commit 30b755be2b798c228745661393efd8f2fe42e6d8
Author: Rizwan Qureshi <rizwan.qureshi(a)intel.com>
Date: Thu Jul 23 22:31:51 2015 +0530
Add SoC specific microcode update check in ramstage
Some Intel SoCs which support SGX feature, report the
microcode patch revision one less than the actual revision.
This results in the same microcode patch getting loaded again.
Add a SoC specific check to avoid reloading the same patch.
BUG=chrome-os-partner:42046
BRANCH=None
TEST=Built for glados and tested on RVP3
CQ-DEPEND=CL:286054
Change-Id: Iab4c34c6c55119045947f598e89352867c67dcb8
Signed-off-by: Patrick Georgi <pgeorgi(a)chromium.org>
Original-Commit-Id: ab2ed73db3581cd432f9bc84acca47f5e53a0e9b
Original-Change-Id: I4f7bf9c841e5800668208c11b0afcf8dba48a775
Original-Signed-off-by: Rizwan Qureshi <rizwan.qureshi(a)intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/287513
Original-Reviewed-by: Aaron Durbin <adurbin(a)chromium.org>
Reviewed-on: http://review.coreboot.org/11055
Reviewed-by: Stefan Reinauer <stefan.reinauer(a)coreboot.org>
Tested-by: build bot (Jenkins)
See http://review.coreboot.org/11055 for details.
-gerrit
the following patch was just integrated into master:
commit c33958310ef820162b2c8f31a10e89a8b7b76d3d
Author: Rizwan Qureshi <rizwan.qureshi(a)intel.com>
Date: Tue Jul 7 18:18:15 2015 +0530
Skylake: Fix microcode reload in bootblock cpu init
If Skylake microcode is being loaded from FIT, Skylake supports
the PRMRR/SGX feature. If this is supported the FIT microcode
load will set the msr (0x08b) with the patch ID one less than the
ID in the microcode binary. This results in microcode getting
reloaded again in the bootblock cpu init.
Avoid the microcode reload by checking for PRMRR support.
BUG=chrome-os-partner:42046
BRANCH=None
TEST=Built for glados and tested on RVP3
Change-Id: I06e59f5cad549098c7ba2dfa608cd94a0b3f0ae1
Signed-off-by: Patrick Georgi <pgeorgi(a)chromium.org>
Original-Commit-Id: 6242b9dea283149bd0c968af1ba186647d37162d
Original-Change-Id: Iea5a223aa625be3fc451e8ee5d3510f548b07f8b
Original-Signed-off-by: Rizwan Qureshi <rizwan.qureshi(a)intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/286054
Original-Reviewed-by: Aaron Durbin <adurbin(a)chromium.org>
Reviewed-on: http://review.coreboot.org/11052
Reviewed-by: Stefan Reinauer <stefan.reinauer(a)coreboot.org>
Tested-by: build bot (Jenkins)
See http://review.coreboot.org/11052 for details.
-gerrit
the following patch was just integrated into master:
commit 8d8799a33aac86c2acdf94e0f0af3ef291748536
Author: Julius Werner <jwerner(a)chromium.org>
Date: Fri Dec 19 16:11:14 2014 -0800
arm, arm64, mips: Add rough static stack size checks with -Wstack-usage
We've seen an increasing need to reduce stack sizes more and more for
space reasons, and it's always guesswork because no one has a good idea
how little is too litte. We now have boards with 3K and 2K stacks, and
old pieces of common code often allocate large temporary buffers that
would lead to very dangerous and hard to detect bugs when someone
eventually tries to use them on one of those.
This patch tries improve this situation at least a bit by declaring 2K
as the minimum stack size all of coreboot code should work with. It
checks all function frames with -Wstack-usage=1536 to make sure we don't
allocate more than 1.5K in a single buffer. This is of course not a
perfect test, but it should catch the most common situation of declaring
a single, large buffer in some close-to-leaf function (with the
assumption that 0.5K is hopefully enough for all the "normal" functions
above that).
Change one example where we were a bit overzealous and put a 1K buffer
into BSS back to stack allocation, since it actually conforms to this
new assumption and frees up another kilobyte of that highly sought-after
verstage space. Not touching x86 with any of this since it's lack of
__PRE_RAM__ BSS often requires it to allocate way more on the stack than
would usually be considered sane.
BRANCH=veyron
BUG=None
TEST=Compiled Cosmos, Daisy, Falco, Blaze, Pit, Storm, Urara and Pinky,
made sure they still build as well as before and don't show any stack
usage warnings.
Change-Id: Idc53d33bd8487bbef49d3ecd751914b0308006ec
Signed-off-by: Patrick Georgi <pgeorgi(a)chromium.org>
Original-Commit-Id: 8e5931066575e256dfc2295c3dab7f0e1b65417f
Original-Change-Id: I30bd9c2c77e0e0623df89b9e5bb43ed29506be98
Original-Signed-off-by: Julius Werner <jwerner(a)chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/236978
Original-Reviewed-by: David Hendricks <dhendrix(a)chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin(a)chromium.org>
Reviewed-on: http://review.coreboot.org/9729
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer(a)coreboot.org>
See http://review.coreboot.org/9729 for details.
-gerrit
Patrick Georgi (pgeorgi(a)google.com) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/9729
-gerrit
commit fe1efcdd9f0339b877f2e1d3560d0ad7a6c38192
Author: Julius Werner <jwerner(a)chromium.org>
Date: Fri Dec 19 16:11:14 2014 -0800
arm, arm64, mips: Add rough static stack size checks with -Wstack-usage
We've seen an increasing need to reduce stack sizes more and more for
space reasons, and it's always guesswork because no one has a good idea
how little is too litte. We now have boards with 3K and 2K stacks, and
old pieces of common code often allocate large temporary buffers that
would lead to very dangerous and hard to detect bugs when someone
eventually tries to use them on one of those.
This patch tries improve this situation at least a bit by declaring 2K
as the minimum stack size all of coreboot code should work with. It
checks all function frames with -Wstack-usage=1536 to make sure we don't
allocate more than 1.5K in a single buffer. This is of course not a
perfect test, but it should catch the most common situation of declaring
a single, large buffer in some close-to-leaf function (with the
assumption that 0.5K is hopefully enough for all the "normal" functions
above that).
Change one example where we were a bit overzealous and put a 1K buffer
into BSS back to stack allocation, since it actually conforms to this
new assumption and frees up another kilobyte of that highly sought-after
verstage space. Not touching x86 with any of this since it's lack of
__PRE_RAM__ BSS often requires it to allocate way more on the stack than
would usually be considered sane.
BRANCH=veyron
BUG=None
TEST=Compiled Cosmos, Daisy, Falco, Blaze, Pit, Storm, Urara and Pinky,
made sure they still build as well as before and don't show any stack
usage warnings.
Change-Id: Idc53d33bd8487bbef49d3ecd751914b0308006ec
Signed-off-by: Patrick Georgi <pgeorgi(a)chromium.org>
Original-Commit-Id: 8e5931066575e256dfc2295c3dab7f0e1b65417f
Original-Change-Id: I30bd9c2c77e0e0623df89b9e5bb43ed29506be98
Original-Signed-off-by: Julius Werner <jwerner(a)chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/236978
Original-Reviewed-by: David Hendricks <dhendrix(a)chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin(a)chromium.org>
---
src/arch/arm/include/arch/memlayout.h | 4 +++-
src/arch/arm64/include/arch/memlayout.h | 4 +++-
src/arch/mips/include/arch/memlayout.h | 4 +++-
src/drivers/spi/spi_flash.c | 4 ++++
src/lib/gpio.c | 4 +++-
src/vendorcode/google/chromeos/vboot2/verstage.c | 2 +-
toolchain.inc | 18 ++++++++++++++++++
7 files changed, 35 insertions(+), 5 deletions(-)
diff --git a/src/arch/arm/include/arch/memlayout.h b/src/arch/arm/include/arch/memlayout.h
index b28e0cf..86f5585 100644
--- a/src/arch/arm/include/arch/memlayout.h
+++ b/src/arch/arm/include/arch/memlayout.h
@@ -35,7 +35,9 @@
"TTB subtable region must be evenly divisible by table size!");
/* ARM stacks need 8-byte alignment and stay in one place through ramstage. */
-#define STACK(addr, size) REGION(stack, addr, size, 8)
+#define STACK(addr, size) \
+ REGION(stack, addr, size, 8) \
+ _ = ASSERT(size >= 2K, "stack should be >= 2K, see toolchain.inc");
#define DMA_COHERENT(addr, size) \
REGION(dma_coherent, addr, size, SUPERPAGE_SIZE) \
diff --git a/src/arch/arm64/include/arch/memlayout.h b/src/arch/arm64/include/arch/memlayout.h
index 522f1ab..30db848 100644
--- a/src/arch/arm64/include/arch/memlayout.h
+++ b/src/arch/arm64/include/arch/memlayout.h
@@ -27,7 +27,9 @@
/* ARM64 stacks need 16-byte alignment. The ramstage will set up its own stacks
* in BSS, so this is only used for the SRAM stages. */
#ifdef __PRE_RAM__
-#define STACK(addr, size) REGION(stack, addr, size, 16)
+#define STACK(addr, size) \
+ REGION(stack, addr, size, 16) \
+ _ = ASSERT(size >= 2K, "stack should be >= 2K, see toolchain.inc");
#else
#define STACK(addr, size) REGION(preram_stack, addr, size, 16)
#endif
diff --git a/src/arch/mips/include/arch/memlayout.h b/src/arch/mips/include/arch/memlayout.h
index 9493173..946fcf3 100644
--- a/src/arch/mips/include/arch/memlayout.h
+++ b/src/arch/mips/include/arch/memlayout.h
@@ -24,7 +24,9 @@
/* MIPS stacks need 8-byte alignment and stay in one place through ramstage. */
/* TODO: Double-check that that's the correct alignment for our ABI. */
-#define STACK(addr, size) REGION(stack, addr, size, 8)
+#define STACK(addr, size) \
+ REGION(stack, addr, size, 8) \
+ _ = ASSERT(size >= 2K, "stack should be >= 2K, see toolchain.inc");
#define DMA_COHERENT(addr, size) REGION(dma_coherent, addr, size, 4K)
diff --git a/src/drivers/spi/spi_flash.c b/src/drivers/spi/spi_flash.c
index 91fd5d3..690b277 100644
--- a/src/drivers/spi/spi_flash.c
+++ b/src/drivers/spi/spi_flash.c
@@ -95,6 +95,9 @@ static int spi_flash_cmd_read(struct spi_slave *spi, const u8 *cmd,
return ret;
}
+/* TODO: This code is quite possibly broken and overflowing stacks. Fix ASAP! */
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Wstack-usage="
int spi_flash_cmd_write(struct spi_slave *spi, const u8 *cmd, size_t cmd_len,
const void *data, size_t data_len)
{
@@ -111,6 +114,7 @@ int spi_flash_cmd_write(struct spi_slave *spi, const u8 *cmd, size_t cmd_len,
return ret;
}
+#pragma GCC diagnostic pop
static int spi_flash_cmd_read_array(struct spi_slave *spi, u8 *cmd,
size_t cmd_len, u32 offset,
diff --git a/src/lib/gpio.c b/src/lib/gpio.c
index b185cc2..72bd7ec 100644
--- a/src/lib/gpio.c
+++ b/src/lib/gpio.c
@@ -17,6 +17,7 @@
* Foundation, Inc.
*/
+#include <assert.h>
#include <base3.h>
#include <console/console.h>
#include <delay.h>
@@ -53,7 +54,8 @@ int gpio_base3_value(gpio_t gpio[], int num_gpio)
int temp;
int index;
int result = 0;
- char value[num_gpio];
+ char value[32];
+ assert(num_gpio <= 32);
/* Enable internal pull up */
for (index = 0; index < num_gpio; ++index)
diff --git a/src/vendorcode/google/chromeos/vboot2/verstage.c b/src/vendorcode/google/chromeos/vboot2/verstage.c
index 2a2a956..7803d39 100644
--- a/src/vendorcode/google/chromeos/vboot2/verstage.c
+++ b/src/vendorcode/google/chromeos/vboot2/verstage.c
@@ -119,7 +119,7 @@ static int hash_body(struct vb2_context *ctx, struct region_device *fw_main)
{
uint64_t load_ts;
uint32_t expected_size;
- MAYBE_STATIC uint8_t block[TODO_BLOCK_SIZE];
+ uint8_t block[TODO_BLOCK_SIZE];
size_t block_size = sizeof(block);
size_t offset;
int rv;
diff --git a/toolchain.inc b/toolchain.inc
index 89bc55c..eea0560 100644
--- a/toolchain.inc
+++ b/toolchain.inc
@@ -74,6 +74,24 @@ CFLAGS_riscv += -ffunction-sections -fdata-sections
CFLAGS_x86_64 += -mcmodel=large -mno-red-zone
+# Some boards only provide 2K stacks, so storing lots of data there leads to
+# problems. Since C rules don't allow us to statically determine the maximum
+# stack use, we use 1.5K as heuristic, assuming that we typically have lots
+# of tiny stack frames and the odd large one.
+#
+# Store larger buffers in BSS, use MAYBE_STATIC to share code with __PRE_RAM__
+# on x86.
+# Since GCCs detection of dynamic array bounds unfortunately seems to be
+# very basic, you'll sometimes have to use a static upper bound for the
+# size and an assert() to make sure it's honored (see gpio_base3_value()
+# for an example).
+# (If you absolutely need a larger stack frame and are 100% sure it cannot
+# cause problems, you can whitelist it with #pragma diagnostic.)
+CFLAGS_arm += -Wstack-usage=1536
+CFLAGS_arm64 += -Wstack-usage=1536
+CFLAGS_mips += -Wstack-usage=1536
+CFLAGS_riscv += -Wstack-usage=1536
+
toolchain_to_dir = \
$(foreach arch,$(ARCH_SUPPORTED),\
$(eval CPPFLAGS_$(arch) += \
Patrick Georgi (pgeorgi(a)google.com) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/11052
-gerrit
commit 3ec8109d372872b819840e555085bc50552418b2
Author: Rizwan Qureshi <rizwan.qureshi(a)intel.com>
Date: Tue Jul 7 18:18:15 2015 +0530
Skylake: Fix microcode reload in bootblock cpu init
If Skylake microcode is being loaded from FIT, Skylake supports
the PRMRR/SGX feature. If this is supported the FIT microcode
load will set the msr (0x08b) with the patch ID one less than the
ID in the microcode binary. This results in microcode getting
reloaded again in the bootblock cpu init.
Avoid the microcode reload by checking for PRMRR support.
BUG=chrome-os-partner:42046
BRANCH=None
TEST=Built for glados and tested on RVP3
Change-Id: I06e59f5cad549098c7ba2dfa608cd94a0b3f0ae1
Signed-off-by: Patrick Georgi <pgeorgi(a)chromium.org>
Original-Commit-Id: 6242b9dea283149bd0c968af1ba186647d37162d
Original-Change-Id: Iea5a223aa625be3fc451e8ee5d3510f548b07f8b
Original-Signed-off-by: Rizwan Qureshi <rizwan.qureshi(a)intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/286054
Original-Reviewed-by: Aaron Durbin <adurbin(a)chromium.org>
---
src/soc/intel/skylake/bootblock/cpu.c | 24 +++++++++++++++++++++++-
src/soc/intel/skylake/include/soc/msr.h | 2 +-
2 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/src/soc/intel/skylake/bootblock/cpu.c b/src/soc/intel/skylake/bootblock/cpu.c
index d4506e5..2e3e000 100644
--- a/src/soc/intel/skylake/bootblock/cpu.c
+++ b/src/soc/intel/skylake/bootblock/cpu.c
@@ -178,11 +178,33 @@ static void check_for_clean_reset(void)
soft_reset();
}
+static int need_microcode_update(void)
+{
+ /* If PRMRR/SGX is supported the FIT microcode load step will set
+ * msr 0x08b with the Patch revision id one less than the id in the
+ * microcode binary. The PRMRR support is indicated in the MSR
+ * MTRRCAP[12]. Check for this feature and avoid reloading the
+ * same microcode during early cpu initialization.
+ */
+ msr = rdmsr(MTRRcap_MSR);
+ return (msr.lo & PRMRR_SUPPORTED) && (current_rev != patch->rev - 1);
+}
+
static void bootblock_cpu_init(void)
{
+ const struct microcode *patch;
+ u32 current_rev;
+ msr_t msr;
+
/* Set flex ratio and reset if needed */
set_flex_ratio_to_tdp_nominal();
check_for_clean_reset();
enable_rom_caching();
- intel_update_microcode_from_cbfs();
+
+ patch = intel_microcode_find();
+
+ current_rev = read_microcode_rev();
+
+ if (need_microcode_update())
+ intel_update_microcode_from_cbfs();
}
diff --git a/src/soc/intel/skylake/include/soc/msr.h b/src/soc/intel/skylake/include/soc/msr.h
index b857dbe..3903757 100644
--- a/src/soc/intel/skylake/include/soc/msr.h
+++ b/src/soc/intel/skylake/include/soc/msr.h
@@ -105,6 +105,6 @@
/* MTRRcap_MSR bits */
#define SMRR_SUPPORTED (1<<11)
-#define EMRR_SUPPORTED (1<<12)
+#define PRMRR_SUPPORTED (1<<12)
#endif