summaryrefslogtreecommitdiff
path: root/src/include/symbols.h
AgeCommit message (Collapse)Author
2019-04-08Replace remaining IS_ENABLED(CONFIG_*) with CONFIG()Nico Huber
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>
2019-03-14vboot: copy data structures to CBMEM for downstream useJoel Kitching
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>
2019-02-22symbols.h: Add macro to define memlayout region symbolsJulius Werner
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>
2019-02-05bootmem: add new memory type for BL31Ting Shen
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>
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>
2018-04-25arch/x86: add support for cache-as-ram pagingAaron Durbin
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>
2017-03-12src/include: Remove spaces before ( and after )Lee Leahy
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>
2016-10-24RISCV: Clean up the common architectural codeRonald G. Minnich
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>
2016-02-22memlayout: Add symbols for stage boundsJulius Werner
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>
2016-02-12timestamp: Remove HAS_PRECBMEM_TIMESTAMP_REGION KconfigJulius Werner
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>
2016-01-21memlayout: Fix unified CBFS_CACHE macroJulius Werner
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>
2015-12-31imgtec/pistachio: Add SOC_REGISTERS memory regionIonela Voinescu
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>
2015-12-03cbfs_spi: Initialize spi_flash when initializing cbfs_cacheMary Ruthven
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>
2015-12-03cbfs_spi: enable CBFS access in early romstageMary Ruthven
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>
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-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>
2015-07-07timestamp: add generic cache regionAaron Durbin
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)
2015-06-09cbmem: Unify CBMEM init tasks with CBMEM_INIT_HOOK() APIKyösti Mälkki
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>
2015-06-02cbfs: new API and better program loadingAaron Durbin
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>
2015-05-21Remove address from GPLv2 headersPatrick Georgi
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>
2015-04-17cbfs: look for CBFS header in a predefined placeVadim Bendebury
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>
2015-04-17rk3288: Handle framebuffer through memlayout, not the resource systemJulius Werner
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>
2015-04-08armv7: Add fine-grained page table supportJulius Werner
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>
2015-04-06New mechanism to define SRAM/memory map with automatic bounds checkingJulius Werner
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>