GNUBoot
/
coreboot-kgpe-d16
2
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
coreboot-kgpe-d16/src/include/rmodule.h

131 lines
4.2 KiB
C
Raw Normal View History

lib: add rmodule support A rmodule is short for relocation module. Relocaiton modules are standalone programs. These programs are linked at address 0 as a shared object with a special linker script that maintains the relocation entries for the object. These modules can then be embedded as a raw binary (objcopy -O binary) to be loaded at any location desired. Initially, the only arch support is for x86. All comments below apply to x86 specific properties. The intial user of this support would be for SMM handlers since those handlers sometimes need to be located at a dynamic address (e.g. TSEG region). The relocation entries are currently Elf32_Rel. They are 8 bytes large, and the entries are not necessarily in sorted order. An future optimization would be to have a tool convert the unsorted relocations into just sorted offsets. This would reduce the size of the blob produced after being processed. Essentialy, 8 bytes per relocation meta entry would reduce to 4 bytes. Change-Id: I2236dcb66e9d2b494ce2d1ae40777c62429057ef Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2692 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2012-12-24 21:28:37 +01:00
/*
* This file is part of the coreboot project.
*
* Copyright (C) 2012 ChromeOS Authors
*
* 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.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
*/
#ifndef RMODULE_H
#define RMODULE_H
#include <stdint.h>
#define RMODULE_MAGIC 0xf8fe
#define RMODULE_VERSION_1 1
enum {
RMODULE_TYPE_SMM,
rmodule: add rmodules class and new type Add an rmodules class so that there are default rules for compiling files that will be linked by the rmodule linker. Also, add a new type for SIPI vectors. Change-Id: Ided9e15577b34aff34dc23e5e16791c607caf399 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2751 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-01-12 07:41:44 +01:00
RMODULE_TYPE_SIPI_VECTOR,
rmodule: add ramstage support Coreboot's ramstage defines certain sections/symbols in its fixed static linker script. It uses these sections/symbols for locating the drivers as well as its own program information. Add these sections and symbols to the rmodule linker script so that ramstage can be linked as an rmodule. These sections and symbols are a noop for other rmodule-linked programs, but they are vital to the ramstage. Also add a comment in coreboot_ram.ld to mirror any changes made there to the rmodule linker script. Change-Id: Ib9885a00e987aef0ee1ae34f1d73066e15bca9b1 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2786 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2013-02-06 22:47:31 +01:00
RMODULE_TYPE_STAGE,
lib: add rmodule support A rmodule is short for relocation module. Relocaiton modules are standalone programs. These programs are linked at address 0 as a shared object with a special linker script that maintains the relocation entries for the object. These modules can then be embedded as a raw binary (objcopy -O binary) to be loaded at any location desired. Initially, the only arch support is for x86. All comments below apply to x86 specific properties. The intial user of this support would be for SMM handlers since those handlers sometimes need to be located at a dynamic address (e.g. TSEG region). The relocation entries are currently Elf32_Rel. They are 8 bytes large, and the entries are not necessarily in sorted order. An future optimization would be to have a tool convert the unsorted relocations into just sorted offsets. This would reduce the size of the blob produced after being processed. Essentialy, 8 bytes per relocation meta entry would reduce to 4 bytes. Change-Id: I2236dcb66e9d2b494ce2d1ae40777c62429057ef Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2692 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2012-12-24 21:28:37 +01:00
};
struct rmodule;
/* Public API for loading rmdoules. */
int rmodule_parse(void *ptr, struct rmodule *m);
void *rmodule_parameters(const struct rmodule *m);
void *rmodule_entry(const struct rmodule *m);
int rmodule_entry_offset(const struct rmodule *m);
int rmodule_memory_size(const struct rmodule *m);
int rmodule_load(void *loc, struct rmodule *m);
int rmodule_load_alignment(const struct rmodule *m);
#define FIELD_ENTRY(x_) ((u32)&x_)
#define RMODULE_HEADER(entry_, type_) \
{ \
.magic = RMODULE_MAGIC, \
.version = RMODULE_VERSION_1, \
.type = type_, \
.payload_begin_offset = FIELD_ENTRY(_payload_begin_offset), \
.payload_end_offset = FIELD_ENTRY(_payload_end_offset), \
.relocations_begin_offset = \
FIELD_ENTRY(_relocations_begin_offset), \
.relocations_end_offset = \
FIELD_ENTRY(_relocations_end_offset), \
.module_link_start_address = \
FIELD_ENTRY(_module_link_start_addr), \
.module_program_size = FIELD_ENTRY(_module_program_size), \
.module_entry_point = FIELD_ENTRY(entry_), \
.parameters_begin = FIELD_ENTRY(_module_params_begin), \
.parameters_end = FIELD_ENTRY(_module_params_end), \
rmodule: add ramstage support Coreboot's ramstage defines certain sections/symbols in its fixed static linker script. It uses these sections/symbols for locating the drivers as well as its own program information. Add these sections and symbols to the rmodule linker script so that ramstage can be linked as an rmodule. These sections and symbols are a noop for other rmodule-linked programs, but they are vital to the ramstage. Also add a comment in coreboot_ram.ld to mirror any changes made there to the rmodule linker script. Change-Id: Ib9885a00e987aef0ee1ae34f1d73066e15bca9b1 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2786 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2013-02-06 22:47:31 +01:00
.bss_begin = FIELD_ENTRY(_bss), \
.bss_end = FIELD_ENTRY(_ebss), \
lib: add rmodule support A rmodule is short for relocation module. Relocaiton modules are standalone programs. These programs are linked at address 0 as a shared object with a special linker script that maintains the relocation entries for the object. These modules can then be embedded as a raw binary (objcopy -O binary) to be loaded at any location desired. Initially, the only arch support is for x86. All comments below apply to x86 specific properties. The intial user of this support would be for SMM handlers since those handlers sometimes need to be located at a dynamic address (e.g. TSEG region). The relocation entries are currently Elf32_Rel. They are 8 bytes large, and the entries are not necessarily in sorted order. An future optimization would be to have a tool convert the unsorted relocations into just sorted offsets. This would reduce the size of the blob produced after being processed. Essentialy, 8 bytes per relocation meta entry would reduce to 4 bytes. Change-Id: I2236dcb66e9d2b494ce2d1ae40777c62429057ef Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2692 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2012-12-24 21:28:37 +01:00
}
#define DEFINE_RMODULE_HEADER(name_, entry_, type_) \
struct rmodule_header name_ \
__attribute__ ((section (".module_header"))) = \
RMODULE_HEADER(entry_, type_)
/* Private data structures below should not be used directly. */
/* All fields with '_offset' in the name are byte offsets into the flat blob.
* The linker and the linker script takes are of assigning the values. */
struct rmodule_header {
u16 magic;
u8 version;
u8 type;
/* The payload represents the program's loadable code and data. */
u32 payload_begin_offset;
u32 payload_end_offset;
/* Begin and of relocation information about the program module. */
u32 relocations_begin_offset;
u32 relocations_end_offset;
/* The starting address of the linked program. This address is vital
* for determining relocation offsets as the reloction info and other
* symbols (bss, entry point) need this value as a basis to calculate
* the offsets.
*/
u32 module_link_start_address;
/* The module_program_size is the size of memory used while running
* the program. The program is assumed to consume a contiguos amount
* of memory. */
u32 module_program_size;
/* This is program's execution entry point. */
u32 module_entry_point;
/* Optional paramter structure that can be used to pass data into
* the module. */
u32 parameters_begin;
u32 parameters_end;
/* BSS section information so the loader can clear the bss. */
u32 bss_begin;
u32 bss_end;
rmodule: add 16 bytes of padding There is a plan to utlize rmodules for loading ramstage as a relocatable module. However, the rmodule header may change. In order to provide some wiggle room for changing the contents of the rmodule header add some padding. This won't stop the need for coordinating properly between the romstage loader that may be in readonly flash and rmodule header fields. But it will provide for a way to make certain assumptions about alignment of the rmodule's program when the rmodule is compressed in the flash. Change-Id: I9ac5cf495c0bce494e7eaa3bd2f2bd39889b4c52 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2749 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-02-06 19:47:26 +01:00
/* Add some room for growth. */
u32 padding[4];
lib: add rmodule support A rmodule is short for relocation module. Relocaiton modules are standalone programs. These programs are linked at address 0 as a shared object with a special linker script that maintains the relocation entries for the object. These modules can then be embedded as a raw binary (objcopy -O binary) to be loaded at any location desired. Initially, the only arch support is for x86. All comments below apply to x86 specific properties. The intial user of this support would be for SMM handlers since those handlers sometimes need to be located at a dynamic address (e.g. TSEG region). The relocation entries are currently Elf32_Rel. They are 8 bytes large, and the entries are not necessarily in sorted order. An future optimization would be to have a tool convert the unsorted relocations into just sorted offsets. This would reduce the size of the blob produced after being processed. Essentialy, 8 bytes per relocation meta entry would reduce to 4 bytes. Change-Id: I2236dcb66e9d2b494ce2d1ae40777c62429057ef Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2692 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2012-12-24 21:28:37 +01:00
} __attribute__ ((packed));
struct rmodule {
void *location;
struct rmodule_header *header;
const void *payload;
int payload_size;
void *relocations;
};
/* These are the symbols assumed that every module contains. The linker script
* provides these symbols. */
extern char _relocations_begin_offset[];
extern char _relocations_end_offset[];
extern char _payload_end_offset[];
extern char _payload_begin_offset[];
rmodule: add ramstage support Coreboot's ramstage defines certain sections/symbols in its fixed static linker script. It uses these sections/symbols for locating the drivers as well as its own program information. Add these sections and symbols to the rmodule linker script so that ramstage can be linked as an rmodule. These sections and symbols are a noop for other rmodule-linked programs, but they are vital to the ramstage. Also add a comment in coreboot_ram.ld to mirror any changes made there to the rmodule linker script. Change-Id: Ib9885a00e987aef0ee1ae34f1d73066e15bca9b1 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2786 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2013-02-06 22:47:31 +01:00
extern char _bss[];
extern char _ebss[];
lib: add rmodule support A rmodule is short for relocation module. Relocaiton modules are standalone programs. These programs are linked at address 0 as a shared object with a special linker script that maintains the relocation entries for the object. These modules can then be embedded as a raw binary (objcopy -O binary) to be loaded at any location desired. Initially, the only arch support is for x86. All comments below apply to x86 specific properties. The intial user of this support would be for SMM handlers since those handlers sometimes need to be located at a dynamic address (e.g. TSEG region). The relocation entries are currently Elf32_Rel. They are 8 bytes large, and the entries are not necessarily in sorted order. An future optimization would be to have a tool convert the unsorted relocations into just sorted offsets. This would reduce the size of the blob produced after being processed. Essentialy, 8 bytes per relocation meta entry would reduce to 4 bytes. Change-Id: I2236dcb66e9d2b494ce2d1ae40777c62429057ef Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2692 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2012-12-24 21:28:37 +01:00
extern char _module_program_size[];
extern char _module_link_start_addr[];
extern char _module_params_begin[];
extern char _module_params_end[];
#endif /* RMODULE_H */