summaryrefslogtreecommitdiff
path: root/src/include/program_loading.h
AgeCommit message (Collapse)Author
2019-01-30selfload: check target memory type in selfload_checkTing Shen
Currently, selflock_check() verifies that the binary is loaded in an usable RAM area. Extend its functionality so we can also check that BL31 is loaded in a manually reserved area, and fail early if the range is not protected. Change-Id: Iecdeedd9e8da67f73ac47d2a82e85b306469a626 Signed-off-by: Ting Shen <phoenixshen@google.com> Reviewed-on: https://review.coreboot.org/c/31122 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2018-11-09include/program_loading: Add POSTCAR prog typePhilipp Deppenwiese
Now postcar is a standalone stage give it a proper type. Change-Id: Ifa6af9cf20aad27ca87a86817e6ad0a0d1de17c8 Signed-off-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com> Reviewed-on: https://review.coreboot.org/29545 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
2018-10-25selfboot: create selfboot_check function, remove check paramRonald G. Minnich
The selfboot function was changed at some point to take a parameter which meant "check the allocated descriptors to see if they target regions of real memory." The region check had to be buried deep in the last step of loading since that is where those descriptors were created and used. An issue with the use of the parameter was that it was not possible for compilers to easily divine whether the check code was used, and it was hence possible for the code, and its dependencies, to be compiled in even if never used (which caused problems for the rampayload code). Now that bounce buffers are gone, we can hoist the check code to the outermost level. Further, by creating a selfload_check and selfload function, we can make it easy for compilers to discard unused code: if selfload_check is never called, all the code it uses can be discarded too. Change-Id: Id5b3f450fd18480d54ffb6e395429fba71edcd77 Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-on: https://review.coreboot.org/29259 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2018-10-11selfboot: remove bounce buffersRonald G. Minnich
Bounce buffers used to be used in those cases where the payload might overlap coreboot. Bounce buffers are a problem for rampayloads as they need malloc. They are also an artifact of our x86 past before we had relocatable ramstage; only x86, out of the 5 architectures we support, needs them; currently they only seem to matter on the following chipsets: src/northbridge/amd/amdfam10/Kconfig src/northbridge/amd/lx/Kconfig src/northbridge/via/vx900/Kconfig src/soc/intel/fsp_baytrail/Kconfig src/soc/intel/fsp_broadwell_de/Kconfig The first three are obsolete or at least could be changed to avoid the need to have bounce buffers. The last two should change to no longer need them. In any event they can be fixed or pegged to a release which supports them. For these five chipsets we change CONFIG_RAMBASE from 0x100000 (the value needed in 1999 for the 32-bit Linux kernel, the original ramstage) to 0xe00000 (14 Mib) which will put the non-relocatable x86 ramstage out of the way of any reasonable payload until we can get rid of it for good. 14 MiB was chosen after some discussion, but it does fit well: o Fits in the 16 MiB cacheable range coreboot sets up by default o Most small payloads are well under 14 MiB (even kernels!) o Most large payloads get loaded at 16 MiB (especially kernels!) With this change in place coreboot correctly still loads a bzImage payload. Werner reports that the 0xe00000 setting works on his broadwell systems. Change-Id: I602feb32f35e8af1d0dc4ea9f25464872c9b824c Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-on: https://review.coreboot.org/28647 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2018-06-19lib/prog_loaders: Move argument selection into selfloadPatrick Rudolph
Set the payload argument in selfload, as other (non self) payloads, are going to set a different argument. Change-Id: I994f604fc4501e0e3b00165819f796b1b8275d8c Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-on: https://review.coreboot.org/25861 Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2018-06-11selfboot: Move x86 quirk under archKyösti Mälkki
Making exceptions for some payload to be loaded near and under 1 MiB boundary sounds like a legacy 16-bit x86 BIOS thing we generally do not want under lib/. Change-Id: I8e8336a03d6f06d8f022c880a8334fe19a777f0a Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/26934 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
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-05-22Revert "program_loading: make types a mask, make unknown type a non-zero"Julius Werner
This reverts commit f3d99b6a657fe2bc3cff71956ab4f68fd1f287fe. Reason for revert: We're now doing this through CBFS types instead, so this shouldn't be needed anymore. Change-Id: I9e0d5446365f8ecc045615e4ba1a1313080c9479 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/26448 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2018-05-16lib/prog_loaders: Store CBFS type in struct progPatrick Rudolph
Store the type of the loaded program after locating the file and add a method to retrieve the type. Will be used to distinguish between SELF and FIT payloads. Change-Id: Ic226e7e028d722ab9e3c6f7f1c22bde2a1cd8a85 Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-on: https://review.coreboot.org/26028 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2018-05-14program_loading: make types a mask, make unknown type a non-zeroRonald G. Minnich
This will allow loading of programs that are more than one type, e.g. ramstage type might now be a stage or payload. Further, unknown types of 0 are dangerous, make it a real value. Change-Id: Ieb4eeb7c5934bddd9046ece8326342db0d76363c Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-on: https://review.coreboot.org/26242 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
2016-11-09ACPI S3: Remove HIGH_MEMORY_SAVE where possibleKyösti Mälkki
Add implementation to use actual requirements of ramstage size for S3 resume backup in CBMEM. The backup covers complete pages of 4 KiB. Only the required amount of low memory is backed up when ACPI_TINY_LOWMEM_BACKUP is selected for the platform. Enable this option for AGESA and binaryPI, other platforms (without RELOCATABLE_RAMSTAGE) currently keep their romstage ramstack in low memory for s3 resume path. Change-Id: Ide7ce013f3727c2928cdb00fbcc7e7e84e859ff1 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/15255 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
2016-10-31lib/prog_loaders: use common ramstage_cache_invalid()Aaron Durbin
All current implementations of ramstage_cache_invalid() were just resetting the system based on the RESET_ON_INVALID_RAMSTAGE_CACHE Kconfig option. Move that behavior to a single implementation within prog_loaders.c which removes duplication. Change-Id: I67aae73f9e1305732f90d947fe57c5aaf66ada9e Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/17184 Tested-by: build bot (Jenkins) Reviewed-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Furquan Shaikh <furquan@google.com>
2016-10-06arm64: Use 'payload' format for ATF instead of 'stage'Simon Glass
Switch the BL31 (ARM Trusted Firmware) format to payload so that it can have multiple independent segments. This also requires disabling the region check since SRAM is currently faulted by that check. This has been tested with Rockchip's pending change: https://chromium-review.googlesource.com/#/c/368592/3 with the patch mentioned on the bug at #13. BUG=chrome-os-partner:56314 BRANCH=none TEST=boot on gru and see that BL31 loads and runs. Im not sure if it is correct though: CBFS: Locating 'fallback/payload' CBFS: Found @ offset 1b440 size 15a75 Loading segment from ROM address 0x0000000000100000 code (compression=1) New segment dstaddr 0x18104800 memsize 0x117fbe0 srcaddr 0x100038 filesize 0x15a3d Loading segment from ROM address 0x000000000010001c Entry Point 0x0000000018104800 Loading Segment: addr: 0x0000000018104800 memsz: 0x000000000117fbe0 filesz: 0x0000000000015a3d lb: [0x0000000000300000, 0x0000000000320558) Post relocation: addr: 0x0000000018104800 memsz: 0x000000000117fbe0 filesz: 0x0000000000015a3d using LZMA [ 0x18104800, 18137d90, 0x192843e0) <- 00100038 Clearing Segment: addr: 0x0000000018137d90 memsz: 0x000000000114c650 dest 0000000018104800, end 00000000192843e0, bouncebuffer ffffffffffffffff Loaded segments BS: BS_PAYLOAD_LOAD times (us): entry 0 run 125150 exit 1 Jumping to boot code at 0000000018104800(00000000f7eda000) CPU0: stack: 00000000ff8ec000 - 00000000ff8f0000, lowest used address 00000000ff8ef3d0, stack used: 3120 bytes CBFS: 'VBOOT' located CBFS at [402000:44cc00) CBFS: Locating 'fallback/bl31' CBFS: Found @ offset 10ec0 size 8d0c Loading segment from ROM address 0x0000000000100000 code (compression=1) New segment dstaddr 0x10000 memsize 0x40000 srcaddr 0x100054 filesize 0x8192 Loading segment from ROM address 0x000000000010001c code (compression=1) New segment dstaddr 0xff8d4000 memsize 0x1f50 srcaddr 0x1081e6 filesize 0xb26 Loading segment from ROM address 0x0000000000100038 Entry Point 0x0000000000010000 Loading Segment: addr: 0x0000000000010000 memsz: 0x0000000000040000 filesz: 0x0000000000008192 lb: [0x0000000000300000, 0x0000000000320558) Post relocation: addr: 0x0000000000010000 memsz: 0x0000000000040000 filesz: 0x0000000000008192 using LZMA [ 0x00010000, 00035708, 0x00050000) <- 00100054 Clearing Segment: addr: 0x0000000000035708 memsz: 0x000000000001a8f8 dest 0000000000010000, end 0000000000050000, bouncebuffer ffffffffffffffff Loading Segment: addr: 0x00000000ff8d4000 memsz: 0x0000000000001f50 filesz: 0x0000000000000b26 lb: [0x0000000000300000, 0x0000000000320558) Post relocation: addr: 0x00000000ff8d4000 memsz: 0x0000000000001f50 filesz: 0x0000000000000b26 using LZMA [ 0xff8d4000, ff8d5f50, 0xff8d5f50) <- 001081e6 dest 00000000ff8d4000, end 00000000ff8d5f50, bouncebuffer ffffffffffffffff Loaded segments INFO: plat_rockchip_pmusram_prepare pmu: code d2bfe625,d2bfe625,80 INFO: plat_rockchip_pmusram_prepare pmu: code 0xff8d4000,0x50000,3364 INFO: plat_rockchip_pmusram_prepare: data 0xff8d4d28,0xff8d4d24,4648 NOTICE: BL31: v1.2(debug): NOTICE: BL31: Built : Sun Sep 4 22:36:16 UTC 2016 INFO: GICv3 with legacy support detected. ARM GICV3 driver initialized in EL3 INFO: plat_rockchip_pmu_init(1189): pd status 3e INFO: BL31: Initializing runtime services INFO: BL31: Preparing for EL3 exit to normal world INFO: Entry point address = 0x18104800 INFO: SPSR = 0x8 Change-Id: Ie2484d122a603f1c7b7082a1de3f240aa6e6d540 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 8c1d75bff6e810a39776048ad9049ec0a9c5d94e Original-Change-Id: I2d60e5762f8377e43835558f76a3928156acb26c Original-Signed-off-by: Simon Glass <sjg@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/376849 Original-Commit-Ready: Simon Glass <sjg@google.com> Original-Tested-by: Simon Glass <sjg@google.com> Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/16706 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2016-07-10intel post-car: Consolidate choose_top_of_stack()Kyösti Mälkki
Change-Id: I2c49d68ea9a8f52737b6064bc4fa703bdb1af1df Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/15463 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-04-02lib/prog_loading: introduce prog_segment_loaded()Aaron Durbin
In order to not muddle arch vs chipset implementations provide a generic prog_segment_loaded() which calls platform_segment_loaded() and arch_segment_loaded() in that order. This allows the arch variants to live in src/arch while the chipset/platform code can implement their own. Change-Id: I17b6497219ec904d92bd286f18c9ec96b2b7af25 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/14214 Reviewed-by: Furquan Shaikh <furquan@google.com> Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
2016-02-22die() when attempting to use bounce buffer on non-i386.Vladimir Serbinenko
Only i386 has code to support bounce buffer. For others coreboot would silently discard part of binary which doesn't work and is a hell to debug. Instead just die. Change-Id: I37ae24ea5d13aae95f9856a896700a0408747233 Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com> Reviewed-on: https://review.coreboot.org/13750 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-12-10lib: remove assets infrastructureAaron Durbin
Now that only CBFS access is supported for finding resources within the boot media the assets infrastructure can be removed. Remove it. BUG=chromium:445938 BRANCH=None TEST=Built and ran on glados. Change-Id: I383fd6579280cf9cfe5a18c2851baf74cad004e9 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/12690 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-12-10cbfs/vboot: remove firmware component supportAaron Durbin
The Chrome OS verified boot path supported multiple CBFS instances in the boot media as well as stand-alone assets sitting in each vboot RW slot. Remove the support for the stand-alone assets and always use CBFS accesses as the way to retrieve data. This is implemented by adding a cbfs_locator object which is queried for locating the current CBFS. Additionally, it is also signalled prior to when a program is about to be loaded by coreboot for the subsequent stage/payload. This provides the same opportunity as previous for vboot to hook in and perform its logic. BUG=chromium:445938 BRANCH=None TEST=Built and ran on glados. CQ-DEPEND=CL:307121,CL:31691,CL:31690 Change-Id: I6a3a15feb6edd355d6ec252c36b6f7885b383099 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/12689 Tested-by: build bot (Jenkins) Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com> Reviewed-by: Patrick Georgi <pgeorgi@google.com> 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-06-02assets: abstract away the firmware assets used for bootingAaron Durbin
As there can be more than one source of firmware assets this patch generalizes the notion of locating a particular asset. struct asset is added along with some helper functions for working on assets as a first class citizen. Change-Id: I2ce575d1e5259aed4c34c3dcfd438abe9db1d7b9 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/10264 Reviewed-by: Patrick Georgi <pgeorgi@google.com> Tested-by: build bot (Jenkins)
2015-06-02prog_loading: add region_device representing memoryAaron Durbin
One can remove the struct buffer_area and use the region_device embedded in the struct prog to represent the in-memory loaded program. Do this by introducing a addrspace_32bit mem_region_device that can have region_device operations performed on it. The addrspace_32bit name was chosen to make it explicit that 32-bits of address space is supported at the max. Change-Id: Ifffa0ef301141de940e54581b5a7b6cd81311ead Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/10261 Reviewed-by: Patrick Georgi <pgeorgi@google.com> Tested-by: build bot (Jenkins)
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-05-11vboot: inject vboot loader for stage loadingAaron Durbin
As previously done the vboot loader can be optionally inserted in the stage loading logic in order to decide the source of each stage. This current patch allows for verstage to be loaded and interrogated for the source of all subsequent stages. Additionally, it's also possible to build this logic directly into one of the additional stages. Note that this patch does not allow x86 to work. Change-Id: Iece018f01b220720c2803dc73c60b2c080d637d0 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/10154 Reviewed-by: Patrick Georgi <pgeorgi@google.com> Tested-by: build bot (Jenkins)
2015-04-30program loading: add optional is_loader_active() callbackAaron Durbin
Add a way for a loader to indicate if it is active. Such users of this callback would be vboot which can indicate to the rest of the system that it isn't active. is_loader_active() also gives vboot a chance to perform the necessary work to make said decision. Change-Id: I6679ac75b19bb1bfff9c2b709da5591986f752ff Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/10022 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-22coreboot: common stage cacheAaron Durbin
Many chipsets were using a stage cache for reference code or when using a relocatable ramstage. Provide a common API for the chipsets to use while reducing code duplication. Change-Id: Ia36efa169fe6bd8a3dbe07bf57a9729c7edbdd46 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/8625 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2015-04-03program loading: unify on struct progAaron Durbin
Instead of having different structures for loading ramstage and payload align to using struct prog. This also removes arch_payload_run() in favor of the prog_run() interface. Change-Id: I31483096094eacc713a7433811cd69cc5621c43e Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/8849 Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com> Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2015-04-03program loading: add prog_run() functionAaron Durbin
The prog_run() function abstracts away what is required for running a given program. Within it, there are 2 calls: 1. platform_prog_run() and 2. arch_prog_run(). The platform_prog_run() allows for a chipset to intercept a program that will be run. This allows for CPU switching as currently needed in t124 and t132. Change-Id: I22a5dd5bfb1018e7e46475e47ac993a0941e2a8c Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/8846 Tested-by: build bot (Jenkins) Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com> Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2015-04-03program loading: introduce struct progAaron Durbin
The struct prog serves as way to consolidate program loading. This abstraction can be used to perform more complicated execution paths such as running a program on a separate CPU after it has been loaded. Currently t124 and t132 need to do that in the boot path. Follow on patches will allow the platform to decide how to execute a particular program. Note: the vboot path is largely untouched because it's already broken in the coreboot.org tree. After getting all the necessary patches pushed then vboot will be fixed. Change-Id: Ic6e6fe28c5660fb41edee5fd8661eaf58222f883 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/8839 Tested-by: build bot (Jenkins) Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com> Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2015-03-31program loading: provide one cache maintenance callbackAaron Durbin
Instead of having 2 different functions to call when a program is loaded provide a single callback with flags parameter. The previous callbacks for cache management routines did this: for_each_program_segment: arch_program_segment_loaded(start, size); arch_program_loaded(); Now, use one callback instead: for_each_program_segment: arch_segment_loaded(start, size, SEG_FINAL?); Change-Id: I3811cba92e3355d172f605e4444f053321b07a2a Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/8838 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-03-31payload loading: remove passing of struct payloadAaron Durbin
There's no need to keep track of struct payload within the boot state machine. It is completely contained within the payload loader module. Change-Id: I16fcecf43d7fb41fc311955fdb82eabbd5c96b11 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/8836 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-03-31loading: move ramstage cache function declarationsAaron Durbin
The functions related to caching ramstage were in cbfs.h. Now that the loading code is separate move those declarations to the common program_loading.h. Change-Id: Ib22ef8a9c66e1d2b53388bceb8386baa6302d28b Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/8835 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-03-27cbfs/rmodule: add architecture specific operations at stage loadIonela Voinescu
Two weak functions were added so that architecture specific operations on each segment of payload or stage can be performed. Each architecture must define its own operations, otherwise the behavior will default to do-nothing functions. This patch has been updated by to fit more in line with how program loading is currently being done. The API is the same as the original, but all call sites to stages/payloads have been updated. This is known to break any archs that use rmodule loading that needs cache maintenance. That will be fixed in a forthcoming patch. Also, the vboot paths are left as is for easier upstreaming of the rest of the vboot patches. Original-Change-Id: Ie29e7f9027dd430c8b4dde9848fa3413c5dbfbfa Original-Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com> Original-Reviewed-on: https://chromium-review.googlesource.com/239881 Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org> (cherry picked from commit c82c21ce87a4c02bd9219548a4226a58e77beef0) Signed-off-by: Aaron Durbin <adurbin@chromium.org> Change-Id: Ifcee5cd9ac5dbca991556296eb5e170b47b77af7 Reviewed-on: http://review.coreboot.org/8837 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-03-20loaders: add run_romstage() function to bootblockAaron Durbin
Provide a common run_romstage() function to be used by bootblocks to load and run romstage. This is similar to run_ramstage() in that it provides a single entry point for doing the necessary work of loading and running romstage. Change-Id: Ia9643cc091f97a836cf5caefdff8df4a3443df4c Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/8709 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-03-20loaders: add program_loading.h header fileAaron Durbin
Instead of two headers for payload and ramstage loading combine the 2 files into one. This also allows for easier refactoring by keeping header files consistent. Change-Id: I4a6dffb78ad84c78e6e96c886d361413f9b4a17d Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/8708 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>