summaryrefslogtreecommitdiff
path: root/src/include
AgeCommit message (Collapse)Author
2016-05-25soc/intel/common: Add common smihandler codeHannah Williams
Provide default handler for some SMI events. Provide the framework for extracting data from SMM Save State area for processors with SMM revision 30100 and 30101. The SOC specific code should initialize southbridge_smi with event handlers. For SMM Save state handling, SOC code should implement get_smm_save_state_ops which initializes the SOC specific ops for SMM Save State handling. Change-Id: I0aefb6dbb2b1cac5961f9e43f4752b5929235df3 Signed-off-by: Hannah Williams <hannah.williams@intel.com> Reviewed-on: https://review.coreboot.org/14615 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
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-21device: Add an ACPI device name and path concept to devicesDuncan Laurie
Add a function to "struct device_operations" to return the ACPI name for the device, and helper functions to find this name (either from the device or its parent) and to build a fully qualified ACPI path from the root device. This addition will allow device drivers to generate their ACPI AML in the SSDT at boot, with customization supplied by devicetree.cb, instead of needing custom DSDT ASL for every mainboard. The root device acpi_name is defined as "\\_SB" and is used to start the path when building a fully qualified name. This requires SOC support to provide handlers for returning the ACPI name for devices that it owns, and those names must match the objects declared in the DSDT. The handler can be done either in each device driver or with a global handler for the entire SOC. Simplified example of how this can be used for an i2c device declared in devicetree.cb with: chip soc/intel/skylake # "\_SB" (from root device) device domain 0 on # "PCI0" device pci 19.2 on # "I2C4" chip drivers/i2c/test0 device i2c 1a.0 on end # "TST0" end end end end And basic SSDT generating code in the device driver: acpigen_write_scope(acpi_device_scope(dev)); acpigen_write_device(acpi_device_name(dev)); acpigen_write_string("_HID", "TEST0000"); acpigen_write_byte("_UID", 0); acpigen_pop_len(); /* device */ acpigen_pop_len(); /* scope */ Will produce this ACPI code: Scope (\_SB.PCI0.I2C4) { Device (TST0) { Name (_HID, "TEST0000") Name (_UID, 0) } } Change-Id: Ie149595aeab96266fa5f006e7934339f0119ac54 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://review.coreboot.org/14840 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
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-16sconfig: Add a new generic device typeDuncan Laurie
Add support for a basic generic device in the devicetree to bind to a device that does not have a specific bus, but may need to be described in tables for the operating system. For instance some chips may have various GPIO connections that need described but do not fall under any other device. In order to support this export the basic 'scan_static_bus()' that can be used in a device_operations->scan_bus() method to scan for the generic devices. It has been possible to get a semi-generic device by using a fake PNP device, but that isn't really appropriate for many devices. Also Re-generate the shipped files for sconfig. Use flex 2.6.0 to avoid everything being rewritten. Clean up the local paths that leak into the generated configs. Change-Id: If45a5b18825bdb2cf1e4ba4297ee426cbd1678e3 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://review.coreboot.org/14789 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Leroy P Leahy <leroy.p.leahy@intel.com>
2016-05-16sconfig: Add 10bit addressing mode to i2c device typeDuncan Laurie
Use the second token for an i2c device entry in devicetree.cb to indicate if it should use 10-bit addressing or 7-bit. The default if not provided is to use 7-bit addressing, but it can be changed to 10-bit addressing with the ".1" suffix. For example: chip drivers/i2c/generic device i2c 3a.1 on end end Change-Id: I1d81a7e154fbc040def4d99ad07966fac242a472 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://review.coreboot.org/14788 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-05-09drivers/uart: Enable override for input clock dividerLee Leahy
Allow the platform to override the input clock divider by adding the uart_input_clock_divider routine. This routine combines the baud-rate oversample divider with any other input clock divider. The default routine returns 16 which is the standard baud-rate oversampling value. A platform may override this default "weak" routine by providing a new routine and selecting UART_OVERRIDE_INPUT_CLOCK_DIVIDER. This works around ROMCC not supporting weak routines. 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: Ieb6453b045d84702b8f730988d0fed9f253f63e2 Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com> Reviewed-on: https://review.coreboot.org/14611 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2016-05-06cpu/x86/mp_init: reduce exposure of internal implementationAaron Durbin
With all users converted to using the mp_ops callbacks there's no need to expose that surface area. Therefore, keep it all within the mp_init compilation unit. Change-Id: Ia1cc5326c1fa5ffde86b90d805b8379f4e4f46cd Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/14598 Tested-by: build bot (Jenkins) Reviewed-by: Duncan Laurie <dlaurie@google.com> Reviewed-by: Furquan Shaikh <furquan@google.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-04cpu/x86: combine multiprocessor and SMM initializationAaron Durbin
In order to reduce code duplication provide a common flow through callback functions that performs the multiprocessor and optionally SMM initialization. The existing MP flight records are utilized but a common flow is provided such that the chipset/cpu only needs to provide a mp_ops structure which has callbacks to gather info and provide hooks at certain points in the sequence. All current users of the MP code can be switched over to this flow since there haven't been any flight records that are overly complicated and long. After the conversion has taken place most of the surface area of the MP API can be hidden away within the compilation unit proper. Change-Id: I6f70969631012982126f0d0d76e5fac6880c24f0 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/14557 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2016-05-04cpu/x86/smm_module_loader: always build with SMM module supportAaron Durbin
The SMM module loader code was guarded by CONFIG_SMM_TSEG, however that's not necessary. It's up to the chipset to take advantage of the SMM module loading. It'll get optimized out if the code isn't used anyway so just expose the declarations. Change-Id: I6ba1b91d0c84febd4f1a92737b3d7303ab61b343 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/14560 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com> Reviewed-by: Furquan Shaikh <furquan@google.com>
2016-05-02cpu/x86/mp_init: remove unused callback argumentsAaron Durbin
The BSP and AP callback declarations both had an optional argument that could be passed. In practice that functionality was never used so drop it. Change-Id: I47fa814a593b6c2ee164c88d255178d3fb71e8ce Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/14556 Tested-by: build bot (Jenkins) Reviewed-by: Werner Zeh <werner.zeh@siemens.com> Reviewed-by: Leroy P Leahy <leroy.p.leahy@intel.com> Reviewed-by: Furquan Shaikh <furquan@google.com>
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-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-19kbuild: Allow drivers to fit src/drivers/[X]/[Y]/ schemeStefan Reinauer
Reorder drivers to fit src/drivers/[X]/[Y]/ scheme to make them pluggable. Also, fix up the following driver subdirectories by switching to the src/drivers/[X]/[Y]/ scheme as these are hard requirements for the main change: * drivers/intel * drivers/pc80 * drivers/dec Change-Id: I455d3089a317181d5b99bf658df759ec728a5f6b Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-on: https://review.coreboot.org/14047 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2016-04-15stddef.h: fix zeroptr's definitionPatrick Georgi
As Aaron pointed out, the old definition made the compiler emit two memory accesses, to 0 (for derefencing) and then reading at whatever address could be read from there. Change-Id: I5cdd53f5bd2d2397c43f09f3e5fa46be08744b01 Found-by: Aaron Durbin <adurbin@chromium.org> Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/14342 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.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-29cbmem: Add comment for cbmem_top returning NULL if backing store is not readyFurquan Shaikh
Board or chipset needs to ensure that cbmem backing store is ready when returning the cbmem top address. cbmem infrastructure has no support for checking the validity of the backing store/address. E.g.: If romstage handles cbmem coming online, chipset or board need to ensure that call to cbmem_top in romstage returns NULL if the backing store is not yet initialized. Add a comment to ensure that developers know this requirement while implementing cbmem_top for future chipsets/boards. Change-Id: I0086b8e528f65190b764a84365cf9bf970b69c3f Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/14181 Tested-by: build bot (Jenkins) Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
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-21device: Add i2c read/write register field APIYidi Lin
i2c_read_field() - read the value from the specific register field i2c_write_field() - write the value to the specific register field BRANCH=none BUG=none TEST=none Change-Id: I2098715b4583c1936c93b3ff45ec330910964304 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 0817fc76d07491b39c066f1393a6435f0831b50c Original-Change-Id: I92c187a89d10cfcecf3dfd9291e0bc015459c393 Original-Signed-off-by: Yidi Lin <yidi.lin@mediatek.com> Original-Reviewed-on: https://chromium-review.googlesource.com/332712 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/14105 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Martin Roth <martinroth@google.com>
2016-03-18mtrr: Define a function for obtaining free var mtrrFurquan Shaikh
Instead of hard-coding var mtrr numbers in code, use this function to identify the first available variable mtrr. If no such mtrr is available, the function will return -1. Change-Id: I2a1e02cdb45c0ab7e30609641977471eaa2431fd Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/14115 Tested-by: build bot (Jenkins) Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
2016-03-12device/i2c: Add i2c_read_bytes() APIJitao Shi
Add multi-bytes read support. BRANCH=none BUG=none TEST=saw edid log and dev screen Change-Id: I106be98e751e2a3b998ccaedb28f71f3c6e18994 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 94ee0b834947e8d971943aa24e61a9353c7b7306 Original-Change-Id: Iac5fe497da92b7d09383e0d6a04d98709aea5b20 Original-Signed-off-by: Jitao Shi <jitao.shi@mediatek.com> Original-Reviewed-on: https://chromium-review.googlesource.com/325211 Original-Commit-Ready: Yidi Lin <yidi.lin@mediatek.com> Original-Tested-by: Yidi Lin <yidi.lin@mediatek.com> Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/13978 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
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-09lib/memrange: add function to initialize range_entryAaron Durbin
In order to enforce the semantics of struct range_entry provide an init function, range_entry_init(), which performs the field initialization to adhere to the internal struture's assumptions. Change-Id: I24b9296e5bcf4775974c9a8d6326717608190215 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/13956 Reviewed-by: Furquan Shaikh <furquan@google.com> Tested-by: build bot (Jenkins) Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
2016-03-08cpu/x86/mtrr: add helper function to detect variable MTRRsAaron Durbin
The current MTRR API doesn't allow one to detect variable MTRRs along with handling fixed MTRRs in one function call. Therefore, add x86_setup_mtrrs_with_detect() to perform the same actions as x86_setup_mtrrs() but always do the dynamic detection. Change-Id: I443909691afa28ce11882e2beab12e836e5bcb3d Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/13935 Reviewed-by: Furquan Shaikh <furquan@google.com> Tested-by: build bot (Jenkins)
2016-03-05include/device/dram: Fix DDR3-1866Patrick Rudolph
The PLL multiplier value is off by one for DDR3-1866 due to a wrong TCK value, resulting in DDR3-1600 being used by the PLL. Needs test on real hardware ! Change-Id: I657b813889945f0d9990dd11680a3d3a25b53467 Signed-off-by: Patrick Rudolph <siro@das-labor.org> Reviewed-on: https://review.coreboot.org/13613 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2016-03-03src/device/dram/ddr3: Parse additional informationPatrick Rudolph
Parse manufacturer id and ASCII serial. Required for SMBIOS type 17 field. Change-Id: I710de1a6822e4777c359d0bfecc6113cb2a5ed8e Signed-off-by: Patrick Rudolph <siro@das-labor.org> Reviewed-on: https://review.coreboot.org/13862 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2016-03-02nb/intel/sandybridge/romstage: Read fuse bits for max MEM ClkPatrick Rudolph
Instead of hardcoding the maximum supported DDR frequency to 800Mhz (DDR3-1600), read the fuse bits that encode this information. Test system: * Intel IvyBridge * Gigabyte GA-B75M-D3H Change-Id: I515a2695a490f16aeb946bfaf3a1e860c607cba9 Signed-off-by: Patrick Rudolph <siro@das-labor.org> Reviewed-on: https://review.coreboot.org/13487 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
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-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-22memlayout: Add symbols for stage boundsJulius Werner
Stages are inconsistent with other memlayout regions in that they don't have _<name> and _e<name> symbols defined. We have _program and _eprogram, but that always only refers to the current stage and _eprogram marks the actual end of the executable's memory footprint, not the end of the area allocated in memlayout. Both of these are sometimes useful to know, so let's add another set of symbols that allow the stage areas to be treated more similarly to other regions. Change-Id: I9e8cff46bb15b51c71a87bd11affb37610aa7df9 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/13737 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-02-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-20nb/intel/sandybridge/raminit: Add XMP supportPatrick Rudolph
Some vendors store lower frequency profiles in the regular SPD, if the SPD contains a XMP profile. To make use of the board's and DIMM's maximum supported DRAM frequency, try to parse the XMP profile and use it instead. Validate the XMP profile to make sure that the installed DIMM count per channel is supported and the requested voltage is supported. To reduce complexity only XMP Profile 1 is read. Allows my DRAM to run at 800Mhz instead of 666Mhz as encoded in the default SPD. Test system: * Gigabyte GA-B75M-D3H * Intel Pentium CPU G2130 Change-Id: Ib4dd68debfdcfdce138e813ad5b0e8e2ce3a40b2 Signed-off-by: Patrick Rudolph <siro@das-labor.org> Reviewed-on: https://review.coreboot.org/13486 Reviewed-by: Martin Roth <martinroth@google.com> Tested-by: build bot (Jenkins)
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-18device: Add device path display supportLee Leahy
Add an optional routine to translate the device path types into a string for display. TEST=Build and run on Galileo Change-Id: Iea5d0a2430d9a8546105324e2beda0955210dca9 Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com> Reviewed-on: https://review.coreboot.org/13715 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.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-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-11arches: lib: add main_decl.h for main() declarationAaron Durbin
It is silly to have a single header to declare the main() symbol, however some of the arches provided it while lib/bootblock.c relied on the arch headers to declare it. Just move the declaration into its own header file and utilize it. Change-Id: I743b4c286956ae047c17fe46241b699feca73628 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/13681 Reviewed-by: Patrick Georgi <pgeorgi@google.com> Tested-by: build bot (Jenkins)
generated by cgit v1.2.3 (git 2.25.1) at 2024-12-20 04:20:57 +0000