2020-04-02 23:48:34 +02:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0-only */
|
CBMEM CONSOLE: Add CBMEM console driver implementation.
The CBMEM console driver saves console output in a CBMEM area, which
then is made available to Linux applications for perusing.
There are some system limitations which need to be worked around
to achieve this goal:
- some console traffic is generated before DRAM is initialized,
leave alone CBMEM initialized.
- after the RAM based stage starts, a lot of traffic is generated
before CBMEM is initialized.
As a result, the console log lives in three different places -
the bottom of the cache as RAM space, the CBMEM buffer (where it
is expected to be) and a static buffer used early in the RAM
stage.
When execution starts (in the cache as RAM mode), the console
buffer is allocated at the bottom of the cache as RAM memory
address range. Once DRAM is initialized, the CBMEM structure is
initialized, and then the console buffer contents are copied from
the bottom of the cache as RAM space into the CBMEM area right
before the cache as RAM mode is disabled. The
src/lib/cbmem_console.c:cbmemc_reinit() takes care of the
copying.
At this point the cache as RAM memory is about to be disabled,
but the ROM stage is still going generating console output. To
make sure this output is not lost, cbmemc_reinit() saves the new
buffer address at a fixed location (0x600 was chosen for this),
and the actual "printing" function checks to see if the RAM is
already initialized (the stack is in RAM), and if so, gets the
console buffer pointer from this location instead of using the
cache as RAM address.
When the RAM stage starts, a static buffer is used to store the
console output, as the CBMEM buffer location is not known. Then,
when CBMEM is reinitialized, cbmemc_reinit() again takes care of
the copying.
In case the allocated buffers are not large enough, the excessive
data is dropped, and the copying routine adds some text to the
output buffer to indicate that there has been data lost and how
many characters were dropped.
Change-Id: I8c126e31db6cb2141f7f4f97c5047f39a8db44fc
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/719
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2011-09-30 02:27:15 +02:00
|
|
|
|
2014-02-17 20:34:42 +01:00
|
|
|
#include <console/cbmem_console.h>
|
2022-01-11 20:48:50 +01:00
|
|
|
#include <console/console.h>
|
2015-04-11 03:04:04 +02:00
|
|
|
#include <console/uart.h>
|
CBMEM CONSOLE: Add CBMEM console driver implementation.
The CBMEM console driver saves console output in a CBMEM area, which
then is made available to Linux applications for perusing.
There are some system limitations which need to be worked around
to achieve this goal:
- some console traffic is generated before DRAM is initialized,
leave alone CBMEM initialized.
- after the RAM based stage starts, a lot of traffic is generated
before CBMEM is initialized.
As a result, the console log lives in three different places -
the bottom of the cache as RAM space, the CBMEM buffer (where it
is expected to be) and a static buffer used early in the RAM
stage.
When execution starts (in the cache as RAM mode), the console
buffer is allocated at the bottom of the cache as RAM memory
address range. Once DRAM is initialized, the CBMEM structure is
initialized, and then the console buffer contents are copied from
the bottom of the cache as RAM space into the CBMEM area right
before the cache as RAM mode is disabled. The
src/lib/cbmem_console.c:cbmemc_reinit() takes care of the
copying.
At this point the cache as RAM memory is about to be disabled,
but the ROM stage is still going generating console output. To
make sure this output is not lost, cbmemc_reinit() saves the new
buffer address at a fixed location (0x600 was chosen for this),
and the actual "printing" function checks to see if the RAM is
already initialized (the stack is in RAM), and if so, gets the
console buffer pointer from this location instead of using the
cache as RAM address.
When the RAM stage starts, a static buffer is used to store the
console output, as the CBMEM buffer location is not known. Then,
when CBMEM is reinitialized, cbmemc_reinit() again takes care of
the copying.
In case the allocated buffers are not large enough, the excessive
data is dropped, and the copying routine adds some text to the
output buffer to indicate that there has been data lost and how
many characters were dropped.
Change-Id: I8c126e31db6cb2141f7f4f97c5047f39a8db44fc
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/719
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2011-09-30 02:27:15 +02:00
|
|
|
#include <cbmem.h>
|
New mechanism to define SRAM/memory map with automatic bounds checking
This patch creates a new mechanism to define the static memory layout
(primarily in SRAM) for a given board, superseding the brittle mass of
Kconfigs that we were using before. The core part is a memlayout.ld file
in the mainboard directory (although boards are expected to just include
the SoC default in most cases), which is the primary linker script for
all stages (though not rmodules for now). It uses preprocessor macros
from <memlayout.h> to form a different valid linker script for all
stages while looking like a declarative, boilerplate-free map of memory
addresses to the programmer. Linker asserts will automatically guarantee
that the defined regions cannot overlap. Stages are defined with a
maximum size that will be enforced by the linker. The file serves to
both define and document the memory layout, so that the documentation
cannot go missing or out of date.
The mechanism is implemented for all boards in the ARM, ARM64 and MIPS
architectures, and should be extended onto all systems using SRAM in the
future. The CAR/XIP environment on x86 has very different requirements
and the layout is generally not as static, so it will stay like it is
and be unaffected by this patch (save for aligning some symbol names for
consistency and sharing the new common ramstage linker script include).
BUG=None
TEST=Booted normally and in recovery mode, checked suspend/resume and
the CBMEM console on Falco, Blaze (both normal and vboot2), Pinky and
Pit. Compiled Ryu, Storm and Urara, manually compared the disassemblies
with ToT and looked for red flags.
Change-Id: Ifd2276417f2036cbe9c056f17e42f051bcd20e81
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: f1e2028e7ebceeb2d71ff366150a37564595e614
Original-Change-Id: I005506add4e8fcdb74db6d5e6cb2d4cb1bd3cda5
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/213370
Reviewed-on: http://review.coreboot.org/9283
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Tauner <stefan.tauner@gmx.at>
Reviewed-by: Aaron Durbin <adurbin@google.com>
2014-08-21 00:29:56 +02:00
|
|
|
#include <symbols.h>
|
2022-01-11 20:48:50 +01:00
|
|
|
#include <types.h>
|
CBMEM CONSOLE: Add CBMEM console driver implementation.
The CBMEM console driver saves console output in a CBMEM area, which
then is made available to Linux applications for perusing.
There are some system limitations which need to be worked around
to achieve this goal:
- some console traffic is generated before DRAM is initialized,
leave alone CBMEM initialized.
- after the RAM based stage starts, a lot of traffic is generated
before CBMEM is initialized.
As a result, the console log lives in three different places -
the bottom of the cache as RAM space, the CBMEM buffer (where it
is expected to be) and a static buffer used early in the RAM
stage.
When execution starts (in the cache as RAM mode), the console
buffer is allocated at the bottom of the cache as RAM memory
address range. Once DRAM is initialized, the CBMEM structure is
initialized, and then the console buffer contents are copied from
the bottom of the cache as RAM space into the CBMEM area right
before the cache as RAM mode is disabled. The
src/lib/cbmem_console.c:cbmemc_reinit() takes care of the
copying.
At this point the cache as RAM memory is about to be disabled,
but the ROM stage is still going generating console output. To
make sure this output is not lost, cbmemc_reinit() saves the new
buffer address at a fixed location (0x600 was chosen for this),
and the actual "printing" function checks to see if the RAM is
already initialized (the stack is in RAM), and if so, gets the
console buffer pointer from this location instead of using the
cache as RAM address.
When the RAM stage starts, a static buffer is used to store the
console output, as the CBMEM buffer location is not known. Then,
when CBMEM is reinitialized, cbmemc_reinit() again takes care of
the copying.
In case the allocated buffers are not large enough, the excessive
data is dropped, and the copying routine adds some text to the
output buffer to indicate that there has been data lost and how
many characters were dropped.
Change-Id: I8c126e31db6cb2141f7f4f97c5047f39a8db44fc
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/719
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2011-09-30 02:27:15 +02:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Structure describing console buffer. It is overlaid on a flat memory area,
|
2017-02-03 02:32:00 +01:00
|
|
|
* with body covering the extent of the memory. Once the buffer is full,
|
|
|
|
|
* output will wrap back around to the start of the buffer. The high bit of the
|
|
|
|
|
* cursor field gets set to indicate that this happened. If the underlying
|
|
|
|
|
* storage allows this, the buffer will persist across multiple boots and append
|
|
|
|
|
* to the previous log.
|
2017-04-25 02:08:06 +02:00
|
|
|
*
|
|
|
|
|
* NOTE: These are known implementations accessing this console that need to be
|
|
|
|
|
* updated in case of structure/API changes:
|
|
|
|
|
*
|
|
|
|
|
* cbmem: [coreboot]/src/util/cbmem/cbmem.c
|
|
|
|
|
* libpayload: [coreboot]/payloads/libpayload/drivers/cbmem_console.c
|
|
|
|
|
* coreinfo: [coreboot]/payloads/coreinfo/bootlog_module.c
|
|
|
|
|
* Linux: drivers/firmware/google/memconsole-coreboot.c
|
|
|
|
|
* SeaBIOS: src/firmware/coreboot.c
|
|
|
|
|
* GRUB: grub-core/term/i386/coreboot/cbmemc.c
|
CBMEM CONSOLE: Add CBMEM console driver implementation.
The CBMEM console driver saves console output in a CBMEM area, which
then is made available to Linux applications for perusing.
There are some system limitations which need to be worked around
to achieve this goal:
- some console traffic is generated before DRAM is initialized,
leave alone CBMEM initialized.
- after the RAM based stage starts, a lot of traffic is generated
before CBMEM is initialized.
As a result, the console log lives in three different places -
the bottom of the cache as RAM space, the CBMEM buffer (where it
is expected to be) and a static buffer used early in the RAM
stage.
When execution starts (in the cache as RAM mode), the console
buffer is allocated at the bottom of the cache as RAM memory
address range. Once DRAM is initialized, the CBMEM structure is
initialized, and then the console buffer contents are copied from
the bottom of the cache as RAM space into the CBMEM area right
before the cache as RAM mode is disabled. The
src/lib/cbmem_console.c:cbmemc_reinit() takes care of the
copying.
At this point the cache as RAM memory is about to be disabled,
but the ROM stage is still going generating console output. To
make sure this output is not lost, cbmemc_reinit() saves the new
buffer address at a fixed location (0x600 was chosen for this),
and the actual "printing" function checks to see if the RAM is
already initialized (the stack is in RAM), and if so, gets the
console buffer pointer from this location instead of using the
cache as RAM address.
When the RAM stage starts, a static buffer is used to store the
console output, as the CBMEM buffer location is not known. Then,
when CBMEM is reinitialized, cbmemc_reinit() again takes care of
the copying.
In case the allocated buffers are not large enough, the excessive
data is dropped, and the copying routine adds some text to the
output buffer to indicate that there has been data lost and how
many characters were dropped.
Change-Id: I8c126e31db6cb2141f7f4f97c5047f39a8db44fc
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/719
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2011-09-30 02:27:15 +02:00
|
|
|
*/
|
|
|
|
|
struct cbmem_console {
|
2017-02-03 21:45:21 +01:00
|
|
|
u32 size;
|
|
|
|
|
u32 cursor;
|
|
|
|
|
u8 body[0];
|
2017-07-13 02:20:27 +02:00
|
|
|
} __packed;
|
CBMEM CONSOLE: Add CBMEM console driver implementation.
The CBMEM console driver saves console output in a CBMEM area, which
then is made available to Linux applications for perusing.
There are some system limitations which need to be worked around
to achieve this goal:
- some console traffic is generated before DRAM is initialized,
leave alone CBMEM initialized.
- after the RAM based stage starts, a lot of traffic is generated
before CBMEM is initialized.
As a result, the console log lives in three different places -
the bottom of the cache as RAM space, the CBMEM buffer (where it
is expected to be) and a static buffer used early in the RAM
stage.
When execution starts (in the cache as RAM mode), the console
buffer is allocated at the bottom of the cache as RAM memory
address range. Once DRAM is initialized, the CBMEM structure is
initialized, and then the console buffer contents are copied from
the bottom of the cache as RAM space into the CBMEM area right
before the cache as RAM mode is disabled. The
src/lib/cbmem_console.c:cbmemc_reinit() takes care of the
copying.
At this point the cache as RAM memory is about to be disabled,
but the ROM stage is still going generating console output. To
make sure this output is not lost, cbmemc_reinit() saves the new
buffer address at a fixed location (0x600 was chosen for this),
and the actual "printing" function checks to see if the RAM is
already initialized (the stack is in RAM), and if so, gets the
console buffer pointer from this location instead of using the
cache as RAM address.
When the RAM stage starts, a static buffer is used to store the
console output, as the CBMEM buffer location is not known. Then,
when CBMEM is reinitialized, cbmemc_reinit() again takes care of
the copying.
In case the allocated buffers are not large enough, the excessive
data is dropped, and the copying routine adds some text to the
output buffer to indicate that there has been data lost and how
many characters were dropped.
Change-Id: I8c126e31db6cb2141f7f4f97c5047f39a8db44fc
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/719
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2011-09-30 02:27:15 +02:00
|
|
|
|
2017-02-03 02:32:00 +01:00
|
|
|
#define MAX_SIZE (1 << 28) /* can't be changed without breaking readers! */
|
|
|
|
|
#define CURSOR_MASK (MAX_SIZE - 1) /* bits 31-28 are reserved for flags */
|
2017-06-10 04:47:57 +02:00
|
|
|
#define OVERFLOW (1UL << 31) /* set if in ring-buffer mode */
|
2017-02-03 02:32:00 +01:00
|
|
|
_Static_assert(CONFIG_CONSOLE_CBMEM_BUFFER_SIZE <= MAX_SIZE,
|
|
|
|
|
"cbmem_console format cannot support buffers larger than 256MB!");
|
2013-05-10 07:45:37 +02:00
|
|
|
|
2019-11-30 10:49:17 +01:00
|
|
|
static struct cbmem_console *current_console;
|
2014-12-21 07:55:47 +01:00
|
|
|
|
2022-01-11 20:48:50 +01:00
|
|
|
static bool console_paused;
|
|
|
|
|
|
CBMEM CONSOLE: Add CBMEM console driver implementation.
The CBMEM console driver saves console output in a CBMEM area, which
then is made available to Linux applications for perusing.
There are some system limitations which need to be worked around
to achieve this goal:
- some console traffic is generated before DRAM is initialized,
leave alone CBMEM initialized.
- after the RAM based stage starts, a lot of traffic is generated
before CBMEM is initialized.
As a result, the console log lives in three different places -
the bottom of the cache as RAM space, the CBMEM buffer (where it
is expected to be) and a static buffer used early in the RAM
stage.
When execution starts (in the cache as RAM mode), the console
buffer is allocated at the bottom of the cache as RAM memory
address range. Once DRAM is initialized, the CBMEM structure is
initialized, and then the console buffer contents are copied from
the bottom of the cache as RAM space into the CBMEM area right
before the cache as RAM mode is disabled. The
src/lib/cbmem_console.c:cbmemc_reinit() takes care of the
copying.
At this point the cache as RAM memory is about to be disabled,
but the ROM stage is still going generating console output. To
make sure this output is not lost, cbmemc_reinit() saves the new
buffer address at a fixed location (0x600 was chosen for this),
and the actual "printing" function checks to see if the RAM is
already initialized (the stack is in RAM), and if so, gets the
console buffer pointer from this location instead of using the
cache as RAM address.
When the RAM stage starts, a static buffer is used to store the
console output, as the CBMEM buffer location is not known. Then,
when CBMEM is reinitialized, cbmemc_reinit() again takes care of
the copying.
In case the allocated buffers are not large enough, the excessive
data is dropped, and the copying routine adds some text to the
output buffer to indicate that there has been data lost and how
many characters were dropped.
Change-Id: I8c126e31db6cb2141f7f4f97c5047f39a8db44fc
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/719
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2011-09-30 02:27:15 +02:00
|
|
|
/*
|
|
|
|
|
* While running from ROM, before DRAM is initialized, some area in cache as
|
2016-07-30 15:51:13 +02:00
|
|
|
* RAM space is used for the console buffer storage. The size and location of
|
New mechanism to define SRAM/memory map with automatic bounds checking
This patch creates a new mechanism to define the static memory layout
(primarily in SRAM) for a given board, superseding the brittle mass of
Kconfigs that we were using before. The core part is a memlayout.ld file
in the mainboard directory (although boards are expected to just include
the SoC default in most cases), which is the primary linker script for
all stages (though not rmodules for now). It uses preprocessor macros
from <memlayout.h> to form a different valid linker script for all
stages while looking like a declarative, boilerplate-free map of memory
addresses to the programmer. Linker asserts will automatically guarantee
that the defined regions cannot overlap. Stages are defined with a
maximum size that will be enforced by the linker. The file serves to
both define and document the memory layout, so that the documentation
cannot go missing or out of date.
The mechanism is implemented for all boards in the ARM, ARM64 and MIPS
architectures, and should be extended onto all systems using SRAM in the
future. The CAR/XIP environment on x86 has very different requirements
and the layout is generally not as static, so it will stay like it is
and be unaffected by this patch (save for aligning some symbol names for
consistency and sharing the new common ramstage linker script include).
BUG=None
TEST=Booted normally and in recovery mode, checked suspend/resume and
the CBMEM console on Falco, Blaze (both normal and vboot2), Pinky and
Pit. Compiled Ryu, Storm and Urara, manually compared the disassemblies
with ToT and looked for red flags.
Change-Id: Ifd2276417f2036cbe9c056f17e42f051bcd20e81
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: f1e2028e7ebceeb2d71ff366150a37564595e614
Original-Change-Id: I005506add4e8fcdb74db6d5e6cb2d4cb1bd3cda5
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/213370
Reviewed-on: http://review.coreboot.org/9283
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Tauner <stefan.tauner@gmx.at>
Reviewed-by: Aaron Durbin <adurbin@google.com>
2014-08-21 00:29:56 +02:00
|
|
|
* the area are defined by the linker script with _(e)preram_cbmem_console.
|
2019-09-13 09:49:20 +02:00
|
|
|
*
|
2018-06-03 11:29:50 +02:00
|
|
|
* When running from RAM, some console output is generated before CBMEM is
|
CBMEM CONSOLE: Add CBMEM console driver implementation.
The CBMEM console driver saves console output in a CBMEM area, which
then is made available to Linux applications for perusing.
There are some system limitations which need to be worked around
to achieve this goal:
- some console traffic is generated before DRAM is initialized,
leave alone CBMEM initialized.
- after the RAM based stage starts, a lot of traffic is generated
before CBMEM is initialized.
As a result, the console log lives in three different places -
the bottom of the cache as RAM space, the CBMEM buffer (where it
is expected to be) and a static buffer used early in the RAM
stage.
When execution starts (in the cache as RAM mode), the console
buffer is allocated at the bottom of the cache as RAM memory
address range. Once DRAM is initialized, the CBMEM structure is
initialized, and then the console buffer contents are copied from
the bottom of the cache as RAM space into the CBMEM area right
before the cache as RAM mode is disabled. The
src/lib/cbmem_console.c:cbmemc_reinit() takes care of the
copying.
At this point the cache as RAM memory is about to be disabled,
but the ROM stage is still going generating console output. To
make sure this output is not lost, cbmemc_reinit() saves the new
buffer address at a fixed location (0x600 was chosen for this),
and the actual "printing" function checks to see if the RAM is
already initialized (the stack is in RAM), and if so, gets the
console buffer pointer from this location instead of using the
cache as RAM address.
When the RAM stage starts, a static buffer is used to store the
console output, as the CBMEM buffer location is not known. Then,
when CBMEM is reinitialized, cbmemc_reinit() again takes care of
the copying.
In case the allocated buffers are not large enough, the excessive
data is dropped, and the copying routine adds some text to the
output buffer to indicate that there has been data lost and how
many characters were dropped.
Change-Id: I8c126e31db6cb2141f7f4f97c5047f39a8db44fc
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/719
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2011-09-30 02:27:15 +02:00
|
|
|
* reinitialized. This static buffer is used to store that output temporarily,
|
|
|
|
|
* to be concatenated with the CBMEM console buffer contents accumulated
|
|
|
|
|
* during the ROM stage, once CBMEM becomes available at RAM stage.
|
|
|
|
|
*/
|
2013-09-09 20:22:18 +02:00
|
|
|
|
|
|
|
|
#define STATIC_CONSOLE_SIZE 1024
|
|
|
|
|
static u8 static_console[STATIC_CONSOLE_SIZE];
|
CBMEM CONSOLE: Add CBMEM console driver implementation.
The CBMEM console driver saves console output in a CBMEM area, which
then is made available to Linux applications for perusing.
There are some system limitations which need to be worked around
to achieve this goal:
- some console traffic is generated before DRAM is initialized,
leave alone CBMEM initialized.
- after the RAM based stage starts, a lot of traffic is generated
before CBMEM is initialized.
As a result, the console log lives in three different places -
the bottom of the cache as RAM space, the CBMEM buffer (where it
is expected to be) and a static buffer used early in the RAM
stage.
When execution starts (in the cache as RAM mode), the console
buffer is allocated at the bottom of the cache as RAM memory
address range. Once DRAM is initialized, the CBMEM structure is
initialized, and then the console buffer contents are copied from
the bottom of the cache as RAM space into the CBMEM area right
before the cache as RAM mode is disabled. The
src/lib/cbmem_console.c:cbmemc_reinit() takes care of the
copying.
At this point the cache as RAM memory is about to be disabled,
but the ROM stage is still going generating console output. To
make sure this output is not lost, cbmemc_reinit() saves the new
buffer address at a fixed location (0x600 was chosen for this),
and the actual "printing" function checks to see if the RAM is
already initialized (the stack is in RAM), and if so, gets the
console buffer pointer from this location instead of using the
cache as RAM address.
When the RAM stage starts, a static buffer is used to store the
console output, as the CBMEM buffer location is not known. Then,
when CBMEM is reinitialized, cbmemc_reinit() again takes care of
the copying.
In case the allocated buffers are not large enough, the excessive
data is dropped, and the copying routine adds some text to the
output buffer to indicate that there has been data lost and how
many characters were dropped.
Change-Id: I8c126e31db6cb2141f7f4f97c5047f39a8db44fc
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/719
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2011-09-30 02:27:15 +02:00
|
|
|
|
2017-02-03 02:32:00 +01:00
|
|
|
static int buffer_valid(struct cbmem_console *cbm_cons_p, u32 total_space)
|
|
|
|
|
{
|
|
|
|
|
return (cbm_cons_p->cursor & CURSOR_MASK) < cbm_cons_p->size &&
|
|
|
|
|
cbm_cons_p->size <= MAX_SIZE &&
|
|
|
|
|
cbm_cons_p->size == total_space - sizeof(struct cbmem_console);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void init_console_ptr(void *storage, u32 total_space)
|
2013-05-10 07:45:37 +02:00
|
|
|
{
|
|
|
|
|
struct cbmem_console *cbm_cons_p = storage;
|
|
|
|
|
|
2017-02-03 02:32:00 +01:00
|
|
|
if (!cbm_cons_p || total_space <= sizeof(struct cbmem_console)) {
|
2019-11-30 10:49:17 +01:00
|
|
|
current_console = NULL;
|
2014-12-21 07:55:47 +01:00
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
2017-02-03 02:32:00 +01:00
|
|
|
if (!buffer_valid(cbm_cons_p, total_space)) {
|
2017-02-03 21:45:21 +01:00
|
|
|
cbm_cons_p->size = total_space - sizeof(struct cbmem_console);
|
|
|
|
|
cbm_cons_p->cursor = 0;
|
2014-12-21 07:55:47 +01:00
|
|
|
}
|
|
|
|
|
|
2019-11-30 10:49:17 +01:00
|
|
|
current_console = cbm_cons_p;
|
2013-05-10 07:45:37 +02:00
|
|
|
}
|
|
|
|
|
|
CBMEM CONSOLE: Add CBMEM console driver implementation.
The CBMEM console driver saves console output in a CBMEM area, which
then is made available to Linux applications for perusing.
There are some system limitations which need to be worked around
to achieve this goal:
- some console traffic is generated before DRAM is initialized,
leave alone CBMEM initialized.
- after the RAM based stage starts, a lot of traffic is generated
before CBMEM is initialized.
As a result, the console log lives in three different places -
the bottom of the cache as RAM space, the CBMEM buffer (where it
is expected to be) and a static buffer used early in the RAM
stage.
When execution starts (in the cache as RAM mode), the console
buffer is allocated at the bottom of the cache as RAM memory
address range. Once DRAM is initialized, the CBMEM structure is
initialized, and then the console buffer contents are copied from
the bottom of the cache as RAM space into the CBMEM area right
before the cache as RAM mode is disabled. The
src/lib/cbmem_console.c:cbmemc_reinit() takes care of the
copying.
At this point the cache as RAM memory is about to be disabled,
but the ROM stage is still going generating console output. To
make sure this output is not lost, cbmemc_reinit() saves the new
buffer address at a fixed location (0x600 was chosen for this),
and the actual "printing" function checks to see if the RAM is
already initialized (the stack is in RAM), and if so, gets the
console buffer pointer from this location instead of using the
cache as RAM address.
When the RAM stage starts, a static buffer is used to store the
console output, as the CBMEM buffer location is not known. Then,
when CBMEM is reinitialized, cbmemc_reinit() again takes care of
the copying.
In case the allocated buffers are not large enough, the excessive
data is dropped, and the copying routine adds some text to the
output buffer to indicate that there has been data lost and how
many characters were dropped.
Change-Id: I8c126e31db6cb2141f7f4f97c5047f39a8db44fc
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/719
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2011-09-30 02:27:15 +02:00
|
|
|
void cbmemc_init(void)
|
|
|
|
|
{
|
2019-09-13 09:49:20 +02:00
|
|
|
if (ENV_ROMSTAGE_OR_BEFORE) {
|
|
|
|
|
/* Pre-RAM environments use special buffer placed by linker script. */
|
|
|
|
|
init_console_ptr(_preram_cbmem_console, REGION_SIZE(preram_cbmem_console));
|
2022-02-25 00:02:49 +01:00
|
|
|
} else if (ENV_SMM) {
|
|
|
|
|
void *cbmemc = NULL;
|
|
|
|
|
size_t cbmemc_size = 0;
|
|
|
|
|
|
|
|
|
|
smm_get_cbmemc_buffer(&cbmemc, &cbmemc_size);
|
|
|
|
|
|
|
|
|
|
init_console_ptr(cbmemc, cbmemc_size);
|
2019-09-13 09:49:20 +02:00
|
|
|
} else {
|
|
|
|
|
/* Post-RAM uses static (BSS) buffer before CBMEM is reinitialized. */
|
|
|
|
|
init_console_ptr(static_console, sizeof(static_console));
|
|
|
|
|
}
|
CBMEM CONSOLE: Add CBMEM console driver implementation.
The CBMEM console driver saves console output in a CBMEM area, which
then is made available to Linux applications for perusing.
There are some system limitations which need to be worked around
to achieve this goal:
- some console traffic is generated before DRAM is initialized,
leave alone CBMEM initialized.
- after the RAM based stage starts, a lot of traffic is generated
before CBMEM is initialized.
As a result, the console log lives in three different places -
the bottom of the cache as RAM space, the CBMEM buffer (where it
is expected to be) and a static buffer used early in the RAM
stage.
When execution starts (in the cache as RAM mode), the console
buffer is allocated at the bottom of the cache as RAM memory
address range. Once DRAM is initialized, the CBMEM structure is
initialized, and then the console buffer contents are copied from
the bottom of the cache as RAM space into the CBMEM area right
before the cache as RAM mode is disabled. The
src/lib/cbmem_console.c:cbmemc_reinit() takes care of the
copying.
At this point the cache as RAM memory is about to be disabled,
but the ROM stage is still going generating console output. To
make sure this output is not lost, cbmemc_reinit() saves the new
buffer address at a fixed location (0x600 was chosen for this),
and the actual "printing" function checks to see if the RAM is
already initialized (the stack is in RAM), and if so, gets the
console buffer pointer from this location instead of using the
cache as RAM address.
When the RAM stage starts, a static buffer is used to store the
console output, as the CBMEM buffer location is not known. Then,
when CBMEM is reinitialized, cbmemc_reinit() again takes care of
the copying.
In case the allocated buffers are not large enough, the excessive
data is dropped, and the copying routine adds some text to the
output buffer to indicate that there has been data lost and how
many characters were dropped.
Change-Id: I8c126e31db6cb2141f7f4f97c5047f39a8db44fc
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/719
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2011-09-30 02:27:15 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void cbmemc_tx_byte(unsigned char data)
|
|
|
|
|
{
|
2022-01-11 20:48:50 +01:00
|
|
|
if (!current_console || !current_console->size || console_paused)
|
CBMEM CONSOLE: Add CBMEM console driver implementation.
The CBMEM console driver saves console output in a CBMEM area, which
then is made available to Linux applications for perusing.
There are some system limitations which need to be worked around
to achieve this goal:
- some console traffic is generated before DRAM is initialized,
leave alone CBMEM initialized.
- after the RAM based stage starts, a lot of traffic is generated
before CBMEM is initialized.
As a result, the console log lives in three different places -
the bottom of the cache as RAM space, the CBMEM buffer (where it
is expected to be) and a static buffer used early in the RAM
stage.
When execution starts (in the cache as RAM mode), the console
buffer is allocated at the bottom of the cache as RAM memory
address range. Once DRAM is initialized, the CBMEM structure is
initialized, and then the console buffer contents are copied from
the bottom of the cache as RAM space into the CBMEM area right
before the cache as RAM mode is disabled. The
src/lib/cbmem_console.c:cbmemc_reinit() takes care of the
copying.
At this point the cache as RAM memory is about to be disabled,
but the ROM stage is still going generating console output. To
make sure this output is not lost, cbmemc_reinit() saves the new
buffer address at a fixed location (0x600 was chosen for this),
and the actual "printing" function checks to see if the RAM is
already initialized (the stack is in RAM), and if so, gets the
console buffer pointer from this location instead of using the
cache as RAM address.
When the RAM stage starts, a static buffer is used to store the
console output, as the CBMEM buffer location is not known. Then,
when CBMEM is reinitialized, cbmemc_reinit() again takes care of
the copying.
In case the allocated buffers are not large enough, the excessive
data is dropped, and the copying routine adds some text to the
output buffer to indicate that there has been data lost and how
many characters were dropped.
Change-Id: I8c126e31db6cb2141f7f4f97c5047f39a8db44fc
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/719
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2011-09-30 02:27:15 +02:00
|
|
|
return;
|
|
|
|
|
|
2019-11-30 10:49:17 +01:00
|
|
|
u32 flags = current_console->cursor & ~CURSOR_MASK;
|
|
|
|
|
u32 cursor = current_console->cursor & CURSOR_MASK;
|
2017-02-03 02:32:00 +01:00
|
|
|
|
2019-11-30 10:49:17 +01:00
|
|
|
current_console->body[cursor++] = data;
|
|
|
|
|
if (cursor >= current_console->size) {
|
2017-02-03 02:32:00 +01:00
|
|
|
cursor = 0;
|
|
|
|
|
flags |= OVERFLOW;
|
|
|
|
|
}
|
|
|
|
|
|
2019-11-30 10:49:17 +01:00
|
|
|
current_console->cursor = flags | cursor;
|
CBMEM CONSOLE: Add CBMEM console driver implementation.
The CBMEM console driver saves console output in a CBMEM area, which
then is made available to Linux applications for perusing.
There are some system limitations which need to be worked around
to achieve this goal:
- some console traffic is generated before DRAM is initialized,
leave alone CBMEM initialized.
- after the RAM based stage starts, a lot of traffic is generated
before CBMEM is initialized.
As a result, the console log lives in three different places -
the bottom of the cache as RAM space, the CBMEM buffer (where it
is expected to be) and a static buffer used early in the RAM
stage.
When execution starts (in the cache as RAM mode), the console
buffer is allocated at the bottom of the cache as RAM memory
address range. Once DRAM is initialized, the CBMEM structure is
initialized, and then the console buffer contents are copied from
the bottom of the cache as RAM space into the CBMEM area right
before the cache as RAM mode is disabled. The
src/lib/cbmem_console.c:cbmemc_reinit() takes care of the
copying.
At this point the cache as RAM memory is about to be disabled,
but the ROM stage is still going generating console output. To
make sure this output is not lost, cbmemc_reinit() saves the new
buffer address at a fixed location (0x600 was chosen for this),
and the actual "printing" function checks to see if the RAM is
already initialized (the stack is in RAM), and if so, gets the
console buffer pointer from this location instead of using the
cache as RAM address.
When the RAM stage starts, a static buffer is used to store the
console output, as the CBMEM buffer location is not known. Then,
when CBMEM is reinitialized, cbmemc_reinit() again takes care of
the copying.
In case the allocated buffers are not large enough, the excessive
data is dropped, and the copying routine adds some text to the
output buffer to indicate that there has been data lost and how
many characters were dropped.
Change-Id: I8c126e31db6cb2141f7f4f97c5047f39a8db44fc
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/719
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2011-09-30 02:27:15 +02:00
|
|
|
}
|
|
|
|
|
|
2022-01-21 17:46:55 +01:00
|
|
|
/*
|
|
|
|
|
* Copy the current console buffer (either from the cache as RAM area or from
|
|
|
|
|
* the static buffer, pointed at by src_cons_p) into the newly initialized CBMEM
|
|
|
|
|
* console. The use of cbmemc_tx_byte() ensures that all special cases for the
|
|
|
|
|
* target console (e.g. overflow) will be handled. If there had been an
|
|
|
|
|
* overflow in the source console, log a message to that effect.
|
|
|
|
|
*/
|
|
|
|
|
static void copy_console_buffer(struct cbmem_console *src_cons_p)
|
|
|
|
|
{
|
|
|
|
|
u32 c;
|
|
|
|
|
|
|
|
|
|
if (!src_cons_p)
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
if (src_cons_p->cursor & OVERFLOW) {
|
|
|
|
|
const char overflow_warning[] = "\n*** Pre-CBMEM " ENV_STRING
|
|
|
|
|
" console overflowed, log truncated! ***\n";
|
|
|
|
|
for (c = 0; c < sizeof(overflow_warning) - 1; c++)
|
|
|
|
|
cbmemc_tx_byte(overflow_warning[c]);
|
|
|
|
|
for (c = src_cons_p->cursor & CURSOR_MASK;
|
|
|
|
|
c < src_cons_p->size; c++)
|
|
|
|
|
cbmemc_tx_byte(src_cons_p->body[c]);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
for (c = 0; c < (src_cons_p->cursor & CURSOR_MASK); c++)
|
|
|
|
|
cbmemc_tx_byte(src_cons_p->body[c]);
|
|
|
|
|
|
|
|
|
|
/* Invalidate the source console, so it will be reinitialized on the
|
|
|
|
|
next reboot. Otherwise, we might copy the same bytes again. */
|
|
|
|
|
src_cons_p->size = 0;
|
|
|
|
|
}
|
|
|
|
|
|
2022-01-13 17:46:21 +01:00
|
|
|
void cbmemc_copy_in(void *buffer, size_t size)
|
|
|
|
|
{
|
|
|
|
|
struct cbmem_console *previous = (void *)buffer;
|
|
|
|
|
|
|
|
|
|
if (!buffer_valid(previous, size))
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
copy_console_buffer(previous);
|
|
|
|
|
}
|
|
|
|
|
|
2015-06-09 20:54:10 +02:00
|
|
|
static void cbmemc_reinit(int is_recovery)
|
CBMEM CONSOLE: Add CBMEM console driver implementation.
The CBMEM console driver saves console output in a CBMEM area, which
then is made available to Linux applications for perusing.
There are some system limitations which need to be worked around
to achieve this goal:
- some console traffic is generated before DRAM is initialized,
leave alone CBMEM initialized.
- after the RAM based stage starts, a lot of traffic is generated
before CBMEM is initialized.
As a result, the console log lives in three different places -
the bottom of the cache as RAM space, the CBMEM buffer (where it
is expected to be) and a static buffer used early in the RAM
stage.
When execution starts (in the cache as RAM mode), the console
buffer is allocated at the bottom of the cache as RAM memory
address range. Once DRAM is initialized, the CBMEM structure is
initialized, and then the console buffer contents are copied from
the bottom of the cache as RAM space into the CBMEM area right
before the cache as RAM mode is disabled. The
src/lib/cbmem_console.c:cbmemc_reinit() takes care of the
copying.
At this point the cache as RAM memory is about to be disabled,
but the ROM stage is still going generating console output. To
make sure this output is not lost, cbmemc_reinit() saves the new
buffer address at a fixed location (0x600 was chosen for this),
and the actual "printing" function checks to see if the RAM is
already initialized (the stack is in RAM), and if so, gets the
console buffer pointer from this location instead of using the
cache as RAM address.
When the RAM stage starts, a static buffer is used to store the
console output, as the CBMEM buffer location is not known. Then,
when CBMEM is reinitialized, cbmemc_reinit() again takes care of
the copying.
In case the allocated buffers are not large enough, the excessive
data is dropped, and the copying routine adds some text to the
output buffer to indicate that there has been data lost and how
many characters were dropped.
Change-Id: I8c126e31db6cb2141f7f4f97c5047f39a8db44fc
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/719
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2011-09-30 02:27:15 +02:00
|
|
|
{
|
2015-04-20 22:24:19 +02:00
|
|
|
const size_t size = CONFIG_CONSOLE_CBMEM_BUFFER_SIZE;
|
2017-02-03 02:32:00 +01:00
|
|
|
/* If CBMEM entry already existed, old contents are not altered. */
|
|
|
|
|
struct cbmem_console *cbmem_cons_p = cbmem_add(CBMEM_ID_CONSOLE, size);
|
2019-11-30 10:49:17 +01:00
|
|
|
struct cbmem_console *previous_cons_p = current_console;
|
CBMEM CONSOLE: Add CBMEM console driver implementation.
The CBMEM console driver saves console output in a CBMEM area, which
then is made available to Linux applications for perusing.
There are some system limitations which need to be worked around
to achieve this goal:
- some console traffic is generated before DRAM is initialized,
leave alone CBMEM initialized.
- after the RAM based stage starts, a lot of traffic is generated
before CBMEM is initialized.
As a result, the console log lives in three different places -
the bottom of the cache as RAM space, the CBMEM buffer (where it
is expected to be) and a static buffer used early in the RAM
stage.
When execution starts (in the cache as RAM mode), the console
buffer is allocated at the bottom of the cache as RAM memory
address range. Once DRAM is initialized, the CBMEM structure is
initialized, and then the console buffer contents are copied from
the bottom of the cache as RAM space into the CBMEM area right
before the cache as RAM mode is disabled. The
src/lib/cbmem_console.c:cbmemc_reinit() takes care of the
copying.
At this point the cache as RAM memory is about to be disabled,
but the ROM stage is still going generating console output. To
make sure this output is not lost, cbmemc_reinit() saves the new
buffer address at a fixed location (0x600 was chosen for this),
and the actual "printing" function checks to see if the RAM is
already initialized (the stack is in RAM), and if so, gets the
console buffer pointer from this location instead of using the
cache as RAM address.
When the RAM stage starts, a static buffer is used to store the
console output, as the CBMEM buffer location is not known. Then,
when CBMEM is reinitialized, cbmemc_reinit() again takes care of
the copying.
In case the allocated buffers are not large enough, the excessive
data is dropped, and the copying routine adds some text to the
output buffer to indicate that there has been data lost and how
many characters were dropped.
Change-Id: I8c126e31db6cb2141f7f4f97c5047f39a8db44fc
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/719
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2011-09-30 02:27:15 +02:00
|
|
|
|
2017-02-03 02:32:00 +01:00
|
|
|
init_console_ptr(cbmem_cons_p, size);
|
|
|
|
|
copy_console_buffer(previous_cons_p);
|
CBMEM CONSOLE: Add CBMEM console driver implementation.
The CBMEM console driver saves console output in a CBMEM area, which
then is made available to Linux applications for perusing.
There are some system limitations which need to be worked around
to achieve this goal:
- some console traffic is generated before DRAM is initialized,
leave alone CBMEM initialized.
- after the RAM based stage starts, a lot of traffic is generated
before CBMEM is initialized.
As a result, the console log lives in three different places -
the bottom of the cache as RAM space, the CBMEM buffer (where it
is expected to be) and a static buffer used early in the RAM
stage.
When execution starts (in the cache as RAM mode), the console
buffer is allocated at the bottom of the cache as RAM memory
address range. Once DRAM is initialized, the CBMEM structure is
initialized, and then the console buffer contents are copied from
the bottom of the cache as RAM space into the CBMEM area right
before the cache as RAM mode is disabled. The
src/lib/cbmem_console.c:cbmemc_reinit() takes care of the
copying.
At this point the cache as RAM memory is about to be disabled,
but the ROM stage is still going generating console output. To
make sure this output is not lost, cbmemc_reinit() saves the new
buffer address at a fixed location (0x600 was chosen for this),
and the actual "printing" function checks to see if the RAM is
already initialized (the stack is in RAM), and if so, gets the
console buffer pointer from this location instead of using the
cache as RAM address.
When the RAM stage starts, a static buffer is used to store the
console output, as the CBMEM buffer location is not known. Then,
when CBMEM is reinitialized, cbmemc_reinit() again takes care of
the copying.
In case the allocated buffers are not large enough, the excessive
data is dropped, and the copying routine adds some text to the
output buffer to indicate that there has been data lost and how
many characters were dropped.
Change-Id: I8c126e31db6cb2141f7f4f97c5047f39a8db44fc
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/719
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2011-09-30 02:27:15 +02:00
|
|
|
}
|
cbmem: Introduce "early" init hooks for console
Over the last couple of years we have continuously added more and more
CBMEM init hooks related to different independent components. One
disadvantage of the API is that it can not model any dependencies
between the different hooks, and their order is essentially undefined
(based on link order). For most hooks this is not a problem, and in fact
it's probably not a bad thing to discourage implicit dependencies
between unrelated components like this... but one resource the
components obviously all share is CBMEM, and since many CBMEM init hooks
are used to create new CBMEM areas, the arbitrary order means that the
order of these areas becomes unpredictable.
Generally code using CBMEM should not care where exactly an area is
allocated, but one exception is the persistent CBMEM console which
relies (on a best effort basis) on always getting allocated at the same
address on every boot. This is, technically, a hack, but it's a pretty
harmless hack that has served us reasonably well so far and would be
difficult to realize in a more robust way (without adding a lot of new
infrastructure). Most of the time, coreboot will allocate the same CBMEM
areas in the same order with the same sizes on every boot, and this all
kinda works out (and since it's only a debug console, we don't need to
be afraid of the odd one-in-a-million edge case breaking it).
But one reproducible difference we can have between boots is the vboot
boot mode (e.g. normal vs. recovery boot), and we had just kinda gotten
lucky in the past that we didn't have differences in CBMEM allocations
in different boot modes. With the recent addition of the RW_MCACHE
(which does not get allocated in recovery mode), this is no longer true,
and as a result CBMEM consoles can no longer persist between normal and
recovery modes.
The somewhat kludgy but simple solution is to just create a new class of
specifically "early" CBMEM init hooks that will always run before all
the others. While arbitrarily partitioning hooks into "early" and "not
early" without any precise definition of what these things mean may seem
a bit haphazard, I think it will be good enough in practice for the very
few cases where this matters and beats building anything much more
complicated (FWIW Linux has been doing something similar for years with
device suspend/resume ordering). Since the current use case only relates
to CBMEM allocation ordering and you can only really be "first" if you
allocate in romstage, the "early" hook is only available in romstage for
now (could be expanded later if we find a use case for it).
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: If2c849a89f07a87d448ec1edbad4ce404afb0746
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54737
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
2021-05-21 02:00:46 +02:00
|
|
|
|
2022-03-31 06:40:10 +02:00
|
|
|
/* Run this hook early so that the console region is one of the earliest created, and
|
cbmem: Introduce "early" init hooks for console
Over the last couple of years we have continuously added more and more
CBMEM init hooks related to different independent components. One
disadvantage of the API is that it can not model any dependencies
between the different hooks, and their order is essentially undefined
(based on link order). For most hooks this is not a problem, and in fact
it's probably not a bad thing to discourage implicit dependencies
between unrelated components like this... but one resource the
components obviously all share is CBMEM, and since many CBMEM init hooks
are used to create new CBMEM areas, the arbitrary order means that the
order of these areas becomes unpredictable.
Generally code using CBMEM should not care where exactly an area is
allocated, but one exception is the persistent CBMEM console which
relies (on a best effort basis) on always getting allocated at the same
address on every boot. This is, technically, a hack, but it's a pretty
harmless hack that has served us reasonably well so far and would be
difficult to realize in a more robust way (without adding a lot of new
infrastructure). Most of the time, coreboot will allocate the same CBMEM
areas in the same order with the same sizes on every boot, and this all
kinda works out (and since it's only a debug console, we don't need to
be afraid of the odd one-in-a-million edge case breaking it).
But one reproducible difference we can have between boots is the vboot
boot mode (e.g. normal vs. recovery boot), and we had just kinda gotten
lucky in the past that we didn't have differences in CBMEM allocations
in different boot modes. With the recent addition of the RW_MCACHE
(which does not get allocated in recovery mode), this is no longer true,
and as a result CBMEM consoles can no longer persist between normal and
recovery modes.
The somewhat kludgy but simple solution is to just create a new class of
specifically "early" CBMEM init hooks that will always run before all
the others. While arbitrarily partitioning hooks into "early" and "not
early" without any precise definition of what these things mean may seem
a bit haphazard, I think it will be good enough in practice for the very
few cases where this matters and beats building anything much more
complicated (FWIW Linux has been doing something similar for years with
device suspend/resume ordering). Since the current use case only relates
to CBMEM allocation ordering and you can only really be "first" if you
allocate in romstage, the "early" hook is only available in romstage for
now (could be expanded later if we find a use case for it).
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: If2c849a89f07a87d448ec1edbad4ce404afb0746
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54737
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
2021-05-21 02:00:46 +02:00
|
|
|
therefore more likely to stay in the same place even across different boot modes where some
|
|
|
|
|
other regions may sometimes not get created (e.g. RW_MCACHE in vboot recovery mode). */
|
2022-03-31 06:40:10 +02:00
|
|
|
CBMEM_READY_HOOK_EARLY(cbmemc_reinit);
|
2015-04-20 22:24:19 +02:00
|
|
|
|
2019-03-06 01:53:33 +01:00
|
|
|
#if CONFIG(CONSOLE_CBMEM_DUMP_TO_UART)
|
2022-01-11 20:44:38 +01:00
|
|
|
void cbmem_dump_console_to_uart(void)
|
2015-04-11 03:04:04 +02:00
|
|
|
{
|
2017-02-03 02:32:00 +01:00
|
|
|
u32 cursor;
|
2022-01-21 21:34:21 +01:00
|
|
|
unsigned int console_index;
|
|
|
|
|
|
2019-11-30 10:49:17 +01:00
|
|
|
if (!current_console)
|
2015-04-11 03:04:04 +02:00
|
|
|
return;
|
|
|
|
|
|
2022-01-21 21:34:21 +01:00
|
|
|
console_index = get_uart_for_console();
|
|
|
|
|
|
|
|
|
|
uart_init(console_index);
|
|
|
|
|
if (current_console->cursor & OVERFLOW) {
|
2019-11-30 10:49:17 +01:00
|
|
|
for (cursor = current_console->cursor & CURSOR_MASK;
|
2022-01-21 21:34:21 +01:00
|
|
|
cursor < current_console->size; cursor++) {
|
2022-01-22 00:33:47 +01:00
|
|
|
if (BIOS_LOG_IS_MARKER(current_console->body[cursor]))
|
|
|
|
|
continue;
|
2022-01-21 21:34:21 +01:00
|
|
|
if (current_console->body[cursor] == '\n')
|
|
|
|
|
uart_tx_byte(console_index, '\r');
|
|
|
|
|
uart_tx_byte(console_index, current_console->body[cursor]);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
for (cursor = 0; cursor < (current_console->cursor & CURSOR_MASK); cursor++) {
|
2022-01-22 00:33:47 +01:00
|
|
|
if (BIOS_LOG_IS_MARKER(current_console->body[cursor]))
|
|
|
|
|
continue;
|
2022-01-21 21:34:21 +01:00
|
|
|
if (current_console->body[cursor] == '\n')
|
|
|
|
|
uart_tx_byte(console_index, '\r');
|
|
|
|
|
uart_tx_byte(console_index, current_console->body[cursor]);
|
|
|
|
|
}
|
2015-04-11 03:04:04 +02:00
|
|
|
}
|
|
|
|
|
#endif
|
2022-01-11 20:48:50 +01:00
|
|
|
|
|
|
|
|
void cbmem_dump_console(void)
|
|
|
|
|
{
|
|
|
|
|
u32 cursor;
|
|
|
|
|
if (!current_console)
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
console_paused = true;
|
|
|
|
|
|
|
|
|
|
if (current_console->cursor & OVERFLOW)
|
|
|
|
|
for (cursor = current_console->cursor & CURSOR_MASK;
|
|
|
|
|
cursor < current_console->size; cursor++)
|
2022-01-22 00:33:47 +01:00
|
|
|
if (!BIOS_LOG_IS_MARKER(current_console->body[cursor]))
|
|
|
|
|
do_putchar(current_console->body[cursor]);
|
2022-01-11 20:48:50 +01:00
|
|
|
for (cursor = 0; cursor < (current_console->cursor & CURSOR_MASK); cursor++)
|
2022-01-22 00:33:47 +01:00
|
|
|
if (!BIOS_LOG_IS_MARKER(current_console->body[cursor]))
|
|
|
|
|
do_putchar(current_console->body[cursor]);
|
2022-01-11 20:48:50 +01:00
|
|
|
|
|
|
|
|
console_paused = false;
|
|
|
|
|
}
|
