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, 17 insertions, 0 deletions

diff --git a/src/lib/bootblock.c b/src/lib/bootblock.c
index 867f1b16e6..d74bebfe83 100644
--- a/src/lib/bootblock.c
+++ b/src/lib/bootblock.c
@@ -70,3 +70,20 @@ void main(void)
 
 	bootblock_main_with_timestamp(base_timestamp, NULL, 0);
 }
+
+#if IS_ENABLED(CONFIG_COMPRESS_BOOTBLOCK)
+/*
+ * This is the bootblock entry point when it is run after a decompressor stage.
+ * For non-decompressor builds, _start is generally defined in architecture-
+ * specific assembly code. In decompressor builds that architecture
+ * initialization code already ran in the decompressor, so the bootblock can
+ * start straight into common code with a C environment.
+ */
+void _start(struct bootblock_arg *arg);
+void _start(struct bootblock_arg *arg)
+{
+	bootblock_main_with_timestamp(arg->base_timestamp, arg->timestamps,
+				      arg->num_timestamps);
+}
+
+#endif