From 99f4683adf3203d11c164b15a5455e778709a3e0 Mon Sep 17 00:00:00 2001 From: Julius Werner Date: Wed, 16 May 2018 14:14:04 -0700 Subject: 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 Reviewed-on: https://review.coreboot.org/26340 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin --- src/Kconfig | 12 ++++++++++++ 1 file changed, 12 insertions(+) (limited to 'src/Kconfig') 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 -- cgit v1.2.3