summaryrefslogtreecommitdiff
path: root/src/lib/program.ld
AgeCommit message (Collapse)Author
2016-04-30lib/reg_script: Allow multiple independent handlersLee Leahy
Remove the platform_bus_table routine and replace it with a link time table. This allows the handlers to be spread across multiple modules without any one module knowing about all of the handlers. Establish number ranges for both the SOC and mainboard. TEST=Build and run on Galileo Gen2 Change-Id: I0823d443d3352f31ba7fa20845bbf550b585c86f Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com> Reviewed-on: https://review.coreboot.org/14554 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins)
2016-04-16program.ld: make sure that zeroptr isn't assigned to debug sectionsPatrick Georgi
Some ld versions seem to merge the .zeroptr section (NOLOAD, address 0) with some debug sections (NOLOAD, address 0) which makes the build explode when the debug sections are then stripped (including the zeroptr symbol). Just define zeroptr to be 0, no sections needed, to avoid this "optimization". Checked the objdump -dS of code using it that the accesses look sane. Change-Id: Ia7cb3e5eae87076caf479d5ae9155a02f74b5663 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/14344 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2016-03-23arch/x86: introduce postcar stage/phaseAaron Durbin
Certain chipsets don't have a memory-mapped boot media so their code execution for stages prior to DRAM initialization is backed by SRAM or cache-as-ram. The postcar stage/phase handles the cache-as-ram situation where in order to tear down cache-as-ram one needs to be executing out of a backing store that isn't transient. By current definition, cache-as-ram is volatile and tearing it down leads to its contents disappearing. Therefore provide a shim layer, postcar, that's loaded into memory and executed which does 2 things: 1. Tears down cache-as-ram with a chipset helper function. 2. Loads and runs ramstage. Because those 2 things are executed out of ram there's no issue of the code's backing store while executing the code that tears down cache-as-ram. The current implementation makes no assumption regarding cacheability of the DRAM itself. If the chipset code wishes to cache DRAM for loading of the postcar stage/phase then it's also up to the chipset to handle any coherency issues pertaining to cache-as-ram destruction. Change-Id: Ia58efdadd0b48f20cfe7de2f49ab462306c3a19b Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/14140 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com> Reviewed-by: Furquan Shaikh <furquan@google.com>
2016-01-28Provide a gcc-safe zero pointerPatrick Georgi
zeroptr is a linker object pointing at 0 that can be used to thwart GCC's (and other compilers') "dereferencing NULL is undefined" optimization strategy when it gets in the way. Change-Id: I6aa6f28283281ebae73d6349811e290bf1b99483 Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-on: https://review.coreboot.org/12294 Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com> Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2015-10-31tree: drop last paragraph of GPL copyright headerPatrick Georgi
It encourages users from writing to the FSF without giving an address. Linux also prefers to drop that and their checkpatch.pl (that we imported) looks out for that. This is the result of util/scripts/no-fsf-addresses.sh with no further editing. Change-Id: Ie96faea295fe001911d77dbc51e9a6789558fbd6 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/11888 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2015-09-28program.ld: terminate ALIGN statementPatrick Georgi
This fixes building with CONFIG_COVERAGE=y Change-Id: I5128ae0ef0d4f71e3ede7bcb3ee7ed7e265d1bb7 Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-on: http://review.coreboot.org/11729 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-09-22linking: link bootblock.elf with .data and .bss sections againAaron Durbin
Currently coreboot expects the loader to clear the bss section for all stages. i.e. stages don't clear their own bss. On ARM SoCs the BootROM would be responsible for this. To do that one needs to include the bss section data (all zeros) in the bootblock.bin file. This was previously being attempted by keeping the .bss info in the .data section because objcopy happened zero out non-file allocated data section data. Instead go back to linking bootblock with the bss section but mark the bss section as loadable allocatable data. That way it will be included in the binary properly when objcopy -O binary is emplyed. Also do the same for the data section in the case of no non-zero object values are in the data section. Without this change the trick of including .bss in .data was not working when there wasn't a non-zero value object in the data section. BUG=None BRANCH=None TEST=Built emulation/qemu-armv7 and noted bootblock.bin contains the cleared bss. Change-Id: I94bd404c2c4a8b9332393e6224e98940a9cad4a2 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/11680 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-09-17linking: Repair special treatments for non-x86 bootblocksJulius Werner
Patch b2a62622b (linking: move romstage and bootblock to use program.ld) unified the linker scripts between different stages. Unfortunately it omitted several special cases from the old bootblock.ld script that are required for non-x86 environments. This patch expands program.ld to once again merge the .BSS into the program image for bootblocks (ensuring correct initialization by the external loader). It also revives the .id section (which adds a human-readable blurb of information to the top of an image) and fixes a problem with unintended automated section alignment. BRANCH=None BUG=None TEST=Jerry and Oak boot again. Change-Id: I54271b8b59a9c773d858d676cde0218cb7f20e74 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 6fddbc00963e363039634fa31a9b66254b6cf18f Original-Change-Id: I4d748056f1ab29a8e730f861879982bdf4c33eab Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/299413 Original-Tested-by: Yidi Lin <yidi.lin@mediatek.com> Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/11660 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-09-09x86: link ramstage the same way regardless of RELOCATABLE_RAMSTAGEAaron Durbin
Previously there were 2 paths in linking ramstage. One was used for RELOCATABLE_RAMSTAGE while the other was fixed location. Now that rmodtool can handle multiple secitons for a single proram segment there's no need for linking ramstage using lib/rmodule.ld. That also means true rmodules don't have symbols required for ramstage purposes so fix memlayout.h. Lastly add default rules for creating rmod files from the known file names and locations. BUG=chrome-os-partner:44827 BRANCH=None TEST=Built rambi. Inspected ramstage.debug as well as rmodules created during the build. Change-Id: I98d249036c27cb4847512ab8bca5ea7b02ce04bd Signed-off-by: Aaron Durbin <adubin@chromium.org> Reviewed-on: http://review.coreboot.org/11524 Tested-by: build bot (Jenkins) Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-09-09rmodule: use program.ld for linkingAaron Durbin
Bring rmodule linking into the common linking method. The __rmodule_entry symbol was removed while using a more common _start symbol. The rmodtool will honor the entry point found within the ELF header. Add ENV_RMODULE so that one can distinguish the environment when generating linker scripts for rmodules. Lastly, directly use program.ld for the rmodule.ld linker script. BUG=chrome-os-partner:44827 BRANCH=None TEST=Built rambi and analyzed the relocatable ramstage, sipi_vector, and smm rmodules. Change-Id: Iaa499eb229d8171272add9ee6d27cff75e7534ac Signed-off-by: Aaron Durbin <adubin@chromium.org> Reviewed-on: http://review.coreboot.org/11517 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-09-09x86: link romstage like the other architecturesAaron Durbin
All the other architectures are using the memlayout for linking romstage. Use that same method on x86 as well for consistency. BUG=chrome-os-partner:44827 BRANCH=None TEST=Built a myriad of boards. Analyzed readelf output. Change-Id: I016666c4b01410df112e588c2949e3fc64540c2e Signed-off-by: Aaron Durbin <adubin@chromium.org> Reviewed-on: http://review.coreboot.org/11510 Tested-by: build bot (Jenkins) Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-09-09linking: lay the groundwork for a unified linking approachAaron Durbin
Though coreboot started as x86 only, the current approach to x86 linking is out of the norm with respect to other architectures. To start alleviating that the way ramstage is linked is partially unified. A new file, program.ld, was added to provide a common way to link stages by deferring to per-stage architectural overrides. The previous ramstage.ld is no longer required. Note that this change doesn't handle RELOCATABLE_RAMSTAGE because that is handled by rmodule.ld. Future convergence can be achieved, but for the time being that's being left out. BUG=chrome-os-partner:44827 BRANCH=None TEST=Built a myriad of boards. Change-Id: I5d689bfa7e0e9aff3a148178515ef241b5f70661 Signed-off-by: Aaron Durbin <adubin@chromium.org> Reviewed-on: http://review.coreboot.org/11507 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com> Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com> Reviewed-by: Julius Werner <jwerner@chromium.org>