summaryrefslogtreecommitdiffstats
path: root/src/lib
Commit message (Collapse)AuthorAgeFilesLines
* lib/prog_loaders: Allow platforms to skip stage cacheFurquan Shaikh2016-05-091-2/+7
| | | | | | | | | | | | | | | Before multi-CBFS support was added, x86 platforms cached their ramstage in TSEG so that it could be re-used on the resume path. However, more resources/assets are being put in cbfs that are utilized during ramstage. Just caching ramstage does not mean that correct cbfs region is used for all the data. Thus, provide an option to allow platforms to skip caching any component for resume. Change-Id: I0e957a6b859cc7d700aaff67209a17c6558be5de Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/14636 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins)
* lib/reg_script: Fix bracesStefan Reinauer2016-05-051-1/+2
| | | | | | | | | | | | | In If0d4d61ed8ef48ec20082b327f358fd1987e3fb9 the code was changed from one to two lines in the body of an if() statement, without adding braces. Change-Id: Ibbbdf240157adae95151fb2ce0135948caa60108 Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-on: https://review.coreboot.org/14621 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) Reviewed-by: Leroy P Leahy <leroy.p.leahy@intel.com>
* lib/reg_script: Add display supportLee Leahy2016-05-041-11/+71
| | | | | | | | | | | | | | | | | | | | | | | | | Add the ability to enable the display of the script: * Added REG_SCRIPT_COMMAND_DISPLAY to enable and disable display output * Added context values to manage display support * display_state - Updated by the command to enable or disable display * display_features - May be updated by step routine to control what the step displays for register and value * display_prefix - Prefix to display before register data * Added REG_SCRIPT_DISPLAY_ON and REG_SCRIPT_DISPLAY_OFF macros to control the display from the register script * Added REG_SCRIPT_DISPLAY_REGISTER and REG_SCRIPT_DISPLAY_VALUE as two features of the common display. With these features enabled the following is output: * Write: <optional prefix> register <-- value * Read: <optional prefix> register --> value TEST=Build and run on Galileo Gen2 Change-Id: If0d4d61ed8ef48ec20082b327f358fd1987e3fb9 Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com> Reviewed-on: https://review.coreboot.org/14553 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
* lib/cbfs: Use fmap derived information about the COREBOOT regionPatrick Georgi2016-05-032-2/+14
| | | | | | | | | | | | | | | | It used to use CONFIG_CBFS_SIZE. The plan is that CBFS_SIZE only informs default*.fmd generation, while everything else derives its information from there. Also document the existing assumption that boot media should access the COREBOOT region (and not any other potentially existing fmap region containing a CBFS). Change-Id: I08254e4510f71edf99c2c8b56ac8f92008727c4a Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/14572 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
* lib/coreboot_table: use the architecture dependent table sizeAaron Durbin2016-05-021-1/+2
| | | | | | | | | | | Utilize the architecture dependent coreboot table size value from <arch/cbconfig.h> Change-Id: I80d51a5caf7c455b0b47c380e1d79cf522502a4c Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/14455 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins)
* lib/reg_script: Allow multiple independent handlersLee Leahy2016-04-302-19/+12
| | | | | | | | | | | | | | | | Remove the platform_bus_table routine and replace it with a link time table. This allows the handlers to be spread across multiple modules without any one module knowing about all of the handlers. Establish number ranges for both the SOC and mainboard. TEST=Build and run on Galileo Gen2 Change-Id: I0823d443d3352f31ba7fa20845bbf550b585c86f Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com> Reviewed-on: https://review.coreboot.org/14554 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins)
* lib/regscript: Add exclusive-or (xor) supportLee Leahy2016-04-301-0/+38
| | | | | | | | | | | | | | | | | Add xor support which enables toggling of a bit: * REG_SCRIPT_COMMAND_RXW enum value * REG_*_RXW* macros to support using REG_SCRIPT_COMMAND_RXW * REG_*_XOR* macros to support using REG_SCRIPT_COMMAND_RXW * reg_script_rxw routine to perform and/xor operation * case in reg_script_run_step to call reg_script_rxw TEST=Build and run on Galileo Gen2 Change-Id: I50a492c7c2643df5dc2d2fa7113e3722c1e480c7 Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com> Reviewed-on: https://review.coreboot.org/14495 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
* ensure correct byte ordering for cbfs segment listGeorge Trudeau2016-04-251-40/+55
| | | | | | | | | | | | | | | | | 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>
* lib: add common write_tables() implementationAaron Durbin2016-04-211-29/+34
| | | | | | | | | | | | | | In order to de-duplicate common patterns implement one write_tables() function. The new write_tables() replaces all the architecture-specific ones that were largely copied. The callbacks are put in place to handle any per-architecture requirements. Change-Id: Id3d7abdce5b30f5557ccfe1dacff3c58c59f5e2b Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/14436 Tested-by: build bot (Jenkins) Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
* lib/coreboot_table: add architecture hooks for adding tablesAaron Durbin2016-04-211-0/+3
| | | | | | | | | | | | Add a architecture specific function, arch_write_tables(), that allows an architecture to add its required tables for booting. This callback helps write_tables() to be de-duplicated. Change-Id: I805c2f166b1e75942ad28b6e7e1982d64d2d5498 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/14435 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
* lib/bootmem: allow architecture specific bootmem rangesAaron Durbin2016-04-211-0/+2
| | | | | | | | | | | | | A architecture-specific function, named bootmem_arch_add_ranges(), is added so that each architecture can add entries into the bootmem memory map. This allows for a common write_tables() implementation to avoid code duplication. Change-Id: I834c82eae212869cad8bb02c7abcd9254d120735 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/14434 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
* lib: add helper for constructing coreboot forwarding tableAaron Durbin2016-04-211-0/+13
| | | | | | | | | | | | | The x86 architecture needs to add a forwarding table to the real coreboot table. Provide a helper function to do this for aligning the architectures on a common write_tables() implementation. Change-Id: I9a2875507e6260679874a654ddf97b879222d44e Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/14433 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
* arch/x86: remove low coreboot table supportAaron Durbin2016-04-211-14/+1
| | | | | | | | | | | | | | | In addition to being consistent with all other architectures, all chipsets support cbmem so the low coreboot table path is stale and never taken. Also it's important to note the memory written in to that low area of memory wasn't automatically reserved unless that path was taken. To that end remove low coreboot table support for x86. Change-Id: Ib96338cf3024e3aa34931c53a7318f40185be34c Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/14432 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
* arch: only print cbmem entries in one placeAaron Durbin2016-04-211-0/+3
| | | | | | | | | | | | | | Each arch was calling cbmem_list() in their own write_tables() function. Consolidate that call and place it in common code in write_coreboot_table(). Change-Id: If0d4c84e0f8634e5cef6996b2be4a86cc83c95a9 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/14430 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>
* program.ld: make sure that zeroptr isn't assigned to debug sectionsPatrick Georgi2016-04-161-3/+1
| | | | | | | | | | | | | | | | | Some ld versions seem to merge the .zeroptr section (NOLOAD, address 0) with some debug sections (NOLOAD, address 0) which makes the build explode when the debug sections are then stripped (including the zeroptr symbol). Just define zeroptr to be 0, no sections needed, to avoid this "optimization". Checked the objdump -dS of code using it that the accesses look sane. Change-Id: Ia7cb3e5eae87076caf479d5ae9155a02f74b5663 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/14344 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
* edid: Make framebuffer row alignment configurableJulius Werner2016-04-071-5/+12
| | | | | | | | | | | | | | | | | | | | | | Our EDID code had always been aligning the framebuffer's bytes_per_line (and x_resolution dependent on that) to 64. It turns out that this is a controller-dependent parameter that seems to only really be necessary for Intel chipsets, and commit 6911219cc (edid: Add helper function to calculate bits-per-pixel dependent values) probably actually broke this for some other controllers by applying the alignment too widely. This patch makes it explicitly configurable and depends the default on ARCH_X86 (which seems to be the simplest and least intrusive way to make it fit most cases for now... boards where this doesn't apply can still override it manually by calling edid_set_framebuffer_bits_per_pixel() again). Change-Id: I1c565a72826fc5ddfbb1ae4a5db5e9063b761455 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/14267 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
* chromeos: Simplify fill_lb_gpios even furtherJulius Werner2016-04-051-8/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A long time ago many Chrome OS boards had pages full of duplicated boilerplate code for the fill_lb_gpios() function, and we spent a lot of time bikeshedding a proper solution that passes a table of lb_gpio structs which can be concisely written with a static struct initializer in http://crosreview.com/234648. Unfortunately we never really finished that patch and in the mean time a different solution using the fill_lb_gpio() helper got standardized onto most boards. Still, that solution is not quite as clean and concise as the one we had already designed, and it also wasn't applied consistently to all recent boards (causing more boards with bad code to get added afterwards). This patch switches all boards newer than Link to the better solution and also adds some nicer debug output for the GPIOs while I'm there. If more boards need to be converted from fill_lb_gpio() to this model later (e.g. from a branch), it's quite easy to do with: s/fill_lb_gpio(gpio++,\n\?\s*\([^,]*\),\n\?\s*\([^,]*\),\n\?\s*\([^,]*\),\n\?\s*\([^,]*\));/\t{\1, \2, \4, \3},/ Based on a patch by Furquan Shaikh <furquan@google.com>. BUG=None BRANCH=None TEST=Booted on Oak. Ran abuild -x. Change-Id: I449974d1c75c8ed187f5e10935495b2f03725811 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/14226 Tested-by: build bot (Jenkins) Reviewed-by: David Hendricks <dhendrix@chromium.org>
* lib/prog_loading: introduce prog_segment_loaded()Aaron Durbin2016-04-024-3/+15
| | | | | | | | | | | | | | | | 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>
* edid: Add helper function to calculate bits-per-pixel dependent valuesJulius Werner2016-03-241-24/+21
| | | | | | | | | | | | | | | | | | | | | | | Coreboot and most payloads support three basic pixel widths for the framebuffer. It assumes 32 by default, but several chipsets need to override that value with whatever else they're supporting. Our struct edid contains multiple convenience values that are directly derived from this (and other properties), so changing the bits per pixel always requires recalculating all those dependents in the chipset code. This patch provides a small convenience wrapper that can be used to consistently update the whole struct edid with a new pixel width instead, so we no longer need to duplicate those calculations everywhere. BUG=None TEST=Booted Oak in all three pixel widths (which it conveniently all supports), confirmed that images looked good. Change-Id: I5376dd4e28cf107ac2fba1dc418f5e1c5a2e2de6 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/14158 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
* arch/x86: introduce postcar stage/phaseAaron Durbin2016-03-232-3/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Certain chipsets don't have a memory-mapped boot media so their code execution for stages prior to DRAM initialization is backed by SRAM or cache-as-ram. The postcar stage/phase handles the cache-as-ram situation where in order to tear down cache-as-ram one needs to be executing out of a backing store that isn't transient. By current definition, cache-as-ram is volatile and tearing it down leads to its contents disappearing. Therefore provide a shim layer, postcar, that's loaded into memory and executed which does 2 things: 1. Tears down cache-as-ram with a chipset helper function. 2. Loads and runs ramstage. Because those 2 things are executed out of ram there's no issue of the code's backing store while executing the code that tears down cache-as-ram. The current implementation makes no assumption regarding cacheability of the DRAM itself. If the chipset code wishes to cache DRAM for loading of the postcar stage/phase then it's also up to the chipset to handle any coherency issues pertaining to cache-as-ram destruction. Change-Id: Ia58efdadd0b48f20cfe7de2f49ab462306c3a19b Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/14140 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com> Reviewed-by: Furquan Shaikh <furquan@google.com>
* gpio: Add support for binary_first base3 number systemJulius Werner2016-03-221-2/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds support for an alternative ternary number system in which group of GPIOs can be interpreted. In this system, the digit combinations that would form a binary number (i.e. that contain no 'Z' state) are used to represent the lower values in the way they're used in the normal binary system, and all the combinations that do contain a 'Z' are used to represent values above those. We can use this for boards that originally get strapped with binary board IDs but eventually require more revisions than that representation allows. We can switch their code to binary_first base3 and all old revisions with already produced boards will still get read as the correct numbers. Credit for the algorithm idea goes to Haran Talmon. BRANCH=None BUG=None TEST=Stubbed out the actual GPIO reading and simulated all combinations of 4 ternary digits for both number systems. Change-Id: Ib5127656455f97f890ce2999ba5ac5f58a20cf93 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/14116 Tested-by: build bot (Jenkins) Reviewed-by: David Hendricks <dhendrix@chromium.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
* lib/rmodule: export parameters in struct rmod_stage_loadAaron Durbin2016-03-221-0/+3
| | | | | | | | | | | | | In order for a caller to utilize an rmodule's parameters section after calling rmodule_stage_load() export the rmodule's parameter pointer in struct rmod_stage_load. Change-Id: I9cd51652cf8cdb3fae773256989851638aa1a60f Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/14139 Tested-by: build bot (Jenkins) Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
* cbmem: Fix cbmem_add_bootmem()Andrey Petrov2016-03-111-3/+3
| | | | | | | | | | | | | | | Change 13363 (555d6c2) introduced a bug where cbmem_add_bootmem() was converted to use a new function. Unfortunately instead of passing a pointer, NULL was passed due to type confusion. This change fixes that problem by passing address of stack variable instead of NULL. Change-Id: Ib8e1add3547cda01f71bf1dea14d3e58bdd99730 Signed-off-by: Andrey Petrov <andrey.petrov@intel.com> Reviewed-on: https://review.coreboot.org/14033 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
* cbmem: Add utility to get memory region occupied by cbmemAlexandru Gagniuc2016-03-101-1/+8
| | | | | | | | | | Change-Id: I8e57c23565f173afc0f4d450579b8bfb35aeb964 Signed-off-by: Alexandru Gagniuc <alexandrux.gagniuc@intel.com> Signed-off-by: Andrey Petrov <andrey.petrov@intel.com> Reviewed-on: https://review.coreboot.org/13363 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
* src/lib/trace.c: Make address size genericMartin Roth2016-03-101-1/+1
| | | | | | | | | | | | | | | | | On platforms that didn't use 32-bit addresses, enabling the CONFIG_TRACE option (Trace function calls) would break the build due to a cast from a pointer of a different size. This fixes this warning: src/lib/trace.c:29:58: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast] Change-Id: Iaab13c1891b6af7559ea6982ecc6e74c09dd0395 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/13962 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
* lib: Implement framework for retrieving WiFi regulatory domainFelix Durairaj2016-03-082-0/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Platforms that need to initialize WRDD package with the regulatory domain information should implement function wifi_regulatory_domain. A weak implementation is provided here. Signed-off-by: fdurairx <felixx.durairaj@intel.com> Reviewed-on: https://chromium-review.googlesource.com/314384 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Pratikkumar V Prajapati <pratikkumar.v.prajapati@intel.com> Commit-Queue: Hannah Williams <hannah.williams@intel.com> Tested-by: Hannah Williams <hannah.williams@intel.com> (cherry picked from commit c25d7221679d1fab830d614eeabfa3436bce6ac1) BUG=chrome-os-partner:50516 BRANCH=glados TEST=build and boot on chell Change-Id: I1cbdf4e940b009c74ee8ed8f4fca85f4f5c943b2 Signed-off-by: Patrick Georgi <pgeorgi@google.com> Original-Commit-Id: 27bba336e620a2d3d331e350d4f46164e337fabc Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Original-Change-Id: I84e2acd748856437b40bbf997bf23f158c711712 Original-Reviewed-on: https://chromium-review.googlesource.com/329291 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/13836 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
* lib/bootblock: provide SoC callback parity with mainboardAaron Durbin2016-02-261-0/+2
| | | | | | | | | | | | | | | | | There was no 'early' call into the SoC code prior to console getting initialized. Not having this enforces the mainboard to drive the setup of the console which typically just ends up calling into the SoC code. Provide a SoC early init call to handle this without having to duplicate the same code in mainboards utilizing the same SoC. Change-Id: Ia233dc3ae89a77df284d6d5cf5b2b051ad3be089 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/13791 Reviewed-by: Furquan Shaikh <furquan@google.com> Tested-by: build bot (Jenkins) Reviewed-by: Andrey Petrov <andrey.petrov@intel.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
* lib/memrange: avoid shadow object declarationsAaron Durbin2016-02-261-2/+2
| | | | | | | | | | | | | | | Fix an error where a variable named 'free' was shadowing the function 'free'. src/lib/memrange.c:293:73: error: declaration of 'free' shadows a global declaration [-Werror=shadow] Change-Id: Ie57194b392f8f00ed4fd5c76dab27299b00ae293 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/13788 Tested-by: build bot (Jenkins) Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
* cbfs: Add LZ4 in-place decompression support for pre-RAM stagesJulius Werner2016-02-224-44/+69
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* fsp_baytrail: Add full support for iosf access in reg_scriptWerner Zeh2016-02-221-7/+10
| | | | | | | | | | | | Add all needed functions to fsp_baytrail so that reg_script can do full iosf access. To keep it simple, this patch synchronises iosf access between baytrail and fsp_baytrail. Change-Id: Ic7f52d7d90c0fe3560fa5a5d96f7fc15062d66d1 Signed-off-by: Werner Zeh <werner.zeh@siemens.com> Reviewed-on: https://review.coreboot.org/13742 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
* die() when attempting to use bounce buffer on non-i386.Vladimir Serbinenko2016-02-221-0/+3
| | | | | | | | | | | | | 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>
* lib/coreboot_table: add function to allow arch code to add recordsAaron Durbin2016-02-191-0/+3
| | | | | | | | | | | | | | | | | Add lb_arch_add_records() to allow the architecture code to generically hook into the coreboot table generation. BUG=chrome-os-partner:50214 BRANCH=glados TEST=With all subsequent patches confirmed lb_arch_add_records() is called when a strong symbol is provided. Change-Id: I7c69c0ff0801392bbcf5aef586a48388b624afd4 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/13669 Tested-by: build bot (Jenkins) Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
* lib: Add Kconfig to toggle boot state debuggingLee Leahy2016-02-181-12/+13
| | | | | | | | | | | | | | | | Add the DEBUG_BOOT_STATE Kconfig value to enable boot state debugging. Update include/bootstate.h and lib/hardwaremain.c to honor this value. Add a dashed line which displays between the states. Testing on Galileo: * select DEBUG_BOOT_STATE in mainboard/intel/galileo/Kconfig * Build and run on Galileo Change-Id: I6e8a0085aa33c8a1394f31c030e67ab3d5bf7299 Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com> Reviewed-on: https://review.coreboot.org/13716 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
* FMAP: Clean up debug outputDuncan Laurie2016-02-131-7/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Reduce the debug output from FMAP lookups. When we had one or two FMAP lookups in a boot this was not a big deal, but now that we do many lookups it is a lot of unnecessary output duplication. This change reduces these 3 lines: FMAP: area VBLOCK_A found FMAP: offset: 200000 FMAP: size: 65536 bytes To just one line: FMAP: area VBLOCK_A found @ 200000 (65536 bytes) And makes the header output only print once: FMAP: Found "FMAP" version 1.0 at c10000. FMAP: base = 0 size = 1000000 #areas = 29 BUG=chrome-os-partner:40635 BRANCH=glados TEST=boot on chell and enjoy non-truncated memconsole Change-Id: Ib5862b8bfad113a700faae89089557094aa6d499 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 6890f36536d4ae6fc4988fc8191b0cff4e33e2e6 Original-Change-Id: Ifefee1ab26e6ee406de552880fbbd5b7916fcadd Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/326887 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/13695 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
* lzma: Port size-checking ulzman() version to corebootJulius Werner2016-02-124-12/+22
| | | | | | | | | | | | | | | | | | | | 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>
* timestamp: Remove HAS_PRECBMEM_TIMESTAMP_REGION KconfigJulius Werner2016-02-122-15/+31
| | | | | | | | | | | | | | | | | | | | | | 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>
* lib/prog_loaders.c: remove arch/stages.h includeAaron Durbin2016-02-111-1/+0
| | | | | | | | | | There's no delcaration used. Remove the include. Change-Id: I6fa7de6362ca0e92f0d5a7d07f3a224b9f77f709 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/13679 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
* timestamp: Bump CBMEM timestamp count, make full use of pre-RAM regionsJulius Werner2016-02-111-5/+10
| | | | | | | | | | | | | | | | | | | Since we're reaching the timestamp limit on certain platforms (both for the pre-RAM cache and the final CBMEM region), this patch increases the amount of space for both. In the pre-RAM case, it achieves this by always utilizing the full size of the TIMESTAMP() region allocated in memlayout.ld, rather than arbitrarily limiting it to some constant. BRANCH=None BUG=None TEST=Booted Oak and confirmed that I can once again see all pre-RAM timestamps after picking in the LZ4 patch series. Change-Id: Iabb075a48d8d1e3e1811afeaad5ab47e7846c972 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/13651 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
* nhlt: add api to override oem_id and oem_table_id of acpi_header_tFang, Yang A2016-02-091-2/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch added nhlt_soc_serialize_oem_overrides and nhlt_serilalize_oem_overrides to be able to override oem_id and oem_table_id.board file can pass specific string by calling nhlt_soc_serialize_oem_overrides kernel use these two fields to construct a topology binary name if the designate file is not found a default dfw_sst.bin will be used it is optional. BUG=chrome-os-partner:49570 BRANCH=glados TEST=Build & Booted kunimitsu board. Verified that kernel can read new strings. Change-Id: I00b64fb8bb63de601d3116e0b8941057c1efa230 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 374ce08b2d8a2f4e5dd7f51eacb505dbb77fd171 Original-Change-Id: I03623c8ac81efb5a5ea3ec9c6cd604d2e9294022 Original-Signed-off-by: Fang, Yang A <yang.a.fang@intel.com> Original-Reviewed-on: https://chromium-review.googlesource.com/322860 Original-Commit-Ready: Yang Fang <yang.a.fang@intel.com> Original-Tested-by: Yang Fang <yang.a.fang@intel.com> Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/13602 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
* chromeos: Remove CONFIG_VBNV_SIZE variableDuncan Laurie2016-02-091-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | The VBNV region size is determined by vboot and is not really configurable. Only the CMOS implementation defined this config variable so switch it to use VBNV_BLOCK_SIZE defined by vboot in vbnv_layout.h instead. This requires updating the broadwell/skylake cmos reset functions to use the right constant. BUG=chrome-os-partner:47915 BRANCH=glados TEST=manually tested on chell Change-Id: I45e3efc2a22efcb1470bbbefbdae4eda33fc6c96 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: e2b803ff3ac30ab22d65d1e62aca623730999a1d Original-Change-Id: I4896a1a5b7889d77ad00c4c8f285d184c4218e17 Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/324520 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/13598 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
* lib: add bootmode.c to verstageAaron Durbin2016-02-041-0/+1
| | | | | | | | | | | | | | | | | | | | | Some of the functions within bootmode.c may be required by boards in verstage. Therefore, allow this file to be built in verstage. BUG=chrome-os-partner:44827 BRANCH=glados TEST=Built chell w/ bootmode.c dependencies in separate verstage. Change-Id: Id291c1b5cc6594c3ee16c7c3385e682addc0efb6 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 084b620e12e7f948087786c0e34d5999a73137a5 Original-Change-Id: I2207819ec1490767cb1cf4b92e34e714783c1c22 Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/324071 Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://review.coreboot.org/13581 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
* lib: Support UNCOMPRESSED_RAMSTAGELee Leahy2016-02-031-1/+3
| | | | | | | | | | | | | | Selecting UNCOMPRESSED_RAMSTAGE prevents lzma.c from being compiled for romstage. Adjust the logic in rmodule.c to prevent calls to the ulzma routine when UNCOMPRESSED_RAMSTAGE is selected. TEST=Build and run on Galileo Change-Id: I7409e082baab3c2a086c57ad5aa9844ba788c7cd Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com> Reviewed-on: https://review.coreboot.org/13591 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins)
* lib/gcov-glue.c: Remove trailing number from COVERAGE_MAGIC macroJean Lucas2016-02-021-1/+1
| | | | | | | | | | | | | | The COVERAGE_MAGIC macro has a trailing `4' on it, which makes it a 64-bit large integer, as opposed to a 32-bit unsigned integer, as originally designated in `util/cbmem/cbmem.c'. Remove this number so building with CODE_COVERAGE will succeed. Change-Id: Ib5d7f2704a4c092c3eca6f62e219edb30950d793 Signed-off-by: Jean Lucas <jean@4ray.co> Reviewed-on: https://review.coreboot.org/13520 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Martin Roth <martinroth@google.com>
* Provide a gcc-safe zero pointerPatrick Georgi2016-01-281-0/+4
| | | | | | | | | | | | | zeroptr is a linker object pointing at 0 that can be used to thwart GCC's (and other compilers') "dereferencing NULL is undefined" optimization strategy when it gets in the way. Change-Id: I6aa6f28283281ebae73d6349811e290bf1b99483 Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-on: https://review.coreboot.org/12294 Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com> Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
* Makefile: Make full use of src-to-obj macroNico Huber2016-01-281-7/+7
| | | | | | | | | | | | | | | | There were several spots in the tree where the path to a per class object file was hardcoded. To make use of the src-to-obj macro for this, it had to be moved before the inclusion of subdirs. Which is fine, as it doesn't have dependencies beside $(obj). Tested by verifying that the resulting coreboot.rom files didn't change for all of Jenkins' abuild configurations. Change-Id: I2eb1beeb8ae55872edfd95f750d7d5a1cee474c4 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/13180 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
* arch/x86: link bootblock like other stages for C_ENVIRONMENT_BOOTBLOCKAaron Durbin2016-01-231-5/+2
| | | | | | | | | | | | | | When C_ENVIRONMENT_BOOTBLOCK is selected link bootblock using the memlayout.ld scripts and infrastructure. This allows bootblock on x86 to utilize all the other coreboot infrastructure without relying romcc. Change-Id: Ie3e077d553360853bf33f30cf8a347ba1df1e389 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/13069 Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Tested-by: build bot (Jenkins) Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
* lib/memrange: allow stack allocated free listAaron Durbin2016-01-231-24/+33
| | | | | | | | | | | | | | | | Instead of solely relying on malloc for building up an address space for the range_entry objects allow one to supply a list of free entries to memranges_init_empty(). Doing this and only calling malloc() in ramstage allows a memranges oboject to be used in a malloc()-free environment. Change-Id: I96c0f744fc04031a7ec228620a690b20bad36804 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/13020 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-by: Martin Roth <martinroth@google.com> Tested-by: build bot (Jenkins)
* lib: compile mdelay for romstagePatrick Georgi2016-01-221-1/+1
| | | | | | | | | | | | Mimicking change I7037308d2, always compile mdelay for romstage. The boards that #included delay.c in the romstage now rely on the linker instead, which is a desirable cleanup. Change-Id: I7e5169ec94e5417536e967194e8eab67381e7c98 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/13115 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
* lib/Makefile.inc: Link hexdump.c in the bootblock as wellAlexandru Gagniuc2016-01-221-0/+1
| | | | | | | | Change-Id: Id58f252e238cc3eb3fe9632493642d2a37c2a772 Signed-off-by: Alexandru Gagniuc <alexandrux.gagniuc@intel.com> Reviewed-on: https://review.coreboot.org/12873 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
* lib/hexdump: Refactor to skip lines with all ones as wellAlexandru Gagniuc2016-01-221-20/+25
| | | | | | | | | | | We already do this for lines with all zeroes, so it makes sense to treat all ones the same, for symmetry. Change-Id: I4b637b07a49e0c649331aa200995b474dd9a2682 Signed-off-by: Alexandru Gagniuc <alexandrux.gagniuc@intel.com> Reviewed-on: https://review.coreboot.org/12872 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
generated by cgit v1.2.3 (git 2.25.1) at 2024-07-31 17:31:05 +0000