summaryrefslogtreecommitdiff
path: root/README
diff options
context:
space:
mode:
authorAaron Durbin <adurbin@chromium.org>2012-12-24 14:28:37 -0600
committerRonald G. Minnich <rminnich@gmail.com>2013-03-18 18:40:34 +0100
commitad93552b86579afd29e99da1b2fcacb0d872cd1a (patch)
tree55a91404826f8c9e94ad2544295b94a981eb2fd6 /README
parent21efd8c0378a8a42ee2fd71957be318416b6f5af (diff)
downloadcoreboot-ad93552b86579afd29e99da1b2fcacb0d872cd1a.tar.xz
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>
Diffstat (limited to 'README')
0 files changed, 0 insertions, 0 deletions