coreboot-gerrit November 2016

coreboot-gerrit@coreboot.org

1 participants
1666 discussions

New patch to review for coreboot: vendorcode/intel/fsp2_0: Add new fields to FSPM UPD on Apollolake
by Andrey Petrov 05 Nov '16

05 Nov '16

Andrey Petrov (andrey.petrov(a)intel.com) just uploaded a new patch set to gerrit, which you can find at https://review.coreboot.org/17236 -gerrit commit 4702ef246d6875729abe48c8ee82f696fc71798f Author: Andrey Petrov <andrey.petrov(a)intel.com> Date: Fri Nov 4 16:21:58 2016 -0700 vendorcode/intel/fsp2_0: Add new fields to FSPM UPD on Apollolake BUG=chrome-os-partner:57515 TEST=with patch series applied: cold reboot, make sure MRC is not updated. Do S3 suspend/resume cycle. Change-Id: I533f504d9e713a28788ad32f6ba399a2930b2384 Signed-off-by: Andrey Petrov <andrey.petrov(a)intel.com> --- .../intel/fsp/fsp2_0/apollolake/FspmUpd.h | 21 +++++++++++++-------- 1 file changed, 13 insertions(+), 8 deletions(-) diff --git a/src/vendorcode/intel/fsp/fsp2_0/apollolake/FspmUpd.h b/src/vendorcode/intel/fsp/fsp2_0/apollolake/FspmUpd.h index d2d2461..21c1110 100644 --- a/src/vendorcode/intel/fsp/fsp2_0/apollolake/FspmUpd.h +++ b/src/vendorcode/intel/fsp/fsp2_0/apollolake/FspmUpd.h @@ -796,33 +796,38 @@ typedef struct { Enable FSP to trigger reset instead of returning reset request. 0x00: Return the Return Status from FSP if a reset is required. (default); 0x01: Perform Reset inside FSP instead of returning from the API. - 0x0:Disabled, 0x1:Enabled + 0x0:Disabled, 0x1:Eabled **/ UINT8 EnableResetSystem; /** Offset 0x014C - Enable HECI2 in S3 resume path Enable HECI2 in S3 resume path. 0x00: Skip HECI2 initialization in S3 resume. ; 0x01: Enable HECI2 in S3 resume path.(Default) - 0x0:Disabled, 0x1:Enabled + 0x0:Disabled, 0x1:Eabled **/ UINT8 EnableS3Heci2; -/** Offset 0x014D + UINT8 unused[3]; +/** Offset 0x0150 +**/ + VOID* VariableNvsBufferPtr; + +/** Offset 0x0154 **/ - UINT8 ReservedFspmUpd[3]; + UINT8 ReservedFspmUpd[12]; } FSP_M_CONFIG; /** Fsp M Test Configuration **/ typedef struct { -/** Offset 0x0150 +/** Offset 0x0160 **/ UINT32 Signature; -/** Offset 0x0154 +/** Offset 0x0164 **/ - UINT8 ReservedFspmTestUpd[28]; + UINT8 ReservedFspmTestUpd[12]; } FSP_M_TEST_CONFIG; /** Fsp M Restricted Configuration @@ -854,7 +859,7 @@ typedef struct { **/ FSP_M_CONFIG FspmConfig; -/** Offset 0x0150 +/** Offset 0x0160 **/ FSP_M_TEST_CONFIG FspmTestConfig;

1 0

New patch to review for coreboot: mainboard/reef: Add RW_VAR_MRC_CACHE
by Andrey Petrov 05 Nov '16

05 Nov '16

Andrey Petrov (andrey.petrov(a)intel.com) just uploaded a new patch set to gerrit, which you can find at https://review.coreboot.org/17235 -gerrit commit 62a85493d24a10c11037de429e70a8d1ea482a76 Author: Andrey Petrov <andrey.petrov(a)intel.com> Date: Fri Nov 4 16:17:11 2016 -0700 mainboard/reef: Add RW_VAR_MRC_CACHE Chop off 4kb block from RW_MRC_CACHE to store variable MRC cache. BUG=chrome-os-partner:57515 TEST=with patch series applied: cold reboot, make sure MRC is not updated. Do S3 suspend/resume cycle. Change-Id: I3e19fff9c9b20d6c73cbb13bfeec49e9a274bb72 Signed-off-by: Andrey Petrov <andrey.petrov(a)intel.com> --- src/mainboard/google/reef/chromeos.fmd | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/mainboard/google/reef/chromeos.fmd b/src/mainboard/google/reef/chromeos.fmd index d25a9b2..6e9816c 100644 --- a/src/mainboard/google/reef/chromeos.fmd +++ b/src/mainboard/google/reef/chromeos.fmd @@ -13,7 +13,8 @@ FLASH 16M { } } MISC_RW@0x400000 0x4a000 { - RW_MRC_CACHE@0x0 0x40000 + RW_MRC_CACHE@0x0 0x3f000 + RW_VAR_MRC_CACHE@0x3f000 0x1000 RW_ELOG@0x40000 0x4000 RW_SHARED@0x44000 0x4000 { SHARED_DATA@0x0 0x2000

1 0

New patch to review for coreboot: WIP: soc/intel/common: Enable SPI NVM functions in pre-ram stages
by Andrey Petrov 05 Nov '16

05 Nov '16

Andrey Petrov (andrey.petrov(a)intel.com) just uploaded a new patch set to gerrit, which you can find at https://review.coreboot.org/17234 -gerrit commit 35a856e656ca300db0e0a2411b129d891c640900 Author: Andrey Petrov <andrey.petrov(a)intel.com> Date: Fri Nov 4 15:37:27 2016 -0700 WIP: soc/intel/common: Enable SPI NVM functions in pre-ram stages Put global variable into car global. BUG=chrome-os-partner:57515 CQ-DEPEND=CL:*303016 TEST=with patch series applied: cold reboot, make sure MRC is not updated. Do S3 suspend/resume cycle. Change-Id: I35ea29096abcdde482b99d90db022b7c7bc95c29 Signed-off-by: Andrey Petrov <andrey.petrov(a)intel.com> --- src/soc/intel/common/Makefile.inc | 1 + src/soc/intel/common/nvm.c | 22 +++++++++++++++++----- 2 files changed, 18 insertions(+), 5 deletions(-) diff --git a/src/soc/intel/common/Makefile.inc b/src/soc/intel/common/Makefile.inc index 38903a0..51b6f86 100644 --- a/src/soc/intel/common/Makefile.inc +++ b/src/soc/intel/common/Makefile.inc @@ -13,6 +13,7 @@ romstage-$(CONFIG_SOC_INTEL_COMMON_LPSS_I2C) += lpss_i2c.c romstage-$(CONFIG_SOC_INTEL_COMMON_RESET) += reset.c romstage-y += util.c romstage-$(CONFIG_MMA) += mma.c +romstage-$(CONFIG_CACHE_MRC_SETTINGS) += nvm.c postcar-y += util.c postcar-$(CONFIG_SOC_INTEL_COMMON_RESET) += reset.c diff --git a/src/soc/intel/common/nvm.c b/src/soc/intel/common/nvm.c index 6b86faf..e4d8bbd 100644 --- a/src/soc/intel/common/nvm.c +++ b/src/soc/intel/common/nvm.c @@ -13,6 +13,7 @@ * GNU General Public License for more details. */ +#include <arch/early_variables.h> #include <stdint.h> #include <stddef.h> #include <bootmode.h> @@ -28,16 +29,17 @@ * address space for reading. Also this module assumes an area it erased * when all bytes read as all 0xff's. */ -static struct spi_flash *flash; +static struct spi_flash *gflash CAR_GLOBAL; static int nvm_init(void) { - if (flash != NULL) - return 0; + struct spi_flash **flash_ptr = car_get_var_ptr(&gflash); + if (*flash_ptr != NULL) + return 0; spi_init(); - flash = spi_flash_probe(0, 0); - if (!flash) { + *flash_ptr = spi_flash_probe(0, 0); + if (!*flash_ptr) { printk(BIOS_DEBUG, "Could not find SPI device\n"); return -1; } @@ -79,25 +81,35 @@ int nvm_is_erased(const void *start, size_t size) int nvm_erase(void *start, size_t size) { + struct spi_flash *flash; + if (nvm_init() < 0) return -1; + flash = (struct spi_flash*) car_get_var(gflash); return flash->erase(flash, nvm_mmio_to_flash_offset(start), size); } /* Write data to NVM. Returns 0 on success < 0 on error. */ int nvm_write(void *start, const void *data, size_t size) { + struct spi_flash *flash; + if (nvm_init() < 0) return -1; + flash = car_get_var(gflash); return flash->write(flash, nvm_mmio_to_flash_offset(start), size, data); } /* Read flash status register to determine if write protect is active */ int nvm_is_write_protected(void) { + struct spi_flash *flash; + if (nvm_init() < 0) return -1; + flash = car_get_var(gflash); + if (IS_ENABLED(CONFIG_CHROMEOS)) { u8 sr1; u8 wp_gpio;

1 0

Patch set updated for coreboot: riscv: map first 2GiB of physical memory at the top of virtual address space
by Ronald G. Minnich 05 Nov '16

05 Nov '16

Ronald G. Minnich (rminnich(a)gmail.com) just uploaded a new patch set to gerrit, which you can find at https://review.coreboot.org/17233 -gerrit commit 6501092197e2a8b21dd0f5abc545d49b1ee0c308 Author: Ronald G. Minnich <rminnich(a)gmail.com> Date: Fri Nov 4 11:27:25 2016 -0700 riscv: map first 2GiB of physical memory at the top of virtual address space We were mapping physical to virtual 1:1, which makes no sense; most kernels want to start at high negative address space. Doing it this way ensures that we're following the intent of the RISCV designers, i.e that virtual addresses are correct at the start; and that the kernel does not have to unmap the low physical addresses once it starts. Change-Id: I8c577ad885891b4c33c20077995abbd90f355f1c Signed-off-by: Ronald G. Minnich <rminnich(a)gmail.com> --- src/arch/riscv/virtual_memory.c | 43 ++++++++++++++++++++++++++++++++++++----- 1 file changed, 38 insertions(+), 5 deletions(-) diff --git a/src/arch/riscv/virtual_memory.c b/src/arch/riscv/virtual_memory.c index 999d73c..7091f02 100644 --- a/src/arch/riscv/virtual_memory.c +++ b/src/arch/riscv/virtual_memory.c @@ -168,12 +168,40 @@ void init_vm(uintptr_t virtMemStart, uintptr_t physMemStart, pte_t *sbi_pt) // IO space. root_pt[0] = pte_create(0, PTE_W|PTE_R, 0); - root_pt[1] = pte_create(0x40000000>>RISCV_PGSHIFT, + root_pt[1] = pte_create(0x40000000 >> RISCV_PGSHIFT, PTE_W|PTE_R, 0); // Start of RAM - root_pt[2] = pte_create(0x80000000>>RISCV_PGSHIFT, - PTE_W|PTE_R, 0); + // + // A RISCV goal is that Machine or Hypervisor modes be able + // start a Supervisor (kernel) at the C entry point. The + // intent is that firmware creates the virtual memory maps for + // the kernel to use. + // + // Question: what is the virtual address of physical memory + // for a kernel? Hey, glad you asked! In most kernels out + // there, physical memory is mapped at the top of the virtual + // address space. The express intent of the RISCV designers + // (I asked them) is that we be able to enter a kernel at + // main() in C, with no assembly needed. + // + // This is a neat idea that may not quite work out. For + // example: where's the stack go? Once you start in + // Supervisor mode, you are using virtual addresses set up by + // coreboot. So you can't use the coreboot stack, it's mapped + // to low physical addresses. You *should* not use the + // coreboot stack, your kernel may need it in a different + // place. So the kernel needs to change the stack, in ... a + // bit of startup assembly code, what else? Oh well. Map + // physical to high virtual. It's the most common way to + // go. Kernels that want to put kernel virtual addresses based + // at 0 will need to fixup page tables in ... a bit of startup + // assembly code :-) + // + // TODO: use a constant for the number of PTEs per page, when + // (hopefully) newer RISCV toolchains define that constant. + root_pt[0x1ff] = pte_create(0x80000000 >> RISCV_PGSHIFT, + PTE_R | PTE_W | PTE_X, 0); mb(); root_page_table = root_pt; uintptr_t ptbr = ((uintptr_t) root_pt) >> RISCV_PGSHIFT; @@ -198,9 +226,14 @@ void initVirtualMemory(void) { } // TODO: Figure out how to grab this from cbfs + // N.B. We used to map phsyical from 0x81000000, + // but since kernels need to be able to see the page tables + // created by firmware, we're going to map from start of RAM. + // All this is subject to change as we learn more. Much + // about RISCV is still in flux. printk(BIOS_DEBUG, "Initializing virtual memory...\n"); - uintptr_t physicalStart = 0x81000000; - uintptr_t virtualStart = 0xffffffff81000000; + uintptr_t physicalStart = 0x80000000; + uintptr_t virtualStart = 0xffffffff80000000; init_vm(virtualStart, physicalStart, (pte_t *)_pagetables); mb(); flush_tlb();

1 0

Patch merged into coreboot/master: reef: tune trackpad i2c frequency to 400kHz
by gerrit＠coreboot.org 04 Nov '16

04 Nov '16

the following patch was just integrated into master: commit 85a80ef4726a0f088d7d2007553349b861908386 Author: Aaron Durbin <adurbin(a)chromium.org> Date: Thu Nov 3 13:34:13 2016 -0500 reef: tune trackpad i2c frequency to 400kHz This brings the frequency down to 400kHz which is spec for fast i2c. BUG=chrome-os-partner:58889 Change-Id: Ibc5f152e55ed618f18ac6425264f086b1f2d1ffa Signed-off-by: Aaron Durbin <adurbin(a)chromium.org> Reviewed-on: https://review.coreboot.org/17215 Reviewed-by: Duncan Laurie <dlaurie(a)chromium.org> Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter(a)users.sourceforge.net> See https://review.coreboot.org/17215 for details. -gerrit

1 0

Patch merged into coreboot/master: reef: tune tpm i2c frequency to 400kHz
by gerrit＠coreboot.org 04 Nov '16

04 Nov '16

the following patch was just integrated into master: commit 242cb3b601396a5178680f7731b8d5f9d257c646 Author: Aaron Durbin <adurbin(a)chromium.org> Date: Thu Nov 3 08:34:23 2016 -0500 reef: tune tpm i2c frequency to 400kHz This brings the frequency down to 400kHz which is spec for fast i2c. BUG=chrome-os-partner:58889 Change-Id: I8689a062b5457aa431eaa7fb688a7170dad83fcf Signed-off-by: Aaron Durbin <adurbin(a)chromium.org> Reviewed-on: https://review.coreboot.org/17214 Reviewed-by: Duncan Laurie <dlaurie(a)chromium.org> Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter(a)users.sourceforge.net> See https://review.coreboot.org/17214 for details. -gerrit

1 0

Patch set updated for coreboot: riscv: map first 2GiB of physical memory at the top of virtual address space
by Ronald G. Minnich 04 Nov '16

04 Nov '16

Ronald G. Minnich (rminnich(a)gmail.com) just uploaded a new patch set to gerrit, which you can find at https://review.coreboot.org/17233 -gerrit commit 112db496abb0fa1f5cf1ac85db4a75d954905ab3 Author: Ronald G. Minnich <rminnich(a)gmail.com> Date: Fri Nov 4 11:27:25 2016 -0700 riscv: map first 2GiB of physical memory at the top of virtual address space We were mapping physical to virtual 1:1, which makes no sense; most kernels want to start at high negative address space. Doing it this way ensures that we're following the intent of the RISCV designers, i.e that virtual addresses are correct at the start; and that the kernel does not have to unmap the low physical addresses once it starts. Change-Id: I8c577ad885891b4c33c20077995abbd90f355f1c Signed-off-by: Ronald G. Minnich <rminnich(a)gmail.com> --- src/arch/riscv/virtual_memory.c | 43 ++++++++++++++++++++++++++++++++++++----- 1 file changed, 38 insertions(+), 5 deletions(-) diff --git a/src/arch/riscv/virtual_memory.c b/src/arch/riscv/virtual_memory.c index 999d73c..b684ef2 100644 --- a/src/arch/riscv/virtual_memory.c +++ b/src/arch/riscv/virtual_memory.c @@ -168,12 +168,40 @@ void init_vm(uintptr_t virtMemStart, uintptr_t physMemStart, pte_t *sbi_pt) // IO space. root_pt[0] = pte_create(0, PTE_W|PTE_R, 0); - root_pt[1] = pte_create(0x40000000>>RISCV_PGSHIFT, + root_pt[1] = pte_create(0x4000000 >> RISCV_PGSHIFT, PTE_W|PTE_R, 0); // Start of RAM - root_pt[2] = pte_create(0x80000000>>RISCV_PGSHIFT, - PTE_W|PTE_R, 0); + // + // A RISCV goal is that Machine or Hypervisor modes be able + // start a Supervisor (kernel) at the C entry point. The + // intent is that firmware creates the virtual memory maps for + // the kernel to use. + // + // Question: what is the virtual address of physical memory + // for a kernel? Hey, glad you asked! In most kernels out + // there, physical memory is mapped at the top of the virtual + // address space. The express intent of the RISCV designers + // (I asked them) is that we be able to enter a kernel at + // main() in C, with no assembly needed. + // + // This is a neat idea that may not quite work out. For + // example: where's the stack go? Once you start in + // Supervisor mode, you are using virtual addresses set up by + // coreboot. So you can't use the coreboot stack, it's mapped + // to low physical addresses. You *should* not use the + // coreboot stack, your kernel may need it in a different + // place. So the kernel needs to change the stack, in ... a + // bit of startup assembly code, what else? Oh well. Map + // physical to high virtual. It's the most common way to + // go. Kernels that want to put kernel virtual addresses based + // at 0 will need to fixup page tables in ... a bit of startup + // assembly code :-) + // + // TODO: use a constant for the number of PTEs per page, when + // (hopefully) newer RISCV toolchains define that constant. + root_pt[0x1ff] = pte_create(0x8000000 >> RISCV_PGSHIFT, + PTE_R | PTE_W | PTE_X, 0); mb(); root_page_table = root_pt; uintptr_t ptbr = ((uintptr_t) root_pt) >> RISCV_PGSHIFT; @@ -198,9 +226,14 @@ void initVirtualMemory(void) { } // TODO: Figure out how to grab this from cbfs + // N.B. We used to map phsyical from 0x81000000, + // but since kernels need to be able to see the page tables + // created by firmware, we're going to map from start of RAM. + // All this is subject to change as we learn more. Much + // about RISCV is still in flux. printk(BIOS_DEBUG, "Initializing virtual memory...\n"); - uintptr_t physicalStart = 0x81000000; - uintptr_t virtualStart = 0xffffffff81000000; + uintptr_t physicalStart = 0x80000000; + uintptr_t virtualStart = 0xffffffff80000000; init_vm(virtualStart, physicalStart, (pte_t *)_pagetables); mb(); flush_tlb();

1 0

New patch to review for coreboot: riscv: map all of physical memory at the top of virtual address space
by Ronald G. Minnich 04 Nov '16

04 Nov '16

Ronald G. Minnich (rminnich(a)gmail.com) just uploaded a new patch set to gerrit, which you can find at https://review.coreboot.org/17233 -gerrit commit cb8980e1f1a5562c391c603985237fc60331ca32 Author: Ronald G. Minnich <rminnich(a)gmail.com> Date: Fri Nov 4 11:27:25 2016 -0700 riscv: map all of physical memory at the top of virtual address space We were mapping physical to virtual 1:1, which makes no sense; most kernels want to start at high negative address space. Doing it this way ensures that we're following the intent of the RISCV designers, i.e that virtual addresses are correct at the start; and that the kernel does not have to unmap the low physical addresses once it starts. Change-Id: I8c577ad885891b4c33c20077995abbd90f355f1c Signed-off-by: Ronald G. Minnich <rminnich(a)gmail.com> --- src/arch/riscv/virtual_memory.c | 43 ++++++++++++++++++++++++++++++++++++----- 1 file changed, 38 insertions(+), 5 deletions(-) diff --git a/src/arch/riscv/virtual_memory.c b/src/arch/riscv/virtual_memory.c index 999d73c..b684ef2 100644 --- a/src/arch/riscv/virtual_memory.c +++ b/src/arch/riscv/virtual_memory.c @@ -168,12 +168,40 @@ void init_vm(uintptr_t virtMemStart, uintptr_t physMemStart, pte_t *sbi_pt) // IO space. root_pt[0] = pte_create(0, PTE_W|PTE_R, 0); - root_pt[1] = pte_create(0x40000000>>RISCV_PGSHIFT, + root_pt[1] = pte_create(0x4000000 >> RISCV_PGSHIFT, PTE_W|PTE_R, 0); // Start of RAM - root_pt[2] = pte_create(0x80000000>>RISCV_PGSHIFT, - PTE_W|PTE_R, 0); + // + // A RISCV goal is that Machine or Hypervisor modes be able + // start a Supervisor (kernel) at the C entry point. The + // intent is that firmware creates the virtual memory maps for + // the kernel to use. + // + // Question: what is the virtual address of physical memory + // for a kernel? Hey, glad you asked! In most kernels out + // there, physical memory is mapped at the top of the virtual + // address space. The express intent of the RISCV designers + // (I asked them) is that we be able to enter a kernel at + // main() in C, with no assembly needed. + // + // This is a neat idea that may not quite work out. For + // example: where's the stack go? Once you start in + // Supervisor mode, you are using virtual addresses set up by + // coreboot. So you can't use the coreboot stack, it's mapped + // to low physical addresses. You *should* not use the + // coreboot stack, your kernel may need it in a different + // place. So the kernel needs to change the stack, in ... a + // bit of startup assembly code, what else? Oh well. Map + // physical to high virtual. It's the most common way to + // go. Kernels that want to put kernel virtual addresses based + // at 0 will need to fixup page tables in ... a bit of startup + // assembly code :-) + // + // TODO: use a constant for the number of PTEs per page, when + // (hopefully) newer RISCV toolchains define that constant. + root_pt[0x1ff] = pte_create(0x8000000 >> RISCV_PGSHIFT, + PTE_R | PTE_W | PTE_X, 0); mb(); root_page_table = root_pt; uintptr_t ptbr = ((uintptr_t) root_pt) >> RISCV_PGSHIFT; @@ -198,9 +226,14 @@ void initVirtualMemory(void) { } // TODO: Figure out how to grab this from cbfs + // N.B. We used to map phsyical from 0x81000000, + // but since kernels need to be able to see the page tables + // created by firmware, we're going to map from start of RAM. + // All this is subject to change as we learn more. Much + // about RISCV is still in flux. printk(BIOS_DEBUG, "Initializing virtual memory...\n"); - uintptr_t physicalStart = 0x81000000; - uintptr_t virtualStart = 0xffffffff81000000; + uintptr_t physicalStart = 0x80000000; + uintptr_t virtualStart = 0xffffffff80000000; init_vm(virtualStart, physicalStart, (pte_t *)_pagetables); mb(); flush_tlb();

1 0

New patch to review for coreboot: elog: fix default elog_add_event_raw() declaration
by Aaron Durbin 04 Nov '16

04 Nov '16

Aaron Durbin (adurbin(a)chromium.org) just uploaded a new patch set to gerrit, which you can find at https://review.coreboot.org/17232 -gerrit commit 74c13b4d55d834d8ecd7f118f6aa901fac361bf2 Author: Aaron Durbin <adurbin(a)chromium.org> Date: Fri Nov 4 11:17:54 2016 -0500 elog: fix default elog_add_event_raw() declaration When CONFIG_ELOG isn't used default empty inline functions are provided, however the elog_add_event_raw() had the wrong type signature. Fix that. BUG=chrome-os-partner:59395 Change-Id: Iaee68440bbafc1e91c88a7b03e283fc3e72de0a3 Signed-off-by: Aaron Durbin <adurbin(a)chromium.org> --- src/include/elog.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/include/elog.h b/src/include/elog.h index 504c52e..e4350f5 100644 --- a/src/include/elog.h +++ b/src/include/elog.h @@ -158,7 +158,8 @@ extern int elog_smbios_write_type15(unsigned long *current, int handle); /* Stubs to help avoid littering sources with #if CONFIG_ELOG */ static inline int elog_init(void) { return -1; } static inline int elog_clear(void) { return -1; } -static inline int elog_add_event_raw(void) { return 0; } +static inline int elog_add_event_raw(u8 event_type, void *data, + u8 data_size) { return 0; } static inline int elog_add_event(u8 event_type) { return 0; } static inline int elog_add_event_byte(u8 event_type, u8 data) { return 0; } static inline int elog_add_event_word(u8 event_type, u16 data) { return 0; }

1 0

Patch set updated for coreboot: soc/intel/common: log event when MRC cache is updated
by Aaron Durbin 04 Nov '16

04 Nov '16

Aaron Durbin (adurbin(a)chromium.org) just uploaded a new patch set to gerrit, which you can find at https://review.coreboot.org/17231 -gerrit commit 15444a98ac8bff776015b5bef1561a6208b01342 Author: Aaron Durbin <adurbin(a)chromium.org> Date: Fri Nov 4 10:07:14 2016 -0500 soc/intel/common: log event when MRC cache is updated Log when the MRC cache is attempted to be updated with status of success or failure. Just one slot is supported currently which is deemed 'normal'. This is because there are more slots anticipated in the future. BUG=chrome-os-partner:59395 Change-Id: I0f81458325697aff9924cc359a4173e0d35da5da Signed-off-by: Aaron Durbin <adurbin(a)chromium.org> --- src/include/elog.h | 10 ++++++++++ src/soc/intel/common/mrc_cache.c | 19 +++++++++++++++++++ 2 files changed, 29 insertions(+) diff --git a/src/include/elog.h b/src/include/elog.h index bdbafc2..7fdcda7 100644 --- a/src/include/elog.h +++ b/src/include/elog.h @@ -149,6 +149,16 @@ struct elog_event_data_me_extended { #define ELOG_TYPE_WAKE 0xa8 #define ELOG_TYPE_FW_WAKE 0xa9 +/* Memory Cache Update */ +#define ELOG_TYPE_MEM_CACHE_UPDATE 0xaa +#define ELOG_MEM_CACHE_UPDATE_SLOT_NORMAL 0 +#define ELOG_MEM_CACHE_UPDATE_STATUS_SUCCESS 0 +#define ELOG_MEM_CACHE_UPDATE_STATUS_FAIL 1 +struct elog_event_mem_cache_update { + u8 slot; + u8 status; +} __attribute__ ((packed)); + #if CONFIG_ELOG /* Eventlog backing storage must be initialized before calling elog_init(). */ extern int elog_init(void); diff --git a/src/soc/intel/common/mrc_cache.c b/src/soc/intel/common/mrc_cache.c index c123da9..bef3ba2 100644 --- a/src/soc/intel/common/mrc_cache.c +++ b/src/soc/intel/common/mrc_cache.c @@ -17,6 +17,7 @@ #include <bootstate.h> #include <console/console.h> #include <cbmem.h> +#include <elog.h> #include <fmap.h> #include <ip_checksum.h> #include <vboot/vboot_common.h> @@ -281,6 +282,18 @@ static int protect_mrc_cache(const struct mrc_data_region *region) return 0; } +static void log_event_cache_update(uint8_t slot, uint8_t status) +{ + const int type = ELOG_TYPE_MEM_CACHE_UPDATE; + struct elog_event_mem_cache_update event = { + .slot = slot, + .status = status, + }; + + if (elog_add_event_raw(type, &event, sizeof(event)) < 0) + printk(BIOS_ERR, "Failed to log mem cache update event.\n"); +} + static void update_mrc_cache(void *unused) { const struct mrc_saved_data *current_boot; @@ -336,7 +349,13 @@ static void update_mrc_cache(void *unused) current_boot->size + sizeof(*current_boot))) { printk(BIOS_DEBUG, "Failure writing MRC cache to %p.\n", next_slot); + log_event_cache_update(ELOG_MEM_CACHE_UPDATE_SLOT_NORMAL, + ELOG_MEM_CACHE_UPDATE_STATUS_FAIL); + } else { + log_event_cache_update(ELOG_MEM_CACHE_UPDATE_SLOT_NORMAL, + ELOG_MEM_CACHE_UPDATE_STATUS_SUCCESS); } + protect_mrc_cache(&region); }

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

coreboot-gerrit November 2016