GNUBoot/coreboot-kgpe-d16
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity
coreboot-kgpe-d16/src/lib/rmodule.ld

112 lines
2.4 KiB
Text
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 linker script is used to link rmodules (relocatable modules). It
* links at zero so that relocation fixups are easy when placing the binaries
* anywhere in the address space.
*
* NOTE: The program's loadable sections (text, module_params, and data) are
rmodules: use rmodtool to create rmodules Start using the rmodtool for generating rmodules. rmodule_link() has been changed to create 2 rules: one for the passed in <name>, the other for creating <name>.rmod which is an ELF file in the format of an rmodule. Since the header is not compiled and linked together with an rmodule there needs to be a way of marking which symbol is the entry point. __rmodule_entry is the symbol used for knowing the entry point. There was a little churn in SMM modules to ensure an rmodule entry point symbol takes a single argument. Change-Id: Ie452ed866f6596bf13f137f5b832faa39f48d26e Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/5379 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins)
2014-03-10 22:13:58 +01:00
* packed into the flat blob. The rmodule loader assumes the entire program
* resides in one contiguous address space. Therefore, alignment for a given
* section (if required) needs to be done at the end of the preceeding section.
* e.g. if the data section should be aligned to an 8 byte address the text
* section should have ALIGN(8) at the end of its section. Otherwise there
* won't be a consistent mapping between the flat blob and the loaded program.
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
*/
BASE_ADDRESS = 0x00000;
coreboot: x86: enable gc-sections Garbage collected sections allow for trimming the size of the binaries as well as allowing for not needing to config off unused functions. To that end, on a rambi build the following differences are observed: $ diff -up \ <(readelf -l coreboot-builds/google_rambi/cbfs/fallback/ramstage.elf) \ <(readelf -l coreboot-builds/google_rambi_gc_sections/cbfs/fallback/ramstage.elf) --- /dev/fd/63 2015-03-10 12:07:27.927985430 -0500 +++ /dev/fd/62 2015-03-10 12:07:27.927985430 -0500 @@ -6,9 +6,9 @@ There are 4 program headers, starting at Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x001000 0x00000000 0x00000000 0x00040 0x00040 RWE 0 - LOAD 0x001040 0x00000040 0x00000040 0x34560 0x34560 RWE 0 - LOAD 0x0355a0 0x000345a0 0x000345a0 0x02578 0x02578 RWE 0 - LOAD 0x037b18 0x00036b18 0x00036b18 0x00000 0x0b560 0 + LOAD 0x001040 0x00000040 0x00000040 0x2cbf8 0x2cbf8 RWE 0 + LOAD 0x02dc38 0x0002cc38 0x0002cc38 0x02208 0x02208 RWE 0 + LOAD 0x02fe40 0x0002ee40 0x0002ee40 0x00000 0x0a888 0 Section to Segment mapping: Segment Sections... $ diff -up \ <(readelf -l coreboot-builds/google_rambi/cbfs/fallback/romstage.elf) \ <(readelf -l coreboot-builds/google_rambi_gc_sections/cbfs/fallback/romstage.elf) --- /dev/fd/63 2015-03-10 12:08:16.855985880 -0500 +++ /dev/fd/62 2015-03-10 12:08:16.851985880 -0500 @@ -5,8 +5,8 @@ There are 1 program headers, starting at Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align - LOAD 0x000060 0xfff20000 0xfff20000 0x08b81 0x08b81 R E 0x10 + LOAD 0x000060 0xfff20000 0xfff20000 0x06300 0x06300 R E 0x10 Section to Segment mapping: Segment Sections... - 00 .rom .text + 00 .rom The following warnings needed to be applied to CFLAGS_common because for some reason gcc was miraculously emitting the warnings with the unrelated *-sections options: -Wno-unused-but-set-variable Change-Id: I210784fdfc273ce4cb9927352cbd5a51be3c6929 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/8635 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2015-03-10 17:45:25 +01:00
ENTRY(__rmodule_entry);
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
SECTIONS
{
. = BASE_ADDRESS;
rmodules: use rmodtool to create rmodules Start using the rmodtool for generating rmodules. rmodule_link() has been changed to create 2 rules: one for the passed in <name>, the other for creating <name>.rmod which is an ELF file in the format of an rmodule. Since the header is not compiled and linked together with an rmodule there needs to be a way of marking which symbol is the entry point. __rmodule_entry is the symbol used for knowing the entry point. There was a little churn in SMM modules to ensure an rmodule entry point symbol takes a single argument. Change-Id: Ie452ed866f6596bf13f137f5b832faa39f48d26e Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/5379 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins)
2014-03-10 22:13:58 +01:00
.payload : {
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
/* C code of the module. */
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
_program = .;
*(.text._start);
*(.text.stage_entry);
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
*(.text);
*(.text.*);
/* C read-only data. */
. = ALIGN(16);
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
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
#ifdef CONFIG_COVERAGE
rmodule: align ld script with latest x86 ld script The x86 linker script added a .textfirst section. In order to properly link ramstage as a relocatable module the .textfirst section needs to be included. Also, the support for code coverage was added by including the constructor section and symbols. Coverage has not been tested as I suspect it might not work in a relocatable environment without some tweaking. However, the section and symbols are there if needed. Change-Id: Ie1f6d987d6eb657ed4aa3a8918b2449dafaf9463 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2883 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-23 01:55:35 +01:00
__CTOR_LIST__ = .;
*(.ctors);
LONG(0);
rmodule: Fix rmodule.ld for 64-bit Fix the alignment for 64-bit systems Change-Id: I7fcb1683d760b96307759b7d44d8770dd49a02e3 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://chromium-review.googlesource.com/214326 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: Furquan Shaikh <furquan@chromium.org> Commit-Queue: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/6953 Reviewed-by: Aaron Durbin <adurbin@google.com> Tested-by: build bot (Jenkins)
2014-08-27 00:01:41 +02:00
LONG(0);
rmodule: align ld script with latest x86 ld script The x86 linker script added a .textfirst section. In order to properly link ramstage as a relocatable module the .textfirst section needs to be included. Also, the support for code coverage was added by including the constructor section and symbols. Coverage has not been tested as I suspect it might not work in a relocatable environment without some tweaking. However, the section and symbols are there if needed. Change-Id: Ie1f6d987d6eb657ed4aa3a8918b2449dafaf9463 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2883 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-23 01:55:35 +01:00
__CTOR_END__ = .;
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
#endif
rmodule: align ld script with latest x86 ld script The x86 linker script added a .textfirst section. In order to properly link ramstage as a relocatable module the .textfirst section needs to be included. Also, the support for code coverage was added by including the constructor section and symbols. Coverage has not been tested as I suspect it might not work in a relocatable environment without some tweaking. However, the section and symbols are there if needed. Change-Id: Ie1f6d987d6eb657ed4aa3a8918b2449dafaf9463 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2883 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-23 01:55:35 +01:00
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
/* The driver sections are to allow linking coreboot's
* ramstage with the rmodule linker. Any changes made in
Rename coreboot_ram stage to ramstage Rename coreboot_ram stage to ramstage. This is done in order to provide consistency with other stage names (bootblock, romstage) and to allow any Makefile rule generalization, required for patches to be submitted later. Change-Id: Ib66e43b7e17b9c48b2d099670ba7e7d857673386 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: http://review.coreboot.org/5567 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2014-04-22 19:41:05 +02:00
* ramstage.ld should be made here as well. */
rmodule: Fix rmodule.ld for 64-bit Fix the alignment for 64-bit systems Change-Id: I7fcb1683d760b96307759b7d44d8770dd49a02e3 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://chromium-review.googlesource.com/214326 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: Furquan Shaikh <furquan@chromium.org> Commit-Queue: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/6953 Reviewed-by: Aaron Durbin <adurbin@google.com> Tested-by: build bot (Jenkins)
2014-08-27 00:01:41 +02:00
. = ALIGN(8);
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
pci_drivers = . ;
coreboot: x86: enable gc-sections Garbage collected sections allow for trimming the size of the binaries as well as allowing for not needing to config off unused functions. To that end, on a rambi build the following differences are observed: $ diff -up \ <(readelf -l coreboot-builds/google_rambi/cbfs/fallback/ramstage.elf) \ <(readelf -l coreboot-builds/google_rambi_gc_sections/cbfs/fallback/ramstage.elf) --- /dev/fd/63 2015-03-10 12:07:27.927985430 -0500 +++ /dev/fd/62 2015-03-10 12:07:27.927985430 -0500 @@ -6,9 +6,9 @@ There are 4 program headers, starting at Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x001000 0x00000000 0x00000000 0x00040 0x00040 RWE 0 - LOAD 0x001040 0x00000040 0x00000040 0x34560 0x34560 RWE 0 - LOAD 0x0355a0 0x000345a0 0x000345a0 0x02578 0x02578 RWE 0 - LOAD 0x037b18 0x00036b18 0x00036b18 0x00000 0x0b560 0 + LOAD 0x001040 0x00000040 0x00000040 0x2cbf8 0x2cbf8 RWE 0 + LOAD 0x02dc38 0x0002cc38 0x0002cc38 0x02208 0x02208 RWE 0 + LOAD 0x02fe40 0x0002ee40 0x0002ee40 0x00000 0x0a888 0 Section to Segment mapping: Segment Sections... $ diff -up \ <(readelf -l coreboot-builds/google_rambi/cbfs/fallback/romstage.elf) \ <(readelf -l coreboot-builds/google_rambi_gc_sections/cbfs/fallback/romstage.elf) --- /dev/fd/63 2015-03-10 12:08:16.855985880 -0500 +++ /dev/fd/62 2015-03-10 12:08:16.851985880 -0500 @@ -5,8 +5,8 @@ There are 1 program headers, starting at Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align - LOAD 0x000060 0xfff20000 0xfff20000 0x08b81 0x08b81 R E 0x10 + LOAD 0x000060 0xfff20000 0xfff20000 0x06300 0x06300 R E 0x10 Section to Segment mapping: Segment Sections... - 00 .rom .text + 00 .rom The following warnings needed to be applied to CFLAGS_common because for some reason gcc was miraculously emitting the warnings with the unrelated *-sections options: -Wno-unused-but-set-variable Change-Id: I210784fdfc273ce4cb9927352cbd5a51be3c6929 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/8635 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2015-03-10 17:45:25 +01:00
KEEP(*(.rodata.pci_driver));
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
epci_drivers = . ;
rmodule: Fix rmodule.ld for 64-bit Fix the alignment for 64-bit systems Change-Id: I7fcb1683d760b96307759b7d44d8770dd49a02e3 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://chromium-review.googlesource.com/214326 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: Furquan Shaikh <furquan@chromium.org> Commit-Queue: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/6953 Reviewed-by: Aaron Durbin <adurbin@google.com> Tested-by: build bot (Jenkins)
2014-08-27 00:01:41 +02:00
. = ALIGN(8);
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
cpu_drivers = . ;
coreboot: x86: enable gc-sections Garbage collected sections allow for trimming the size of the binaries as well as allowing for not needing to config off unused functions. To that end, on a rambi build the following differences are observed: $ diff -up \ <(readelf -l coreboot-builds/google_rambi/cbfs/fallback/ramstage.elf) \ <(readelf -l coreboot-builds/google_rambi_gc_sections/cbfs/fallback/ramstage.elf) --- /dev/fd/63 2015-03-10 12:07:27.927985430 -0500 +++ /dev/fd/62 2015-03-10 12:07:27.927985430 -0500 @@ -6,9 +6,9 @@ There are 4 program headers, starting at Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x001000 0x00000000 0x00000000 0x00040 0x00040 RWE 0 - LOAD 0x001040 0x00000040 0x00000040 0x34560 0x34560 RWE 0 - LOAD 0x0355a0 0x000345a0 0x000345a0 0x02578 0x02578 RWE 0 - LOAD 0x037b18 0x00036b18 0x00036b18 0x00000 0x0b560 0 + LOAD 0x001040 0x00000040 0x00000040 0x2cbf8 0x2cbf8 RWE 0 + LOAD 0x02dc38 0x0002cc38 0x0002cc38 0x02208 0x02208 RWE 0 + LOAD 0x02fe40 0x0002ee40 0x0002ee40 0x00000 0x0a888 0 Section to Segment mapping: Segment Sections... $ diff -up \ <(readelf -l coreboot-builds/google_rambi/cbfs/fallback/romstage.elf) \ <(readelf -l coreboot-builds/google_rambi_gc_sections/cbfs/fallback/romstage.elf) --- /dev/fd/63 2015-03-10 12:08:16.855985880 -0500 +++ /dev/fd/62 2015-03-10 12:08:16.851985880 -0500 @@ -5,8 +5,8 @@ There are 1 program headers, starting at Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align - LOAD 0x000060 0xfff20000 0xfff20000 0x08b81 0x08b81 R E 0x10 + LOAD 0x000060 0xfff20000 0xfff20000 0x06300 0x06300 R E 0x10 Section to Segment mapping: Segment Sections... - 00 .rom .text + 00 .rom The following warnings needed to be applied to CFLAGS_common because for some reason gcc was miraculously emitting the warnings with the unrelated *-sections options: -Wno-unused-but-set-variable Change-Id: I210784fdfc273ce4cb9927352cbd5a51be3c6929 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/8635 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2015-03-10 17:45:25 +01:00
KEEP(*(.rodata.cpu_driver));
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
ecpu_drivers = . ;
rmodule: Fix rmodule.ld for 64-bit Fix the alignment for 64-bit systems Change-Id: I7fcb1683d760b96307759b7d44d8770dd49a02e3 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://chromium-review.googlesource.com/214326 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: Furquan Shaikh <furquan@chromium.org> Commit-Queue: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/6953 Reviewed-by: Aaron Durbin <adurbin@google.com> Tested-by: build bot (Jenkins)
2014-08-27 00:01:41 +02:00
. = ALIGN(8);
boot state: schedule static callbacks Many of the boot state callbacks can be scheduled at compile time. Therefore, provide a way for a compilation unit to inform the boot state machine when its callbacks should be called. Each C module can export the callbacks and their scheduling requirements without changing the shared boot flow code. Change-Id: Ibc4cea4bd5ad45b2149c2d4aa91cbea652ed93ed Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3133 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-24 23:12:52 +02:00
_bs_init_begin = .;
coreboot: x86: enable gc-sections Garbage collected sections allow for trimming the size of the binaries as well as allowing for not needing to config off unused functions. To that end, on a rambi build the following differences are observed: $ diff -up \ <(readelf -l coreboot-builds/google_rambi/cbfs/fallback/ramstage.elf) \ <(readelf -l coreboot-builds/google_rambi_gc_sections/cbfs/fallback/ramstage.elf) --- /dev/fd/63 2015-03-10 12:07:27.927985430 -0500 +++ /dev/fd/62 2015-03-10 12:07:27.927985430 -0500 @@ -6,9 +6,9 @@ There are 4 program headers, starting at Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x001000 0x00000000 0x00000000 0x00040 0x00040 RWE 0 - LOAD 0x001040 0x00000040 0x00000040 0x34560 0x34560 RWE 0 - LOAD 0x0355a0 0x000345a0 0x000345a0 0x02578 0x02578 RWE 0 - LOAD 0x037b18 0x00036b18 0x00036b18 0x00000 0x0b560 0 + LOAD 0x001040 0x00000040 0x00000040 0x2cbf8 0x2cbf8 RWE 0 + LOAD 0x02dc38 0x0002cc38 0x0002cc38 0x02208 0x02208 RWE 0 + LOAD 0x02fe40 0x0002ee40 0x0002ee40 0x00000 0x0a888 0 Section to Segment mapping: Segment Sections... $ diff -up \ <(readelf -l coreboot-builds/google_rambi/cbfs/fallback/romstage.elf) \ <(readelf -l coreboot-builds/google_rambi_gc_sections/cbfs/fallback/romstage.elf) --- /dev/fd/63 2015-03-10 12:08:16.855985880 -0500 +++ /dev/fd/62 2015-03-10 12:08:16.851985880 -0500 @@ -5,8 +5,8 @@ There are 1 program headers, starting at Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align - LOAD 0x000060 0xfff20000 0xfff20000 0x08b81 0x08b81 R E 0x10 + LOAD 0x000060 0xfff20000 0xfff20000 0x06300 0x06300 R E 0x10 Section to Segment mapping: Segment Sections... - 00 .rom .text + 00 .rom The following warnings needed to be applied to CFLAGS_common because for some reason gcc was miraculously emitting the warnings with the unrelated *-sections options: -Wno-unused-but-set-variable Change-Id: I210784fdfc273ce4cb9927352cbd5a51be3c6929 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/8635 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2015-03-10 17:45:25 +01:00
KEEP(*(.bs_init));
bootstate: use structure pointers for scheduling callbacks The GCC 4.9.2 update showed that the boot_state_init_entry structures were being padded and assumed to be aligned in to an increased size. The bootstate scheduler for static entries, boot_state_schedule_static_entries(), was then calculating the wrong values within the array. To fix this just use a pointer to the boot_state_init_entry structure that needs to be scheduled. In addition to the previous issue noted above, the .bs_init section was sitting in the read only portion of the image while the fields within it need to be writable. Also, the boot_state_schedule_static_entries() was using symbol comparison to terminate a loop which in C can lead the compiler to always evaluate the loop at least once since the language spec indicates no 2 symbols can be the same value. Change-Id: I6dc5331c2979d508dde3cd5c3332903d40d8048b Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/8699 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-03-16 23:30:09 +01:00
LONG(0);
LONG(0);
boot state: schedule static callbacks Many of the boot state callbacks can be scheduled at compile time. Therefore, provide a way for a compilation unit to inform the boot state machine when its callbacks should be called. Each C module can export the callbacks and their scheduling requirements without changing the shared boot flow code. Change-Id: Ibc4cea4bd5ad45b2149c2d4aa91cbea652ed93ed Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3133 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-24 23:12:52 +02:00
_bs_init_end = .;
rmodule: Fix rmodule.ld for 64-bit Fix the alignment for 64-bit systems Change-Id: I7fcb1683d760b96307759b7d44d8770dd49a02e3 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://chromium-review.googlesource.com/214326 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: Furquan Shaikh <furquan@chromium.org> Commit-Queue: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/6953 Reviewed-by: Aaron Durbin <adurbin@google.com> Tested-by: build bot (Jenkins)
2014-08-27 00:01:41 +02:00
. = ALIGN(8);
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
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
*(.rodata);
*(.rodata.*);
rmodule: Fix rmodule.ld for 64-bit Fix the alignment for 64-bit systems Change-Id: I7fcb1683d760b96307759b7d44d8770dd49a02e3 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://chromium-review.googlesource.com/214326 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: Furquan Shaikh <furquan@chromium.org> Commit-Queue: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/6953 Reviewed-by: Aaron Durbin <adurbin@google.com> Tested-by: build bot (Jenkins)
2014-08-27 00:01:41 +02:00
. = ALIGN(8);
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
/* The parameters section can be used to pass parameters
* to a module, however there has to be an prior agreement
* on how to interpret the parameters. */
_module_params_begin = .;
coreboot: x86: enable gc-sections Garbage collected sections allow for trimming the size of the binaries as well as allowing for not needing to config off unused functions. To that end, on a rambi build the following differences are observed: $ diff -up \ <(readelf -l coreboot-builds/google_rambi/cbfs/fallback/ramstage.elf) \ <(readelf -l coreboot-builds/google_rambi_gc_sections/cbfs/fallback/ramstage.elf) --- /dev/fd/63 2015-03-10 12:07:27.927985430 -0500 +++ /dev/fd/62 2015-03-10 12:07:27.927985430 -0500 @@ -6,9 +6,9 @@ There are 4 program headers, starting at Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x001000 0x00000000 0x00000000 0x00040 0x00040 RWE 0 - LOAD 0x001040 0x00000040 0x00000040 0x34560 0x34560 RWE 0 - LOAD 0x0355a0 0x000345a0 0x000345a0 0x02578 0x02578 RWE 0 - LOAD 0x037b18 0x00036b18 0x00036b18 0x00000 0x0b560 0 + LOAD 0x001040 0x00000040 0x00000040 0x2cbf8 0x2cbf8 RWE 0 + LOAD 0x02dc38 0x0002cc38 0x0002cc38 0x02208 0x02208 RWE 0 + LOAD 0x02fe40 0x0002ee40 0x0002ee40 0x00000 0x0a888 0 Section to Segment mapping: Segment Sections... $ diff -up \ <(readelf -l coreboot-builds/google_rambi/cbfs/fallback/romstage.elf) \ <(readelf -l coreboot-builds/google_rambi_gc_sections/cbfs/fallback/romstage.elf) --- /dev/fd/63 2015-03-10 12:08:16.855985880 -0500 +++ /dev/fd/62 2015-03-10 12:08:16.851985880 -0500 @@ -5,8 +5,8 @@ There are 1 program headers, starting at Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align - LOAD 0x000060 0xfff20000 0xfff20000 0x08b81 0x08b81 R E 0x10 + LOAD 0x000060 0xfff20000 0xfff20000 0x06300 0x06300 R E 0x10 Section to Segment mapping: Segment Sections... - 00 .rom .text + 00 .rom The following warnings needed to be applied to CFLAGS_common because for some reason gcc was miraculously emitting the warnings with the unrelated *-sections options: -Wno-unused-but-set-variable Change-Id: I210784fdfc273ce4cb9927352cbd5a51be3c6929 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/8635 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2015-03-10 17:45:25 +01:00
KEEP(*(.module_parameters));
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
_module_params_end = .;
rmodule: put all code/data bits in one section While debugging a crash it was discovered that ld was inserting address space for sections that were empty depending on section address boundaries. This led to the assumption breaking down that on-disk payload (code/data bits) was contiguous with the address space. When that assumption breaks down relocation updates change the wrong memory. Fix this by making the rmodule.ld linker script put all code/data bits into a payload section. Change-Id: Ib5df7941bbd64662090136e49d15a570a1c3e041 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3149 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins)
2013-04-29 20:53:41 +02:00
. = ALIGN(8);
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
rmodule: put all code/data bits in one section While debugging a crash it was discovered that ld was inserting address space for sections that were empty depending on section address boundaries. This led to the assumption breaking down that on-disk payload (code/data bits) was contiguous with the address space. When that assumption breaks down relocation updates change the wrong memory. Fix this by making the rmodule.ld linker script put all code/data bits into a payload section. Change-Id: Ib5df7941bbd64662090136e49d15a570a1c3e041 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3149 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins)
2013-04-29 20:53:41 +02:00
/* Data section. */
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
. = ALIGN(64); /* Mirror cache line alignment from ramstage. */
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
_sdata = .;
*(.data);
rmodule: add subsections to linker script Depending on the compiler options, subsections of the form of .section.subsection could be generated. Therefore, include those subsections for .bss, .sbss, and .data. Change-Id: I80dd64d8c62e7bc449ee2bbc0a22a941777e2ea6 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/5407 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
2014-03-25 20:53:28 +01:00
*(.data.*);
rmodule: Fix rmodule.ld for 64-bit Fix the alignment for 64-bit systems Change-Id: I7fcb1683d760b96307759b7d44d8770dd49a02e3 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://chromium-review.googlesource.com/214326 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: Furquan Shaikh <furquan@chromium.org> Commit-Queue: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/6953 Reviewed-by: Aaron Durbin <adurbin@google.com> Tested-by: build bot (Jenkins)
2014-08-27 00:01:41 +02:00
. = ALIGN(8);
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
_edata = .;
rmodule: put all code/data bits in one section While debugging a crash it was discovered that ld was inserting address space for sections that were empty depending on section address boundaries. This led to the assumption breaking down that on-disk payload (code/data bits) was contiguous with the address space. When that assumption breaks down relocation updates change the wrong memory. Fix this by making the rmodule.ld linker script put all code/data bits into a payload section. Change-Id: Ib5df7941bbd64662090136e49d15a570a1c3e041 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3149 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins)
2013-04-29 20:53:41 +02:00
. = ALIGN(8);
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
}
.bss (NOLOAD) : {
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
/* C uninitialized data of the module. */
_bss = .;
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
*(.bss);
rmodule: add subsections to linker script Depending on the compiler options, subsections of the form of .section.subsection could be generated. Therefore, include those subsections for .bss, .sbss, and .data. Change-Id: I80dd64d8c62e7bc449ee2bbc0a22a941777e2ea6 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/5407 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
2014-03-25 20:53:28 +01:00
*(.bss.*)
*(.sbss)
*(.sbss.*)
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
*(COMMON);
. = ALIGN(8);
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
_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
/*
* Place the heap after BSS. The heap size is passed in by
* by way of ld --defsym=__heap_size=<>
*/
_heap = .;
. = . + __heap_size;
_eheap = .;
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
_eprogram = .;
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
}
/DISCARD/ : {
rmodules: use rmodtool to create rmodules Start using the rmodtool for generating rmodules. rmodule_link() has been changed to create 2 rules: one for the passed in <name>, the other for creating <name>.rmod which is an ELF file in the format of an rmodule. Since the header is not compiled and linked together with an rmodule there needs to be a way of marking which symbol is the entry point. __rmodule_entry is the symbol used for knowing the entry point. There was a little churn in SMM modules to ensure an rmodule entry point symbol takes a single argument. Change-Id: Ie452ed866f6596bf13f137f5b832faa39f48d26e Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/5379 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins)
2014-03-10 22:13:58 +01:00
/* Drop unnecessary sections. */
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
*(.eh_frame);
src/lib/rmodule.ld: DISCARD (.note|.note.*) sections We have no need for these sections winding up in the build leading to possible overlaps, such as in the case of Clang builds. Discard sections from inclusion into the resulting binary. Change-Id: Ie807e5809594dcc6e94660a64e359e3b2ca1a0f6 Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-on: http://review.coreboot.org/7439 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2014-11-12 01:52:56 +01:00
*(.note);
*(.note.*);
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
}
}
Reference in a new issue Copy permalink