summaryrefslogtreecommitdiff
path: root/src/lib/rmodule.c
AgeCommit message (Collapse)Author
2013-03-21rmodule: add ability to calculate module placementAaron Durbin
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>
2013-03-18lib: add rmodule supportAaron Durbin
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>