Daniel Maslowski has uploaded this change for review. ( https://review.coreboot.org/c/coreboot/+/33008
Change subject: sb/intel/lynxpoint: Fix flashconsole after lockdown
......................................................................
sb/intel/lynxpoint: Fix flashconsole after lockdown
Same as with sb/intel/bd82x6x:
SMM final locks the SPI BAR, which causes flashconsole to hang.
Re-init it like SMM does with CONFIG_SPI_FLASH_SMM.
Change-Id: Ie35af9610ebbba5c66351e9668e9a55cae3c7520
Signed-off-by: Daniel Maslowski <dan(a)orangecms.org>
---
M src/southbridge/intel/lynxpoint/lpc.c
1 file changed, 9 insertions(+), 1 deletion(-)
git pull ssh://review.coreboot.org:29418/coreboot refs/changes/08/33008/1
diff --git a/src/southbridge/intel/lynxpoint/lpc.c b/src/southbridge/intel/lynxpoint/lpc.c
index b0f57c1..714c696 100644
--- a/src/southbridge/intel/lynxpoint/lpc.c
+++ b/src/southbridge/intel/lynxpoint/lpc.c
@@ -965,8 +965,16 @@
RCBA32(0x3898) = SPI_OPMENU_LOWER;
RCBA32(0x389c) = SPI_OPMENU_UPPER;
- if (acpi_is_wakeup_s3() || CONFIG(INTEL_CHIPSET_LOCKDOWN))
+ if (acpi_is_wakeup_s3() || CONFIG(INTEL_CHIPSET_LOCKDOWN)) {
outb(APM_CNT_FINALIZE, APM_CNT);
+ if (CONFIG(CONSOLE_SPI_FLASH)) {
+ /* Re-init SPI driver to handle locked BAR.
+ This prevents flashconsole from hanging.
+ If other code needs to use SPI during
+ ramstage, whitelist it here. */
+ spi_init();
+ }
+ }
}
static struct pci_operations pci_ops = {
--
To view, visit https://review.coreboot.org/c/coreboot/+/33008
To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings
Gerrit-Project: coreboot
Gerrit-Branch: master
Gerrit-Change-Id: Ie35af9610ebbba5c66351e9668e9a55cae3c7520
Gerrit-Change-Number: 33008
Gerrit-PatchSet: 1
Gerrit-Owner: Daniel Maslowski <info(a)orangecms.org>
Gerrit-MessageType: newchange
Patrick Rudolph has uploaded this change for review. ( https://review.coreboot.org/c/coreboot/+/33664
Change subject: Documentation: Update CBFS
......................................................................
Documentation: Update CBFS
Update some parts to match current implementation.
Change-Id: I84d07ae1c5c1ded2b9ab5934e2babbbabb749440
---
M Documentation/lib/cbfs.md
M Documentation/lib/payloads/selfboot.md
2 files changed, 46 insertions(+), 34 deletions(-)
git pull ssh://review.coreboot.org:29418/coreboot refs/changes/64/33664/1
diff --git a/Documentation/lib/cbfs.md b/Documentation/lib/cbfs.md
index 83d8b44..ce87b78 100644
--- a/Documentation/lib/cbfs.md
+++ b/Documentation/lib/cbfs.md
@@ -7,7 +7,7 @@
## Introduction
-This document describes the coreboot CBFS specification (from here
+This document describes the coreboot filesystem specification (from here
referred to as CBFS). CBFS is a scheme for managing independent chunks
of data in a system ROM. Though not a true filesystem, the style and
concepts are similar.
@@ -15,7 +15,7 @@
## Architecture
-The CBFS architecture looks like the following:
+The CBFS on x86 architecture looks like the following:
```
/---------------\ <-- Start of ROM
@@ -49,11 +49,11 @@
The CBFS architecture consists of a binary associated with a physical
ROM disk referred hereafter as the ROM. A number of independent of
-components, each with a header prepended on to data are located within
-the ROM. The components are nominally arranged sequentially, though they
+components, each with a header prepended on to data are located within
+the ROM. The components are nominally arranged sequentially, though they
are aligned along a pre-defined boundary.
-The bootblock occupies the last 20k of the ROM. Within
+On x86 legacy the bootblock occupies the last 20k of the ROM. Within
the bootblock is a master header containing information about the ROM
including the size, alignment of the components, and the offset of the
start of the first CBFS component within the ROM.
@@ -62,14 +62,13 @@
The master header contains essential information about the ROM that is
used by both the CBFS implementation within coreboot at runtime as well
-as host based utilities to create and manage the ROM. The master header
-will be located somewhere within the bootblock (last 20k of the ROM). A
-pointer to the location of the header will be located at offset
--4 from the end of the ROM. This translates to address 0xFFFFFFFC on a
-normal x86 system. The pointer will be to physical memory somewhere
-between - 0xFFFFB000 and 0xFFFFFFF0. This makes it easier for coreboot
-to locate the header at run time. Build time utilities will
-need to read the pointer and do the appropriate math to locate the header.
+as host based utilities to create and manage the ROM. The master header
+will be located at the start of CBFS. A pointer to the location of the
+header will be located at offset -4 from the end of the ROM.
+This translates to address 0xFFFFFFFC on a normal x86 system.
+This makes it easier for coreboot to locate the header at run time.
+Build time utilities will need to read the pointer and do the appropriate
+math to locate the header.
The following is the structure of the master header:
@@ -114,16 +113,16 @@
for.
## Bootblock
-The bootblock is a mandatory component in the ROM. It is located in the
-last 20k of the ROM space, and contains, among other things, the location of the
-master header and the entry point for the loader firmware. The bootblock
-does not have a component header attached to it.
+The bootblock is a mandatory component in the ROM. On x86 legacy it is located
+at the end of the CBFS, and contains, among other things, the location of the
+master header and the entry point for the loader firmware. On other
+architectures the bootblock might not be part of the CBFS.
## Components
CBFS components are placed in the ROM starting at 'offset' specified in
-the master header and ending at the bootblock. Thus the total size
-available for components in the ROM is (ROM size - 20k - 'offset').
+the master header and ending at the end of the CBFS. Thus the total size
+available for components in the ROM is (ROM size - 'offset').
Each CBFS component is to be aligned according to the 'align' value in the
header.
Thus, if a component of size 1052 is located at offset 0 with an 'align'
@@ -208,10 +207,10 @@
#### Stages
-Stages are code loaded by coreboot during the boot process. They are
-essential to a successful boot. Stages are comprised of a single blob
+Stages are code loaded by coreboot during the boot process. They are
+essential to a successful boot. Stages are comprised of a single blob
of binary data that is to be loaded into a particular location in memory
-and executed. The uncompressed header contains information about how
+and executed. The uncompressed header contains information about how
large the data is, and where it should be placed, and what additional memory
needs to be cleared.
@@ -244,8 +243,8 @@
`compression` is an integer defining how the data is compressed. There
are three compression types defined by this version of the standard:
-none (0x0), lzma (0x1), and nrv2b (0x02, deprecated), though additional
-types may be added assuming that coreboot understands how to handle the scheme.
+none (0x0), lzma (0x1), and lz4 (0x02), though additional types may be
+added assuming that coreboot understands how to handle the scheme.
`entry` is a 64 bit value indicating the location where the program
counter should jump following the loading of the stage. This should be
@@ -271,13 +270,13 @@
#### Payloads
Payloads are loaded by coreboot following the boot process.
+The default payloads supported by coreboot are [SELF] payloads.
-Stages are assigned a component value of 0x20. When coreboot sees this
+[SELF] stages are assigned a component value of 0x20. When coreboot sees this
component type, it knows that it should pass the data to a sub-function
-that will process the payload. Furthermore, other run time applications such
-as 'bayou' may easily index all available payloads
-on the system by searching for the payload type.
-
+that will process the payload. Furthermore, other run time applications such
+as 'bayou' may easily index all available payloads on the system by searching
+for the payload type.
The following is the format of a stage component:
@@ -338,9 +337,9 @@
`compression` is the compression scheme for the segment. Each segment can
be independently compressed. There are three compression types defined by
-this version of the standard: none (0x0), lzma (0x1), and nrv2b
-(0x02, deprecated), though additional types may be added assuming that
-coreboot understands how to handle the scheme.
+this version of the standard: none (0x0), lzma (0x1), and lz4 (0x02), though
+additional types may be added assuming that coreboot understands how to handle
+the scheme.
`offset` is the address of the data within the component, starting from
the component header.
@@ -355,6 +354,13 @@
The data will located immediately following the last segment.
+#### FIT payload
+
+A payload of type [FIT] is supported on some architectures.
+
+[FIT] stages are assigned a component value of 0x21 and do not support
+compressions at all.
+
#### Option ROMS
The third specified component type will be Option ROMs. Option ROMS will
@@ -364,8 +370,11 @@
#### NULL
-There is a 4th component type ,defined as NULL (0xFFFFFFFF). This is
-the "don't care" component type. This can be used when the component
+There is a 4th component type, defined as NULL (0xFFFFFFFF, 0x00000000).
+This is the "don't care" component type. This can be used when the component
type is not necessary (such as when the name of the component is unique.
i.e. option_table). It is recommended that all components be assigned a
unique type, but NULL can be used when the type does not matter.
+
+[FIT]: payloads/fit.md
+[SELF]: payloads/selfboot.md
diff --git a/Documentation/lib/payloads/selfboot.md b/Documentation/lib/payloads/selfboot.md
index 62a4393..791d6c0 100644
--- a/Documentation/lib/payloads/selfboot.md
+++ b/Documentation/lib/payloads/selfboot.md
@@ -18,6 +18,8 @@
address they specify. If it's not possible to load the payload at the specified
address, the system won't boot.
+Implementations details can be found in the [CBFS] documentation.
+
### Calling conventions
The SELF payload is called with a pointer to the coreboot tables as first
argument.
@@ -26,3 +28,4 @@
and a pointer to the *FDT* as arguments.
[RISC-V]: ../../arch/riscv/index.md
+[CBFS]: ../cbfs.md
--
To view, visit https://review.coreboot.org/c/coreboot/+/33664
To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings
Gerrit-Project: coreboot
Gerrit-Branch: master
Gerrit-Change-Id: I84d07ae1c5c1ded2b9ab5934e2babbbabb749440
Gerrit-Change-Number: 33664
Gerrit-PatchSet: 1
Gerrit-Owner: Patrick Rudolph <patrick.rudolph(a)9elements.com>
Gerrit-MessageType: newchange
Matt Delco has uploaded this change for review. ( https://review.coreboot.org/c/coreboot/+/33303
Change subject: libpayload/drivers/i8042: ignore special keys on keyboard
......................................................................
libpayload/drivers/i8042: ignore special keys on keyboard
Some keyboards have a fn-key (and/or fn-mode lock) that can generate
0xe0-prefixed scan codes for certain keys. Previously the 0xe0 prefix
state wasn't tracked (it was ignored), so these scan codes could be
misinterpreted as non-0xe0 presses (e.g., 'mute' generates 0xe0 0x20
but this would get interpreted as 0x20 and be treated as a 'D' press).
Most 0xe0-prefixed codes (besides those for the 10-key) are irrelevant
for firmware so we'll ignore them.
BUG=none
BRANCH=none
TEST=local build and flash. Verified that special keys are no longer
interpreted as other keystrokes.
Change-Id: Ie6a828b6a0a3ab47456d6db2db504aa0d7aefc28
Signed-off-by: Matt Delco <delco(a)chromium.org>
---
M payloads/libpayload/drivers/i8042/keyboard.c
1 file changed, 23 insertions(+), 5 deletions(-)
git pull ssh://review.coreboot.org:29418/coreboot refs/changes/03/33303/1
diff --git a/payloads/libpayload/drivers/i8042/keyboard.c b/payloads/libpayload/drivers/i8042/keyboard.c
index 3e5f988..bca916f 100644
--- a/payloads/libpayload/drivers/i8042/keyboard.c
+++ b/payloads/libpayload/drivers/i8042/keyboard.c
@@ -235,12 +235,30 @@
unsigned char ch;
int shift;
int ret = 0;
-
- while (!keyboard_havechar()) ;
+ static int prior_special = 0;
ch = keyboard_get_scancode();
- if (!(ch & 0x80) && ch < 0x59) {
+ if (prior_special) {
+ if (ch == 0x5e)
+ ret = POWER_BUTTON;
+ /*
+ * For now 0xe0 with 0x1c, 0x35, or 0x47 - 0x53 is the same as
+ * non-0xe0. For 10-key scan codes 0x47-0x53 it's probably more
+ * accurate for the non-0xe0 presses to use the numeric
+ * interpretation of the key (i.e., when num lock is on) and
+ * the 0xe0 prefixed versions should use the non-numeric
+ * interpretation (i.e., num lock off). However, the existing
+ * tables are using the non-numeric interpretation so for now
+ * the 0xe0 presses can use what's in the table for non-0xe0
+ * presses. The main exception is that shift+'/' on the keypad
+ * (0xe0 0x35) should still produce a '/' (vs. a '?' like on
+ * the key that's to the left of the right-shift on English
+ * keyboards) so we'll ignore the shift status.
+ */
+ else if (ch == 0x1c || ch == 0x35 || (ch >= 0x47 && ch <= 0x53))
+ ret = map->map[0][ch];
+ } else if (ch < 0x59) { /* implies !(ch & 0x80), i.e., key press */
shift =
(modifier & KB_MOD_SHIFT) ^ (modifier & KB_MOD_CAPSLOCK) ? 1 : 0;
@@ -265,8 +283,8 @@
}
}
- if (ch == 0x5e)
- ret = POWER_BUTTON;
+ /* sequence 0xe0 0xe0 should not leave prior_special set. */
+ prior_special = !prior_special && ch == 0xe0;
return ret;
}
--
To view, visit https://review.coreboot.org/c/coreboot/+/33303
To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings
Gerrit-Project: coreboot
Gerrit-Branch: master
Gerrit-Change-Id: Ie6a828b6a0a3ab47456d6db2db504aa0d7aefc28
Gerrit-Change-Number: 33303
Gerrit-PatchSet: 1
Gerrit-Owner: Matt Delco <delco(a)chromium.org>
Gerrit-MessageType: newchange