Introduce bootblock self-decompression

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>

1 files changed, 12 insertions, 0 deletions

diff --git a/src/Kconfig b/src/Kconfig
index 99a704dbd7..d2b9fc23b6 100644
--- a/src/Kconfig
+++ b/src/Kconfig
@@ -146,6 +146,18 @@ config COMPRESS_PRERAM_STAGES
 	  time spent decompressing. Doesn't work for XIP stages (assume all
 	  ARCH_X86 for now) for obvious reasons.
 
+config COMPRESS_BOOTBLOCK
+	bool
+	help
+	  This option can be used to compress the bootblock with LZ4 and attach
+	  a small self-decompression stub to its front. This can drastically
+	  reduce boot time on platforms where the bootblock is loaded over a
+	  very slow connection and bootblock size trumps all other factors for
+	  speed. Since this using this option usually requires changes to the
+	  SoC memlayout and possibly extra support code, it should not be
+	  user-selectable. (There's no real point in offering this to the user
+	  anyway... if it works and saves boot time, you would always want it.)
+
 config INCLUDE_CONFIG_FILE
 	bool "Include the coreboot .config file into the ROM image"
 	# Default value set at the end of the file