summaryrefslogtreecommitdiff
path: root/src/lib
AgeCommit message (Collapse)Author
2016-05-21program.ld: Don't exclude sbe region from verstageStefan Reinauer
This fixes compilation of coreboot on Glados Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org> BRANCH=none TEST=emerge-glados coreboot works again BUG=none Change-Id: Ibaae68192a3dc070c6ecf79223da4a1e1f18b352 Reviewed-on: https://chromium-review.googlesource.com/346198 Reviewed-by: Stefan Reinauer <reinauer@google.com> Commit-Queue: Stefan Reinauer <reinauer@google.com> Tested-by: Stefan Reinauer <reinauer@google.com> Reviewed-by: Luigi Semenzato <semenzato@chromium.org> (cherry picked from commit d7c2c72698e81b1410f9839c77be2e77b8ed83d6) Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://review.coreboot.org/14930 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: Duncan Laurie <dlaurie@google.com>
2016-05-21gpio: Add a function to map GPIO to ACPI pathDuncan Laurie
Add a new function "gpio_acpi_path()" that can be implemented by SoC/board code to provide a mapping from a "gpio_t" pin to a controller by returning the ACPI path for the controller that owns this particular GPIO. This is implemented separately from the "acpi_name" handler as many SOCs do not have a specific device that handles GPIOs (or may have many devices and the only way to know which is the opaque gpio_t) and the current GPIO library does not have any association with the device tree. If not implemented (many SoCs do not implement the GPIO library abstraction at all in coreboot) then the default handler will return NULL and the caller knows it cannot determine this reliably. Change-Id: Iaa0ff6c8c058f00cddf0909c4b7405a0660d4cfb Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://review.coreboot.org/14842 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins)
2016-05-21hexstrtobin: Add a library function to decode ASCII hex into binaryDuncan Laurie
This function will turn a string of ASCII hex characters into an array of bytes. It will ignore any non-ASCII-hex characters in the input string and decode up to len bytes of data from it. This can be used for turning MAC addresses or UUID strings into binary for storage or further processing. Sample usage: uint8_t buf[6]; hexstrtobin("00:0e:c6:81:72:01", buf, sizeof(buf)); acpigen_emit_stream(buf, sizeof(buf)); Change-Id: I2de9bd28ae8c42cdca09eec11a3bba497a52988c Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://review.coreboot.org/14837 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-05-19lib/bootblock: Provide mechanism to pass in an early timestampAlexandru Gagniuc
This is useful, for example, in the bootblock, when a timestamp is available which predates the call to main() in lib/bootblock.c Change-Id: I17bb0add9f2d8721504b2e534dd6904d1201989c Signed-off-by: Alexandru Gagniuc <alexandrux.gagniuc@intel.com> Reviewed-on: https://review.coreboot.org/14862 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2016-05-19lib/timestamp: Do not initialize cache in timestamp_cache_get()Alexandru Gagniuc
timestamp_cache_get() would call timestamp_cache_init() whenever it found a timestamp cache in the TIMESTAMP_CACHE_UNINITIALIZED state. That means that timestamp_cache_get() will never reurn a cache in the uninitialized state. However, timestamp_init() checks against the uninitialized state, as it does not expect timestamp_cache_get() to perform any initialization. As a result, the conditional branch can never be reached. Simply remove the timestamp_cache_init() call from timestamp_cache_get(). Change-Id: I573ffbf948b69948a3b383fa3bc94382f205b8f8 Signed-off-by: Alexandru Gagniuc <alexandrux.gagniuc@intel.com> Reviewed-on: https://review.coreboot.org/14861 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Furquan Shaikh <furquan@google.com>
2016-05-11lib: remove FLASHMAP_OFFSET config variableAaron Durbin
The FLASHMAP_OFFSET config variable is used in lib/fmap.c, however the fmdtool creates a fmap_config.h with a FMAP_OFFSET #define. Those 2 values are not consistent. Therefore, remove the Kconfig variable and defer to the #define generated by fmdtool. Change-Id: Ib4ecbc429e142b3e250106eea59fea1caa222917 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/14765 Reviewed-by: Patrick Georgi <pgeorgi@google.com> Tested-by: build bot (Jenkins) Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Leroy P Leahy <leroy.p.leahy@intel.com>
2016-05-09coreboot_tables: Extend serial port descriptionLee Leahy
Extend the serial port description to include the input clock frequency and a payload specific value. Without the input frequency it is impossible for the payload to compute the baud-rate divisor without making an assumption about the frequency. This breaks down when the UART is able to support multiple input clock frequencies. Add the UART_PCI_ADDR Kconfig value to specify the unique PCI device being used as the console UART. Specify this value as zero when the UART is not on the PCI bus. Otherwise specify the device using bus, device and function along with setting the valid bit. Currently the only payload to consume these new fields is the EDK-II CorebootPayloadPkg. Testing on Galileo: * Edit the src/mainboard/intel/galileo/Makefile.inc file: * Add "select ADD_FSP_PDAT_FILE" * Add "select ADD_FSP_RAW_BIN" * Add "select ADD_RMU_FILE" * Place the FSP.bin file in the location specified by CONFIG_FSP_FILE * Place the pdat.bin files in the location specified by CONFIG_FSP_PDAT_FILE * Place the rmu.bin file in the location specified by CONFIG_RMU_FILE * Build EDK2 CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc to generate UEFIPAYLOAD.fd * Testing is successful when CorebootPayloadPkg is able to properly initialize the serial port without using built-in values. Change-Id: Id4b4455bbf9583f0d66c315d38c493a81fd852a8 Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com> Reviewed-on: https://review.coreboot.org/14609 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2016-05-09lib/prog_loaders: Allow platforms to skip stage cacheFurquan Shaikh
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)
2016-05-05lib/reg_script: Fix bracesStefan Reinauer
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>
2016-05-04lib/reg_script: Add display supportLee Leahy
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>
2016-05-03lib/cbfs: Use fmap derived information about the COREBOOT regionPatrick Georgi
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>
2016-05-02lib/coreboot_table: use the architecture dependent table sizeAaron Durbin
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)
2016-04-30lib/reg_script: Allow multiple independent handlersLee Leahy
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)
2016-04-30lib/regscript: Add exclusive-or (xor) supportLee Leahy
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>
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-21lib: add common write_tables() implementationAaron Durbin
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>
2016-04-21lib/coreboot_table: add architecture hooks for adding tablesAaron Durbin
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>
2016-04-21lib/bootmem: allow architecture specific bootmem rangesAaron Durbin
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>
2016-04-21lib: add helper for constructing coreboot forwarding tableAaron Durbin
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>
2016-04-21arch/x86: remove low coreboot table supportAaron Durbin
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>
2016-04-21arch: only print cbmem entries in one placeAaron Durbin
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>
2016-04-16program.ld: make sure that zeroptr isn't assigned to debug sectionsPatrick Georgi
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>
2016-04-07edid: Make framebuffer row alignment configurableJulius Werner
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>
2016-04-05chromeos: Simplify fill_lb_gpios even furtherJulius Werner
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>
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-03-24edid: Add helper function to calculate bits-per-pixel dependent valuesJulius Werner
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>
2016-03-23arch/x86: introduce postcar stage/phaseAaron Durbin
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>
2016-03-22gpio: Add support for binary_first base3 number systemJulius Werner
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>
2016-03-22lib/rmodule: export parameters in struct rmod_stage_loadAaron Durbin
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>
2016-03-11cbmem: Fix cbmem_add_bootmem()Andrey Petrov
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>
2016-03-10cbmem: Add utility to get memory region occupied by cbmemAlexandru Gagniuc
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>
2016-03-10src/lib/trace.c: Make address size genericMartin Roth
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>
2016-03-08lib: Implement framework for retrieving WiFi regulatory domainFelix Durairaj
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>
2016-02-26lib/bootblock: provide SoC callback parity with mainboardAaron Durbin
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>
2016-02-26lib/memrange: avoid shadow object declarationsAaron Durbin
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>
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-22fsp_baytrail: Add full support for iosf access in reg_scriptWerner Zeh
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>
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-19lib/coreboot_table: add function to allow arch code to add recordsAaron Durbin
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>
2016-02-18lib: Add Kconfig to toggle boot state debuggingLee Leahy
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>
2016-02-13FMAP: Clean up debug outputDuncan Laurie
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>
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>
2016-02-12timestamp: Remove HAS_PRECBMEM_TIMESTAMP_REGION KconfigJulius Werner
This patch generalizes the approach previously used for ARM32 TTB_SUBTABLES to "auto-detect" whether a certain region was defined in memlayout.ld. This allows us to get rid of the explicit Kconfig for the TIMESTAMP region, reducing configuration redundancy and avoiding confusion when setting up future boards. (Removing armv4/bootblock_simple.c because it references this Kconfig and it is a dead file that I just forgot to remove in CL:12076.) BRANCH=None BUG=None TEST=Booted Oak and confirmed that all pre-RAM timestamps are still there. Built Nyan and Falco. Change-Id: I557a4b263018511d17baa4177963130a97ea310a Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/13652 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-02-11lib/prog_loaders.c: remove arch/stages.h includeAaron Durbin
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>
2016-02-11timestamp: Bump CBMEM timestamp count, make full use of pre-RAM regionsJulius Werner
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>
2016-02-09nhlt: add api to override oem_id and oem_table_id of acpi_header_tFang, Yang A
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>
2016-02-09chromeos: Remove CONFIG_VBNV_SIZE variableDuncan Laurie
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>
2016-02-04lib: add bootmode.c to verstageAaron Durbin
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>
2016-02-03lib: Support UNCOMPRESSED_RAMSTAGELee Leahy
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)
2016-02-02lib/gcov-glue.c: Remove trailing number from COVERAGE_MAGIC macroJean Lucas
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>
2016-01-28Provide a gcc-safe zero pointerPatrick Georgi
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>
2016-01-28Makefile: Make full use of src-to-obj macroNico Huber
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>
2016-01-23arch/x86: link bootblock like other stages for C_ENVIRONMENT_BOOTBLOCKAaron Durbin
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>
2016-01-23lib/memrange: allow stack allocated free listAaron Durbin
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)
2016-01-22lib: compile mdelay for romstagePatrick Georgi
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>
2016-01-22lib/Makefile.inc: Link hexdump.c in the bootblock as wellAlexandru Gagniuc
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>
2016-01-22lib/hexdump: Refactor to skip lines with all ones as wellAlexandru Gagniuc
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>
2016-01-21memlayout: Fix unified CBFS_CACHE macroJulius Werner
commit a8aef3ac (cbfs_spi: Initialize spi_flash when initializing cbfs_cache) introduced a bug that makes the rarely-used unified CBFS_CACHE() memlayout macro break when used in conjunction with cbfs_spi.c (since that macro does not define a separate postram_cbfs_cache region). This patch fixes the problem by making all three region names always available for both the unified and split macros in every stage (and adds code to ensure we don't reinitialize the same buffer again in romstage, which might be a bad idea if previous mappings are still in use). BRANCH=None BUG=None TEST=Compiled for both kinds of macros, manually checked symbols in disassembled stages. Change-Id: I114933e93080c8eceab04bfdba3aabf0f75f8ef9 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 0f270f88e54b42afb8b5057b0773644c4ef357ef Original-Change-Id: If172d9fa3d1fe587aa449bd4de7b5ca87d0f4915 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/318834 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/12933 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2016-01-21*/Makefile.inc: Compile files needed by uart8250 in x86 bootblockAlexandru Gagniuc
These files provide symbols needed by console and uart drivers. This was not an issue in the past, as we were not setting up a C environment this early in the boot process. Change-Id: Ied5106ac30a68971c8330e8f8270ab060994a89d Signed-off-by: Alexandru Gagniuc <alexandrux.gagniuc@intel.com> Reviewed-on: https://review.coreboot.org/12869 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-01-20lib: compile mdelay for bootblockPatrick Georgi
Mediatek's bootblock needs mdelay, which depends on a udelay implementation. Compiling the file for bootblock poses no harm: Either udelay exists (in which case mdelay is usable) or it doesn't in which case we see exactly the same kind of build time error (just with udelay instead of mdelay). Change-Id: I7037308d2d79c5cb1b05bb2b57a0912ad11cd7a6 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/13049 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2016-01-15lib: NHLT ACPI table supportAaron Durbin
Intel's SST (Smart Sound Technology) employs audio support which may not consist of HDA. In order to define the topology of the audio devices (mics, amps, codecs) connected to the platform a NHLT specification was created to pass this information from the firmware to the OS/userland. BUG=chrome-os-partner:44481 BRANCH=None TEST=Tested on glados. Audio does get emitted and some mic recording works. Change-Id: I8a9c2f4f76a0d129be44070f09d938c28a73fd27 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 2472af5793dcffd2607a7b95521ddd25b4be0e8c Original-Change-Id: If469f99ed1a958364101078263afb27761236421 Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/312264 Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://review.coreboot.org/12935 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2016-01-07Correct some common spelling mistakesMartin Roth
- occured -> occurred - accomodate -> accommodate - existant -> existent - asssertion -> assertion - manangement -> management - cotroller -> controller Change-Id: Ibd6663752466d691fabbdc216ea05f2b58ac12d1 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/12850 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2016-01-06commonlib: Add common cbfs parsing logic to coreboot and cbfstool.Aaron Durbin
To continue sharing more code between the tools and coreboot proper provide cbfs parsing logic in commonlib. A cbfs_for_each_file() function was added to allow one to act on each file found within a cbfs. cbfs_locate() was updated to use that logic. BUG=chrome-os-partner:48412 BUG=chromium:445938 BRANCH=None TEST=Utilized and booted on glados. Change-Id: I1f23841583e78dc3686f106de9eafe1adbef8c9f Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/12783 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-12-10lib: remove assets infrastructureAaron Durbin
Now that only CBFS access is supported for finding resources within the boot media the assets infrastructure can be removed. Remove it. BUG=chromium:445938 BRANCH=None TEST=Built and ran on glados. Change-Id: I383fd6579280cf9cfe5a18c2851baf74cad004e9 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/12690 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-12-10cbfs/vboot: remove firmware component supportAaron Durbin
The Chrome OS verified boot path supported multiple CBFS instances in the boot media as well as stand-alone assets sitting in each vboot RW slot. Remove the support for the stand-alone assets and always use CBFS accesses as the way to retrieve data. This is implemented by adding a cbfs_locator object which is queried for locating the current CBFS. Additionally, it is also signalled prior to when a program is about to be loaded by coreboot for the subsequent stage/payload. This provides the same opportunity as previous for vboot to hook in and perform its logic. BUG=chromium:445938 BRANCH=None TEST=Built and ran on glados. CQ-DEPEND=CL:307121,CL:31691,CL:31690 Change-Id: I6a3a15feb6edd355d6ec252c36b6f7885b383099 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/12689 Tested-by: build bot (Jenkins) Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com> Reviewed-by: Patrick Georgi <pgeorgi@google.com> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-12-04cbfs: Fix typo in cbfs_prog_stage_load()Julius Werner
The proper return value to signal an error from cbfs_prog_stage_load() is -1, not 0. Change-Id: Ie53b0359c7c036e3f809d1f941dab53f090b84ab Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/12633 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins)
2015-12-03cbfs_spi: Initialize spi_flash when initializing cbfs_cacheMary Ruthven
Most devices do not use SPI before they initialize CBMEM. This change initializes spi_flash in the CBMEM_INIT_HOOK to initialize the postram cbfs cache so it is not overwritten when boot_device_init is called later. BUG=chromium:210230 BRANCH=none TEST=confirm that the first cbfs access can occur before RAM initialized and after on panther and jerry. Change-Id: If3b6efc04082190e81c3773c0d3ce116bb12421f Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 0ab242786a16eba7fb423694f6b266e27d7660ec Original-Change-Id: I5f884b473e51e6813fdd726bba06b56baf3841b0 Original-Signed-off-by: Mary Ruthven <mruthven@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/314311 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/12601 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-12-03cbfs_spi: enable CBFS access in early romstageMary Ruthven
Currently the CBFS mmap cannot be accessed at the beginning of romstage because it waits until DRAM is initialized. This change first loads CBFS into SRAM and then switches to using DRAM as the backing once it is initialized. BUG=chromium:210230 BRANCH=none TEST=confirm that the cbfs can be access at the beginning and end of romstage on different boards. Change-Id: I9fdaef392349c27ba1c19d4cd07e8ee0ac92dddc Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: ccaaba266386c7d5cc62de63bdca81a0cc7c4d83 Original-Change-Id: Idabfab99765b52069755e1d1aa61bbee39501796 Original-Signed-off-by: Mary Ruthven <mruthven@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/312577 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/12586 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-11-24lib/timestamp.c: only log "Timestamp table full" onceBen Gardner
If the timestamp table gets corrupted (separate issue), the timestamp_sync_cache_to_cbmem() function may add a large number of bogus timestamp entries. This causes a flood of "ERROR: Timestamp table full". With logs going to a serial console, this renders the system essentially unbootable. There really isn't a need to log that more than once, so log it when the last slot in the timestamp table is filled. Change-Id: I05d131183afceca31f4dac91c5edc95cfb1e443f Signed-off-by: Ben Gardner <gardner.ben@gmail.com> Reviewed-on: http://review.coreboot.org/12506 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-11-21hexdump: Fix output if length is not a multiple of 16Ben Gardner
hexdump currently rounds up length to a multiple of 16. So, hexdump(ptr, 12) prints 16 hex digits, including 4 garbage bytes. That isn't desirable and is easy to fix. Change-Id: I86415fa9bc6cdc84b111e5e1968e39f570f294d9 Signed-off-by: Ben Gardner <gardner.ben@gmail.com> Reviewed-on: http://review.coreboot.org/12486 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2015-11-19vendorcode/google/chromeos: Cache VPD data into CBMEMHung-Te Lin
There are few drawbacks reading VPD from SPI flash in user land, including "lack of firmware level authority" and "slow reading speed". Since for many platforms we are already reading VPD in firmware (for example MAC and serial number), caching the VPD data in CBMEM should will speed up and simplify user land VPD processing without adding performance cost. A new CBMEM ID is added: CBMEM_ID_VPD, referring to a structure containing raw Google VPD 2.0 structure and can be found by the new LB_TAG_VPD in Coreboot tables. BRANCH=smaug BUG=chrome-os-partner:39945 TEST=emerge-smaug coreboot chromeos-bootimage # and boots successfully. [pg: lots of changes to make it work with what happened in upstream since 2013] Change-Id: If8629ac002d52abed7b480d3d06298665613edbf Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 117a9e88912860a22d250ff0e53a7d40237ddd45 Original-Change-Id: Ic79f424a6e3edfb6c5d168b9661d61a56fab295f Original-Signed-off-by: Hung-Te Lin <hungte@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/285031 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/12453 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins)
2015-11-19edid: Don't half parse (and wrongly print) more detailed timingsDouglas Anderson
The EDID parsing code continued to update _some_ fields of the output edid but not others if "did_detailed_timing" was already set. It also then went on to print out this halfway mix of modes each time, despite the fact that it didn't really update everything. Let's fix that. We'll reduce code changes by using a temporary copy of data in detailed_block() and then we'll copy it back if we decide we should update. BRANCH=none BUG=chrome-os-partner:46998 TEST=No more bogus printouts Change-Id: Idbfa233e0997244c22ef21c892c4473a91621821 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 4d69999cdd7ce3cd2c9332ab3f22ea8eb4b6f2e9 Original-Change-Id: Ia72cac7fda2772f26477e43237678fa30feca584 Original-Signed-off-by: Douglas Anderson <dianders@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/309541 Original-Reviewed-on: https://chromium-review.googlesource.com/309609 Original-Commit-Ready: David Hendricks <dhendrix@chromium.org> Original-Tested-by: David Hendricks <dhendrix@chromium.org> Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/12444 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-11-19edid: Use a better mode for 640x480Douglas Anderson
The hardcoded clock value for 640x480 was 25.175 MHz. That's a valid clock to use, but is quite hard to make a non-jittery clock from PLLs. It's much easier to make 25.200 MHz, so let's do that. The difference between the two modes is 59.9 Hz vs. 60 Hz and it seems better to make a non-jittery 60 Hz rather than a very jittery 59.9 Hz. BRANCH=none BUG=chrome-os-partner:46256 TEST=Insignia monitor works, so do others Change-Id: I8aa124d04a90f5dcf9cfa923ed3b693fbb4a06d8 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: e32ce13462101dc60cfed60b6948b7597e93525a Original-Change-Id: Ia9804afe8011a915e4bec306e863d34ad7e27be5 Original-Signed-off-by: Douglas Anderson <dianders@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/309540 Original-Reviewed-by: Stphane Marchesin <marcheu@chromium.org> Original-(cherry picked from commit 7f32c9f460991e5e3b947117d6ae4080e630a532) Original-Reviewed-on: https://chromium-review.googlesource.com/309576 Original-Commit-Ready: David Hendricks <dhendrix@chromium.org> Original-Tested-by: David Hendricks <dhendrix@chromium.org> Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/12443 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-11-19edid: Don't set standard timings as supported if they're notDouglas Anderson
The set to say that a standard timing was supported was not properly in the "if" test. That meant that even when standard timings weren't supported, we thought that they were. That had the side effect of never using the detailed mode. BRANCH=none BUG=chrome-os-partner:46998 TEST=Adafruit panel works now Change-Id: Ide3ed6c5682840f808d854755dac58e9057e6bda Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: c99d3ee8d163fc6be207c5a7df2a7aecd7af7849 Original-Change-Id: Ib67735219fd28516857d9b63f1ba156573f1bea3 Original-Signed-off-by: Douglas Anderson <dianders@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/309521 Original-(cherry picked from commit 4e4c2816e2239299bc02e3a57fb18056db62b56c) Original-Reviewed-on: https://chromium-review.googlesource.com/309552 Original-Commit-Ready: David Hendricks <dhendrix@chromium.org> Original-Tested-by: David Hendricks <dhendrix@chromium.org> Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/12442 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-11-19edid: Remove useless parameter from detailed_cvt_descriptor()Douglas Anderson
The detailed_cvt_descriptor() function takes a parameter "out" for no good reason. Remove it. BRANCH=none BUG=chrome-os-partner:46998 TEST=Build and boot Change-Id: I1042dba9ddf2b4b543bd07615013088be5055950 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 5c3474c9b1f9fb73f44d64d3a0592f92339da2df Original-Change-Id: I4d695a6dba6606d2132578ce0ab4cb612c83d0f4 Original-Signed-off-by: Douglas Anderson <dianders@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/309598 Original-(cherry picked from commit 39122e242e808d71a4e274e8a23e9a63f4984388) Original-Reviewed-on: https://chromium-review.googlesource.com/309496 Original-Commit-Ready: David Hendricks <dhendrix@chromium.org> Original-Tested-by: David Hendricks <dhendrix@chromium.org> Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/12441 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-11-17arm64: tegra132: tegra210: Remove old arm64/stage_entry.SJulius Werner
This patch removes the old arm64/stage_entry.S code that was too specific to the Tegra SoC boot flow, and replaces it with code that hides the peculiarities of switching to a different CPU/arch in ramstage in the Tegra SoC directories. BRANCH=None BUG=None TEST=Built Ryu and Smaug. !!!UNTESTED!!! Change-Id: Ib3a0448b30ac9c7132581464573efd5e86e03698 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/12078 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-11-11arm/arm64: Generalize bootblock C entry pointJulius Werner
When we first added ARM support to coreboot, it was clear that the bootblock would need to do vastly different tasks than on x86, so we moved its main logic under arch/. Now that we have several more architectures, it turns out (as with so many things lately) that x86 is really the odd one out, and all the others are trying to do pretty much the same thing. This has already caused maintenance issues as the ARM32 bootblock developed and less-mature architectures were left behind with old cruft. This patch tries to address that problem by centralizing that logic under lib/ for use by all architectures/SoCs that don't explicitly opt-out (with the slightly adapted existing BOOTBLOCK_CUSTOM option). This works great out of the box for ARM32 and ARM64. It could probably be easily applied to MIPS and RISCV as well, but I don't have any of those boards to test so I'll mark them as BOOTBLOCK_CUSTOM for now and leave that for later cleanup. BRANCH=None BUG=None TEST=Built Jerry and Falco, booted Oak. Change-Id: Ibbf727ad93651e388aef20e76f03f5567f9860cb Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/12076 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins)
2015-11-10edid: add hdmi_monitor_detected in data struct edidYakir Yang
HDMI driver need to know whether the monitor is DVI or HDMI interface, so this commit just introduce a new number 'hdmi_monitor_detected' to struct edid. There were four bits to indicate the monitor interfaces, it's better to take use of that. But those bits only existed in EDID 1.4 version, but didn't persented in the previous EDID version, so I decided to detect the hdmi cea block. BRANCH=none BUG=chrome-os-partner:43789 TEST=When mickey connect with HDMI monitor, see 'hdmi_monitor_detected' is 'true'. When mickey connect with DVI monitor, see 'hdmi_monitor_detected' is 'false'. Change-Id: I1a4f1410e1cce1474ffae858db161a18578cac3a Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 409f041805d9fdff2d49faa1a3a262cf4dc609c2 Original-Change-Id: Ife770898b0f2b4f58b8259711101a0cab4a5e4ac Original-Signed-off-by: Yakir Yang <ykk@rock-chips.com> Original-Reviewed-on: https://chromium-review.googlesource.com/309055 Original-Tested-by: David Hendricks <dhendrix@chromium.org> Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/12345 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-11-07arm64: remove secmonAaron Durbin
It's been decided to only support ARM Trusted Firmware for any EL3 monitor. That means any SoC that requires PSCI needs to add its support for ATF otherwise multi-processor bring up won't work. Change-Id: Ic931dbf5eff8765f4964374910123a197148f0ff Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/11897 Tested-by: build bot (Jenkins) Reviewed-by: Julius Werner <jwerner@chromium.org>
2015-11-03drivers/pc80: Rework normal / fallback selector codeTimothy Pearson
Per IRC and Gerrit discussion, the normal / fallback selector code is a rather weak spot in coreboot, and did not function correctly for certain use cases. Rework the selector to more clearly indicate proper operation, and also remove dead code. Also tentatively abandon use of RTC bit 385; a follow-up patch will remove said bit from all affected mainboards. The correct operation of the fallback code selector approximates that of a power line recloser, with a user option to attempt normal boot that can be cleared by firmware, but never set by firmware. Additionally, if cleared by user, the fallback path should always be used on the next reboot. Change-Id: I753ae9f0710c524875a85354ac2547df0c305569 Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com> Reviewed-on: http://review.coreboot.org/12289 Reviewed-by: Nico Huber <nico.h@gmx.de> Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2015-11-03cbmem: add coreboot table records for each cbmem entryAaron Durbin
In order to not expose the cbmem data structures to userland that are used by coreboot internally add each of the cbmem entries to a coreboot table record. The payload ABI uses coreboot tables so this just provides a shortcut for cbmem entries which were manually added previously by doing the work on behalf of all entries. A cursor structure and associated functions are added to the imd code for walking the entries in order to be placed in the coreboot tables. Additionally a struct lb_cbmem_entry is added that lists the base address, size, and id of the cbmem entry. BUG=chrome-os-partner:43731 BRANCH=None TEST=Booted glados. View coreboot table entries with cbmem. Change-Id: I125940aa1898c3e99077ead0660eff8aa905b13b Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/11757 Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Tested-by: build bot (Jenkins)
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-10-28jpeg: add jpeg_fetch_size()Patrick Georgi
This aids the fuzzer test case. Change-Id: Ic7d43b76cf5660e085e7b3b13499de0358c13197 Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-on: http://review.coreboot.org/12181 Reviewed-by: Martin Roth <martinroth@google.com> Tested-by: build bot (Jenkins)
2015-10-27boot_device: add call to boot_device_init()Aaron Durbin
In the program loading paths using vboot it's possible that the boot media has not been initiazed for that stage. Therefore, provide this call such that it's guaranteed to be called at least once. BUG=chrome-os-partner:44827 BRANCH=None TEST=Built and booted glados. Change-Id: I3a0ef4d9eebbf5f15780316cc76b469e8ac3f358 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 6ee0c5bb36d17fd80ba34762e7547359fd8971ce Original-Change-Id: If8dfeedbe1243ec482764e05c8d3f333c18aedd2 Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/305540 Original-Tested-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/12154 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-10-27coreboot: make lb_framebuffer a weak functionrobbie zhang
This is to support other gfx enable method such as Gfx Peim (AKA GOP) for Intel soc. BRANCH=none BUG=chrome-os-partner:44559 TEST=Built and boot on kunimitsu/glados. Change-Id: Ib8010ea6901ea906a8b4129807b94ace71ef1165 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: ad26a99560009c487070cccf6ab132188b9e247d Original-Change-Id: Id132718a8bcec5446cc4c0d9d636d26e8a99bb15 Original-Signed-off-by: robbie zhang <robbie.zhang@intel.com> Original-Reviewed-on: https://chromium-review.googlesource.com/303801 Original-Commit-Ready: Robbie Zhang <robbie.zhang@intel.com> Original-Tested-by: Robbie Zhang <robbie.zhang@intel.com> Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/12140 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-10-24lib/stack: Add stack overrun detectionTimothy Pearson
Change-Id: I9a59fcb7cf221ae590a047c520e7aff99e23ecf1 Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com> Reviewed-on: http://review.coreboot.org/11962 Tested-by: build bot (Jenkins) Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2015-10-20Revert "coreboot_table: don't add CMOS checksum twice."Nico Huber
This reverts commit e6606518243d9beda31693d40493b5f7a1a3e2e0. After some discussion on IRC we decided to revert it as libpayload can only read the copy that was removed (and other users like nvramtool can only read the other copy). So we need both copies at this time. Signed-off-by: Nico Huber <nico.h@gmx.de> Change-Id: I6cf6b2a1523d771bb52f3d5720b1b16ed4b348db Reviewed-on: http://review.coreboot.org/11696 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-10-16bootblock: Link timestamp.c only with EARLY_CBMEM_INITPaul Menzel
Commit dbeedbef (arch/x86/bootblock: Link in object files selected with bootblock-y) breaks building of x86 boards with `CONFIG_EARLY_CBMEM_INIT` *not* selected but CBMEM time stamp collection enabled. Aaron Durbin explained as below [1] and provided this patch to fix it. > That change actually processes bootblock-objs where before it never did > such a thing. I'm sure this isn’t the only issue lurking. bootblock on > x86 implied romcc and thus all the bootblock-y += rules that other > architectures use worked, but now all the implied assumptions are no > longer true on x86. > > timestamp stuff on x86 !CONFIG_EARLY_CBMEM_INIT is the issue you're > seeing. In order to compile timestamp.c for bootblock under these > conditions will mean there needs to be some more Makefile guarding. [1] http://review.coreboot.org/11864 Change-Id: I3441b9fcdbbc8bbe82b9f2075e60668a846ecf09 Fix-by: Aaron Durbin <adurbin@chromium.org> Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-on: http://review.coreboot.org/11875 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Tested-by: build bot (Jenkins)
2015-10-14x86: add standalone verstage supportAaron Durbin
To support x86 verstage one needs a working buffer for vboot. That buffer resides in the cache-as-ram region which persists across verstage and romstage. The current assumption is that verstage brings cache-as-ram up and romstage tears cache-as-ram down. The timestamp, cbmem console, and the vboot work buffer are persistent through in both romstage and verstage. The vboot work buffer as well as the cbmem console are permanently destroyed once cache-as-ram is torn down. The timestamp region is migrated. When verstage is enabled the assumption is that _start is the romstage entry point. It's currently expected that the chipset provides the entry point to romstage when verstage is employed. Also, the car_var_*() APIs use direct access when in verstage since its expected verstage does not tear down cache-as-ram. Lastly, supporting files were added to verstage-y such that an x86 verstage will build and link. BUG=chrome-os-partner:44827 BRANCH=None TEST=Built and booted glados using separate verstage. Change-Id: I097aa0b92f3bb95275205a3fd8b21362c67b97aa Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/11822 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-10-11cbfs: don't load x86 programs over the top of read-only mediaAaron Durbin
On x86 the early stages are currently execute-in-place which means they live in the memory-mapped spi flash. However, when loading romstage from verstage the romstage is execute-in-place so it's unnecessary to write over a read-only media -- not to mention writing to read-only memory is wrong to begin with. BUG=chrome-os-partner:44827 BRANCH=None TEST=Built and booted glados. Noted reduction of 20ms when loading romstage. Change-Id: I7cd399302a3925a05fbce82600b4c50ea66a0fcb Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/11823 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-10-11cbmem console: make verstage first class citizenAaron Durbin
The conditions in cbmem console for supporting verstage were implicitly utilizing CONFIG_BOOTBLOCK_CONSOLE to handle the cbmem console enablement. Fix it so verstage is a first class citizen for deciding actions pertaining to cbmem console. BUG=chrome-os-partner:44827 BRANCH=None TEST=Built and booted glados using verstage. cbmem console shows verstage output. Change-Id: Iba79efd1c1d4056f1a105a5e10ffc95f3e69b597 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/11820 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-10-11Derive lvds_dual_channel from EDID timings.Vladimir Serbinenko
Based on the info by Felix Held. Change-Id: Iab84dd8a0e3c942da20a6e21db5510e4ad16cadd Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com> Reviewed-on: http://review.coreboot.org/11857 Tested-by: build bot (Jenkins) Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2015-10-08lib/gcov-glue.c: Define macro `COVERAGE_MAGIC` and use itPaul Menzel
The macro is defined in `util/cbmem/cbmem.c` too, so do the same here, so that searching for that macro name shows all the usages. Change-Id: I52e9fa414fbbe2012bc6d00312db528efba3e564 Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-on: http://review.coreboot.org/11803 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Tested-by: build bot (Jenkins)
2015-10-07cbfs: add struct cbfsfAaron Durbin
Now that cbfs is adding more metadata in the cbfs file header one needs to access that metadata. Therefore, add struct cbfsf which tracks the metadata and data of the file separately. Note that stage and payload metadata specific to itself is still contained within the 'data' portion of a cbfs file. Update the cbfs API to use struct cbfsf. Additionally, remove struct cbfsd as there's nothing else associated with a cbfs region aside from offset and size which tracked by a region_device (thanks, CBFS_ALIGNMENT!). BUG=None BRANCH=None TEST=Built and booted through end of ramstage on qemu armv7. Built and booted glados using Chrome OS. Change-Id: I05486c6cf6cfcafa5c64b36324833b2374f763c2 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/11679 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-09-28program.ld: terminate ALIGN statementPatrick Georgi
This fixes building with CONFIG_COVERAGE=y Change-Id: I5128ae0ef0d4f71e3ede7bcb3ee7ed7e265d1bb7 Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-on: http://review.coreboot.org/11729 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-09-24coreboot: move TS_END_ROMSTAGE to one spotAaron Durbin
While the romstage code flow is not consistent across all mainboards/chipsets there is only one way of running ramstage from romstage -- run_ramstage(). Move the timestamp_add_now(TS_END_ROMSTAGE) to be within run_ramstage(). BUG=chrome-os-partner:44827 BRANCH=None TEST=Built and booted glados. TS_END_ROMSTAGE still present in timestamp table. Change-Id: I4b584e274ce2107e83ca6425491fdc71a138e82c Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/11700 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-09-22linking: link bootblock.elf with .data and .bss sections againAaron Durbin
Currently coreboot expects the loader to clear the bss section for all stages. i.e. stages don't clear their own bss. On ARM SoCs the BootROM would be responsible for this. To do that one needs to include the bss section data (all zeros) in the bootblock.bin file. This was previously being attempted by keeping the .bss info in the .data section because objcopy happened zero out non-file allocated data section data. Instead go back to linking bootblock with the bss section but mark the bss section as loadable allocatable data. That way it will be included in the binary properly when objcopy -O binary is emplyed. Also do the same for the data section in the case of no non-zero object values are in the data section. Without this change the trick of including .bss in .data was not working when there wasn't a non-zero value object in the data section. BUG=None BRANCH=None TEST=Built emulation/qemu-armv7 and noted bootblock.bin contains the cleared bss. Change-Id: I94bd404c2c4a8b9332393e6224e98940a9cad4a2 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/11680 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-09-22coreboot: introduce commonlibAaron Durbin
Instead of reaching into src/include and re-writing code allow for cleaner code sharing within coreboot and its utilities. The additional thing needed at this point is for the utilities to provide a printk() declaration within a <console/console.h> file. That way code which uses printk() can than be mapped properly to verbosity of utility parameters. Change-Id: I9e46a279569733336bc0a018aed96bc924c07cdd Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/11592 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
2015-09-17linking: Repair special treatments for non-x86 bootblocksJulius Werner
Patch b2a62622b (linking: move romstage and bootblock to use program.ld) unified the linker scripts between different stages. Unfortunately it omitted several special cases from the old bootblock.ld script that are required for non-x86 environments. This patch expands program.ld to once again merge the .BSS into the program image for bootblocks (ensuring correct initialization by the external loader). It also revives the .id section (which adds a human-readable blurb of information to the top of an image) and fixes a problem with unintended automated section alignment. BRANCH=None BUG=None TEST=Jerry and Oak boot again. Change-Id: I54271b8b59a9c773d858d676cde0218cb7f20e74 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 6fddbc00963e363039634fa31a9b66254b6cf18f Original-Change-Id: I4d748056f1ab29a8e730f861879982bdf4c33eab Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/299413 Original-Tested-by: Yidi Lin <yidi.lin@mediatek.com> Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/11660 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-09-09x86: link ramstage the same way regardless of RELOCATABLE_RAMSTAGEAaron Durbin
Previously there were 2 paths in linking ramstage. One was used for RELOCATABLE_RAMSTAGE while the other was fixed location. Now that rmodtool can handle multiple secitons for a single proram segment there's no need for linking ramstage using lib/rmodule.ld. That also means true rmodules don't have symbols required for ramstage purposes so fix memlayout.h. Lastly add default rules for creating rmod files from the known file names and locations. BUG=chrome-os-partner:44827 BRANCH=None TEST=Built rambi. Inspected ramstage.debug as well as rmodules created during the build. Change-Id: I98d249036c27cb4847512ab8bca5ea7b02ce04bd Signed-off-by: Aaron Durbin <adubin@chromium.org> Reviewed-on: http://review.coreboot.org/11524 Tested-by: build bot (Jenkins) Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com> Reviewed-by: Patrick Georgi <pgeorgi@google.com>