The .inc suffix is confusing to various tools as it's not specific to
Makefiles. This means that editors don't recognize the files, and don't
open them with highlighting and any other specific editor functionality.
This issue is also seen in the release notes generation script where
Makefiles get renamed before running cloc.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I9eabe84d55fd9f434e4128866810c0e4970f2ae7
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80081
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Having a separate romstage is only desirable:
- with advanced setups like vboot or normal/fallback
- boot medium is slow at startup (some ARM SOCs)
- bootblock is limited in size (Intel APL 32K)
When this is not the case there is no need for the extra complexity
that romstage brings. Including the romstage sources inside the
bootblock substantially reduces the total code footprint. Often the
resulting code is 10-20k smaller.
This is controlled via a Kconfig option.
TESTED: works on qemu x86, arm and aarch64 with and without VBOOT.
Change-Id: Id68390edc1ba228b121cca89b80c64a92553e284
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55068
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
To help identify the licenses of the various files contained in the
coreboot source, we've added SPDX headers to the top of all of the
.c and .h files. This extends that practice to Makefiles.
Any file in the coreboot project without a specific license is bound
to the license of the overall coreboot project, GPL Version 2.
This patch adds the GPL V2 license identifier to the top of all
makefiles in the commonlib, console, northbridge, security, and
southbridge directories that don't already have an SPDX license line
at the top.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I02804a10d0b0355e41271a035613d9f3dfb122f8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68985
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
It's hidden behind the configuration option `CONFIG_ROMSTAGE_LIBHWBASE'.
This also adds some glue code to use the coreboot console for debug
output and our monotonic timer framework as timer backend.
Running Ada code in romstage and more particular libhwbase brings a few
challenges as global initialized variables are not supported in
Cache-As-Ram mode.
1. The libhwbase dynamic mmio driver implementation makes the Gnat
compiler generate some global initialized variables.
For this reason, when compiled for romstage or for romstage and
ramstage the static mmio driver is enforced (`HWBASE_STATIC_MMIO').
2. The Gnat compiler generates elaboration functions to initialize
program data at runtime. These elaboration functions are called by
the romstage_adainit() function.
The data references symbols suffixed by `_E'. Even though these
symbols, at compilation time, do not contain any data and are
filled with zeros, the Gnat compiler installs them in the .data
section.
Since these symbols are actually filled with zeros, it is safe to
install them in the .bss section.
cf. https://docs.adacore.com/gnat_ugn-docs/html/gnat_ugn/gnat_ugn/elaboration_order_handling_in_gnat.html#elaboration-code
This patch requires the libhwbase
https://review.coreboot.org/c/libhwbase/+/69854 CL.
BUG=b:252792591
BRANCH=firmware-brya-14505.B
TEST=libhwbae compiles for romstage and loads successfully
Change-Id: I670249d33506e886a683e55d1589cb2bf9b16aa3
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70275
Reviewed-by: Boris Mittelberg <bmbm@google.com>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Reviewed-by: Zhixing Ma <zhixing.ma@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch adds an option to disable loglevel prefixes. This patch helps
to achieve clear messages when low loglevel is used and very few
messages are displayed on a terminal. This option also allows to
maintain compatibility with log readers and continuous integration
systems that depend on fixed log content.
If the code contains:
printk(BIOS_DEBUG, "This is a debug message!\n")
it will show as:
[DEBUG] This is a debug message!
but if the Kconfig contains:
CONFIG_CONSOLE_USE_LOGLEVEL_PREFIX=n
the same message will show up as
This is a debug message!
Signed-off-by: Igor Bagnucki <igor.bagnucki@3mdeb.com>
Change-Id: I911bb601cf1933a4c6498b2ae1e4cb4d4bc85621
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63144
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
In the LOG_FAST macro, the comparison was incorrectly made with 'level'
value. Correct is the comparison with 'speed'.
With the wrong comparison you cannot set a lower level for console log,
the highest level is always output.
TEST:
- Boot mc_ehl2 with console log level 5 and check output
Change-Id: Ib5b4537ae2cbf01c51c3568d312b5242c4bee7bb
Signed-off-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/62261
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Patrick Georgi <patrick@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Post codes don't signify an emergency error, so they shouldn't be
classified as BIOS_EMERG. Now that loglevels are more visible, this
misclassification looks pretty glaring. This patch changes them to
BIOS_INFO which seems more appropriate for an informational code that is
expected to occur in the normal boot flow.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I85c8768232ae0cbf65669a7ee6abd538a3b2d5e1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61692
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
A common use case when running coreboot on production systems is that
only the CBMEM console (the one with the least impact on boot speed) is
enabled. In this case, some of the code in the console subsystem has no
effect. Due to the way it's all genericized over multiple consoles and
tied together with function pointers, not all of this can be
compile-time eliminated automatically, so this patch adds a little
helper to facilitate that. This results in roughly 200 (compressed)
bytes of savings per stage on an arm64 system.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I1d5b8bda80d02a13ee0b7835e0805c4319fd21d8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61613
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
In order to provide the same loglevel prefixes and highlighting that
were recently introduced for "interactive" consoles (e.g. UART) to
"stored" consoles (e.g. CBMEM) but minimize the amont of extra storage
space wasted on this info, this patch will write a 1-byte control
character marker indicating the loglevel to the start of every line
logged in those consoles. The `cbmem` utility will then interpret those
markers and translate them back into loglevel prefixes and escape
sequences as needed.
Since coreboot and userspace log readers aren't always in sync,
occasionally an older reader may come across these markers and not know
how to interpret them... but that should usually be fine, as the range
chosen contains non-printable ASCII characters that normally have no
effect on the terminal. At worst the outdated reader would display one
garbled character at the start of every line which isn't that bad.
(Older versions of the `cbmem` utility will translate non-printable
characters into `?` question marks.)
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I86073f48aaf1e0a58e97676fb80e2475ec418ffc
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61308
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
This patch adds ANSI escape sequences to highlight a log line based on
its loglevel to the output of "interactive" consoles that are meant to
be displayed on a terminal (e.g. UART). This should help make errors and
warnings stand out better among the usual spew of debug messages. For
users whose terminal or use case doesn't support these sequences for
some reason (or who simply don't like them), they can be disabled with a
Kconfig.
While ANSI escape sequences can be used to add color, minicom (the
presumably most common terminal emulator for UART endpoints?) doesn't
support color output unless explicitly enabled (via -c command line
flag), and other terminal emulators may have similar restrictions, so in
an effort to make this as widely useful by default as possible I have
chosen not to use color codes and implement this highlighting via
bolding, underlining and inverting alone (which seem to go through in
all cases). If desired, support for separate color highlighting could be
added via Kconfig later.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I868f4026918bc0e967c32e14bcf3ac05816415e8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61307
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
In an attempt to make loglevels more visible (and therefore useful,
hopefully), this patch adds a prefix indicating the log level to every
line sent to an "interactive" console (such as a UART). If the code
contains a `printk(BIOS_DEBUG, "This is a debug message!\n"), it will
now show up as
[DEBUG] This is a debug message!
on the UART output.
"Stored" consoles (such as in CBMEM) will get a similar but more
space-efficient feature in a later CL.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Ic83413475400821f8097ef1819a293ee8926bb0b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61306
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
This patch makes a slight change in the way CONSOLE_LOG_FAST and
CONSOLE_LOG_ALL are differentiated, by no longer passing a different
tx_byte() function pointer and instead using the `data` argument to
vtxprintf() to encode the difference. It also passes the message log
level through to the tx_byte() function this way, which will be needed
in the next patch.
Change-Id: I0bba134cd3e70c2032689abac83ff53d7cdf2d7f
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61580
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Chromebooks normally run with non-serial enabled firmware because
writing to the UART console is very slow. This unfortunately makes
debugging boot errors more difficult. We tend to rely on port 80s and/or
the vboot recovery code.
When CONSOLE_CBMEM_DUMP_TO_UART is selected it will dump the entire
cbmem console to the UART whenever `vboot_reboot()` is called. We don't
incur any boot time penalty in the happy path, but still retain the
ability to access the logs when an error occurs.
The previous implementation was using a hard coded UART index and
`get_uart_baudrate` was always returning 0 since `CONFIG_TTYS0_BAUD`
wasn't defined. This change makes it so the UART console properties are
available when CONSOLE_CBMEM_DUMP_TO_UART is set. This results in the
following .config diff:
+CONFIG_UART_FOR_CONSOLE=0
+CONFIG_TTYS0_BASE=0x3f8
+CONFIG_TTYS0_LCS=3
+CONFIG_CONSOLE_SERIAL_115200=y
+CONFIG_TTYS0_BAUD=115200
This functionality is especially helpful on Guybrush. PSP Verstage is
run on S0i3 resume. Today, if there is an error, the cbmem console is
lost since it lives in the PSP SRAM.
BUG=b:213828947, b:215599230
TEST=Build non-serial guybrush FW and verify no serial output happens in
happy path. Inject a vboot error and perform an S0i3 suspend/resume.
Verify CBMEM console gets dumped to the correct UART.
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I997942204603362e51876a9ae25e493fe527437b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61305
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Pre-bootblock stages (i.e., VBOOT_STARTS_BEFORE_BOOTBLOCK) might not
have the ability to log to the UART, so their console messages are
inaccessible until the boot processes gets into the payload or OS.
This makes it difficult to debug verstage.
This feature will dump the pre-bootblock CBMEM console immediately
after the bootblock console is initialized. I chose to do this in
console_init instead of bootblock_soc_init because I wanted to have the
pre-bootblock contents dumped before the coreboot bootblock starting
message is printed.
BUG=b:213828947
TEST=Boot guybrush with PSP verstage and verify verstage logs are dumped
to the UART.
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I363c93ef3ee6c5c303a6a68f88a622e2aa62594c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61012
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
We never call console_init from asm, so we don't need the asmlinkage.
This allows us to remove the arch/cpu.h include since we only needed it
for the asmlinkage #define.
BUG=b:179699789
TEST=build guybrush
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I9a7895d4f5cba59f6b05915fa4d6c6fd6ab85773
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57568
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
CB:55356 removed static inline declarations from get_log_level(). This
commit puts them back. It also changes the method of accessing static
symbols in tests/console/routing-test to source file inclusion like
in CB:46458 to avoid changing tested source file.
Signed-off-by: Jakub Czapiga <jacz@semihalf.com>
Change-Id: Iaa5dcbccb327f819374967be51ef642b1fb25e7b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55473
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Looks like the option is generally not compatible with
garbage collections.
Nothing gets inlined, for example is_smp_boot() no longer
evaluates to constant false and thus the symbols from
secondary.S would need to be present for the build to pass
even if we set SMP=n.
Also the addresses of relocatable ramstage are currently
not normalised on the logs, so util/genprof would be unable
dress those.
Change-Id: I0b6f310e15e6f4992cd054d288903fea8390e5cf
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45757
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
We limited the configurability of the debug level to stages that have
a `.data` section. This is not really a requirement, because a `.bss`
section should suffice and we always have that now.
We want to make the debug level configurable early but also want to
avoid calling get_option() early, as an error therein could result
in no console output at all. Hence, we compromise and start using
get_option() from the second console init on.
TEST=Booted QEMU once with `debug_level=Debug` and once with
`debug_level=Notice`. On the second boot, most messages
vanished for all stages but the bootblock.
Change-Id: I11484fc32dcbba8d31772bd0b82785f17b2fba11
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45765
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Marc Jones <marc@marcjonesconsulting.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
