| Age | Commit message (Collapse) | Author |
|---|
|
There is a need to calculate the proper placement for an rmodule
in memory. e.g. loading a compressed rmodule from flash into ram
can be an issue. Determining the placement is hard since the header
is not readable until it is decompressed so choosing the wrong location
may require a memmove() after decompression. This patch provides
a function to perform this calculation by finding region below a given
address while making an assumption on the size of the rmodule header..
Change-Id: I2703438f58ae847ed6e80b58063ff820fbcfcbc0
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2788
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
