summaryrefslogtreecommitdiffstats
path: root/src/include/symbols.h
Commit message (Collapse)AuthorAgeFilesLines
* ELOG: Refactor watchdog_tombstoneKyösti Mälkki2022-04-061-0/+1
| | | | | | | | | | | | The symbol watchdog_tombstone is not really about ChromeOS but ELOG instead. This prepares for furher move of the watchdog_tombstone implementation. Change-Id: I8446fa1a395b2d17912a23b87b83277c80828874 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/63300 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
* lib/prog_loaders, soc/amd/: Make payload_preload use cbfs_preloadRaul E Rangel2021-11-161-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Now that CBFS has this functionality built in, we no longer need to manually code it. payload_preload used to use the payload_preload_cache region to store the raw payload contents. This region was placed outside the firmware reserved region, so it was available for use by the OS. This was possible because the payload isn't loaded again on S3 resume. cbfs_preload only uses the cbfs_cache region. This region must be reserved because it gets used on the S3 resume path. Unfortunately this means that cbfs_cache must be increased to hold the payload. Cezanne is the only platform currently using payload_preload, and the size of cbfs_cache has already been adjusted. In the future we could look into adding an option to cbfs_preload that would allow it to use a different memory pool for the cache allocation. BUG=b:179699789 TEST=Boot guybrush and verify preloading the payload was successful CBFS DEBUG: get_preload_rdev(name='fallback/payload') preload successful Signed-off-by: Raul E Rangel <rrangel@chromium.org> Change-Id: Idc521b238620ff52b8ba481cd3c10e5c4f1394bd Reviewed-on: https://review.coreboot.org/c/coreboot/+/58962 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
* lib/prog_loaders: Add payload_preloadRaul E Rangel2021-07-191-0/+1
| | | | | | | | | | | | | | This method will allow the SoC code to start loading the payload before it is required. BUG=b:177909625 TEST=Boot guybrush and see read/decompress drop by 23 ms. Signed-off-by: Raul E Rangel <rrangel@chromium.org> Change-Id: Ifa8f30a0f4f931ece803c2e8e022e4d33d3fe581 Reviewed-on: https://review.coreboot.org/c/coreboot/+/56051 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martinroth@google.com>
* cbfs: Pull handling of the CBFS_CACHE mem_pool into CBFS coreJulius Werner2021-03-081-3/+3
| | | | | | | | | | | | | | | | | This patch pulls control of the memory pool serving allocations from the CBFS_CACHE memlayout area into cbfs.c and makes it a core part of the CBFS API. Previously, platforms would independently instantiate this as part of boot_device_ro() (mostly through cbfs_spi.c). The new cbfs_cache pool is exported as a global so these platforms can still use it to directly back rdev_mmap() on their boot device, but the cbfs_cache can now also use it to directly make allocations itself. This is used to allow transparent decompression support in cbfs_map(). Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: I0d52b6a8f582a81a19fd0fd663bb89eab55a49d9 Reviewed-on: https://review.coreboot.org/c/coreboot/+/49333 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
* memlayout: Store region sizes as separate symbolsJulius Werner2021-02-191-3/+5
| | | | | | | | | | | | | | | | 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>
* cbfs: Add metadata cacheJulius Werner2020-11-211-0/+1
| | | | | | | | | | | | | | | | | | | This patch adds a new CBFS "mcache" (metadata cache) -- a memory buffer that stores the headers of all CBFS files. Similar to the existing FMAP cache, this cache should reduce the amount of SPI accesses we need to do every boot: rather than having to re-read all CBFS headers from SPI flash every time we're looking for a file, we can just walk the same list in this in-memory copy and finally use it to directly access the flash at the right position for the file data. This patch adds the code to support the cache but doesn't enable it on any platform. The next one will turn it on by default. Change-Id: I5b1084bfdad1c6ab0ee1b143ed8dd796827f4c65 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/38423 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
* symbols: Change implementation details of DECLARE_OPTIONAL_REGION()Julius Werner2020-08-271-13/+16
| | | | | | | | | | | | | | | | | | It seems that GCC's LTO doesn't like the way we implement DECLARE_OPTIONAL_REGION(). This patch changes it so that rather than having a normal DECLARE_REGION() in <symbols.h> and then an extra DECLARE_OPTIONAL_REGION() in the C file using it, you just say DECLARE_OPTIONAL_REGION() directly in <symbols.h> (in place and instead of the usual DECLARE_REGION()). This basically looks the same way in the resulting object file but somehow LTO seems to like it better. Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: I6096207b311d70c8e9956cd9406bec45be04a4a2 Reviewed-on: https://review.coreboot.org/c/coreboot/+/44791 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Jacob Garber <jgarber1@ualberta.ca> Reviewed-by: Hung-Te Lin <hungte@chromium.org> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
* soc/amd/picasso: Add console & timestamp buffers to psp_verstageMartin Roth2020-08-241-0/+1
| | | | | | | | | | | | | | Create areas for console & timestamp data in psp_verstage and pass it to the x86 to save for use later. BUG=b:159220781 TEST=Build & Boot trembyle Signed-off-by: Martin Roth <martin@coreboot.org> Change-Id: I41c8d7a1565e761187e941d7d6021805a9744d06 Reviewed-on: https://review.coreboot.org/c/coreboot/+/42830 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Raul Rangel <rrangel@chromium.org>
* lib: Add ASan support to romstage on x86 archHarshit Sharma2020-08-211-1/+6
| | | | | | | | | | | | | | This patch adds ASan support to romstage on x86 architecture. A Kconfig option is added to enable ASan in romstage. Compiler flags are updated. A memory space representing the shadow region is reserved in linker section. And a function call to asan_init() is added to initialize shadow region when romstage loads. Change-Id: I67ebfb5e8d602e865b1f5c874860861ae4e54381 Signed-off-by: Harshit Sharma <harshitsharmajs@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/43604 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
* lib: Add ASan support to ramstage on x86 archHarshit Sharma2020-08-211-0/+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>
* treewide: Replace CONFIG(ARCH_xx) testsKyösti Mälkki2020-06-171-1/+1
| | | | | | | | | | | | | | Once we support building stages for different architectures, such CONFIG(ARCH_xx) tests do not evaluate correctly anymore. Change-Id: I599995b3ed5c4dfd578c87067fe8bfc8c75b9d43 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/42183 Reviewed-by: Raul Rangel <rrangel@chromium.org> Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* 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/include: Use SPDX for GPL-2.0-only filesAngel Pons2020-04-051-13/+2
| | | | | | | | | | Done with sed and God Lines. Only done for C-like code for now. Change-Id: I2fa3bad88bb5b068baa1cfc6bbcddaabb09da1c5 Signed-off-by: Angel Pons <th3fanbus@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/40053 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
* security/vboot: Decouple measured boot from verified bootBill XIE2020-03-311-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, those who want to use measured boot implemented within vboot should enable verified boot first, along with sections such as GBB and RW slots defined with manually written fmd files, even if they do not actually want to verify anything. As discussed in CB:34977, measured boot should be decoupled from verified boot and make them two fully independent options. Crypto routines necessary for measurement could be reused, and TPM and CRTM init should be done somewhere other than vboot_logic_executed() if verified boot is not enabled. In this revision, only TCPA log is initialized during bootblock. Before TPM gets set up, digests are not measured into tpm immediately, but cached in TCPA log, and measured into determined PCRs right after TPM is up. This change allows those who do not want to use the verified boot scheme implemented by vboot as well as its requirement of a more complex partition scheme designed for chromeos to make use of the measured boot functionality implemented within vboot library to measure the boot process. TODO: Measure MRC Cache somewhere, as MRC Cache has never resided in CBFS any more, so it cannot be covered by tspi_measure_cbfs_hook(). Change-Id: I1fb376b4a8b98baffaee4d574937797bba1f8aee Signed-off-by: Bill XIE <persmule@hardenedlinux.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/35077 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
* 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>
* lib/fmap: Add optional pre-RAM cacheJulius Werner2019-11-141-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds an optional pre-RAM cache for the FMAP which most platforms should be able to use, complementing the recently added post-RAM FMAP cache in CBMEM. vboot systems currently read the FMAP about half a dozen times from flash in verstage, which will all be coalesced into a single read with this patch. It will also help future vboot improvements since when FMAP reads become "free" vboot doesn't need to keep track of so much information separately. In order to make sure we have a single, well-defined point where the new cache is first initialized, eliminate the build-time hardcoding of the CBFS section offsets, so that all CBFS accesses explicitly read the FMAP. Add FMAP_CACHEs to all platforms that can afford it (other than the RISC-V things where I have no idea how they work), trying to take the space from things that look like they were oversized anyway (pre-RAM consoles and CBFS caches). Change-Id: I2820436776ef620bdc4481b5cd4b6957764248ea Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/36657 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Joel Kitching <kitching@google.com>
* x86: Introduce RESET_VECTOR_IN_RAM optionMartin Roth2019-08-261-1/+1
| | | | | | | | | | | | | | | Create a new Kconfig symbol that allows an x86 device to begin execution when its reset vector is in DRAM and not at the traditional 0xfffffff0. The implementation will follow later, this is just to setup various ENV_xxx definitions correctly for the build environment. Change-Id: I098ecf8bf200550db1e15f178f7661c1ac516dc5 Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com> Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/35004 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
* arch/x86: Obsolete CACHE_AS_RAM configKyösti Mälkki2019-08-111-1/+1
| | | | | | | | | | | It was originally inverse of romcc-built romstages on x86, and is currently always true on x86. Change-Id: I65fa6b3ce8a86781724bbf08f5eadee4112667c4 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/34806 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
* lib/bootmem: Prepare for OpenSBIPatrick Rudolph2019-07-311-0/+1
| | | | | | | | | | | | | Add a new bootmem memory type OpenSBI. It's similar to BL31 on aarch64. Required for OpenSBI integration. Change-Id: I5ceafd5a295f4284e99e12f7ea2aa4c6d1dbb188 Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/34140 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
* Replace remaining IS_ENABLED(CONFIG_*) with CONFIG()Nico Huber2019-04-081-1/+1
| | | | | | | | | | | | | | Another run of find src/ -type f | xargs sed -i -e 's/IS_ENABLED\s*(CONFIG_/CONFIG(/g' Change-Id: I3243197ab852a3fbc3eb2e2e782966a350b78af2 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/32224 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Julius Werner <jwerner@chromium.org>
* vboot: copy data structures to CBMEM for downstream useJoel Kitching2019-03-141-0/+7
| | | | | | | | | | | | | | | | | | | | | | For platforms that do not employ VBOOT_STARTS_IN_ROMSTAGE, vboot verification occurs before CBMEM is brought online. In order to make vboot data structures available downstream, copy vb2_working_data from CAR/SRAM into CBMEM when CBMEM comes online. Create VBOOT_MIGRATE_WORKING_DATA config option to toggle this functionality. BUG=b:124141368, b:124192753 TEST=Built and deployed on eve with STARTS_IN_BOOTBLOCK TEST=Built and deployed on eve with STARTS_IN_ROMSTAGE TEST=util/lint/checkpatch.pl -g origin/master..HEAD TEST=util/abuild/abuild -B -e -y -c 50 -p none -x BRANCH=none Change-Id: I62c11268a83927bc00ae9bd93b1b31363b38e8cf Signed-off-by: Joel Kitching <kitching@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/31329 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
* symbols.h: Add macro to define memlayout region symbolsJulius Werner2019-02-221-91/+33
| | | | | | | | | | | | | | | | | | | | | | | | | When <symbols.h> was first introduced, it only declared a handful of regions and we didn't expect that too many architectures and platforms would need to add their own later. However, our amount of platforms has greatly expanded since, and with them the need for more special memory regions. The amount of code duplication is starting to get unsightly, and platforms keep defining their own <soc/symbols.h> files that need this as well. This patch adds another macro to cut down the definition boilerplate. Unfortunately, macros cannot define other macros when they're called, so referring to region sizes as _name_size doesn't work anymore. This patch replaces the scheme with REGION_SIZE(name). Not touching the regions in the x86-specific <arch/symbols.h> yet since they don't follow the standard _region/_eregion naming scheme. They can be converted later if desired. Change-Id: I44727d77d1de75882c72a94f29bd7e2c27741dd8 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/c/31539 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
* bootmem: add new memory type for BL31Ting Shen2019-02-051-0/+4
| | | | | | | | | | | After CL:31122, we can finally define a memory type specific for BL31, to make sure BL31 is not loaded on other reserved area. Change-Id: Idbd9a7fe4b12af23de1519892936d8d88a000e2c Signed-off-by: Ting Shen <phoenixshen@google.com> Reviewed-on: https://review.coreboot.org/c/31123 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
* Introduce bootblock self-decompressionJulius Werner2018-05-221-0/+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>
* arch/x86: add support for cache-as-ram pagingAaron Durbin2018-04-251-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Processors, such as glk, need to have paging enabled while in cache-as-ram mode because the front end is agressive about fetching lines into the L1I cache. If the line is dirty and in the L1D then it writes it back to "memory". However, in this case there is no backing store so the cache-as-ram data that was written back transforms to all 0xff's when read back in causing corruption. In order to mitigate the failure add x86 architecture support for enabling paging while in cache-as-ram mode. A Kconfig variable, NUM_CAR_PAGE_TABLE_PAGES, determines the number of pages to carve out for page tables within the cache-as-ram region. Additionally, the page directory pointer table is also carved out of cache-as-ram. Both areas are allocated from the persist-across-stages region of cache-as-ram so all stages utilizing cache-as-ram don't corrupt the page tables. The two paging-related areas are loaded by calling paging_enable_for_car() with the names of cbfs files to load the initial paging structures from. BUG=b:72728953 Change-Id: I7ea6e3e7be94a0ef9fd3205ce848e539bfbdcb6e Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/25717 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Justin TerAvest <teravest@chromium.org>
* src/include: Remove spaces before ( and after )Lee Leahy2017-03-121-1/+1
| | | | | | | | | | | | | | | Fix the following error messages found by checkpatch.pl: ERROR: space prohibited after that open parenthesis '(' ERROR: space prohibited before that close parenthesis ')' TEST=Build and run on Galileo Gen2 Change-Id: I2a9a0df640c51ff3efa83dde852dd6ff37ac3c06 Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com> Reviewed-on: https://review.coreboot.org/18651 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
* RISCV: Clean up the common architectural codeRonald G. Minnich2016-10-241-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | This version of coreboot successfully starts a Harvey (Plan 9) kernel as a payload, entering main() with no supporting assembly code for startup. The Harvey port is not complete so it just panics but ... it gets started. We provide a standard payload function that takes a pointer argument and makes the jump from machine to supervisor mode; the days of kernels running in machine mode are over. We do some small tweaks to the virtual memory code. We temporarily disable two functions that won't work on some targets as register numbers changed between 1.7 and 1.9. Once lowrisc catches up we'll reenable them. We add the PAGETABLES to the memlayout.ld and use _pagetables in the virtual memory setup code. We now use the _stack and _estack from memlayout so we know where things are. As time goes on maybe we can kill all the magic numbers. Change-Id: I6caadfa9627fa35e31580492be01d4af908d31d9 Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-on: https://review.coreboot.org/17058 Tested-by: build bot (Jenkins) Reviewed-by: Furquan Shaikh <furquan@google.com>
* memlayout: Add symbols for stage boundsJulius Werner2016-02-221-0/+18
| | | | | | | | | | | | | | | | Stages are inconsistent with other memlayout regions in that they don't have _<name> and _e<name> symbols defined. We have _program and _eprogram, but that always only refers to the current stage and _eprogram marks the actual end of the executable's memory footprint, not the end of the area allocated in memlayout. Both of these are sometimes useful to know, so let's add another set of symbols that allow the stage areas to be treated more similarly to other regions. Change-Id: I9e8cff46bb15b51c71a87bd11affb37610aa7df9 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/13737 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
* timestamp: Remove HAS_PRECBMEM_TIMESTAMP_REGION KconfigJulius Werner2016-02-121-0/+7
| | | | | | | | | | | | | | | | | | | | | | This patch generalizes the approach previously used for ARM32 TTB_SUBTABLES to "auto-detect" whether a certain region was defined in memlayout.ld. This allows us to get rid of the explicit Kconfig for the TIMESTAMP region, reducing configuration redundancy and avoiding confusion when setting up future boards. (Removing armv4/bootblock_simple.c because it references this Kconfig and it is a dead file that I just forgot to remove in CL:12076.) BRANCH=None BUG=None TEST=Booted Oak and confirmed that all pre-RAM timestamps are still there. Built Nyan and Falco. Change-Id: I557a4b263018511d17baa4177963130a97ea310a Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/13652 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
* memlayout: Fix unified CBFS_CACHE macroJulius Werner2016-01-211-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | commit a8aef3ac (cbfs_spi: Initialize spi_flash when initializing cbfs_cache) introduced a bug that makes the rarely-used unified CBFS_CACHE() memlayout macro break when used in conjunction with cbfs_spi.c (since that macro does not define a separate postram_cbfs_cache region). This patch fixes the problem by making all three region names always available for both the unified and split macros in every stage (and adds code to ensure we don't reinitialize the same buffer again in romstage, which might be a bad idea if previous mappings are still in use). BRANCH=None BUG=None TEST=Compiled for both kinds of macros, manually checked symbols in disassembled stages. Change-Id: I114933e93080c8eceab04bfdba3aabf0f75f8ef9 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 0f270f88e54b42afb8b5057b0773644c4ef357ef Original-Change-Id: If172d9fa3d1fe587aa449bd4de7b5ca87d0f4915 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/318834 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/12933 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
* imgtec/pistachio: Add SOC_REGISTERS memory regionIonela Voinescu2015-12-311-0/+4
| | | | | | | | | | | | When used with a U-boot payload it will need this region identity mapped also, so we're defining it in preparation for that functionality. Change-Id: I27cee5b58cb899433b52bd06df07b5f2105212af Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com> Reviewed-on: https://review.coreboot.org/12768 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
* cbfs_spi: Initialize spi_flash when initializing cbfs_cacheMary Ruthven2015-12-031-3/+3
| | | | | | | | | | | | | | | | | | | | | | | Most devices do not use SPI before they initialize CBMEM. This change initializes spi_flash in the CBMEM_INIT_HOOK to initialize the postram cbfs cache so it is not overwritten when boot_device_init is called later. BUG=chromium:210230 BRANCH=none TEST=confirm that the first cbfs access can occur before RAM initialized and after on panther and jerry. Change-Id: If3b6efc04082190e81c3773c0d3ce116bb12421f Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 0ab242786a16eba7fb423694f6b266e27d7660ec Original-Change-Id: I5f884b473e51e6813fdd726bba06b56baf3841b0 Original-Signed-off-by: Mary Ruthven <mruthven@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/314311 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/12601 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
* cbfs_spi: enable CBFS access in early romstageMary Ruthven2015-12-031-0/+4
| | | | | | | | | | | | | | | | | | | | | | | Currently the CBFS mmap cannot be accessed at the beginning of romstage because it waits until DRAM is initialized. This change first loads CBFS into SRAM and then switches to using DRAM as the backing once it is initialized. BUG=chromium:210230 BRANCH=none TEST=confirm that the cbfs can be access at the beginning and end of romstage on different boards. Change-Id: I9fdaef392349c27ba1c19d4cd07e8ee0ac92dddc Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: ccaaba266386c7d5cc62de63bdca81a0cc7c4d83 Original-Change-Id: Idabfab99765b52069755e1d1aa61bbee39501796 Original-Signed-off-by: Mary Ruthven <mruthven@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/312577 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/12586 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
* 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>
* linking: lay the groundwork for a unified linking approachAaron Durbin2015-09-091-14/+1
| | | | | | | | | | | | | | | | | | | | | | | | | 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>
* timestamp: add generic cache regionAaron Durbin2015-07-071-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In order to accommodate tracking timestamps in all the __PRE_RAM__ stages (bootblock, verstage, romstage, etc) of a platform one needs to provide a way to specify a persistent region of SRAM or cache-as-ram to store the timestamps until cbmem comes online. Provide that infrastructure. Based on original patches from chromium.org: Original-Change-Id: I4d78653c0595523eeeb02115423e7fecceea5e1e Original-Signed-off-by: Furquan Shaikh <furquan@google.com> Original-Reviewed-on: https://chromium-review.googlesource.com/223348 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Original-Reviewed-by: Patrick Georgi <pgeorgi@chromium.org> Original-Tested-by: Furquan Shaikh <furquan@chromium.org> Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org> Original-Change-Id: Ie5ffda3112d626068bd1904afcc5a09bc4916d16 Original-Signed-off-by: Furquan Shaikh <furquan@google.com> Original-Reviewed-on: https://chromium-review.googlesource.com/224024 Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org> Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org> Original-Tested-by: Furquan Shaikh <furquan@chromium.org> Change-Id: I8779526136e89ae61a6f177ce5c74a6530469ae1 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/10790 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins)
* cbmem: Unify CBMEM init tasks with CBMEM_INIT_HOOK() APIKyösti Mälkki2015-06-091-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Squashed and adjusted two changes from chromium.git. Covers CBMEM init for ROMTAGE and RAMSTAGE. cbmem: Unify random on-CBMEM-init tasks under common CBMEM_INIT_HOOK() API There are several use cases for performing a certain task when CBMEM is first set up (usually to migrate some data into it that was previously kept in BSS/SRAM/hammerspace), and unfortunately we handle each of them differently: timestamp migration is called explicitly from cbmem_initialize(), certain x86-chipset-specific tasks use the CAR_MIGRATION() macro to register a hook, and the CBMEM console is migrated through a direct call from romstage (on non-x86 and SandyBridge boards). This patch decouples the CAR_MIGRATION() hook mechanism from cache-as-RAM and rechristens it to CBMEM_INIT_HOOK(), which is a clearer description of what it really does. All of the above use cases are ported to this new, consistent model, allowing us to have one less line of boilerplate in non-CAR romstages. BRANCH=None BUG=None TEST=Built and booted on Nyan_Blaze and Falco with and without CONFIG_CBMEM_CONSOLE. Confirmed that 'cbmem -c' shows the full log after boot (and the resume log after S3 resume on Falco). Compiled for Parrot, Stout and Lumpy. Original-Change-Id: I1681b372664f5a1f15c3733cbd32b9b11f55f8ea Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/232612 Reviewed-by: Aaron Durbin <adurbin@chromium.org> cbmem: Extend hooks to ramstage, fix timestamp synching Commit 7dd5bbd71 (cbmem: Unify random on-CBMEM-init tasks under common CBMEM_INIT_HOOK() API) inadvertently broke ramstage timestamps since timestamp_sync() was no longer called there. Oops. This patch fixes the issue by extending the CBMEM_INIT_HOOK() mechanism to the cbmem_initialize() call in ramstage. The macro is split into explicit ROMSTAGE_/RAMSTAGE_ versions to make the behavior as clear as possible and prevent surprises (although just using a single macro and relying on the Makefiles to link an object into all appropriate stages would also work). This allows us to get rid of the explicit cbmemc_reinit() in ramstage (which I somehow accounted for in the last patch without realizing that timestamps work exactly the same way...), and replace the older and less flexible cbmem_arch_init() mechanism. Also added a size assertion for the pre-RAM CBMEM console to memlayout that could prevent a very unlikely buffer overflow I just noticed. BRANCH=None BUG=None TEST=Booted on Pinky and Falco, confirmed that ramstage timestamps once again show up. Compile-tested for Rambi and Samus. Original-Change-Id: If907266c3f20dc3d599b5c968ea5b39fe5c00e9c Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/233533 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Change-Id: I1be89bafacfe85cba63426e2d91f5d8d4caa1800 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Signed-off-by: Marc Jones <marc.jones@se-eng.com> Reviewed-on: http://review.coreboot.org/7878 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
* cbfs: new API and better program loadingAaron Durbin2015-06-021-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A new CBFS API is introduced to allow making CBFS access easier for providing multiple CBFS sources. That is achieved by decoupling the cbfs source from a CBFS file. A CBFS source is described by a descriptor. It contains the necessary properties for walking a CBFS to locate a file. The CBFS file is then decoupled from the CBFS descriptor in that it's no longer needed to access the contents of the file. All of this is accomplished using the regions infrastructure by repsenting CBFS sources and files as region_devices. Because region_devices can be chained together forming subregions this allows one to decouple a CBFS source from a file. This also allows one to provide CBFS files that came from other sources for payload and/or stage loading. The program loading takes advantage of those very properties by allowing multiple sources for locating a program. Because of this we can reduce the overhead of loading programs because it's all done in the common code paths. Only locating the program is per source. Change-Id: I339b84fce95f03d1dbb63a0f54a26be5eb07f7c8 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9134 Tested-by: build bot (Jenkins) Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
* Remove address from GPLv2 headersPatrick Georgi2015-05-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As per discussion with lawyers[tm], it's not a good idea to shorten the license header too much - not for legal reasons but because there are tools that look for them, and giving them a standard pattern simplifies things. However, we got confirmation that we don't have to update every file ever added to coreboot whenever the FSF gets a new lease, but can drop the address instead. util/kconfig is excluded because that's imported code that we may want to synchronize every now and then. $ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, *MA[, ]*02110-1301[, ]*USA:Foundation, Inc.:" {} + $ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin Street, Suite 500, Boston, MA 02110-1335, USA:Foundation, Inc.:" {} + $ find * -type f -exec sed -i "s:Foundation, Inc., 59 Temple Place[-, ]*Suite 330, Boston, MA *02111-1307[, ]*USA:Foundation, Inc.:" {} + $ find * -type f -exec sed -i "s:Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.:Foundation, Inc.:" {} + $ find * -type f -a \! -name \*.patch \ -a \! -name \*_shipped \ -a \! -name LICENSE_GPL \ -a \! -name LGPL.txt \ -a \! -name COPYING \ -a \! -name DISCLAIMER \ -exec sed -i "/Foundation, Inc./ N;s:Foundation, Inc.* USA\.* *:Foundation, Inc. :;s:Foundation, Inc. $:Foundation, Inc.:" {} + Change-Id: Icc968a5a5f3a5df8d32b940f9cdb35350654bef9 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/9233 Tested-by: build bot (Jenkins) Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
* cbfs: look for CBFS header in a predefined placeVadim Bendebury2015-04-171-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch introduces a new option (CONFIG_MULTIPLE_CBFS_INSTANCES) to allow multiple CBFS instances in the bootrom. When the new option is enabled, the code running on the target controls which CBFS instance is used. Since all other then header CBFS structures use relative addressing, the only value which needs explicit setting is the offset of the CBFS header in the bootrom. This patch adds a facility to set the CBFS header offset. The offset value of zero means default. i.e. the CBFS initialization code still discovers the offset through the value saved at the top of the ROM. BRANCH=storm BUG=chrome-os-partner:34161, chromium:445938 TEST=with the rest patches in, storm target successfully boots from RW section A. Change-Id: Id8333c9373e61597f0c653c727dcee4ef6a58cd2 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: e57a3a15bba7cdcca4a5d684ed78f8ac6dbbc95e Original-Change-Id: I4c026389ec4fbaa19bd11b2160202282d2f9283c Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/237569 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9747 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
* rk3288: Handle framebuffer through memlayout, not the resource systemJulius Werner2015-04-171-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We've traditionally tucked the framebuffer at the end of memory (above CBMEM) on ARM and declared it reserved through coreboot's resource allocator. This causes depthcharge to mark this area as reserved in the kernel's device tree, which may be necessary to avoid display corruption on handoff but also wastes space that the OS could use instead. Since rk3288 boards now have proper display shutdown code in depthcharge, keeping the framebuffer memory reserved across the handoff (and thus throughout the lifetime of the system) should no longer be necessary. For now let's just switch the rk3288 implementation to define it through memlayout instead, which is not communicated through the coreboot tables and will get treated as normal memory by depthcharge. Note that this causes it to get wiped in developer/recovery mode, which should not be a problem because that is done in response to VbInit() (long before any images are drawn) and 0 is the default value for a corebootfb anyway (a black pixel). Eventually, we might want to think about adding more memory types to coreboot's resource system (e.g. "reserved until kernel handoff", or something specifically for the frame buffer) to model this situation better, and maybe merge it with memlayout somehow. CQ-DEPEND=CL:239470 BRANCH=veyron BUG=chrome-os-partner:34713 TEST=Booted Jerry, noticed that 'free' now displays 0x7f000 more bytes than before (curiously not 0x80000 bytes, I guess there's some alignment waste in the kernel somewhere). Made sure the memory map output from coreboot looks as expected, there's no visible display corruption in developer/recovery mode and the 'cbmem' utility still works. Change-Id: I12b7bfc1b7525f5a08cb7c64f0ff1b174df252d4 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 10afdba54dd5d680acec9cb3fe5b9234e33ca5a2 Original-Change-Id: I1950407d3b734e2845ef31bcef7bc59b96c2ea03 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/240819 Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9732 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
* armv7: Add fine-grained page table supportJulius Werner2015-04-081-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds an mmu_config_range_kb() function, which can set memory types at the 4KB level by chaining a fine-grained page table to an existing superpage entry. It is only intended for special cases where this level of precision is really necessary and therefore comes with a few practical limitations (the area for each invocation must be confined within a single superpage, and you are not allowed to remap the same region with mmu_config_range() again later). Since the fine-grained page tables need some space, boards intending to use this feature must define a TTB_SUBTABLES() region in their memlayout.ld. BUG=chrome-os-partner:32848 TEST=Booted both Veyron_Pinky (normal) and Nyan_Blaze (LPAE), ensured that they still work. Checksummed the page tables with and without this patch, confirmed that they end up equal. Hacked in some subtable test entries, hexdumped all tables and manually confirmed that they look as expected. Change-Id: I8c3eb7c2eb9c82e2abc5f2c0dda91f5b2eee7023 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 2f13e60cf5509b9a63fb7b8d84846daf889dc1b7 Original-Change-Id: Iedf7ca435ae337ead85115200d6987fb0d4828d7 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/223781 Reviewed-on: http://review.coreboot.org/9341 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
* New mechanism to define SRAM/memory map with automatic bounds checkingJulius Werner2015-04-061-0/+76
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>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-23 11:58:37 +0000