coreboot-kgpe-d16/src/console/Makefile.inc

43 lines
1.2 KiB
PHP
Raw Normal View History

ramstage-y += vtxprintf.c printk.c vsprintf.c
ramstage-y += init.c console.c
ramstage-y += post.c
ramstage-y += die.c
ifeq ($(CONFIG_HWBASE_DEBUG_CB),y)
ramstage-$(CONFIG_RAMSTAGE_LIBHWBASE) += hw-debug_sink.ads
ramstage-$(CONFIG_RAMSTAGE_LIBHWBASE) += hw-debug_sink.adb
lib: Hook up libhwbase in romstage It's hidden behind the configuration option `CONFIG_ROMSTAGE_LIBHWBASE'. This also adds some glue code to use the coreboot console for debug output and our monotonic timer framework as timer backend. Running Ada code in romstage and more particular libhwbase brings a few challenges as global initialized variables are not supported in Cache-As-Ram mode. 1. The libhwbase dynamic mmio driver implementation makes the Gnat compiler generate some global initialized variables. For this reason, when compiled for romstage or for romstage and ramstage the static mmio driver is enforced (`HWBASE_STATIC_MMIO'). 2. The Gnat compiler generates elaboration functions to initialize program data at runtime. These elaboration functions are called by the romstage_adainit() function. The data references symbols suffixed by `_E'. Even though these symbols, at compilation time, do not contain any data and are filled with zeros, the Gnat compiler installs them in the .data section. Since these symbols are actually filled with zeros, it is safe to install them in the .bss section. cf. https://docs.adacore.com/gnat_ugn-docs/html/gnat_ugn/gnat_ugn/elaboration_order_handling_in_gnat.html#elaboration-code This patch requires the libhwbase https://review.coreboot.org/c/libhwbase/+/69854 CL. BUG=b:252792591 BRANCH=firmware-brya-14505.B TEST=libhwbae compiles for romstage and loads successfully Change-Id: I670249d33506e886a683e55d1589cb2bf9b16aa3 Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/70275 Reviewed-by: Boris Mittelberg <bmbm@google.com> Reviewed-by: Nick Vaccaro <nvaccaro@google.com> Reviewed-by: Tarun Tuli <taruntuli@google.com> Reviewed-by: Zhixing Ma <zhixing.ma@intel.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2022-12-01 23:07:51 +01:00
romstage-$(CONFIG_ROMSTAGE_LIBHWBASE) += hw-debug_sink.ads
romstage-$(CONFIG_ROMSTAGE_LIBHWBASE) += hw-debug_sink.adb
endif
smm-$(CONFIG_DEBUG_SMI) += init.c console.c vtxprintf.c printk.c
smm-y += die.c
smm-y += post.c
ifneq ($(CONFIG_VBOOT_STARTS_BEFORE_BOOTBLOCK),y)
verstage-y += printk.c
verstage-y += console.c
endif
verstage-y += post.c
verstage-y += die.c
verstage-y += init.c
verstage-y += vtxprintf.c vsprintf.c
romstage-y += vtxprintf.c printk.c vsprintf.c
romstage-y += init.c console.c
romstage-y += post.c
romstage-y += die.c
postcar-y += vtxprintf.c vsprintf.c
postcar-$(CONFIG_POSTCAR_CONSOLE) += printk.c
postcar-$(CONFIG_POSTCAR_CONSOLE) += init.c console.c
postcar-y += post.c
postcar-y += die.c
bootblock-$(CONFIG_BOOTBLOCK_CONSOLE) += printk.c
bootblock-y += vtxprintf.c vsprintf.c
bootblock-$(CONFIG_BOOTBLOCK_CONSOLE) += init.c console.c
bootblock-y += post.c
bootblock-y += die.c
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>
2018-05-16 23:14:04 +02:00
decompressor-y += die.c