coreboot-kgpe-d16/src/lib/bootblock.c

111 lines
3.1 KiB
C
Raw Normal View History

/*
* This file is part of the coreboot project.
*
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as
* published by the Free Software Foundation; version 2 of
* the License.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*/
#include <arch/exception.h>
#include <bootblock_common.h>
#include <console/console.h>
timer: Reestablish init_timer(), consolidate timer initialization calls We have known for a while that the old x86 model of calling init_timer() in ramstage doesn't make sense on other archs (and is questionable in general), and finally removed it with CL:219719. However, now timer initialization is completely buried in the platform code, and it's hard to ensure it is done in time to set up timestamps. For three out of four non-x86 SoC vendors we have brought up for now, the timers need some kind of SoC-specific initialization. This patch reintroduces init_timer() as a weak function that can be overridden by platform code. The call in ramstage is restricted to x86 (and should probably eventually be removed from there as well), and other archs should call them at the earliest reasonable point in their bootblock. (Only changing arm for now since arm64 and mips bootblocks are still in very early state and should sync up to features in arm once their requirements are better understood.) This allows us to move timestamp_init() into arch code, so that we can rely on timestamps being available at a well-defined point and initialize our base value as early as possible. (Platforms who know that their timers start at zero can still safely call timestamp_init(0) again from platform code.) BRANCH=None BUG=None TEST=Booted Pinky, Blaze and Storm, compiled Daisy and Pit. Change-Id: I1b064ba3831c0c5b7965b1d88a6f4a590789c891 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: ffaebcd3785c4ce998ac1536e9fdd46ce3f52bfa Original-Change-Id: Iece1614b7442d4fa9ca981010e1c8497bdea308d Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/234062 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9606 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2014-12-08 22:39:14 +01:00
#include <delay.h>
#include <option.h>
#include <pc80/mc146818rtc.h>
#include <program_loading.h>
#include <symbols.h>
#include <timestamp.h>
DECLARE_OPTIONAL_REGION(timestamp);
__weak void bootblock_mainboard_early_init(void) { /* no-op */ }
__weak void bootblock_soc_early_init(void) { /* do nothing */ }
__weak void bootblock_soc_init(void) { /* do nothing */ }
__weak void bootblock_mainboard_init(void) { /* do nothing */ }
ipq/arm: Redesign hooks for bootblock The following patches had to be squashed to properly build all the different ARM boards. ipq8064: storm: re-arrange bootblock initialization The recent addition of the storm bootblock initialization broke compilation of Exynos platforms. The SOC specific code needs to be kept in the respective source files, not in the common CPU code. As of now coreboot does not provide a separate SOC initialization API. In general it makes sense to invoke SOC initialization from the board initialization code, as the board knows what SOC it is running on. Presently all what's need initialization on 8064 is the timer. This patch adds the SOC initialization framework for 8064 and moves there the related code. BUG=chrome-os-partner:27784 TEST=manual . nyan_big, peach_pit, and storm targets build fine now. Original-Change-Id: Iae9a021f8cbf7d009770b02d798147a3e08420e8 Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/197835 (cherry picked from commit 3ea7307b531b1a78c692e4f71a0d81b32108ebf0) Signed-off-by: Marc Jones <marc.jones@se-eng.com> arm: Redesign mainboard and SoC hooks for bootblock This patch makes some slight changes to the way bootblock_cpu_init() and bootblock_mainboard_init() are used on ARM. Experience has shown that nearly every board needs either one or both of these hooks, so having explicit Kconfigs for them has become unwieldy. Instead, this patch implements them as a weak symbol that can be overridden by mainboard/SoC code, as the more recent arm64_soc_init() is also doing. Since the whole concept of a single "CPU" on ARM systems has kinda died out, rename bootblock_cpu_init() to bootblock_soc_init(). (This had already been done on Storm/ipq806x, which is now adjusted to directly use the generic hook.) Also add a proper license header to bootblock_common.h that was somehow missing. Leaving non-ARM32 architectures out for now, since they are still using the really old and weird x86 model of directly including a file. These architectures should also eventually be aligned with the cleaner ARM32 model as they mature. BRANCH=None BUG=chrome-os-partner:32123 TEST=Booted on Pinky. Compiled for Storm and confirmed in the disassembly that bootblock_soc_init() is still compiled in and called right before the (now no-op) bootblock_mainboard_init(). Original-Change-Id: I57013b99c3af455cc3d7e78f344888d27ffb8d79 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/231940 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> (cherry picked from commit 257aaee9e3aeeffe50ed54de7342dd2bc9baae76) Signed-off-by: Marc Jones <marc.jones@se-eng.com> Change-Id: Id055fe60a8caf63a9787138811dc69ac04dfba57 Reviewed-on: http://review.coreboot.org/7879 Reviewed-by: David Hendricks <dhendrix@chromium.org> Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2014-04-23 20:09:44 +02:00
/*
* This is a the same as the bootblock main(), with the difference that it does
* not collect a timestamp. Instead it accepts the initial timestamp and
* possibly additional timestamp entries as arguments. This can be used in cases
* where earlier stamps are available. Note that this function is designed to be
* entered from C code. This function assumes that the timer has already been
* initialized, so it does not call init_timer().
*/
static void bootblock_main_with_timestamp(uint64_t base_timestamp,
struct timestamp_entry *timestamps, size_t num_timestamps)
{
/* Initialize timestamps if we have TIMESTAMP region in memlayout.ld. */
if (CONFIG(COLLECT_TIMESTAMPS) &&
REGION_SIZE(timestamp) > 0) {
int i;
timestamp_init(base_timestamp);
for (i = 0; i < num_timestamps; i++)
timestamp_add(timestamps[i].entry_id,
timestamps[i].entry_stamp);
}
timer: Reestablish init_timer(), consolidate timer initialization calls We have known for a while that the old x86 model of calling init_timer() in ramstage doesn't make sense on other archs (and is questionable in general), and finally removed it with CL:219719. However, now timer initialization is completely buried in the platform code, and it's hard to ensure it is done in time to set up timestamps. For three out of four non-x86 SoC vendors we have brought up for now, the timers need some kind of SoC-specific initialization. This patch reintroduces init_timer() as a weak function that can be overridden by platform code. The call in ramstage is restricted to x86 (and should probably eventually be removed from there as well), and other archs should call them at the earliest reasonable point in their bootblock. (Only changing arm for now since arm64 and mips bootblocks are still in very early state and should sync up to features in arm once their requirements are better understood.) This allows us to move timestamp_init() into arch code, so that we can rely on timestamps being available at a well-defined point and initialize our base value as early as possible. (Platforms who know that their timers start at zero can still safely call timestamp_init(0) again from platform code.) BRANCH=None BUG=None TEST=Booted Pinky, Blaze and Storm, compiled Daisy and Pit. Change-Id: I1b064ba3831c0c5b7965b1d88a6f4a590789c891 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: ffaebcd3785c4ce998ac1536e9fdd46ce3f52bfa Original-Change-Id: Iece1614b7442d4fa9ca981010e1c8497bdea308d Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/234062 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9606 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2014-12-08 22:39:14 +01:00
timestamp_add_now(TS_START_BOOTBLOCK);
bootblock_soc_early_init();
2014-11-25 22:22:20 +01:00
bootblock_mainboard_early_init();
if (CONFIG(USE_OPTION_TABLE))
sanitize_cmos();
if (CONFIG(CMOS_POST))
cmos_post_init();
if (CONFIG(BOOTBLOCK_CONSOLE)) {
console_init();
exception_init();
}
2014-11-25 22:22:20 +01:00
bootblock_soc_init();
bootblock_mainboard_init();
timestamp_add_now(TS_END_BOOTBLOCK);
run_romstage();
}
void bootblock_main_with_basetime(uint64_t base_timestamp)
{
bootblock_main_with_timestamp(base_timestamp, NULL, 0);
}
void main(void)
{
uint64_t base_timestamp = 0;
init_timer();
if (CONFIG(COLLECT_TIMESTAMPS))
base_timestamp = timestamp_get();
bootblock_main_with_timestamp(base_timestamp, NULL, 0);
}
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
#if CONFIG(COMPRESS_BOOTBLOCK)
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
/*
* 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