This patch enables the new bootblock compression feature on RK3399,
which requires moving MMU initialization into the decompressor stage and
linking the decompressor (rather than the bootblock) into the entry
point jumped to by the masked ROM.
RK3399's masked ROM seems to be using a bitbang SPI driver to load us
(very long pauses between clocking in each byte), with an effective data
rate of about 1Mbit. Bootblock loading time (as measured on a SPI
analyzer) is reduced by almost 100ms (about a third), while the
decompression time is trivial (under 1ms).
Change-Id: I48967ca5bb51cc4481d69dbacb4ca3c6b96cccea
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/26341
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Masked ROMs are the silent killers of boot speed on devices without
memory-mapped SPI flash. They often contain awfully slow SPI drivers
(presumably bit-banged) that take hundreds of milliseconds to load our
bootblock, and every extra kilobyte of bootblock size has a hugely
disproportionate impact on boot speed. The coreboot timestamps can never
show that component, but it impacts our users all the same.
This patch tries to alleviate that issue a bit by allowing us to
compress the bootblock with LZ4, which can cut its size down to nearly
half. Of course, masked ROMs usually don't come with decompression
algorithms built in, so we need to introduce a little decompression stub
that can decompress the rest of the bootblock. This is done by creating
a new "decompressor" stage which runs before the bootblock, but includes
the compressed bootblock code in its data section. It needs to be as
small as possible to get a real benefit from this approach, which means
no device drivers, no console output, no exception handling, etc.
Besides the decompression algorithm itself we only include the timer
driver so that we can measure the boot speed impact of decompression. On
ARM and ARM64 systems, we also need to give SoC code a chance to
initialize the MMU, since running decompression without MMU is
prohibitively slow on these architectures.
This feature is implemented for ARM and ARM64 architectures for now,
although most of it is architecture-independent and it should be
relatively simple to port to other platforms where a masked ROM loads
the bootblock into SRAM. It is also supposed to be a clean starting
point from which later optimizations can hopefully cut down the
decompression stub size (currently ~4K on RK3399) a bit more.
NOTE: Bootblock compression is not for everyone. Possible side effects
include trying to run LZ4 on CPUs that come out of reset extremely
underclocked or enabling this too early in SoC bring-up and getting
frustrated trying to find issues in an undebuggable environment. Ask
your SoC vendor if bootblock compression is right for you.
Change-Id: I0dc1cad9ae7508892e477739e743cd1afb5945e8
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/26340
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch adds the CCACHE_EXTRAFILES variable to the list of exported
environment variables, which can be useful as a target-specific variable
to make ccache aware of extra dependencies that it cannot figure out on
its own. It also adds a CPPFLAGS parameter to define the __BUILD_DIR__
constant for the preprocessor so that the current output build directory
can be referenced in C code if necessary.
Change-Id: I4fdd08842972cfed8ef5e5a61ebf859c0571bcfb
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/26451
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch adds more parameters to bootblock_main_with_timestamp() to
give callers the opportunity to add additional timestamps that were
recorded in the platform-specific initialization phase.
Change-Id: Idf3a0fcf5aee88a33747afc69e055b95bd38750c
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/26339
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This patch moves the objcopy invocation that changes the bootblock's
section flags to make sure .data and .bss are preserved in the binary
image from the generation of bootblock.raw.bin into a separate
bootblock.raw.elf file. Some SoCs (like SDM845) like to have an ELF
rather than a raw binary as input to their masked ROM wrapper
generation script.
Also move those objcopy flags out into a variable because I'll need them
again in a later patch.
Change-Id: I9557b184df7f753a442c7e0ceb58e81c5e19f2c5
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/26338
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch adds a new "rawcompress" command to cbfs-compression-tool,
that works exactly the same as "compress" except that it doesn't add the
custom 8-byte header to the file. This can be useful if you need to
compress something into a format that coreboot's decompression routines
can work with, but it's not supposed to go into CBFS.
Change-Id: I18a97a35bb0b0f71f3226f97114936dc81d379eb
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/26337
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Bip should have different devicetree entries than Yorp; it doesn't have
a DA7219 audio codec (instead it uses ALC5682).
BRANCH=none
BUG=b:79771967
TEST=boot, no longer see DA7219 ACPI in console.
Change-Id: Ic63bbc51e122afc9fc2e8ec7fb024d18a3815b38
Signed-off-by: Justin TerAvest <teravest@chromium.org>
Reviewed-on: https://review.coreboot.org/26342
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com>
This patch adds two minor improvements to the way cbfs-compression-tool
parses the compression algorithm type that is passed through the -t
option of the 'compress' subcommand. These improvements are intended
to prevent accidents and unexpected behavior when using the
cbfs-compression-tool, in particular in automated contexts such as a
Makefile rule.
In the first part of this patch, a return statement is inserted after
the 'if (algo->name == NULL)' check of the compress() function. This
causes the function to exit immediately and subsequently abort the
program when the algorithm type was not detected correctly. Previously,
execution would continue with the 'algo' pointer pointing to the zeroed
out stopper entry of the types_cbfs_compression[] array. The ultimate
effect of this would be to pass 0 as 'algo->type' to the
compression_function() function, which happens to be the same
enumeration value as is used for CBFS_COMPRESS_NONE, leading to a valid
compression function result that matches the behavior of no compression.
Thus, if a script calling cbfs-compression-tool compress contained a
typo in the -t parameter, it would continue running with an unintended
compression result rather than immediately exiting cleanly.
In the second part of this patch, the strcmp() function is replaced with
strcasecmp() when comparing 'algo->name' with the 'algoname' parameter
that was passed to the compress() function. strcasecmp() uses an
identical function signature as strcmp() and is thus suitable as a
drop-in replacement, but it differs in behavior: rather than only
returning a result of 0 when the two NULL-terminated input strings are
character by character identical, the strcasecmp() function applies a
weaker concept of identity where characters of the latin alphabet
(hexadecimal ranges 0x41 through 0x5a and 0x61 through 0x7a) are also
considered identical to other characters that differ from them only in
their case. This causes the -t parameter of cbfs-compression-tool
compress to also accept lowercase spellings of the available compression
algorithms, such as "lz4" instead of "LZ4" and "lzma" instead of "LZMA".
As an unintended but harmless side-effect, mixed-case spellings such as
"lZ4" or "LZmA" will also be recognized as valid compression algorithms.
(Note that since the character "4" (hexadecimal 0x34) of the "LZ4"
compression type name is not part of the above-mentioned ranges of latin
alphabet characters, no new substitutions become valid for that part of
the "LZ4" string with this patch.)
Change-Id: I375dbaeefaa0d4b0c5be81bf7668f8f330f1cf61
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/26389
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Stack smashing was detected during raminit when not loading from MRC.
Adding CAR_GLOBAL to a struct inside raminit was suggested in
https://mail.coreboot.org/pipermail/coreboot/2018-May/086677.html in
order to fix the problem.
Adding CAR_GLOBAL to the ram timings variable solves the issue (adding
it to the ram_training or raminfo struct had no effect).
This is just a workaround and might need a proper fix in the future.
Tested on Lenovo X201i with 2+2 and 4+4 GB RAM.
Change-Id: I21b380db61be2aedc045201821d83e18e7d07ad1
Signed-off-by: Matthias Gazzari <mail@qtux.eu>
Reviewed-on: https://review.coreboot.org/26388
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Up to this point, junit.xml has only been used to build tools, as abuild
has handled the coreboot builds. To add additional tests not covered
by abuild, we need junit.xml to work with bare directories.
This also requires updating the build directory (BLD_DIR) for existing
builds using the junit.xml target.
Change-Id: If6e27e02e25e20f48e5a9372373de6058ca378dd
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: https://review.coreboot.org/26421
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
We use packed structs with unaligned members all the time, which is the
entire point of us using the packed attribute.
Change-Id: Ib26b422ba83257d1a7f26134ee20217fad5823cd
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/25996
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
It turns out that even with the `-gnatp` switch to suppress runtime
checks, the compiler is still allowed to generate them (it only doesn't
have to). If we can't control generation of checks, we also can't
make assumptions about propagation of their exceptions.
The compiler warning that led to this change seems spurious, though
(the check might be generated, but is dropped later). So we might
revert this decision if the compiler can be fixed.
Change-Id: I7470d74b1f96f90d0d15b24dfd636d5f1c778d46
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/26350
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
