summaryrefslogtreecommitdiff
path: root/src/lib/selfboot.c
AgeCommit message (Collapse)Author
2020-04-04src/lib: Use SPDX for GPL-2.0-only filesAngel Pons
Done with sed and God Lines. Only done for C-like code for now. Change-Id: Id3a0b63272ebda3dad13803700bcff36d36f4815 Signed-off-by: Angel Pons <th3fanbus@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/40054 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2020-03-17src (minus soc and mainboard): Remove copyright noticesPatrick Georgi
They're listed in AUTHORS and often incorrect anyway, for example: - What's a "Copyright $year-present"? - Which incarnation of Google (Inc, LLC, ...) is the current copyright holder? - People sometimes have their editor auto-add themselves to files even though they only deleted stuff - Or they let the editor automatically update the copyright year, because why not? - Who is the copyright holder "The coreboot project Authors"? - Or "Generated Code"? Sidestep all these issues by simply not putting these notices in individual files, let's list all copyright holders in AUTHORS instead and use the git history to deal with the rest. Change-Id: I89b10076e0f4a4b3acd59160fb7abe349b228321 Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/39611 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: David Hendricks <david.hendricks@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-01-28commonlib: Add commonlib/bsdJulius Werner
This patch creates a new commonlib/bsd subdirectory with a similar purpose to the existing commonlib, with the difference that all files under this subdirectory shall be licensed under the BSD-3-Clause license (or compatible permissive license). The goal is to allow more code to be shared with libpayload in the future. Initially, I'm going to move a few files there that have already been BSD-licensed in the existing commonlib. I am also exracting most contents of the often-needed <commonlib/helpers.h> as long as they have either been written by me (and are hereby relicensed) or have an existing equivalent in BSD-licensed libpayload code. I am also relicensing <commonlib/compression.h> (written by me) and <commonlib/compiler.h> (same stuff exists in libpayload). Finally, I am extracting the cb_err error code definitions from <types.h> into a new BSD-licensed header so that future commonlib/bsd code can build upon a common set of error values. I am making the assumption here that the enum constants and the half-sentence fragments of documentation next to them by themselves do not meet the threshold of copyrightability. Change-Id: I316cea70930f131e8e93d4218542ddb5ae4b63a2 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/38420 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Rudolph <siro@das-labor.org>
2019-12-11printf: Automatically prefix %p with 0xJulius Werner
According to the POSIX standard, %p is supposed to print a pointer "as if by %#x", meaning the "0x" prefix should automatically be prepended. All other implementations out there (glibc, Linux, even libpayload) do this, so we should make coreboot match. This patch changes vtxprintf() accordingly and removes any explicit instances of "0x%p" from existing format strings. How to handle zero padding is less clear: the official POSIX definition above technically says there should be no automatic zero padding, but in practice most other implementations seem to do it and I assume most programmers would prefer it. The way chosen here is to always zero-pad to 32 bits, even on a 64-bit system. The rationale for this is that even on 64-bit systems, coreboot always avoids using any memory above 4GB for itself, so in practice all pointers should fit in that range and padding everything to 64 bits would just hurt readability. Padding it this way also helps pointers that do exceed 4GB (e.g. prints from MMU config on some arm64 systems) stand out better from the others. Change-Id: I0171b52f7288abb40e3fc3c8b874aee14b9bdcd6 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/37626 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Patrick Georgi <pgeorgi@google.com> Reviewed-by: David Guckian
2019-04-25src/lib/selfboot: Remove unused variablesElyes HAOUAS
Change-Id: I8d80084095912c30bfd8fc100bf27b522485a08a Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/32430 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
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-10-30Add selfboot to the romstageRonald G. Minnich
Now that bounce buffers are gone, and we can elide the selfload checking code at build time, it is safe to add selfboot to the romstage. Make it so. This required a few other tweaks to rules.h and selfboot.c to make it buildon ARM. Change-Id: Ib6540921ad7cd7d58bfeab881d3978325b303cc2 Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-on: https://review.coreboot.org/29338 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Philipp Hug <philipp@hug.cx> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
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-08-16src/{commonlib,lib}: Fix typoElyes HAOUAS
Change-Id: If7650ac4d9be2614a9665c7f2aba9ac5cc413efe Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/28097 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martinroth@google.com>
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-12arch/x86: Fix payload loading via bounce-bufferKyösti Mälkki
Fix regression (supposedly) after commit: 23d62dd lib/bootmem: Add more bootmem tags Without RELOCATABLE_RAMSTAGE, payload is allowed to overwrite memory regions of the running ramstage. This case is handled gracefully via a bounce-buffer implementation in arch/x86/boot.c. Change-Id: I1c9bbdb963a7210d0817a7a990a70a1e4fc03624 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/26935 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Julius Werner <jwerner@chromium.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-04lib/bootmem: Add more bootmem tagsPatrick Rudolph
Introduce new bootmem tags to allow more fine grained control over buffer allocation on various platforms. The new tags are: BM_MEM_RAMSTAGE : Memory where any kind of boot firmware resides and that should not be touched by bootmem (by example: stack, TTB, program, ...). BM_MEM_PAYLOAD : Memory where any kind of payload resides and that should not be touched by bootmem. Starting with this commit all bootmem methods will no longer see memory that is used by coreboot as usable RAM. Bootmem changes: * Introduce a weak function to add platform specific memranges. * Mark memory allocated by bootmem as BM_TAG_PAYLOAD. * Assert on failures. * Add _stack and _program as BM_MEM_RAMSTAGE. ARMv7 and ARMv8 specific changes: * Add _ttb and _postram_cbfs_cache as BM_MEM_RAMSTAGE. ARMv7 specific changes: * Add _ttb_subtables as BM_MEM_RAMSTAGE. Change-Id: I0c983ce43616147c519a43edee3b61d54eadbb9a Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-on: https://review.coreboot.org/25383 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2018-04-30lib/bootmem: Introduce custom bootmem tagsPatrick Rudolph
Introduce bootmem custom memory tags and use them instead of reusing LB_MEM tags. Use asserts in bootmem_add_range to verify parameters. Tested with uImage payload on Cavium SoC. Change-Id: I7be8fa792fc7933ca218ecd43d250d3a9c55caa6 Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-on: https://review.coreboot.org/25633 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2017-06-07src: change coreboot to lowercaseMartin Roth
The word 'coreboot' should always be written in lowercase, even at the start of a sentence. Change-Id: I7945ddb988262e7483da4e623cedf972380e65a2 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/20029 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2017-03-13src/lib: Wrap lines at 80 columnsLee Leahy
Fix the following warning detected by checkpatch.pl: WARNING: line over 80 characters TEST=Build and run on Galileo Gen2 Change-Id: I5fa3f8e950e2f0c60bd0e8f030342dc8c0469299 Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com> Reviewed-on: https://review.coreboot.org/18758 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2017-03-13src/lib: Use tabs instead of spacesLee Leahy
Fix the following errors and warnings detected by checkpatch.pl: ERROR: code indent should use tabs where possible ERROR: switch and case should be at the same indent WARNING: Statements should start on a tabstop WARNING: please, no spaces at the start of a line WARNING: please, no space before tabs WARNING: suspect code indent for conditional statements WARNING: labels should not be indented TEST=Build and run on Galileo Gen2 Change-Id: Iebcff26ad41ab6eb0027b871a1c06f3b52dd207c Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com> Reviewed-on: https://review.coreboot.org/18732 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2017-03-12src/lib: Remove space between function name and (Lee Leahy
Fix the following warning detected by checkpatch.pl: WARNING: space prohibited between function name and open parenthesis '(' TEST=Build and run on Galileo Gen2 Change-Id: I8f3c79302dc5eb1861ffb245617a27addf8653ef Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com> Reviewed-on: https://review.coreboot.org/18731 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2017-03-09src/lib: Add space before (Lee Leahy
Fix the following error detected by checkpatch.pl: ERROR: space required before the open parenthesis '(' TEST=Build and run on Galileo Gen2 Change-Id: I8953fecbe75136ff989c9e3cf6c5e155dcee3c3b Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com> Reviewed-on: https://review.coreboot.org/18698 Reviewed-by: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com> Tested-by: build bot (Jenkins) Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2017-03-09src/lib: Fix space between type, * and variable nameLee Leahy
Fix the following errors detected by checkpatch.pl: ERROR: "foo* bar" should be "foo *bar" ERROR: "(foo*)" should be "(foo *)" ERROR: "foo * const * bar" should be "foo * const *bar" TEST=Build and run on Galileo Gen2 Change-Id: I0d20ca360d8829f7d7670bacf0da4a0300bfb0c1 Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com> Reviewed-on: https://review.coreboot.org/18696 Tested-by: build bot (Jenkins) Reviewed-by: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
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-09-20selfboot: Move the usable-RAM check into a functionSimon Glass
In preparation for making this check optional, move it into its own function. load_self_segments() is already long and we don't want to make it longer. BUG=chrome-os-partner:56314 BRANCH=none TEST=boot on gru and see that BL31 loads and runs correctly Change-Id: If48d2bf485a23f21c5599670e77a7b8b098f1a88 Signed-off-by: Martin Roth <martinroth@chromium.org> Original-Commit-Id: 2381e02efa2033857ac06acbc4f0c0dd08de1080 Original-Change-Id: I005e5e4d9b2136605bdd95e9060655df7a8238cb Original-Signed-off-by: Simon Glass <sjg@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/381092 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/16585 Tested-by: build bot (Jenkins) Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2016-07-31src/lib: Capitalize ROM, RAM, NVRAM and CPUElyes HAOUAS
Change-Id: Id0871b0c2eb31e2d728180b44cc5b518b751add4 Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/15985 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Omar Pakker Reviewed-by: Martin Roth <martinroth@google.com>
2016-07-12lib/selfboot: clear BSS segmentsAaron Durbin
For some reason the self loader wasn't clearing segments marked as BSS type. Other segments which weren't fully written by the file-backed content were being cleared up to the indicated memsize. Treat segments marked BSS similarly by clearing their content. Change-Id: I9296c11a89455a02e5dd18bba13d4911517c04f6 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/15603 Tested-by: build bot (Jenkins) Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2016-07-12lib/selfboot: remove duplicate prog_set_area()Aaron Durbin
There were two successive calls to prog_set_area() which duplicated the same logic. Remove the unnecessary redundancy. Change-Id: I594577f8e7e78d403e7a5656f78e784e98c2c859 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/15602 Tested-by: build bot (Jenkins) Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2016-07-12lib/selfboot: don't open code linked list operationsAaron Durbin
The list insertion operations were open coded at each location. Add helper functions which provide the semantics needed by the selfboot code in a single place. Change-Id: Ic757255e01934b499def839131c257bde9d0cc93 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/15601 Tested-by: build bot (Jenkins) Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2016-04-25ensure correct byte ordering for cbfs segment listGeorge Trudeau
Decode each cbfs_payload_segment into native byte order during segments iteration. Note : List ordering has been changed, segments are now always inserted at the end. cbfs_serialized.h PAYLOAD_SEGMENT definitions have been changed to their standard order (big-endian). Change-Id: Icb3c6a7da2d253685a3bc157bc7f5a51183c9652 Signed-off-by: George Trudeau <george.trudeau@usherbrooke.ca> Reviewed-on: https://review.coreboot.org/14294 Tested-by: build bot (Jenkins) Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com> 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-22cbfs: Add LZ4 in-place decompression support for pre-RAM stagesJulius Werner
This patch ports the LZ4 decompression code that debuted in libpayload last year to coreboot for use in CBFS stages (upgrading the base algorithm to LZ4's dev branch to access the new in-place decompression checks). This is especially useful for pre-RAM stages in constrained SRAM-based systems, which previously could not be compressed due to the size requirements of the LZMA scratchpad and bounce buffer. The LZ4 algorithm offers a very lean decompressor function and in-place decompression support to achieve roughly the same boot speed gains (trading compression ratio for decompression time) with nearly no memory overhead. For now we only activate it for the stages that had previously not been compressed at all on non-XIP (read: non-x86) boards. In the future we may also consider replacing LZMA completely for certain boards, since which algorithm wins out on boot speed depends on board-specific parameters (architecture, processor speed, SPI transfer rate, etc.). BRANCH=None BUG=None TEST=Built and booted Oak, Jerry, Nyan and Falco. Measured boot time on Oak to be about ~20ms faster (cutting load times for affected stages almost in half). Change-Id: Iec256c0e6d585d1b69985461939884a54e3ab900 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/13638 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
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>
2016-02-12lzma: Port size-checking ulzman() version to corebootJulius Werner
We've had a second version of ulzma() that would check the input and output buffer sizes in libpayload for a while now. Since it's generally never a bad idea to double-check for overruns, let's port it to coreboot and use it where applicable. (This requires a small fix in the four byte at a time read optimization we only have in coreboot, since it made the stream counter hit the end a little earlier than the algorithm liked and could trigger an assertion.) BRANCH=None BUG=None TEST=Booted Oak, Jerry and Falco. Change-Id: Id566b31dfa896ea1b991badf5a6ad9d075aef987 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/13637 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.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-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-21Unify byte order macros and clrsetbitsJulius Werner
This patch removes quite a bit of code duplication between cpu_to_le32() and clrsetbits_le32() style macros on the different architectures. This also syncs those macros back up to the new write32(a, v) style IO accessor macros that are now used on ARM and ARM64. CQ-DEPEND=CL:254862 BRANCH=none BUG=chromium:444723 TEST=Compiled Cosmos, Daisy, Blaze, Falco, Pinky, Pit, Rambi, Ryu, Storm and Urara. Booted on Jerry. Tried to compare binary images... unfortunately something about the new macro notation makes the compiler evaluate it more efficiently (not recalculating the address between the read and the write), so this was of limited value. Change-Id: If8ab62912c952d68a67a0f71e82b038732cd1317 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: fd43bf446581bfb84bec4f2ebb56b5de95971c3b Original-Change-Id: I7d301b5bb5ac0db7f5ff39e3adc2b28a1f402a72 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/254866 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9838 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>
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: 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-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 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>
2014-12-31Print segment clean up information only when required.Vadim Bendebury
Eliminate duplicated printout and if needed, print only changed information. BUG=none TEST=verified that the 'New segment dstaddr...' message is not duplicated anymore Original-Change-Id: Ia13593394fccbb225f2bd9ab2b9228bac29d50fb Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/199672 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> (cherry picked from commit aadf018821ebfa63d6ac9d2429ae1fb483dd6cb3) Signed-off-by: Marc Jones <marc.jones@se-eng.com> Change-Id: I7544bddc4026191395cfe3b8ac66256ec223391e Reviewed-on: http://review.coreboot.org/7937 Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Tested-by: build bot (Jenkins)
2014-04-26Rename coreboot_ram stage to ramstageFurquan Shaikh
Rename coreboot_ram stage to ramstage. This is done in order to provide consistency with other stage names (bootblock, romstage) and to allow any Makefile rule generalization, required for patches to be submitted later. Change-Id: Ib66e43b7e17b9c48b2d099670ba7e7d857673386 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: http://review.coreboot.org/5567 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2014-03-03lib/selfboot: s_srcaddr is uninitialized.Edward O'Callaghan
s_srcaddr is uninitialized in the BSS section, leading to a garbage valued operand on the LHS of a '<' on line 383. Change-Id: Ie4fec91b09c70fb1d91ad3918ac3f60653fa1d83 Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-on: http://review.coreboot.org/5314 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com>
2014-03-03selfboot: use bootmem infrastructureAaron Durbin
Instead of packing and unpacking entries in lb_mem use the bootmem infrastructure for performing sanity checks during payload loading. Change-Id: Ica2bee7ebb0f6bf9ded31deac8cb700aa387bc7a Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/5303 Tested-by: build bot (Jenkins) Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
2014-03-03coreboot: introduce arch_payload_run()Aaron Durbin
The selfboot() function relied on global variables within the selfboot.c compilation unit. Now that the bounce buffer is a part of struct payload use a new architecture-specific arch_payload_run() function for jumping to the payload. selfboot() can then be removed. Change-Id: Icec74942e94599542148561b3311ce5096ac5ea5 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/5300 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2014-03-03selfboot: store bounce buffer in struct payloadAaron Durbin
In order to break the dependency on selfboot for jumping to payload the bounce buffer location needs to be communicated. Therefore, add the bounce buffer to struct payload. Change-Id: I9d9396e5c5bfba7a63940227ee0bdce6cba39578 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/5299 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2014-03-03coreboot: use struct payload for selfload()Aaron Durbin
In order to encapsulate more data for self loading use struct payload as the type. That way modifications to what is needed for payload loading does not introduce more global variables. Change-Id: I5b8facd7881e397ca7de1c04cec747fc1dce2d5f Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/5298 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2014-03-03coreboot: move common code to payload_run() from selfboot()Aaron Durbin
The selfboot() routine was perfoming most of the common teardown and stack checking infrastructure. Move that code into payload_run() to prepare removal of the selfboot() function. Change-Id: I29f2a5cfcc692f7a0fe2656cb1cda18158c49c6e Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/5297 Tested-by: build bot (Jenkins) Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
2014-03-03coreboot: unify infrastructure for loading payloadsAaron Durbin
A payload can be loaded either from a vboot region or from cbfs. Provide a common place for choosing where the payload is loaded from. Additionally, place the logic in the 'loaders' directory similarly to the ramstage loader infrastructure. Change-Id: I6b0034ea5ebd04a3d058151819ac77a126a6bfe2 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/5296 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2013-11-18cbfs: 64-bit cleanupsRonald G. Minnich
cbfs used u32 in a number of cases where uintptr_t was correct. This change builds for both 64-bit and 32-bit boards. Change-Id: If42c722a8a9e8d565d3827f65ed6c2cb8e90ba60 Signed-off-by: Ronald G. Minnich <rminnich@google.com> Reviewed-on: http://review.coreboot.org/4037 Tested-by: build bot (Jenkins) Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com> Reviewed-by: Aaron Durbin <adurbin@google.com>
2013-08-31Remove NRV2B compression supportPatrick Georgi
It wasn't even hooked up to the build system anymore. Change-Id: I4b962ffd945b39451e19da3ec2f7b8e0eecf2e53 Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-on: http://review.coreboot.org/3892 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins)
2013-07-10Drop ELF remains from boot codeStefan Reinauer
This stuff is not used, so let's drop it. Change-Id: I671a5e87855b4c59622cafacdefe466ab3d70143 Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3660 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-10lib: Fix spellingMartin Roth
Change-Id: I999987af9cb44906e3c3135c0351a0cd6eb210ff Signed-off-by: Martin Roth <martin.roth@se-eng.com> Reviewed-on: http://review.coreboot.org/3756 Reviewed-by: Dave Frodin <dave.frodin@se-eng.com> Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-05-01boot state: rebalance payload load vs actual bootAaron Durbin
The notion of loading a payload in the current boot state machine isn't actually loading the payload. The reason is that cbfs is just walked to find the payload. The actual loading and booting were occuring in selfboot(). Change this balance so that loading occurs in one function and actual booting happens in another. This allows for ample opportunity to delay work until just before booting. Change-Id: Ic91ed6050fc5d8bb90c8c33a44eea3b1ec84e32d Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3139 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-05-01x86: use boot state callbacks to disable rom cacheAaron Durbin
On x86 systems there is a concept of cachings the ROM. However, the typical policy is that the boot cpu is the only one with it enabled. In order to ensure the MTRRs are the same across cores the rom cache needs to be disabled prior to OS resume or boot handoff. Therefore, utilize the boot state callbacks to schedule the disabling of the ROM cache at the ramstage exit points. Change-Id: I4da5886d9f1cf4c6af2f09bb909f0d0f0faa4e62 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3138 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-05-01coverage: use boot state callbacksAaron Durbin
Utilize the static boot state callback scheduling to initialize and tear down the coverage infrastructure at the appropriate points. The coverage initialization is performed at BS_PRE_DEVICE which is the earliest point a callback can be called. The tear down occurs at the 2 exit points of ramstage: OS resume and payload boot. Change-Id: Ie5ee51268e1f473f98fa517710a266e38dc01b6d Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3135 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-01boot: add disable_cache_rom() functionAaron Durbin
On certain architectures such as x86 the bootstrap processor does most of the work. When CACHE_ROM is employed it's appropriate to ensure that the caching enablement of the ROM is disabled so that the caching settings are symmetric before booting the payload or OS. Tested this on an x86 machine that turned on ROM caching. Linux did not complain about asymmetric MTRR settings nor did the ROM show up as cached in the MTRR settings. Change-Id: Ia32ff9fdb1608667a0e9a5f23b9c8af27d589047 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2980 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-21coreboot: introduce CONFIG_RELOCATABLE_RAMSTAGEAaron Durbin
This patch adds an option to build the ramstage as a reloctable binary. It uses the rmodule library for the relocation. The main changes consist of the following: 1. The ramstage is loaded just under the cmbem space. 2. Payloads cannot be loaded over where ramstage is loaded. If a payload is attempted to load where the relocatable ramstage resides the load is aborted. 3. The memory occupied by the ramstage is reserved from the OS's usage using the romstage_handoff structure stored in cbmem. This region is communicated to ramstage by an CBMEM_ID_ROMSTAGE_INFO entry in cbmem. 4. There is no need to reserve cbmem space for the OS controlled memory for the resume path because the ramsage region has been reserved in #3. 5. Since no memory needs to be preserved in the wake path, the loading and begin of execution of a elf payload is straight forward. Change-Id: Ia66cf1be65c29fa25ca7bd9ea6c8f11d7eee05f5 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2792 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com>
2013-03-19cbfs: alternative support for cbfs_load_payload()Aaron Durbin
In certain situations boot speed can be increased by providing an alternative implementation to cbfs_load_payload(). The ALT_CBFS_LOAD_PAYLOAD option allows for the mainboard or chipset to provide its own implementation. Booted baskingridge board with alternative and regular cbfs_load_payload(). Change-Id: I547ac9881a82bacbdb3bbdf38088dfcc22fd0c2c Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2782 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2013-02-27selfboot: Report correct entry point address in debug message.Hung-Te Lin
Entry point in payload segment header is a 64 bit integer (ntohll). The debug message is currently reading that as a 32 bit integer (which will produce 00000000 for most platforms). Change-Id: I931072bbb82c099ce7fae04f15c8a35afa02e510 Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2535 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins)
2013-01-30Extend CBFS to support arbitrary ROM source media.Hung-Te Lin
Summary: Isolate CBFS underlying I/O to board/arch-specific implementations as "media stream", to allow loading and booting romstage on non-x86. CBFS functions now all take a new "media source" parameter; use CBFS_DEFAULT_MEDIA if you simply want to load from main firmware. API Changes: cbfs_find => cbfs_get_file. cbfs_find_file => cbfs_get_file_content. cbfs_get_file => cbfs_get_file_content with correct type. CBFS used to work only on memory-mapped ROM (all x86). For platforms like ARM, the ROM may come from USB, UART, or SPI -- any serial devices and not available for memory mapping. To support these devices (and allowing CBFS to read from multiple source at the same time), CBFS operations are now virtual-ized into "cbfs_media". To simplify porting existing code, every media source must support both "reading into pre-allocated memory (read)" and "read and return an allocated buffer (map)". For devices without native memory-mapped ROM, "cbfs_simple_buffer*" provides simple memory mapping simulation. Every CBFS function now takes a cbfs_media* as parameter. CBFS_DEFAULT_MEDIA is defined for CBFS functions to automatically initialize a per-board default media (CBFS will internally calls init_default_cbfs_media). Also revised CBFS function names relying on memory mapped backend (ex, "cbfs_find" => actually loads files). Now we only have two getters: struct cbfs_file *entry = cbfs_get_file(media, name); void *data = cbfs_get_file_content(CBFS_DEFAULT_MEDIA, name, type); Test results: - Verified to work on x86/qemu. - Compiles on ARM, and follow up commit will provide working SPI driver. Change-Id: Iac911ded25a6f2feffbf3101a81364625bb07746 Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2182 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-01-12Implement GCC code coverage analysisStefan Reinauer
In order to provide some insight on what code is executed during coreboot's run time and how well our test scenarios work, this adds code coverage support to coreboot's ram stage. This should be easily adaptable for payloads, and maybe even romstage. See http://gcc.gnu.org/onlinedocs/gcc/Gcov.html for more information. To instrument coreboot, select CONFIG_COVERAGE ("Code coverage support") in Kconfig, and recompile coreboot. coreboot will then store its code coverage information into CBMEM, if possible. Then, run "cbmem -CV" as root on the target system running the instrumented coreboot binary. This will create a whole bunch of .gcda files that contain coverage information. Tar them up, copy them to your build system machine, and untar them. Then you can use your favorite coverage utility (gcov, lcov, ...) to visualize code coverage. For a sneak peak of what will expect you, please take a look at http://www.coreboot.org/~stepan/coreboot-coverage/ Change-Id: Ib287d8309878a1f5c4be770c38b1bc0bb3aa6ec7 Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/2052 Tested-by: build bot (Jenkins) Reviewed-by: David Hendricks <dhendrix@chromium.org> Reviewed-by: Martin Roth <martin@se-eng.com> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2012-11-30Drop boot directoryStefan Reinauer
It only has two files, move them to src/lib Change-Id: I17943db4c455aa3a934db1cf56e56e89c009679f Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/1959 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins)
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-06 07:23:17 +0000