summaryrefslogtreecommitdiff
path: root/src/lib/program.ld
AgeCommit message (Collapse)Author
2021-01-07arch/x86: Move prologue to .init sectionKyösti Mälkki
For arch/x86 the realmode part has to be located within the same 64 KiB as the reset vector. Some older intel platforms also require 4 KiB alignment for _start16bit. To enforce the above, and to separate required parts of .text without matching *(.text.*) rules in linker scripts, tag the pre-C environment assembly code with section .init directive. Description of .init section for ELF: This section holds executable instructions that contribute to the process initialization code. When a program starts to run, the system arranges to execute the code in this section before calling the main program entry point (called main for C programs). Change-Id: If32518b1c19d08935727330314904b52a246af3c Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/47599 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-12-17arch/arm: Replace .id section with build_info in CBFSKyösti Mälkki
For arch/arm[64], the offsets to board identification strings and CONFIG_ROM_SIZE inside .id were never really used; it was only a convenience to have the strings appear near the start of image. Add the same strings in an uncompressed file in CBFS. Change-Id: I35d3312336e9c66d657d2ca619cf30fd79e18fd4 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/47602 Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Julius Werner <jwerner@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-12-03cbfs: Add verification for RO CBFS metadata hashJulius Werner
This patch adds the first stage of the new CONFIG_CBFS_VERIFICATION feature. It's not useful to end-users in this stage so it cannot be selected in menuconfig (and should not be used other than for development) yet. With this patch coreboot can verify the metadata hash of the RO CBFS when it starts booting, but it does not verify individual files yet. Likewise, verifying RW CBFSes with vboot is not yet supported. Verification is bootstrapped from a "metadata hash anchor" structure that is embedded in the bootblock code and marked by a unique magic number. This anchor contains both the CBFS metadata hash and a separate hash for the FMAP which is required to find the primary CBFS. Both are verified on first use in the bootblock (and halt the system on failure). The CONFIG_TOCTOU_SAFETY option is also added for illustrative purposes to show some paths that need to be different when full protection against TOCTOU (time-of-check vs. time-of-use) attacks is desired. For normal verification it is sufficient to check the FMAP and the CBFS metadata hash only once in the bootblock -- for TOCTOU verification we do the same, but we need to be extra careful that we do not re-read the FMAP or any CBFS metadata in later stages. This is mostly achieved by depending on the CBFS metadata cache and FMAP cache features, but we allow for one edge case in case the RW CBFS metadata cache overflows (which may happen during an RW update and could otherwise no longer be fixed because mcache size is defined by RO code). This code is added to demonstrate design intent but won't really matter until RW CBFS verification can be supported. Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: I8930434de55eb938b042fdada9aa90218c0b5a34 Reviewed-on: https://review.coreboot.org/c/coreboot/+/41120 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2020-08-21lib: Add ASan support to ramstage on x86 archHarshit Sharma
This patch adds address sanitizer module to the library and reserves a linker section representing the shadow region for ramstage. Also, it adds an instruction to initialize shadow region on x86 architecture when ramstage is loaded. Change-Id: Ica06bd2be78fcfc79fa888721ed920d4e8248f3b Signed-off-by: Harshit Sharma <harshitsharmajs@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/42496 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
2020-06-10lib/program.ld: Replace CONFIG(ARCH_xx) testsKyösti Mälkki
Once we support building stages for different architectures, such CONFIG(ARCH_xx) tests do not evaluate correctly anymore. For x86 we define .id linking explicitly elsewhere. Change-Id: I43f849465e985068cd0b8a1944213b7c26245b8d Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/42160 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2020-05-28arch/x86: Remove more romcc leftoversKyösti Mälkki
The sections .rom.* were for romcc and no longer used. Some romcc comments were left behind when guards were removed. Change-Id: I060ad7af2f03c67946f9796e625c072b887280c1 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/37955 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2020-05-26Remove MAYBE_STATIC_BSS and ENV_STAGE_HAS_BSS_SECTIONKyösti Mälkki
After removal of CAR_MIGRATION there are no more reasons to carry around ENV_STAGE_HAS_BSS_SECTION=n case. Replace 'MAYBE_STATIC_BSS' with 'static' and remove explicit zero-initializers. Change-Id: I14dd9f52da5b06f0116bd97496cf794e5e71bc37 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/40535 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Furquan Shaikh <furquan@google.com>
2020-05-11treewide: Remove "this file is part of" linesPatrick Georgi
Stefan thinks they don't add value. Command used: sed -i -e '/file is part of /d' $(git grep "file is part of " |egrep ":( */\*.*\*/\$|#|;#|-- | *\* )" | cut -d: -f1 |grep -v crossgcc |grep -v gcov | grep -v /elf.h |grep -v nvramtool) The exceptions are for: - crossgcc (patch file) - gcov (imported from gcc) - elf.h (imported from GNU's libc) - nvramtool (more complicated header) The removed lines are: - fmt.Fprintln(f, "/* This file is part of the coreboot project. */") -# This file is part of a set of unofficial pre-commit hooks available -/* This file is part of coreboot */ -# This file is part of msrtool. -/* This file is part of msrtool. */ - * This file is part of ncurses, designed to be appended after curses.h.in -/* This file is part of pgtblgen. */ - * This file is part of the coreboot project. - /* This file is part of the coreboot project. */ -# This file is part of the coreboot project. -# This file is part of the coreboot project. -## This file is part of the coreboot project. --- This file is part of the coreboot project. -/* This file is part of the coreboot project */ -/* This file is part of the coreboot project. */ -;## This file is part of the coreboot project. -# This file is part of the coreboot project. It originated in the - * This file is part of the coreinfo project. -## This file is part of the coreinfo project. - * This file is part of the depthcharge project. -/* This file is part of the depthcharge project. */ -/* This file is part of the ectool project. */ - * This file is part of the GNU C Library. - * This file is part of the libpayload project. -## This file is part of the libpayload project. -/* This file is part of the Linux kernel. */ -## This file is part of the superiotool project. -/* This file is part of the superiotool project */ -/* This file is part of uio_usbdebug */ Change-Id: I82d872b3b337388c93d5f5bf704e9ee9e53ab3a9 Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41194 Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-04-04src/lib: Use SPDX for GPL-2.0-only filesAngel Pons
Done with sed and God Lines. Only done for C-like code for now. Change-Id: Id3a0b63272ebda3dad13803700bcff36d36f4815 Signed-off-by: Angel Pons <th3fanbus@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/40054 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2020-03-17src (minus soc and mainboard): Remove copyright noticesPatrick Georgi
They're listed in AUTHORS and often incorrect anyway, for example: - What's a "Copyright $year-present"? - Which incarnation of Google (Inc, LLC, ...) is the current copyright holder? - People sometimes have their editor auto-add themselves to files even though they only deleted stuff - Or they let the editor automatically update the copyright year, because why not? - Who is the copyright holder "The coreboot project Authors"? - Or "Generated Code"? Sidestep all these issues by simply not putting these notices in individual files, let's list all copyright holders in AUTHORS instead and use the git history to deal with the rest. Change-Id: I89b10076e0f4a4b3acd59160fb7abe349b228321 Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/39611 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: David Hendricks <david.hendricks@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-09-14src/: Replace some __PRE_RAM__ useKyösti Mälkki
Change-Id: Iaa56e7b98aad33eeb876edd7465c56c80fd1ac18 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/35398 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2019-08-26arch/x86: Simplify <arch/early_variables.h>Kyösti Mälkki
This enables the use of .bss section for ENV_BOOTBLOCK and ENV_VERSTAGE even with CAR_GLOBAL_MIGRATION=y. In practice, boards with CAR_GLOBAL_MIGRATION=y currently build with romcc-bootblock so they will not be using .bss. Change-Id: Ie9dc14f3e528d3e4f48304f4d7de50df448a8af6 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/35016 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2019-08-26Move and rename ARCH_STAGE_HAS_xxx_SECTION rulesKyösti Mälkki
Currently only x86 requires special handling here, for simplicity avoid introducing <arch/rules.h> and deal with this directly in <rules.h>. For consistency prefixes are changed from ARCH_ to ENV_. Change-Id: I95a56dbad3482202f6cc03043589bebfb13c39af Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/35014 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2019-03-08coreboot: Replace all IS_ENABLED(CONFIG_XXX) with CONFIG(XXX)Julius Werner
This patch is a raw application of find src/ -type f | xargs sed -i -e 's/IS_ENABLED\s*(CONFIG_/CONFIG(/g' Change-Id: I6262d6d5c23cabe23c242b4f38d446b74fe16b88 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/31774 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2018-05-22Introduce bootblock self-decompressionJulius Werner
Masked ROMs are the silent killers of boot speed on devices without memory-mapped SPI flash. They often contain awfully slow SPI drivers (presumably bit-banged) that take hundreds of milliseconds to load our bootblock, and every extra kilobyte of bootblock size has a hugely disproportionate impact on boot speed. The coreboot timestamps can never show that component, but it impacts our users all the same. This patch tries to alleviate that issue a bit by allowing us to compress the bootblock with LZ4, which can cut its size down to nearly half. Of course, masked ROMs usually don't come with decompression algorithms built in, so we need to introduce a little decompression stub that can decompress the rest of the bootblock. This is done by creating a new "decompressor" stage which runs before the bootblock, but includes the compressed bootblock code in its data section. It needs to be as small as possible to get a real benefit from this approach, which means no device drivers, no console output, no exception handling, etc. Besides the decompression algorithm itself we only include the timer driver so that we can measure the boot speed impact of decompression. On ARM and ARM64 systems, we also need to give SoC code a chance to initialize the MMU, since running decompression without MMU is prohibitively slow on these architectures. This feature is implemented for ARM and ARM64 architectures for now, although most of it is architecture-independent and it should be relatively simple to port to other platforms where a masked ROM loads the bootblock into SRAM. It is also supposed to be a clean starting point from which later optimizations can hopefully cut down the decompression stub size (currently ~4K on RK3399) a bit more. NOTE: Bootblock compression is not for everyone. Possible side effects include trying to run LZ4 on CPUs that come out of reset extremely underclocked or enabling this too early in SoC bring-up and getting frustrated trying to find issues in an undebuggable environment. Ask your SoC vendor if bootblock compression is right for you. Change-Id: I0dc1cad9ae7508892e477739e743cd1afb5945e8 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/26340 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2017-07-30lib/program.ld: Guard .id section placementNico Huber
For x86, we place the .id section at 4GiB - CONFIG_ID_SECTION_OFFSET. To take effect, we have to guard the conflicting default placement in `program.ld`. Also, as we only include the .id section into the boot- block, guard it by ENV_BOOTBLOCK too. Change-Id: Idc7cbd670ce4f75b7790ff8d95578683e355ba7e Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/20810 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
2016-10-31lib/program.ld: add .sdata sectionsAaron Durbin
Ron reported some toolchain emitting .sdata sections. Let's ensure we catch objects in those sections instead of getting dropped on the floor for architectures which emit those sections. Change-Id: I0680228f8424f99611914ef5fc31adf5d3891eee Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/17180 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2016-09-19arch/x86,lib: make cbmem console work in postcar stageAaron Durbin
Implement postcar stage cbmem console support. The postcar stage is more like ramstage in that RAM is already up. Therefore, in order to make the cbmem console reinit flow work one needs the cbmem init hook infrastructure in place and the cbmem recovery called. This call is added to x86/postcar.c to achieve that. Additionally, one needs to provide postcar stage cbmem init hook callbacks for the cbmem console library to use. A few other places need to become postcar stage aware so that the code paths are taken. Lastly, since postcar is backed by ram indicate that to the cbmem backing store. BUG=chrome-os-partner:57513 Change-Id: I51db65d8502c456b08f291fd1b59f6ea72059dfd Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/16619 Tested-by: build bot (Jenkins) Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2016-05-21program.ld: Don't exclude sbe region from verstageStefan Reinauer
This fixes compilation of coreboot on Glados Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org> BRANCH=none TEST=emerge-glados coreboot works again BUG=none Change-Id: Ibaae68192a3dc070c6ecf79223da4a1e1f18b352 Reviewed-on: https://chromium-review.googlesource.com/346198 Reviewed-by: Stefan Reinauer <reinauer@google.com> Commit-Queue: Stefan Reinauer <reinauer@google.com> Tested-by: Stefan Reinauer <reinauer@google.com> Reviewed-by: Luigi Semenzato <semenzato@chromium.org> (cherry picked from commit d7c2c72698e81b1410f9839c77be2e77b8ed83d6) Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://review.coreboot.org/14930 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: Duncan Laurie <dlaurie@google.com>
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>