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

251 lines
6.9 KiB
C
Raw Normal View History

/*
* This file is part of the coreboot project.
*
* Copyright (C) 2003 Eric W. Biederman <ebiederm@xmission.com>
* Copyright (C) 2009 Ron Minnich <rminnich@gmail.com>
* Copyright (C) 2016 George Trudeau <george.trudeau@usherbrooke.ca>
*
* 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 <commonlib/compression.h>
#include <commonlib/endian.h>
#include <console/console.h>
#include <cpu/cpu.h>
#include <stdint.h>
#include <stdlib.h>
#include <string.h>
New mechanism to define SRAM/memory map with automatic bounds checking This patch creates a new mechanism to define the static memory layout (primarily in SRAM) for a given board, superseding the brittle mass of Kconfigs that we were using before. The core part is a memlayout.ld file in the mainboard directory (although boards are expected to just include the SoC default in most cases), which is the primary linker script for all stages (though not rmodules for now). It uses preprocessor macros from <memlayout.h> to form a different valid linker script for all stages while looking like a declarative, boilerplate-free map of memory addresses to the programmer. Linker asserts will automatically guarantee that the defined regions cannot overlap. Stages are defined with a maximum size that will be enforced by the linker. The file serves to both define and document the memory layout, so that the documentation cannot go missing or out of date. The mechanism is implemented for all boards in the ARM, ARM64 and MIPS architectures, and should be extended onto all systems using SRAM in the future. The CAR/XIP environment on x86 has very different requirements and the layout is generally not as static, so it will stay like it is and be unaffected by this patch (save for aligning some symbol names for consistency and sharing the new common ramstage linker script include). BUG=None TEST=Booted normally and in recovery mode, checked suspend/resume and the CBMEM console on Falco, Blaze (both normal and vboot2), Pinky and Pit. Compiled Ryu, Storm and Urara, manually compared the disassemblies with ToT and looked for red flags. Change-Id: Ifd2276417f2036cbe9c056f17e42f051bcd20e81 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: f1e2028e7ebceeb2d71ff366150a37564595e614 Original-Change-Id: I005506add4e8fcdb74db6d5e6cb2d4cb1bd3cda5 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/213370 Reviewed-on: http://review.coreboot.org/9283 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Tauner <stefan.tauner@gmx.at> Reviewed-by: Aaron Durbin <adurbin@google.com>
2014-08-21 00:29:56 +02:00
#include <symbols.h>
#include <cbfs.h>
#include <lib.h>
#include <bootmem.h>
#include <program_loading.h>
#include <timestamp.h>
#include <cbmem.h>
/* Decode a serialized cbfs payload segment
* from memory into native endianness.
*/
static void cbfs_decode_payload_segment(struct cbfs_payload_segment *segment,
const struct cbfs_payload_segment *src)
{
segment->type = read_be32(&src->type);
segment->compression = read_be32(&src->compression);
segment->offset = read_be32(&src->offset);
segment->load_addr = read_be64(&src->load_addr);
segment->len = read_be32(&src->len);
segment->mem_len = read_be32(&src->mem_len);
}
selfboot: remove bounce buffers Bounce buffers used to be used in those cases where the payload might overlap coreboot. Bounce buffers are a problem for rampayloads as they need malloc. They are also an artifact of our x86 past before we had relocatable ramstage; only x86, out of the 5 architectures we support, needs them; currently they only seem to matter on the following chipsets: src/northbridge/amd/amdfam10/Kconfig src/northbridge/amd/lx/Kconfig src/northbridge/via/vx900/Kconfig src/soc/intel/fsp_baytrail/Kconfig src/soc/intel/fsp_broadwell_de/Kconfig The first three are obsolete or at least could be changed to avoid the need to have bounce buffers. The last two should change to no longer need them. In any event they can be fixed or pegged to a release which supports them. For these five chipsets we change CONFIG_RAMBASE from 0x100000 (the value needed in 1999 for the 32-bit Linux kernel, the original ramstage) to 0xe00000 (14 Mib) which will put the non-relocatable x86 ramstage out of the way of any reasonable payload until we can get rid of it for good. 14 MiB was chosen after some discussion, but it does fit well: o Fits in the 16 MiB cacheable range coreboot sets up by default o Most small payloads are well under 14 MiB (even kernels!) o Most large payloads get loaded at 16 MiB (especially kernels!) With this change in place coreboot correctly still loads a bzImage payload. Werner reports that the 0xe00000 setting works on his broadwell systems. Change-Id: I602feb32f35e8af1d0dc4ea9f25464872c9b824c Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-on: https://review.coreboot.org/28647 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2018-09-16 18:59:54 +02:00
static int segment_targets_usable_ram(void *dest, unsigned long memsz)
{
selfboot: remove bounce buffers Bounce buffers used to be used in those cases where the payload might overlap coreboot. Bounce buffers are a problem for rampayloads as they need malloc. They are also an artifact of our x86 past before we had relocatable ramstage; only x86, out of the 5 architectures we support, needs them; currently they only seem to matter on the following chipsets: src/northbridge/amd/amdfam10/Kconfig src/northbridge/amd/lx/Kconfig src/northbridge/via/vx900/Kconfig src/soc/intel/fsp_baytrail/Kconfig src/soc/intel/fsp_broadwell_de/Kconfig The first three are obsolete or at least could be changed to avoid the need to have bounce buffers. The last two should change to no longer need them. In any event they can be fixed or pegged to a release which supports them. For these five chipsets we change CONFIG_RAMBASE from 0x100000 (the value needed in 1999 for the 32-bit Linux kernel, the original ramstage) to 0xe00000 (14 Mib) which will put the non-relocatable x86 ramstage out of the way of any reasonable payload until we can get rid of it for good. 14 MiB was chosen after some discussion, but it does fit well: o Fits in the 16 MiB cacheable range coreboot sets up by default o Most small payloads are well under 14 MiB (even kernels!) o Most large payloads get loaded at 16 MiB (especially kernels!) With this change in place coreboot correctly still loads a bzImage payload. Werner reports that the 0xe00000 setting works on his broadwell systems. Change-Id: I602feb32f35e8af1d0dc4ea9f25464872c9b824c Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-on: https://review.coreboot.org/28647 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2018-09-16 18:59:54 +02:00
uintptr_t d = (uintptr_t) dest;
if (bootmem_region_targets_usable_ram(d, memsz))
return 1;
selfboot: remove bounce buffers Bounce buffers used to be used in those cases where the payload might overlap coreboot. Bounce buffers are a problem for rampayloads as they need malloc. They are also an artifact of our x86 past before we had relocatable ramstage; only x86, out of the 5 architectures we support, needs them; currently they only seem to matter on the following chipsets: src/northbridge/amd/amdfam10/Kconfig src/northbridge/amd/lx/Kconfig src/northbridge/via/vx900/Kconfig src/soc/intel/fsp_baytrail/Kconfig src/soc/intel/fsp_broadwell_de/Kconfig The first three are obsolete or at least could be changed to avoid the need to have bounce buffers. The last two should change to no longer need them. In any event they can be fixed or pegged to a release which supports them. For these five chipsets we change CONFIG_RAMBASE from 0x100000 (the value needed in 1999 for the 32-bit Linux kernel, the original ramstage) to 0xe00000 (14 Mib) which will put the non-relocatable x86 ramstage out of the way of any reasonable payload until we can get rid of it for good. 14 MiB was chosen after some discussion, but it does fit well: o Fits in the 16 MiB cacheable range coreboot sets up by default o Most small payloads are well under 14 MiB (even kernels!) o Most large payloads get loaded at 16 MiB (especially kernels!) With this change in place coreboot correctly still loads a bzImage payload. Werner reports that the 0xe00000 setting works on his broadwell systems. Change-Id: I602feb32f35e8af1d0dc4ea9f25464872c9b824c Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-on: https://review.coreboot.org/28647 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2018-09-16 18:59:54 +02:00
if (payload_arch_usable_ram_quirk(d, memsz))
return 1;
selfboot: remove bounce buffers Bounce buffers used to be used in those cases where the payload might overlap coreboot. Bounce buffers are a problem for rampayloads as they need malloc. They are also an artifact of our x86 past before we had relocatable ramstage; only x86, out of the 5 architectures we support, needs them; currently they only seem to matter on the following chipsets: src/northbridge/amd/amdfam10/Kconfig src/northbridge/amd/lx/Kconfig src/northbridge/via/vx900/Kconfig src/soc/intel/fsp_baytrail/Kconfig src/soc/intel/fsp_broadwell_de/Kconfig The first three are obsolete or at least could be changed to avoid the need to have bounce buffers. The last two should change to no longer need them. In any event they can be fixed or pegged to a release which supports them. For these five chipsets we change CONFIG_RAMBASE from 0x100000 (the value needed in 1999 for the 32-bit Linux kernel, the original ramstage) to 0xe00000 (14 Mib) which will put the non-relocatable x86 ramstage out of the way of any reasonable payload until we can get rid of it for good. 14 MiB was chosen after some discussion, but it does fit well: o Fits in the 16 MiB cacheable range coreboot sets up by default o Most small payloads are well under 14 MiB (even kernels!) o Most large payloads get loaded at 16 MiB (especially kernels!) With this change in place coreboot correctly still loads a bzImage payload. Werner reports that the 0xe00000 setting works on his broadwell systems. Change-Id: I602feb32f35e8af1d0dc4ea9f25464872c9b824c Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-on: https://review.coreboot.org/28647 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2018-09-16 18:59:54 +02:00
printk(BIOS_ERR, "SELF segment doesn't target RAM: 0x%p, %lu bytes\n", dest, memsz);
bootmem_dump_ranges();
return 0;
}
selfboot: remove bounce buffers Bounce buffers used to be used in those cases where the payload might overlap coreboot. Bounce buffers are a problem for rampayloads as they need malloc. They are also an artifact of our x86 past before we had relocatable ramstage; only x86, out of the 5 architectures we support, needs them; currently they only seem to matter on the following chipsets: src/northbridge/amd/amdfam10/Kconfig src/northbridge/amd/lx/Kconfig src/northbridge/via/vx900/Kconfig src/soc/intel/fsp_baytrail/Kconfig src/soc/intel/fsp_broadwell_de/Kconfig The first three are obsolete or at least could be changed to avoid the need to have bounce buffers. The last two should change to no longer need them. In any event they can be fixed or pegged to a release which supports them. For these five chipsets we change CONFIG_RAMBASE from 0x100000 (the value needed in 1999 for the 32-bit Linux kernel, the original ramstage) to 0xe00000 (14 Mib) which will put the non-relocatable x86 ramstage out of the way of any reasonable payload until we can get rid of it for good. 14 MiB was chosen after some discussion, but it does fit well: o Fits in the 16 MiB cacheable range coreboot sets up by default o Most small payloads are well under 14 MiB (even kernels!) o Most large payloads get loaded at 16 MiB (especially kernels!) With this change in place coreboot correctly still loads a bzImage payload. Werner reports that the 0xe00000 setting works on his broadwell systems. Change-Id: I602feb32f35e8af1d0dc4ea9f25464872c9b824c Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-on: https://review.coreboot.org/28647 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2018-09-16 18:59:54 +02:00
static int load_one_segment(uint8_t *dest,
uint8_t *src,
size_t len,
size_t memsz,
uint32_t compression,
int flags)
{
selfboot: remove bounce buffers Bounce buffers used to be used in those cases where the payload might overlap coreboot. Bounce buffers are a problem for rampayloads as they need malloc. They are also an artifact of our x86 past before we had relocatable ramstage; only x86, out of the 5 architectures we support, needs them; currently they only seem to matter on the following chipsets: src/northbridge/amd/amdfam10/Kconfig src/northbridge/amd/lx/Kconfig src/northbridge/via/vx900/Kconfig src/soc/intel/fsp_baytrail/Kconfig src/soc/intel/fsp_broadwell_de/Kconfig The first three are obsolete or at least could be changed to avoid the need to have bounce buffers. The last two should change to no longer need them. In any event they can be fixed or pegged to a release which supports them. For these five chipsets we change CONFIG_RAMBASE from 0x100000 (the value needed in 1999 for the 32-bit Linux kernel, the original ramstage) to 0xe00000 (14 Mib) which will put the non-relocatable x86 ramstage out of the way of any reasonable payload until we can get rid of it for good. 14 MiB was chosen after some discussion, but it does fit well: o Fits in the 16 MiB cacheable range coreboot sets up by default o Most small payloads are well under 14 MiB (even kernels!) o Most large payloads get loaded at 16 MiB (especially kernels!) With this change in place coreboot correctly still loads a bzImage payload. Werner reports that the 0xe00000 setting works on his broadwell systems. Change-Id: I602feb32f35e8af1d0dc4ea9f25464872c9b824c Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-on: https://review.coreboot.org/28647 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2018-09-16 18:59:54 +02:00
unsigned char *middle, *end;
printk(BIOS_DEBUG, "Loading Segment: addr: 0x%p memsz: 0x%016zx filesz: 0x%016zx\n",
dest, memsz, len);
/* Compute the boundaries of the segment */
end = dest + memsz;
/* Copy data from the initial buffer */
selfboot: remove bounce buffers Bounce buffers used to be used in those cases where the payload might overlap coreboot. Bounce buffers are a problem for rampayloads as they need malloc. They are also an artifact of our x86 past before we had relocatable ramstage; only x86, out of the 5 architectures we support, needs them; currently they only seem to matter on the following chipsets: src/northbridge/amd/amdfam10/Kconfig src/northbridge/amd/lx/Kconfig src/northbridge/via/vx900/Kconfig src/soc/intel/fsp_baytrail/Kconfig src/soc/intel/fsp_broadwell_de/Kconfig The first three are obsolete or at least could be changed to avoid the need to have bounce buffers. The last two should change to no longer need them. In any event they can be fixed or pegged to a release which supports them. For these five chipsets we change CONFIG_RAMBASE from 0x100000 (the value needed in 1999 for the 32-bit Linux kernel, the original ramstage) to 0xe00000 (14 Mib) which will put the non-relocatable x86 ramstage out of the way of any reasonable payload until we can get rid of it for good. 14 MiB was chosen after some discussion, but it does fit well: o Fits in the 16 MiB cacheable range coreboot sets up by default o Most small payloads are well under 14 MiB (even kernels!) o Most large payloads get loaded at 16 MiB (especially kernels!) With this change in place coreboot correctly still loads a bzImage payload. Werner reports that the 0xe00000 setting works on his broadwell systems. Change-Id: I602feb32f35e8af1d0dc4ea9f25464872c9b824c Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-on: https://review.coreboot.org/28647 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2018-09-16 18:59:54 +02:00
switch (compression) {
case CBFS_COMPRESS_LZMA: {
printk(BIOS_DEBUG, "using LZMA\n");
timestamp_add_now(TS_START_ULZMA);
len = ulzman(src, len, dest, memsz);
timestamp_add_now(TS_END_ULZMA);
if (!len) /* Decompression Error. */
return 0;
break;
}
case CBFS_COMPRESS_LZ4: {
printk(BIOS_DEBUG, "using LZ4\n");
timestamp_add_now(TS_START_ULZ4F);
len = ulz4fn(src, len, dest, memsz);
timestamp_add_now(TS_END_ULZ4F);
if (!len) /* Decompression Error. */
return 0;
break;
}
case CBFS_COMPRESS_NONE: {
printk(BIOS_DEBUG, "it's not compressed!\n");
memcpy(dest, src, len);
break;
}
default:
selfboot: remove bounce buffers Bounce buffers used to be used in those cases where the payload might overlap coreboot. Bounce buffers are a problem for rampayloads as they need malloc. They are also an artifact of our x86 past before we had relocatable ramstage; only x86, out of the 5 architectures we support, needs them; currently they only seem to matter on the following chipsets: src/northbridge/amd/amdfam10/Kconfig src/northbridge/amd/lx/Kconfig src/northbridge/via/vx900/Kconfig src/soc/intel/fsp_baytrail/Kconfig src/soc/intel/fsp_broadwell_de/Kconfig The first three are obsolete or at least could be changed to avoid the need to have bounce buffers. The last two should change to no longer need them. In any event they can be fixed or pegged to a release which supports them. For these five chipsets we change CONFIG_RAMBASE from 0x100000 (the value needed in 1999 for the 32-bit Linux kernel, the original ramstage) to 0xe00000 (14 Mib) which will put the non-relocatable x86 ramstage out of the way of any reasonable payload until we can get rid of it for good. 14 MiB was chosen after some discussion, but it does fit well: o Fits in the 16 MiB cacheable range coreboot sets up by default o Most small payloads are well under 14 MiB (even kernels!) o Most large payloads get loaded at 16 MiB (especially kernels!) With this change in place coreboot correctly still loads a bzImage payload. Werner reports that the 0xe00000 setting works on his broadwell systems. Change-Id: I602feb32f35e8af1d0dc4ea9f25464872c9b824c Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-on: https://review.coreboot.org/28647 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2018-09-16 18:59:54 +02:00
printk(BIOS_INFO, "CBFS: Unknown compression type %d\n", compression);
return 0;
}
/* Calculate middle after any changes to len. */
middle = dest + len;
printk(BIOS_SPEW, "[ 0x%08lx, %08lx, 0x%08lx) <- %08lx\n",
(unsigned long)dest,
(unsigned long)middle,
(unsigned long)end,
(unsigned long)src);
/* Zero the extra bytes between middle & end */
if (middle < end) {
printk(BIOS_DEBUG,
"Clearing Segment: addr: 0x%016lx memsz: 0x%016lx\n",
(unsigned long)middle,
(unsigned long)(end - middle));
/* Zero the extra bytes */
memset(middle, 0, end - middle);
}
/*
* Each architecture can perform additional operations
* on the loaded segment
*/
selfboot: remove bounce buffers Bounce buffers used to be used in those cases where the payload might overlap coreboot. Bounce buffers are a problem for rampayloads as they need malloc. They are also an artifact of our x86 past before we had relocatable ramstage; only x86, out of the 5 architectures we support, needs them; currently they only seem to matter on the following chipsets: src/northbridge/amd/amdfam10/Kconfig src/northbridge/amd/lx/Kconfig src/northbridge/via/vx900/Kconfig src/soc/intel/fsp_baytrail/Kconfig src/soc/intel/fsp_broadwell_de/Kconfig The first three are obsolete or at least could be changed to avoid the need to have bounce buffers. The last two should change to no longer need them. In any event they can be fixed or pegged to a release which supports them. For these five chipsets we change CONFIG_RAMBASE from 0x100000 (the value needed in 1999 for the 32-bit Linux kernel, the original ramstage) to 0xe00000 (14 Mib) which will put the non-relocatable x86 ramstage out of the way of any reasonable payload until we can get rid of it for good. 14 MiB was chosen after some discussion, but it does fit well: o Fits in the 16 MiB cacheable range coreboot sets up by default o Most small payloads are well under 14 MiB (even kernels!) o Most large payloads get loaded at 16 MiB (especially kernels!) With this change in place coreboot correctly still loads a bzImage payload. Werner reports that the 0xe00000 setting works on his broadwell systems. Change-Id: I602feb32f35e8af1d0dc4ea9f25464872c9b824c Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-on: https://review.coreboot.org/28647 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2018-09-16 18:59:54 +02:00
prog_segment_loaded((uintptr_t)dest, memsz, flags);
return 1;
}
/* Note: this function is a bit dangerous so is not exported.
* It assumes you're smart enough not to call it with the very
* last segment, since it uses seg + 1 */
static int last_loadable_segment(struct cbfs_payload_segment *seg)
{
return read_be32(&(seg + 1)->type) == PAYLOAD_SEGMENT_ENTRY;
}
static int load_payload_segments(
struct cbfs_payload_segment *cbfssegs,
int check_regions,
uintptr_t *entry)
{
uint8_t *dest, *src;
size_t filesz, memsz;
uint32_t compression;
struct cbfs_payload_segment *first_segment, *seg, segment;
int flags = 0;
for (first_segment = seg = cbfssegs;; ++seg) {
printk(BIOS_DEBUG, "Loading segment from ROM address 0x%p\n", seg);
cbfs_decode_payload_segment(&segment, seg);
dest = (uint8_t *)(uintptr_t)segment.load_addr;
memsz = segment.mem_len;
compression = segment.compression;
filesz = segment.len;
switch (segment.type) {
case PAYLOAD_SEGMENT_CODE:
case PAYLOAD_SEGMENT_DATA:
printk(BIOS_DEBUG, " %s (compression=%x)\n",
segment.type == PAYLOAD_SEGMENT_CODE
? "code" : "data", segment.compression);
src = ((uint8_t *)first_segment) + segment.offset;
printk(BIOS_DEBUG,
" New segment dstaddr 0x%p memsize 0x%zx srcaddr 0x%p filesize 0x%zx\n",
dest, memsz, src, filesz);
/* Clean up the values */
if (filesz > memsz) {
filesz = memsz;
printk(BIOS_DEBUG, " cleaned up filesize 0x%zx\n", filesz);
}
break;
case PAYLOAD_SEGMENT_BSS:
printk(BIOS_DEBUG, " BSS 0x%p (%d byte)\n", (void *)
(intptr_t)segment.load_addr, segment.mem_len);
filesz = 0;
src = ((uint8_t *)first_segment) + segment.offset;
compression = CBFS_COMPRESS_NONE;
break;
case PAYLOAD_SEGMENT_ENTRY:
printk(BIOS_DEBUG, " Entry Point 0x%p\n", (void *)
(intptr_t)segment.load_addr);
*entry = segment.load_addr;
/* Per definition, a payload always has the entry point
* as last segment. Thus, we use the occurrence of the
* entry point as break condition for the loop.
*/
return 0;
default:
/* We found something that we don't know about. Throw
* hands into the sky and run away!
*/
printk(BIOS_EMERG, "Bad segment type %x\n", segment.type);
return -1;
}
if (check_regions && !segment_targets_usable_ram(dest, memsz))
return -1;
/* Note that the 'seg + 1' is safe as we only call this
* function on "not the last" * items, since entry
* is always last. */
if (last_loadable_segment(seg))
flags = SEG_FINAL;
if (!load_one_segment(dest, src, filesz, memsz, compression, flags))
return -1;
}
return 1;
}
selfboot: remove bounce buffers Bounce buffers used to be used in those cases where the payload might overlap coreboot. Bounce buffers are a problem for rampayloads as they need malloc. They are also an artifact of our x86 past before we had relocatable ramstage; only x86, out of the 5 architectures we support, needs them; currently they only seem to matter on the following chipsets: src/northbridge/amd/amdfam10/Kconfig src/northbridge/amd/lx/Kconfig src/northbridge/via/vx900/Kconfig src/soc/intel/fsp_baytrail/Kconfig src/soc/intel/fsp_broadwell_de/Kconfig The first three are obsolete or at least could be changed to avoid the need to have bounce buffers. The last two should change to no longer need them. In any event they can be fixed or pegged to a release which supports them. For these five chipsets we change CONFIG_RAMBASE from 0x100000 (the value needed in 1999 for the 32-bit Linux kernel, the original ramstage) to 0xe00000 (14 Mib) which will put the non-relocatable x86 ramstage out of the way of any reasonable payload until we can get rid of it for good. 14 MiB was chosen after some discussion, but it does fit well: o Fits in the 16 MiB cacheable range coreboot sets up by default o Most small payloads are well under 14 MiB (even kernels!) o Most large payloads get loaded at 16 MiB (especially kernels!) With this change in place coreboot correctly still loads a bzImage payload. Werner reports that the 0xe00000 setting works on his broadwell systems. Change-Id: I602feb32f35e8af1d0dc4ea9f25464872c9b824c Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-on: https://review.coreboot.org/28647 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2018-09-16 18:59:54 +02:00
__weak int payload_arch_usable_ram_quirk(uint64_t start, uint64_t size)
{
return 0;
}
bool selfload(struct prog *payload, bool check_regions)
{
uintptr_t entry = 0;
selfboot: remove bounce buffers Bounce buffers used to be used in those cases where the payload might overlap coreboot. Bounce buffers are a problem for rampayloads as they need malloc. They are also an artifact of our x86 past before we had relocatable ramstage; only x86, out of the 5 architectures we support, needs them; currently they only seem to matter on the following chipsets: src/northbridge/amd/amdfam10/Kconfig src/northbridge/amd/lx/Kconfig src/northbridge/via/vx900/Kconfig src/soc/intel/fsp_baytrail/Kconfig src/soc/intel/fsp_broadwell_de/Kconfig The first three are obsolete or at least could be changed to avoid the need to have bounce buffers. The last two should change to no longer need them. In any event they can be fixed or pegged to a release which supports them. For these five chipsets we change CONFIG_RAMBASE from 0x100000 (the value needed in 1999 for the 32-bit Linux kernel, the original ramstage) to 0xe00000 (14 Mib) which will put the non-relocatable x86 ramstage out of the way of any reasonable payload until we can get rid of it for good. 14 MiB was chosen after some discussion, but it does fit well: o Fits in the 16 MiB cacheable range coreboot sets up by default o Most small payloads are well under 14 MiB (even kernels!) o Most large payloads get loaded at 16 MiB (especially kernels!) With this change in place coreboot correctly still loads a bzImage payload. Werner reports that the 0xe00000 setting works on his broadwell systems. Change-Id: I602feb32f35e8af1d0dc4ea9f25464872c9b824c Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-on: https://review.coreboot.org/28647 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2018-09-16 18:59:54 +02:00
struct cbfs_payload_segment *cbfssegs;
void *data;
data = rdev_mmap_full(prog_rdev(payload));
if (data == NULL)
return false;
selfboot: remove bounce buffers Bounce buffers used to be used in those cases where the payload might overlap coreboot. Bounce buffers are a problem for rampayloads as they need malloc. They are also an artifact of our x86 past before we had relocatable ramstage; only x86, out of the 5 architectures we support, needs them; currently they only seem to matter on the following chipsets: src/northbridge/amd/amdfam10/Kconfig src/northbridge/amd/lx/Kconfig src/northbridge/via/vx900/Kconfig src/soc/intel/fsp_baytrail/Kconfig src/soc/intel/fsp_broadwell_de/Kconfig The first three are obsolete or at least could be changed to avoid the need to have bounce buffers. The last two should change to no longer need them. In any event they can be fixed or pegged to a release which supports them. For these five chipsets we change CONFIG_RAMBASE from 0x100000 (the value needed in 1999 for the 32-bit Linux kernel, the original ramstage) to 0xe00000 (14 Mib) which will put the non-relocatable x86 ramstage out of the way of any reasonable payload until we can get rid of it for good. 14 MiB was chosen after some discussion, but it does fit well: o Fits in the 16 MiB cacheable range coreboot sets up by default o Most small payloads are well under 14 MiB (even kernels!) o Most large payloads get loaded at 16 MiB (especially kernels!) With this change in place coreboot correctly still loads a bzImage payload. Werner reports that the 0xe00000 setting works on his broadwell systems. Change-Id: I602feb32f35e8af1d0dc4ea9f25464872c9b824c Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-on: https://review.coreboot.org/28647 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2018-09-16 18:59:54 +02:00
cbfssegs = &((struct cbfs_payload *)data)->segments;
if (load_payload_segments(cbfssegs, check_regions, &entry))
goto out;
printk(BIOS_SPEW, "Loaded segments\n");
rdev_munmap(prog_rdev(payload), data);
/* Pass cbtables to payload if architecture desires it. */
prog_set_entry(payload, (void *)entry, cbmem_find(CBMEM_ID_CBTABLE));
return true;
out:
rdev_munmap(prog_rdev(payload), data);
return false;
}