summaryrefslogtreecommitdiffstats
path: root/src/lib/program.ld
Commit message (Collapse)AuthorAgeFilesLines
* CBMEM: Change declarations for initialization hooksKyösti Mälkki2022-05-201-1/+1
| | | | | | | | | | | | | | | | | | There are efforts to have bootflows that do not follow a traditional bootblock-romstage-postcar-ramstage model. As part of that CBMEM initialisation hooks will need to move from romstage to bootblock. The interface towards platforms and drivers will change to use one of CBMEM_CREATION_HOOK() or CBMEM_READY_HOOK(). Former will only be called in the first stage with CBMEM available. Change-Id: Ie24bf4e818ca69f539196c3a814f3c52d4103d7e Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/63375 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Raul Rangel <rrangel@chromium.org>
* rules.h: Use more consistent namingArthur Heymans2022-05-161-2/+2
| | | | | | | | | | Use 'ENV' consistently and drop the redundant 'STAGE' in the naming. Change-Id: I51f2a7e70eefad12aa214e92f23e5fd2edf46698 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/64296 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Raul Rangel <rrangel@chromium.org>
* cbmem: Introduce "early" init hooks for consoleJulius Werner2021-05-271-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Over the last couple of years we have continuously added more and more CBMEM init hooks related to different independent components. One disadvantage of the API is that it can not model any dependencies between the different hooks, and their order is essentially undefined (based on link order). For most hooks this is not a problem, and in fact it's probably not a bad thing to discourage implicit dependencies between unrelated components like this... but one resource the components obviously all share is CBMEM, and since many CBMEM init hooks are used to create new CBMEM areas, the arbitrary order means that the order of these areas becomes unpredictable. Generally code using CBMEM should not care where exactly an area is allocated, but one exception is the persistent CBMEM console which relies (on a best effort basis) on always getting allocated at the same address on every boot. This is, technically, a hack, but it's a pretty harmless hack that has served us reasonably well so far and would be difficult to realize in a more robust way (without adding a lot of new infrastructure). Most of the time, coreboot will allocate the same CBMEM areas in the same order with the same sizes on every boot, and this all kinda works out (and since it's only a debug console, we don't need to be afraid of the odd one-in-a-million edge case breaking it). But one reproducible difference we can have between boots is the vboot boot mode (e.g. normal vs. recovery boot), and we had just kinda gotten lucky in the past that we didn't have differences in CBMEM allocations in different boot modes. With the recent addition of the RW_MCACHE (which does not get allocated in recovery mode), this is no longer true, and as a result CBMEM consoles can no longer persist between normal and recovery modes. The somewhat kludgy but simple solution is to just create a new class of specifically "early" CBMEM init hooks that will always run before all the others. While arbitrarily partitioning hooks into "early" and "not early" without any precise definition of what these things mean may seem a bit haphazard, I think it will be good enough in practice for the very few cases where this matters and beats building anything much more complicated (FWIW Linux has been doing something similar for years with device suspend/resume ordering). Since the current use case only relates to CBMEM allocation ordering and you can only really be "first" if you allocate in romstage, the "early" hook is only available in romstage for now (could be expanded later if we find a use case for it). Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: If2c849a89f07a87d448ec1edbad4ce404afb0746 Reviewed-on: https://review.coreboot.org/c/coreboot/+/54737 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Furquan Shaikh <furquan@google.com>
* memlayout: Store region sizes as separate symbolsJulius Werner2021-02-191-0/+12
| | | | | | | | | | | | | | | | This patch changes the memlayout macro infrastructure so that the size of a region "xxx" (i.e. the distance between the symbols _xxx and _exxx) is stored in a separate _xxx_size symbol. This has the advantage that region sizes can be used inside static initializers, and also saves an extra subtraction at runtime. Since linker symbols can only be treated as addresses (not as raw integers) by C, retain the REGION_SIZE() accessor macro to hide the necessary typecast. Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: Ifd89708ca9bd3937d0db7308959231106a6aa373 Reviewed-on: https://review.coreboot.org/c/coreboot/+/49332 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
* arch/x86: Top-align .init in bootblockKyösti Mälkki2021-01-281-0/+2
| | | | | | | | | | | | Link .init section near the end of bootblock program. It contains _start16bit, gdtptr and gdt that must be addressable from realmode, thus within top 64 KiB. Change-Id: If7b9737650362ac7cd82685cfdfaf18bd2429238 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/47970 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
* arch/x86: Move prologue to .init sectionKyösti Mälkki2021-01-071-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* arch/arm: Replace .id section with build_info in CBFSKyösti Mälkki2020-12-171-3/+0
| | | | | | | | | | | | | | | 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>
* cbfs: Add verification for RO CBFS metadata hashJulius Werner2020-12-031-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* lib: Add ASan support to ramstage on x86 archHarshit Sharma2020-08-211-1/+6
| | | | | | | | | | | | | 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>
* lib/program.ld: Replace CONFIG(ARCH_xx) testsKyösti Mälkki2020-06-101-4/+1
| | | | | | | | | | | | | | 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>
* arch/x86: Remove more romcc leftoversKyösti Mälkki2020-05-281-6/+0
| | | | | | | | | | | | | | 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>
* Remove MAYBE_STATIC_BSS and ENV_STAGE_HAS_BSS_SECTIONKyösti Mälkki2020-05-261-1/+1
| | | | | | | | | | | | | | | | | 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>
* treewide: Remove "this file is part of" linesPatrick Georgi2020-05-111-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* src/lib: Use SPDX for GPL-2.0-only filesAngel Pons2020-04-041-13/+2
| | | | | | | | | | 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>
* src (minus soc and mainboard): Remove copyright noticesPatrick Georgi2020-03-171-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | 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>
* src/: Replace some __PRE_RAM__ useKyösti Mälkki2019-09-141-1/+1
| | | | | | | | 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>
* arch/x86: Simplify <arch/early_variables.h>Kyösti Mälkki2019-08-261-1/+1
| | | | | | | | | | | | | | 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>
* Move and rename ARCH_STAGE_HAS_xxx_SECTION rulesKyösti Mälkki2019-08-261-3/+3
| | | | | | | | | | | | | | 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>
* coreboot: Replace all IS_ENABLED(CONFIG_XXX) with CONFIG(XXX)Julius Werner2019-03-081-4/+4
| | | | | | | | | | | | 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>
* Introduce bootblock self-decompressionJulius Werner2018-05-221-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* lib/program.ld: Guard .id section placementNico Huber2017-07-301-0/+3
| | | | | | | | | | | | | | 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>
* lib/program.ld: add .sdata sectionsAaron Durbin2016-10-311-0/+2
| | | | | | | | | | | | | 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>
* arch/x86,lib: make cbmem console work in postcar stageAaron Durbin2016-09-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | 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>
* program.ld: Don't exclude sbe region from verstageStefan Reinauer2016-05-211-1/+1
| | | | | | | | | | | | | | | | | | | | | 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>
* lib/reg_script: Allow multiple independent handlersLee Leahy2016-04-301-0/+5
| | | | | | | | | | | | | | | | 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)
* program.ld: make sure that zeroptr isn't assigned to debug sectionsPatrick Georgi2016-04-161-3/+1
| | | | | | | | | | | | | | | | | 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>
* arch/x86: introduce postcar stage/phaseAaron Durbin2016-03-231-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Provide a gcc-safe zero pointerPatrick Georgi2016-01-281-0/+4
| | | | | | | | | | | | | 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>
* tree: drop last paragraph of GPL copyright headerPatrick Georgi2015-10-311-4/+0
| | | | | | | | | | | | | | | | 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>
* program.ld: terminate ALIGN statementPatrick Georgi2015-09-281-1/+1
| | | | | | | | | | | 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>
* linking: link bootblock.elf with .data and .bss sections againAaron Durbin2015-09-221-7/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* linking: Repair special treatments for non-x86 bootblocksJulius Werner2015-09-171-5/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* x86: link ramstage the same way regardless of RELOCATABLE_RAMSTAGEAaron Durbin2015-09-091-3/+3
| | | | | | | | | | | | | | | | | | | | | | 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>
* rmodule: use program.ld for linkingAaron Durbin2015-09-091-4/+11
| | | | | | | | | | | | | | | | | | | | | 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>
* x86: link romstage like the other architecturesAaron Durbin2015-09-091-0/+6
| | | | | | | | | | | | | | | | | 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>
* linking: lay the groundwork for a unified linking approachAaron Durbin2015-09-091-0/+129
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>
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-19 14:24:24 +0000