summaryrefslogtreecommitdiffstats
path: root/toolchain.inc
diff options
context:
space:
mode:
authorJulius Werner <jwerner@chromium.org>2018-05-16 14:14:04 -0700
committerJulius Werner <jwerner@chromium.org>2018-05-22 02:44:14 +0000
commit99f4683adf3203d11c164b15a5455e778709a3e0 (patch)
tree077268ffcfa2df08671633ff0e0501e9626fda22 /toolchain.inc
parent9123449734f43922fe39cdb08c3d60f02f0eb3ed (diff)
downloadcoreboot-99f4683adf3203d11c164b15a5455e778709a3e0.tar.gz
coreboot-99f4683adf3203d11c164b15a5455e778709a3e0.tar.bz2
coreboot-99f4683adf3203d11c164b15a5455e778709a3e0.zip
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>
Diffstat (limited to 'toolchain.inc')
-rw-r--r--toolchain.inc3
1 files changed, 2 insertions, 1 deletions
diff --git a/toolchain.inc b/toolchain.inc
index f8ee87578efc..ec57b5d24c10 100644
--- a/toolchain.inc
+++ b/toolchain.inc
@@ -47,7 +47,8 @@ HOSTCXX:=CCC_CXX="$(HOSTCXX)" $(CXX)
ROMCC=CCC_CC="$(ROMCC_BIN)" $(CC)
endif
-COREBOOT_STANDARD_STAGES := bootblock verstage romstage ramstage
+COREBOOT_STANDARD_STAGES := decompressor bootblock verstage romstage ramstage
+MAP-decompressor := bootblock
ARCHDIR-i386 := x86
ARCHDIR-x86_32 := x86