summaryrefslogtreecommitdiff
path: root/src/drivers
AgeCommit message (Collapse)Author
2015-08-29intel/fsp1_1/hob.c: Refactor file to match coreboot coding styleAlexandru Gagniuc
Avoid ASSERT() when a better solution exists, avoid UPPERCASE types when C99 types exist, and use stdlib functions where possible. Change-Id: Ia40ec8ff34ec82994b687d517dc4b145fb58716c Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-on: http://review.coreboot.org/11455 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-08-29drivers/intel/fsp1_1: Don't compile GOP support in romstageAlexandru Gagniuc
We don't need the code in romstage, and it saves us a few #ifdefs. Change-Id: I26d867566f07c7d80890cd01bf055be7497130d3 Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-on: http://review.coreboot.org/11457 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-08-29fsp1_1: remove duplicate mrc caching mechanismAaron Durbin
For some reason fsp 1.1 has a duplicate mechanism for saving mrc data as soc/intel/common. Defer to the common code as all the existing users were already using the common code. BUG=chrome-os-partner:44620 BRANCH=None TEST=Built and booted glados. Suspended and resumed. Change-Id: I951d47deb85445a5f010d23dfd11abb0b6f65e5e Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Original-Commit-Id: 2138b6ff1517c440d24f72a5f399bd6cb6097274 Original-Change-Id: I06609c1435b06b1365b1762f83cfcba532eb8c7a Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/295236 Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/11454 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins)
2015-08-28edid: Use edid_mode struct to reduce redundancyDavid Hendricks
This replaces various timing mode parameters parameters with an edid_mode struct within the edid struct. BUG=none BRANCH=firmware-veyron TEST=built and booted on Mickey, saw display come up, also compiled for link,falco,peppy,rambi,nyan_big,rush,smaug [pg: extended to also cover peach_pit, daisy and lenovo/t530] Change-Id: Icd0d67bfd3c422be087976261806b9525b2b9c7e Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Original-Commit-Id: abcbf25c81b25fadf71cae106e01b3e36391f5e9 Original-Change-Id: I1bfba5b06a708d042286db56b37f67302f61fff6 Original-Signed-off-by: David Hendricks <dhendrix@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/289964 Original-Reviewed-by: Yakir Yang <ykk@rock-chips.com> Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/11388 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-08-14fsp1_1: fsp_relocate: use struct region_device and struct progAaron Durbin
Using struct prog and struct region_device allows for the caller to be none-the-wiser about where FSP gets placed. It also allows for the source location to be abstracted away such that it doesn't require a large mapping up front to do the relocation. Lastly, it allows for simplifying the intel/commmon FSP support in that it can pass around a struct prog. BUG=chrome-os-partner:43636 BRANCH=None TEST=Built, booted, suspended, and resumed on glados. Original-Change-Id: I034b04ab2b7e9e01f5ee14fcc190f04b90517d30 Original-Signed-off-by: Aaron Durbin <adurbin@chroumium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/290830 Original-Tested-by: Aaron Durbin <adurbin@chromium.org> Original-Reviewed-by: Leroy P Leahy <leroy.p.leahy@intel.com> Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org> Original-Commit-Queue: Aaron Durbin <adurbin@chromium.org> Change-Id: Ibe1f206a9541902103551afaf212418fcc90e73c Signed-off-by: Aaron Durbin <adurbin@chroumium.org> Reviewed-on: http://review.coreboot.org/11193 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-08-13uart8250mem: provide uart_fill_lb()Aaron Durbin
There was no implementation for uart_fill_lb() in the 8250mem driver. Rectify this so when 8250MEM and CONSOLE_SERIAL are employed then the build doesn't fail. BUG=chrome-os-partner:43419 BRANCH=None TEST=Built with glados using 8250MEM Original-Change-Id: I35d6b15e47989c1854ddcee9c6d46711edffaf3e Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/289899 Original-Reviewed-by: Patrick Georgi <pgeorgi@chromium.org> Change-Id: I972b069a4def666f509268816de91ed6c0f655d9 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/11169 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-08-09drivers/pc80/i8254.c: Indent with GNU indent 2.2.11Paul Menzel
Run `indent -linux src/drivers/pc80/i8254.c` and manually put the `;` in the while loop back on a separate line. Change-Id: I58c4c5df3846a91ef92aafb608962dc26a21f811 Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-on: http://review.coreboot.org/10452 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-07-29arm, arm64, mips: Add rough static stack size checks with -Wstack-usageJulius Werner
We've seen an increasing need to reduce stack sizes more and more for space reasons, and it's always guesswork because no one has a good idea how little is too litte. We now have boards with 3K and 2K stacks, and old pieces of common code often allocate large temporary buffers that would lead to very dangerous and hard to detect bugs when someone eventually tries to use them on one of those. This patch tries improve this situation at least a bit by declaring 2K as the minimum stack size all of coreboot code should work with. It checks all function frames with -Wstack-usage=1536 to make sure we don't allocate more than 1.5K in a single buffer. This is of course not a perfect test, but it should catch the most common situation of declaring a single, large buffer in some close-to-leaf function (with the assumption that 0.5K is hopefully enough for all the "normal" functions above that). Change one example where we were a bit overzealous and put a 1K buffer into BSS back to stack allocation, since it actually conforms to this new assumption and frees up another kilobyte of that highly sought-after verstage space. Not touching x86 with any of this since it's lack of __PRE_RAM__ BSS often requires it to allocate way more on the stack than would usually be considered sane. BRANCH=veyron BUG=None TEST=Compiled Cosmos, Daisy, Falco, Blaze, Pit, Storm, Urara and Pinky, made sure they still build as well as before and don't show any stack usage warnings. Change-Id: Idc53d33bd8487bbef49d3ecd751914b0308006ec Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 8e5931066575e256dfc2295c3dab7f0e1b65417f Original-Change-Id: I30bd9c2c77e0e0623df89b9e5bb43ed29506be98 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/236978 Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9729 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-07-21console: Add UART8250MEM 32bit supportNaveen Krishna Chatradhi
This patch adds UART8250MEM_32 feature flag to support UART8250 compatible with 32bit access in memory mapped mode. [pg: rebuilt to reuse the existing UART8250 8bit access driver which reduces code duplication.] Change-Id: I310e70dfab81dcca575e9931e0ccf93af70efa40 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 0c3b2c628b854e8334540ff5158c2587dbfabf95 Original-Change-Id: I07ee256f25e48480372af9a9255bf487c331e51d Original-Signed-off-by: Rishavnath Satapathy <rishavnath.satapathy@intel.com> Original-Signed-off-by: Naveen Krishna Chatradhi <naveenkrishna.ch@intel.com> Original-Reviewed-on: https://chromium-review.googlesource.com/271759 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Original-Tested-by: Wenkai Du <wenkai.du@intel.com> Original-Commit-Queue: Wenkai Du <wenkai.du@intel.com> Reviewed-on: http://review.coreboot.org/10998 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2015-07-12Verify Kconfigs symbols are not zero for hex and int type symbolsMartin Roth
For hex and int type kconfig symbols, IS_ENABLED() doesn't work. Instead check to make sure they're defined and not zero. In some cases, zero might be a valid value, but it didn't look like zero was valid in these cases. Change-Id: Ib51fb31b3babffbf25ed3ae4ed11a2dc9a4be709 Signed-off-by: Martin Roth <gaumless@gmail.com> Reviewed-on: http://review.coreboot.org/10886 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-07-10FSP 1.1: Update the CBFS image typeLee Leahy
Update Makefile.inc to use the simplified CBFS image type. BRANCH=none BUG=None TEST=Build and run on cyan Change-Id: Ibb8413ab90b147e9d26d32639a8822c57ca54a46 Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com> Reviewed-on: http://review.coreboot.org/10871 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins)
2015-06-30drivers/i2c/tpm: move tpm driver around a bit more.Patrick Georgi
The many different places to put vboot support in can be confusing. Instead of using libverstage (which isn't enough since those functions are sometimes called outside that, too), mention all stages where it can resides explicitly. Change-Id: Idddb9f5e2ef7bcc273f429d9f432bd37b4573567 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/10728 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-06-30drivers/i2c/tpm: push tpm driver from verstage to libverstagePatrick Georgi
That way it's available wherever the verstage code ends up, bootblock, verstage or romstage. Change-Id: I0665e297f199acd60cff93e1b39812f183115d33 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/10707 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-06-27Kconfig: Remove unnecessary and incorrect MRC_CACHE symbolsMartin Roth
Because of a misunderstanding of how Kconfig files are parsed, the OVERRIDE_MRC_CACHE_LOC symbol was added to make sure that the value was correctly set. This is not needed unless for some reason the Kconfig parser is suddenly rewritten to parse everything differently. At some point, the value in the FSP's Kconfig file was updated to OVERRIDE_CACHE_CACHE_LOC, while the entries in the mainboard Kconfig files were not updated. This resulted in the default values not getting set correctly by default on the FSP Bay Trail boards. This removes the whole bunch of incorrect and unnecessary symbols and just sets the default for the MRC cache location directly. Change-Id: I1cec758576866b7e0677272b8309bfde8d4a1ee4 Signed-off-by: Martin Roth <gaumless@gmail.com> Reviewed-on: http://review.coreboot.org/10611 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-06-25Intel FSP 1.1: Move Kconfig comment inside 'if' blockMartin Roth
- Move the 'Intel FSP' Kconfig comment inside the 'if' block so that it doesn't show up on platforms that aren't using it. - Update the comment to reflect that this is version 1.1 of the FSP interface. Change-Id: I7182c5b07332c4f95620f7374526ab1de0484d01 Signed-off-by: Martin Roth <gaumless@gmail.com> Reviewed-on: http://review.coreboot.org/10650 Tested-by: build bot (Jenkins) Reviewed-by: Leroy P Leahy <leroy.p.leahy@intel.com>
2015-06-24FSP 1.1: Bring source up-to-dateLee Leahy
Use 3rdparty/blobs subdirectory for binary files Display the MTRRs after TempRamExit and before the MTRR setup Clear all of the variable MTRRs before the MTRR setup Define the FSP attributes location and bits Properly display the FSP_RESERVED_MEMORY_RESOURCE_HOB and the FSP_BOOTLOADER_TOLUM_HOB. BRANCH=none BUG=None TEST=Build and run on cyan Change-Id: I788a5f1e7676b1a06c1bcd66ddbd0a2249cad47c Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com> Reviewed-on: http://review.coreboot.org/10589 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-06-11lenovo: Hide SMBIOS configVladimir Serbinenko
It's derived from EEPROM on Lenovo machines and not from user config which is ignored. Change-Id: I54fb76a3160e47cd36d33d2937c4bfaddcd36a69 Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com> Reviewed-on: http://review.coreboot.org/7055 Tested-by: build bot (Jenkins) Reviewed-by: Nicolas Reinecke <nr@das-labor.org>
2015-06-09cbmem: add indicator to hooks if cbmem is being recoveredAaron Durbin
It can be helpful to certain users of the cbmem init hooks to know if recovery was done or not. Therefore, add this as a parameter to the hooks. Change-Id: I049fc191059cfdb8095986d3dc4eee9e25cf5452 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/10480 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-06-09cbmem: Unify CBMEM init tasks with CBMEM_INIT_HOOK() APIKyösti Mälkki
Squashed and adjusted two changes from chromium.git. Covers CBMEM init for ROMTAGE and RAMSTAGE. cbmem: Unify random on-CBMEM-init tasks under common CBMEM_INIT_HOOK() API There are several use cases for performing a certain task when CBMEM is first set up (usually to migrate some data into it that was previously kept in BSS/SRAM/hammerspace), and unfortunately we handle each of them differently: timestamp migration is called explicitly from cbmem_initialize(), certain x86-chipset-specific tasks use the CAR_MIGRATION() macro to register a hook, and the CBMEM console is migrated through a direct call from romstage (on non-x86 and SandyBridge boards). This patch decouples the CAR_MIGRATION() hook mechanism from cache-as-RAM and rechristens it to CBMEM_INIT_HOOK(), which is a clearer description of what it really does. All of the above use cases are ported to this new, consistent model, allowing us to have one less line of boilerplate in non-CAR romstages. BRANCH=None BUG=None TEST=Built and booted on Nyan_Blaze and Falco with and without CONFIG_CBMEM_CONSOLE. Confirmed that 'cbmem -c' shows the full log after boot (and the resume log after S3 resume on Falco). Compiled for Parrot, Stout and Lumpy. Original-Change-Id: I1681b372664f5a1f15c3733cbd32b9b11f55f8ea Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/232612 Reviewed-by: Aaron Durbin <adurbin@chromium.org> cbmem: Extend hooks to ramstage, fix timestamp synching Commit 7dd5bbd71 (cbmem: Unify random on-CBMEM-init tasks under common CBMEM_INIT_HOOK() API) inadvertently broke ramstage timestamps since timestamp_sync() was no longer called there. Oops. This patch fixes the issue by extending the CBMEM_INIT_HOOK() mechanism to the cbmem_initialize() call in ramstage. The macro is split into explicit ROMSTAGE_/RAMSTAGE_ versions to make the behavior as clear as possible and prevent surprises (although just using a single macro and relying on the Makefiles to link an object into all appropriate stages would also work). This allows us to get rid of the explicit cbmemc_reinit() in ramstage (which I somehow accounted for in the last patch without realizing that timestamps work exactly the same way...), and replace the older and less flexible cbmem_arch_init() mechanism. Also added a size assertion for the pre-RAM CBMEM console to memlayout that could prevent a very unlikely buffer overflow I just noticed. BRANCH=None BUG=None TEST=Booted on Pinky and Falco, confirmed that ramstage timestamps once again show up. Compile-tested for Rambi and Samus. Original-Change-Id: If907266c3f20dc3d599b5c968ea5b39fe5c00e9c Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/233533 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Change-Id: I1be89bafacfe85cba63426e2d91f5d8d4caa1800 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Signed-off-by: Marc Jones <marc.jones@se-eng.com> Reviewed-on: http://review.coreboot.org/7878 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-06-08Remove empty lines at end of fileElyes HAOUAS
Used command line to remove empty lines at end of file: find . -type f -exec sed -i -e :a -e '/^\n*$/{$d;N;};/\n$/ba' {} \; Change-Id: I816ac9666b6dbb7c7e47843672f0d5cc499766a3 Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: http://review.coreboot.org/10446 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-06-07Fix Kconfig whitespace.Martin Roth
All other Kconfig locations start with tabs. Change-Id: I0ee5f0b0b82f85c8ae58b3626f142f159554efb3 Signed-off-by: Martin Roth <gaumless@gmail.com> Reviewed-on: http://review.coreboot.org/10438 Tested-by: build bot (Jenkins) Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2015-06-04devicetree: Discriminate device ops scan_bus()Kyösti Mälkki
Use of scan_static_bus() and tree traversals is somewhat convoluted. Start cleaning this up by assigning each path type with separate static scan_bus() function. For ME, SMBus and LPC paths a bus cannot expose bridges, as those would add to the number of encountered PCI buses. Change-Id: I8bb11450516faad4fa33b8f69bce5b9978ec75e5 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/8534 Tested-by: build bot (Jenkins) Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
2015-06-04Remove address from GPLv2 headersPatrick Georgi
Follow up for commit b890a12, some contributions brought back a number of FSF addresses, so get rid of them again. Change-Id: Idcd059f05523916f726b94931c2487ab028b7d72 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/10409 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
2015-06-02tpm: Add dummy _DSM to make Bitlocker happy.Vladimir Serbinenko
Change-Id: Ieb6f70f5b2863336bd6143b2dfbb1d67c4c26109 Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com> Reviewed-on: http://review.coreboot.org/10323 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-06-02Hide PLATFORM_USES_FSP1_1.Vladimir Serbinenko
This should be an internal selectable variable rather than user-visible config. Moreover the description is misleading. This is a typical case of an option "Should it work?" where there is only one right answer yet we still ask it. Change-Id: Idc0ce2e1b9f89eddd034966cc877483d994ce0eb Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com> Reviewed-on: http://review.coreboot.org/10378 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-06-02cbfs: new API and better program loadingAaron Durbin
A new CBFS API is introduced to allow making CBFS access easier for providing multiple CBFS sources. That is achieved by decoupling the cbfs source from a CBFS file. A CBFS source is described by a descriptor. It contains the necessary properties for walking a CBFS to locate a file. The CBFS file is then decoupled from the CBFS descriptor in that it's no longer needed to access the contents of the file. All of this is accomplished using the regions infrastructure by repsenting CBFS sources and files as region_devices. Because region_devices can be chained together forming subregions this allows one to decouple a CBFS source from a file. This also allows one to provide CBFS files that came from other sources for payload and/or stage loading. The program loading takes advantage of those very properties by allowing multiple sources for locating a program. Because of this we can reduce the overhead of loading programs because it's all done in the common code paths. Only locating the program is per source. Change-Id: I339b84fce95f03d1dbb63a0f54a26be5eb07f7c8 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9134 Tested-by: build bot (Jenkins) Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-06-02TPM: Add Infineon SLB9670 SPI TPM supportWenkai Du
This patch provides support for TPM Infineon SLB9670 by adding its device ID to the list. BRANCH=None BUG=chrome-os-partner:40640 TEST=Built and test SLB9670 on SKL U Reference board Fab 2 Change-Id: I2d26fc6c7d074881f2e6189e1325808544b7d26d Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 3c92884be75b631c302801e162292c245ed7bf5d Original-Change-Id: I4607fc96f70175b2461b40ba61e7a821e187de40 Original-Signed-off-by: Wenkai Du <wenkai.du@intel.com> Original-Reviewed-on: https://chromium-review.googlesource.com/274053 Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/10387 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-05-29tpm: Add Infineon TPM 1.2 supportSubrata
This patch provides support for TPM Infineon TT1.2 devices by enumerating the TT1.2 ID in the Infineon device list. BRANCH=None BUG=None TEST=Built for sklrvp and tested on RVP3. Change-Id: I9daecc09311477fd9947e829d80abc040b2c9e3d Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 3ff86f96cb3e2f203dbc86e7004f1a037b98b90a Original-Change-Id: I8b59eba348fc44632e22600646eb0b10eb2f4901 Original-Signed-off-by: Subrata <subrata.banik@intel.com> Original-Reviewed-on: https://chromium-review.googlesource.com/271256 Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org> Original-Commit-Queue: Naveenkrishna Ch <naveenkrishna.ch@intel.com> Original-Tested-by: Naveenkrishna Ch <naveenkrishna.ch@intel.com> Reviewed-on: http://review.coreboot.org/10302 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Philipp Deppenwiese <zaolin@das-labor.org>
2015-05-29tpm: Fix multiple device supportSubrata
Current TPM driver does not support multiple devices for a given vendor. As the device object never takes the 2nd ID in the list. This patch fixes the same. BRANCH=None BUG=None TEST=Built for sklrvp and tested on RVP3. Change-Id: I82c3267c6c74b22650fc53dc6abdc2eb3daa138e Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: ff42613f11b4f1a79e907601f1ecb7b83a3aeaab Original-Change-Id: Ieb44735c37208bfe90a8e22e0348dd41c8c642d2 Original-Signed-off-by: Subrata <subrata.banik@intel.com> Original-Reviewed-on: https://chromium-review.googlesource.com/271727 Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org> Original-Commit-Queue: Naveenkrishna Ch <naveenkrishna.ch@intel.com> Original-Tested-by: Naveenkrishna Ch <naveenkrishna.ch@intel.com> Original-Commit-Queue: Pravin K Angolkar <pravin.k.angolkar@intel.com> Original-Tested-by: Pravin K Angolkar <pravin.k.angolkar@intel.com> Reviewed-on: http://review.coreboot.org/10303 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Philipp Deppenwiese <zaolin@das-labor.org>
2015-05-28Remove leftover tseg_relocateVladimir Serbinenko
Change-Id: I534f992ed479c7cdc049bd598259b1f1cf2953b9 Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com> Reviewed-on: http://review.coreboot.org/10354 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-05-28igd.asl rewriteVladimir Serbinenko
Old igd.asl had inconsistent addresses (between _DOD and actual device) and ghost devices. Any of those is enough to make brightness on windows fail and make igd.asl out-of-ACPI-spec. Also old code favoured ridiculous copying of the same thing 6 times per chipset. Leave only hooking up and chipset-specific part in chipset directory. Move NVS handling and ACPI-spec parts to a common file. Change-Id: I556769e5e28b83e7465e3db689e26c8c0ab44757 Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com> Reviewed-on: http://review.coreboot.org/7472 Tested-by: build bot (Jenkins) Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com> Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
2015-05-28Remove address from GPLv2 headersPatrick Georgi
Follow up for commit b890a12, some contributions brought back a number of FSF addresses, so get rid of them again. Change-Id: I0ac0c957738ce512deb0ed82b2219ef90d96d46b Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/10322 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2015-05-27Deactivate TPMVladimir Serbinenko
Just not exporting TPM isn't good enough as it can still be accessed. You need to send it a deactivate command. Change-Id: I3eb84660949c2d1e2b492d541e01d4ba78037630 Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com> Reviewed-on: http://review.coreboot.org/10270 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-05-27Move TPM code out of chromeosVladimir Serbinenko
This code is not specific to ChromeOS and is useful outside of it. Like with small modifications it can be used to disable TPM altogether. Change-Id: I8c6baf0a1f7c67141f30101a132ea039b0d09819 Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com> Reviewed-on: http://review.coreboot.org/10269 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-05-26fmap: new API using region_deviceAaron Durbin
Instead of being pointer based use the region infrastrucutre. Additionally, this removes the need for arch-specific compilation paths. The users of the new API can use the region APIs to memory map or read the region provided by the new fmap API. Change-Id: Ie36e9ff9cb554234ec394b921f029eeed6845aee Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9170 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-05-23Hide TPM_TIS_BASE_ADDRESSVladimir Serbinenko
TPM_TIS_BASE_ADDRESS is technical setting, shouldn't be user-visible. Change-Id: Ibf74f52be16fb7d2cfa78419087a4c3e7607368a Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com> Reviewed-on: http://review.coreboot.org/10271 Tested-by: build bot (Jenkins) Reviewed-by: Philipp Deppenwiese <zaolin@das-labor.org>
2015-05-23drivers/intel: Update FSP 1.1 DriverLee Leahy
Update the FSP driver files from 1.0 to 1.1. Updates will occur manually to these files only for FSP 1.1 support. An fsp_x_y should be added in the future to support newer versions of the FSP specification. Please note that due to the interface with EDK2, these files make references to data structures and fields that use CamelCase. BRANCH=none BUG=None TEST=Build for Braswell or Skylake boards using FSP 1.1. Change-Id: I2914c047d786a3060075356783ac9758bc41f633 Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com> Reviewed-on: http://review.coreboot.org/10049 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-05-21Remove address from GPLv2 headersPatrick Georgi
As per discussion with lawyers[tm], it's not a good idea to shorten the license header too much - not for legal reasons but because there are tools that look for them, and giving them a standard pattern simplifies things. However, we got confirmation that we don't have to update every file ever added to coreboot whenever the FSF gets a new lease, but can drop the address instead. util/kconfig is excluded because that's imported code that we may want to synchronize every now and then. $ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, *MA[, ]*02110-1301[, ]*USA:Foundation, Inc.:" {} + $ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin Street, Suite 500, Boston, MA 02110-1335, USA:Foundation, Inc.:" {} + $ find * -type f -exec sed -i "s:Foundation, Inc., 59 Temple Place[-, ]*Suite 330, Boston, MA *02111-1307[, ]*USA:Foundation, Inc.:" {} + $ find * -type f -exec sed -i "s:Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.:Foundation, Inc.:" {} + $ find * -type f -a \! -name \*.patch \ -a \! -name \*_shipped \ -a \! -name LICENSE_GPL \ -a \! -name LGPL.txt \ -a \! -name COPYING \ -a \! -name DISCLAIMER \ -exec sed -i "/Foundation, Inc./ N;s:Foundation, Inc.* USA\.* *:Foundation, Inc. :;s:Foundation, Inc. $:Foundation, Inc.:" {} + Change-Id: Icc968a5a5f3a5df8d32b940f9cdb35350654bef9 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/9233 Tested-by: build bot (Jenkins) Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
2015-05-21lenovo: Remerge smbios_mainboard_bios_version.Vladimir Serbinenko
Change-Id: I8df5b7f6707957b925f7bb4dc06a717252c70868 Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com> Reviewed-on: http://review.coreboot.org/10275 Reviewed-by: Nicolas Reinecke <nr@das-labor.org> Tested-by: build bot (Jenkins)
2015-05-19ivybridge native gfx init: Adjust state to be compatible with OPROM.Vladimir Serbinenko
My main payload is GRUB and I load SeaBIOS as secondary payload when for some reason I want to boot windows. In this scenario SeaBIOS runs VGA oprom (SeaVGABIOS is not good enough with intel gfx). VGA oprom expects either completely uninited gfx or some special state in gmbus and software scratch registers. Provide this state. The only alternative without this patch for such usecase is to use oprom and I'd like to avoid doing so when going my main boot path to GNU/Linux. Change-Id: I38e78fb845e43b81df084cd4d65f4618bfb2506d Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com> Reviewed-on: http://review.coreboot.org/10205 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-05-19gma/edid: Fix gma register access.Vladimir Serbinenko
0x20 was incorrectly represented as 4 * 5 while in fact it's 4 * 8 Change-Id: I6053a3baa6de0da9f1d648009353bc1fe542f81f Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com> Reviewed-on: http://review.coreboot.org/10237 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-05-18drivers/gic: reprogram the GIC CPU interface to bypass IRQJoseph Lo
GICv2 provides a wake IRQ/FIQ (for wake-event purpose), which are not disabled by GIC CPU interface. This is done by adding a bypass override capability when the interrupts are disabled at the CPU interface. To support this, there are four bits about IRQ/FIQ BypassDisable in CPU interface Control Register. So the CPU can exit from WFI when an asserted IRQ is coming. This is critical for power gating a CPU. BRANCH=none BUG=chrome-os-partner:39620 TEST=testing with CPU idle with power down state support and CPU can wake up normally Change-Id: I71ac642e28024a562db898665b74a5791fce325a Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 3a3f098cbf3fbfdab8150ebd4fd688fdb472b529 Original-Change-Id: I20569a18f34a4b11b8c8c67ea255b3d0f021839f Original-Signed-off-by: Joseph Lo <josephl@nvidia.com> Original-Reviewed-on: https://chromium-review.googlesource.com/269116 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/10172 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-05-17lenovo/x200: Enable wacom digitizer support for x200tAlex David
This patch is based on commit f2b3cd63 (lenovo/x60: Support digitizer on X60t and X201t) Tested on Thinkpad X200 Tablet (7450): all pen functionallity works (i.e. movements, presure sensitivity and buttons) Change-Id: I9bd18642a6ea4211dc3be065456a507fc0b72561 Signed-off-by: Alex David <opdecirkel@gmail.com> Reviewed-on: http://review.coreboot.org/10208 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
2015-05-15x230: Fix ricoh driver.Vladimir Serbinenko
Inclusion of ricoh driver was lost in 1d7b9de3504e90f0886fccec3a1f8a783fd4cc58. So the relevant code wasn't even compiled. Fix copy-paste mistakes without significance while on it as well. Change-Id: Ie548cb43f986f147658fc9c67963f8a055250598 Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com> Reviewed-on: http://review.coreboot.org/10211 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-05-13verstage: provide support for serial consoleAaron Durbin
verstage previously lacked serial console support. Add the necessary objects and macro checks to allow verstage to include the serial console. Change-Id: Ibe911ad347cac0b089f5bc0d4263956f44f3d116 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/10196 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins)
2015-05-12FSP 1.1 Comparison BaseLee Leahy
Add FSP 1.0 source for comparison with FSP 1.1. BRANCH=none BUG=None TEST=None Change-Id: I8df349f97acfa74f4de3607d49633da3d4884546 Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com> Reviewed-on: http://review.coreboot.org/10116 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-05-12usbdebug: Add FTDI FT232H supportKyösti Mälkki
Tested with gizmosphere/gizmo1 Explorer add-on board, which exposes the following device: 0x0403 Future Technology Devices International, Ltd 0x6014 FT232H Single HS USB-UART/FIFO IC For now UART is hard-coded to 115200, 8n1, no flow-control. Change-Id: I4081f84f7700751ccbf079e7fcbb1467aa71d872 Signed-off-by: Nico Huber <nico.h@gmx.de> Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/10063 Tested-by: build bot (Jenkins)
2015-05-11secmon: Add some missing filesPatrick Georgi
secmon is referring to uart's default_baudrate() and various coreboot version strings. Change-Id: I40a8d1979146058409a814d94ea24de83ee4d634 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/10129 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-05-08northbridge/intel/gm45/gma: Add backlight control register fieldTimothy Pearson
This allows the backlight control register to be set via devicetree.cb Change-Id: I32b42dfc1cc609fb6f8995c6158c85be67633770 Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com> Reviewed-on: http://review.coreboot.org/9330 Tested-by: build bot (Jenkins)
2015-05-07kbuild: Use wildcard for driver subdirectoriesStefan Reinauer
Change-Id: Id1685c0b28ec8e3ab972a671af6f2de6f321c645 Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-on: http://review.coreboot.org/9805 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-05-04drivers/spi/stmicro: Rename N25Q256A to N25Q256David Imhoff
The 'A' indicates the production process(64 nm). All other chips from the same family leave this out. TEST=Build and booted on Minnowboard Max Change-Id: I21e6c01de5d547bbc2252e679a001948e7ab752c Signed-off-by: David Imhoff <dimhoff_devel@xs4all.nl> Reviewed-on: http://review.coreboot.org/10078 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2015-05-04drivers/spi/stmicro: Add '.op_erase' for N25Q256David Imhoff
'.op_erase' was not specified for this chip. Set it to sub sector erase(CMD_M25PXX_SSE). Adjust page/sector size for sub sector erase to work. TEST=Untested, due to lack of hardware. Change-Id: Icc2748fbd3afeb56693e1c17d97eb490fba67064 Signed-off-by: David Imhoff <dimhoff_devel@xs4all.nl> Reviewed-on: http://review.coreboot.org/10077 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-05-04drivers/spi/stmicro: Add N25Q064 supportDavid Imhoff
N25Q064 is similar to N25Q128. TEST=Build and booted twice on Minnowboard Max Change-Id: Iec105f8b81f619846cf40b40042cc59150b81149 Signed-off-by: David Imhoff <dimhoff_devel@xs4all.nl> Reviewed-on: http://review.coreboot.org/10076 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-05-04spi: Remove out of date comment and reorder flash tableDavid Imhoff
What is described by the comment has already been fixed in f0d038f4 (flash: use two bytes of device ID to identify stmicro chips). This also means that STM_ID_N25Q128 doesn't have to be at the top of stmicro_spi_flash_table anymore. TEST=Untested, due to lack of hardware Change-Id: I7a9e9a0cdfdb1cf34e914e186fc6957c1d9b5ca6 Signed-off-by: David Imhoff <dimhoff_devel@xs4all.nl> Reviewed-on: http://review.coreboot.org/10068 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2015-05-04spi: Change 'page' to 'sector' in log messageDavid Imhoff
The log message says 'page size' while actually the sector size is printed. This is confusing since for stmicro page size != sector size. Also add '0x' prefix to numbers to make it clear they are in hex. TEST=Build and booted on Minnowboard Max Change-Id: I795a4b7c1bc8de2538a87fd4ba56f5a78d9ca2ac Signed-off-by: David Imhoff <dimhoff_devel@xs4all.nl> Reviewed-on: http://review.coreboot.org/10067 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2015-05-02drivers/intel/fsp1_0: Remove executable bit from C filesPaul Menzel
Fix up commit c13ad6c6 (driver/intel/fsp: Correct the fastboot data (MRC data) printing length) unintentionally making the changed files executable. Change-Id: I909c323023a9ccfb0c20094d9085ae90043b9e04 Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-on: http://review.coreboot.org/10060 Tested-by: build bot (Jenkins) Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
2015-04-30vboot: split class in library and stagePatrick Georgi
The build system includes a bunch of files into verstage that also exist in romstage - generic drivers etc. These create link time conflicts when trying to link both the verstage copy and romstage copy together in a combined configuration, so separate "stage" parts (that allow things to run) from "library" parts (that contain the vboot specifics). Change-Id: Ieed910fcd642693e5e89e55f3e6801887d94462f Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/10041 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-04-30i2c/tpm: add final newlinePatrick Georgi
Change-Id: I0024c4d56f93eb6c9a54103e79c9d8a8b7d8d6fb Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/10043 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-04-28Kconfig whitespace fixesMartin Roth
trivial whitespace fixes. Mostly changing leading spaces to tabs. Change-Id: I0bdfe2059b90725e64adfc0bdde785b4e406969d Signed-off-by: Martin Roth <gaumless@gmail.com> Reviewed-on: http://review.coreboot.org/10000 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-28fsp platforms: consolidate FspNotify callsMartin Roth
Consolidate the FspNotify calls into the FSP driver directory, using BOOT_STATE_INIT_ENTRY to set up the call times. Change-Id: I184ab234ebb9dcdeb8eece1537c12d03f227c25e Signed-off-by: Martin Roth <gaumless@gmail.com> Reviewed-on: http://review.coreboot.org/9780 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-28Fix some minor Kconfig issuesMartin Roth
- Remove Kconfig files that are no longer used: src/vencorcode/Kconfig src/soc/marvell/Kconfig - Fix the drivers/sil/Kconfig to point to drivers/sil/3114 which had the same code. - Make sure all Kconfig files have linefeeds at the end. This can cause problems, although it wasn't in this case. - Include cpu/intel/model_65x/Kconfig which was not being included. Change-Id: Ia57a1e0433e302fa9be557525dc966cae57059c9 Signed-off-by: Martin Roth <gaumless@gmail.com> Reviewed-on: http://review.coreboot.org/9998 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-28OxPCIe: Fix UART base addressesKyösti Mälkki
The offset of 0x2000 was for a configuration with two separate OxPCIe chips. The setup we support is a single chip with 8 UART pors. Change-Id: If4be046a14464af7b90b86aca5464c6b3400dffc Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/8780 Tested-by: build bot (Jenkins) Reviewed-by: Idwer Vollering <vidwer@gmail.com> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-24driver/intel/fsp: Correct the fastboot data (MRC data) printing lengthYork Yang
Fastboot data in Intel FSP project is printed by hexdump32() in dword length. So the data length needs to be divided by 4 when printing it. Change-Id: I959d538bd6e60282882dd138045cc730b4bd8159 Signed-off-by: York Yang <york.yang@intel.com> Reviewed-on: http://review.coreboot.org/9976 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2015-04-24fsp: Move fsp to fsp1_0Marc Jones
Prepare for FSP 1.1 integration by moving the FSP to a FSP 1.0 specific directory. See follow-on patches for sharing of common code. Change-Id: Ic58cb4074c65b91d119909132a012876d7ee7b74 Signed-off-by: Marc Jones <marc.jones@se-eng.com> Reviewed-on: http://review.coreboot.org/9970 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-04-22i2c/ww_ring: add a pattern for normal bootVadim Bendebury
It became necessary to indicate the beginning of the normal boot process. This patch adds a new pattern, a slow (over 2 seconds) fade in into the 0, 87, 155 color. BRANCH=storm BUG=chrome-os-partner:39044 TEST=tested by the next patch. Change-Id: Idd977688e5aa2cc55fc295072c0766526ae95016 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 577c8bd6f8c69073cfdd7acd4a87e7ae603d48e6 Original-Change-Id: I9aff3f4558e733ff2e47206075533556e400f183 Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/265535 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9922 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-22i2c/ww_ring: update color definitionsVadim Bendebury
After testing on a final assembly the PD team adjusted the wipeout request and recovery request modes' colors. BRANCH=storm BUG=none TEST=verified new colors while booting an SP5 device in recovery mode Change-Id: I9bd2dac63b99140573533c2cda8eaa9213478ab1 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 41c34a619dc0317af67907f18ee844c71a73d623 Original-Change-Id: Iab84710ebdeed35ddd4a8a163bbb6b8ac9cdb799 Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/262602 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9890 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-22i2c/ww_ring: change colors for different display modesVadim Bendebury
Modify colors as suggested by product review folks. This is not final, to make it easier to identify RGB locations in the hex dumps, express their values in decimal as opposed to hex. BRANCH=storm BUG=chrome-os-partner:36059 TEST=verified new all three color schemes while pressing the recovery button at boot for 20 seconds. Change-Id: I7461acd7004e3d10cba6665a9bfe25ec8aa6f3ba Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 7a075824a1954eb5d1b65ce887304924724a6d21 Original-Change-Id: I7f5968e361333572fd1f84aa11b7150194ad902a Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/261690 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9880 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-22i2c/ww_ring: use shorter blinking programVadim Bendebury
The originally loaded blinking program was written to allow gradual change in LED brightness, which required controlling each LED with its own engine. In fact there is no need in gradual brightness changes when the firmware is controlling the ring. This allows to control all LEDs by one engine, making the code simpler and more robust (no need to synchronize the three engines any more). BRANCH=storm BUG=chrome-os-partner:36059 TEST=verified that recovery boot WW ring patterns work as expected. Change-Id: I89d231fb61693f4e834d8d9323ae5a7ddd149525 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 19809cf8120df8865da9b5b9e7b8e932334bf4b5 Original-Change-Id: I41038fd976dc9600f223dc0e9c9602331baf68f9 Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/261026 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9873 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-22i2c/ww_ring: stop running programs before loading the new onesVadim Bendebury
The two controllers on the ring are programmed independently, and if the second controller is running the old pattern while the first one was loaded with a new pattern, there is a window of when the two unrelated patterns might interact. To avoid this shut down execution on both controllers before starting downloading the new pattern code. BRANCH=storm BUG=chrome-os-partner:36059 TEST=verified recovery/wipeout LED ring behavior did not change. Change-Id: I163f2983d414fe839208054ae3e9025663a46aeb Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 3502ca6b119c033855b45388e7b782d35cfdd82b Original-Change-Id: I0f71f94a7e82f6c0e7f98d3aad1f93ece207248f Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/261200 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9872 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-22i2c/ww_ring: define display pattern programsVadim Bendebury
Add compiled lp55231 code snippets to allow display certain patterns when booting the device with the recovery button pressed. As soon as the press is detected, the low intensify solid white pattern is enabled. Holding recovery button long enough causes the device transition between the wipeout requested and recovery requested states, with the appropriate changes in the displayed pattern. The patch also includes the source code for the LED controller as well as instructions on how to compile and modify the code to result in different colors, intensities, blink periods and duty cycles. BRANCH=storm BUG=chrome-os-partner:36059 TEST=reboot an SP5 device with the LED ring attached, keep the recovery button pressed, observe the changes in the LED display pattern while the device progresses through the boot sequence. Change-Id: Ic7d45fc7c313b6d21119d4ae6adaeb4f46f7d181 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 0fd6a5c0067d705197816629f41640a931d2f7cd Original-Change-Id: Ib5cc5188c2eeedbba128101bf4092a0b9a74e155 Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/260670 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9870 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-22i2c/ww_ring: decouple LED display from vbootVadim Bendebury
The patterns displayed on the LED ring while under the coreboot control are not driven by the vboot, but by the board code instead, The four distinct states of the LED display are: - all off - recovery button push detected, waiting for it to be released - wipeout request pending - recovery button was pushed long enough to trigger this request - recovery request pending - recovery button was pushed long enough to trigger this request. BRANCH=storm BUG=chrome-os-partner:36059 TEST=no functional changes Change-Id: I38d9a3028013b902a7a67ccd4eb1c5d533bf071c Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: bdfff0e646283da6a2faaacf33e0179d2fea221c Original-Change-Id: Ie279151b6060a2888268a2e9a0d4dc22ecaba460 Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/260649 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9868 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-22i2c/ww_ring: various driver fixes and improvementsVadim Bendebury
When in development environment, some SP5 devices might not have the LED ring attached. They are still fully functional, but when booting up are generating massive amount of i2c error messages. This patch prevents accesses to non-existing lp55321 devices. When loading the program into the device the vendor recommends 1 ms delay when accessing the program control register. This patch separates these accesses into a function and add a delay after every access. Another fix - advance the program address when loading multipage programs. Set the global variable register 3c, not used by coreboot programs, to a fixed value. This will allow depthcharge to avoid re-initializing the controller when not necessary. BRANCH=storm BUG=chrome-os-partner:36059 TEST=booted firmware on an SP5 with no LED ring attached, no excessive error messages are generated, saw the default pattern displayed when the recovery button is pressed during reset. Change-Id: I6a2a27968684c40dae15317540a16405b1419e30 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 5e0b4c84aca27460db594da1faf627ddee56f399 Original-Change-Id: I10f1f53cefb866d11ecf76ea48f74131d8b0ce77 Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/260648 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9867 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-22i2c: add support for ww_ringVadim Bendebury
This is a copy of the depthcharge ww ring driver implementation ported into coreboot. The main differences are: - direct use of the i2c driver instead of using the callback driver description - no dynamic memory allocation for the controller structures BRANCH=storm BUG=chrome-os-partner:36059 TEST=with the rest of the patches applied the LED ring gets initialized to the default pattern at coreboot start. Change-Id: I6902c8b76fc173ad2ec28b8cc94695e892df338a Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: eda24b78f8aff311dd6296d458bdfecf26c3d65a Original-Change-Id: I5660dc3f255aab8fbe3a87041c72916a645c193b Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/257730 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9858 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-22elog: use CONFIG_RTCPatrick Georgi
When RTC is not selected, return all 0. Change-Id: I892a9489fc1d82fb8e61cf02666f797dc6412e05 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/9955 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-04-22rtc: add config flag to denote rtc API availabilityPatrick Georgi
RTC drivers now select RTC, so that code which depends on them can implement fallback behavior for systems that lack the hardware or driver. Change-Id: I0f5a15d643b0c45c511f1151a98e071b4155fb5a Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/9953 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-04-22armv8/secmon: Disable and Enable GIC in PSCI pathFurquan Shaikh
Disable and enable GIC before switching off a CPU and after bringing it up back respectively. BUG=None BRANCH=None TEST=Compiles successfully and psci commands work for ryu. Change-Id: Ib43af60e994e3d072e897a59595775d0b2dcef83 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: d5271d731f0a569583c2b32ef6726dadbfa846d3 Original-Change-Id: I672945fcb0ff416008a1aad5ed625cfa91bb9cbd Original-Signed-off-by: Furquan Shaikh <furquan@google.com> Original-Reviewed-on: https://chromium-review.googlesource.com/265623 Original-Trybot-Ready: Furquan Shaikh <furquan@chromium.org> Original-Tested-by: Furquan Shaikh <furquan@chromium.org> Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org> Reviewed-on: http://review.coreboot.org/9926 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins)
2015-04-22elog: Eliminate CONFIG_ELOG_FULL_THRESHOLD and CONFIG_ELOG_SHRINK_SIZESol Boucher
These Kconfig options provided a level of configurability that is almost never necessary, so they are being moved into ordinary preprocessor defines in elog_internal.h. The new threshold to trigger shrinking is relative to the number of additional (maximum-size) events that can fit, and the new target post-shrink size is a percentage of the total ELOG area size. BUG=chromium:467820 TEST=Add loop at the end of elog_init() that fills the ELOG area to just below full_threshold with dummy events. Observe successful shrinkage when the next event is logged. BRANCH=None Change-Id: I414c4955a2d819d112ae4f0c7d3571576f732336 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: ce439361e3954a2bf5186292f96936329171cf56 Original-Change-Id: I926097f86262888dcdd47d73fba474bb2e19856a Original-Signed-off-by: Sol Boucher <solb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/260501 Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org> Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org> Reviewed-on: http://review.coreboot.org/9869 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-21Unify byte order macros and clrsetbitsJulius Werner
This patch removes quite a bit of code duplication between cpu_to_le32() and clrsetbits_le32() style macros on the different architectures. This also syncs those macros back up to the new write32(a, v) style IO accessor macros that are now used on ARM and ARM64. CQ-DEPEND=CL:254862 BRANCH=none BUG=chromium:444723 TEST=Compiled Cosmos, Daisy, Blaze, Falco, Pinky, Pit, Rambi, Ryu, Storm and Urara. Booted on Jerry. Tried to compare binary images... unfortunately something about the new macro notation makes the compiler evaluate it more efficiently (not recalculating the address between the read and the write), so this was of limited value. Change-Id: If8ab62912c952d68a67a0f71e82b038732cd1317 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: fd43bf446581bfb84bec4f2ebb56b5de95971c3b Original-Change-Id: I7d301b5bb5ac0db7f5ff39e3adc2b28a1f402a72 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/254866 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9838 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-21arm(64): Manually clean up the mess left by write32() transitionJulius Werner
This patch is a manual cleanup of all the rubble left by coccinelle waltzing through our code base. It's generally not very good with line breaks and sometimes even eats comments, so this patch is my best attempt at putting it all back together. Also finally remove those hated writel()-style macros from the headers. BRANCH=none BUG=chromium:444723 TEST=None (depends on next patch) Change-Id: Id572f69c420c35577701feb154faa5aaf79cd13e Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 817402a80ab77083728b55aed74b3b4202ba7f1d Original-Change-Id: I3b0dcd6fe09fc4e3b83ee491625d6dced98e3047 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/254865 Reviewed-on: http://review.coreboot.org/9837 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-21arm(64): Globally replace writel(v, a) with write32(a, v)Julius Werner
This patch is a raw application of the following spatch to src/: @@ expression A, V; @@ - writel(V, A) + write32(A, V) @@ expression A, V; @@ - writew(V, A) + write16(A, V) @@ expression A, V; @@ - writeb(V, A) + write8(A, V) @@ expression A; @@ - readl(A) + read32(A) @@ expression A; @@ - readb(A) + read8(A) BRANCH=none BUG=chromium:444723 TEST=None (depends on next patch) Change-Id: I5dd96490c85ee2bcbc669f08bc6fff0ecc0f9e27 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 64f643da95d85954c4d4ea91c34a5c69b9b08eb6 Original-Change-Id: I366a2eb5b3a0df2279ebcce572fe814894791c42 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/254864 Reviewed-on: http://review.coreboot.org/9836 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-21arm(64): Replace write32() and friends with writel()Julius Werner
This patch is a raw application of the following spatch to the directories src/arch/arm(64)?, src/mainboard/<arm(64)-board>, src/soc/<arm(64)-soc> and src/drivers/gic: @@ expression A, V; @@ - write32(V, A) + writel(V, A) @@ expression A, V; @@ - write16(V, A) + writew(V, A) @@ expression A, V; @@ - write8(V, A) + writeb(V, A) This replaces all uses of write{32,16,8}() with write{l,w,b}() which is currently equivalent and much more common. This is a preparatory step that will allow us to easier flip them all at once to the new write32(a,v) model. BRANCH=none BUG=chromium:451388 TEST=Compiled Cosmos, Daisy, Blaze, Pit, Ryu, Storm and Pinky. Change-Id: I16016cd77780e7cadbabe7d8aa7ab465b95b8f09 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 93f0ada19b429b4e30d67335b4e61d0f43597b24 Original-Change-Id: I1ac01c67efef4656607663253ed298ff4d0ef89d Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/254862 Reviewed-on: http://review.coreboot.org/9834 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-17flash: use two bytes of device ID to identify stmicro chipsDaisuke Nojiri
stmicro flash chips use 2 bytes as a device id: upper byte for memory type and lower byte for capacity. with this change, we will use all 2 bytes to identify a chip. BUG=none BRANCH=broadcom-firmware TEST=booted purin and verified n25q256a was identified. Change-Id: I8f382eddc4fa70d3deceb4f9d2e82026a7025629 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 12f70a1d4b7e1142afec9ce097c4a21b6225f66e Original-Change-Id: Id3378a77318fabb74ddb30f1a9549010636872ba Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> Original-Reviewed-on: https://chrome-internal-review.googlesource.com/199387 Original-Reviewed-by: Corneliu Doban <cdoban@broadcom.com> Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Original-Commit-Queue: Daisuke Nojiri <dnojiri@google.com> Original-Tested-by: Daisuke Nojiri <dnojiri@google.com> Original-Reviewed-on: https://chromium-review.googlesource.com/251305 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/9774 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
2015-04-17spi: allow inclusion of Micronix and STM drivers in bootblockVadim Bendebury
Bootblock does not allow using malloc, use statically allocated chip structures instead. BRANCH=storm BUG=chrome-os-partner:33489 TEST=both drivers compile when configured in, also booted whirlwind with an STM compatible SPI NOR flash. Change-Id: I154c33ce5fc278d594205d8b8e62a56edb4e177e Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: eedbb959a595e0898e7a1dd551fc7c517a02f370 Original-Change-Id: I29b37107ac1d58a293f531f59ee76b3d8c4b3e7c Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/248992 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9772 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-17uart: pass register width in the coreboot tableVadim Bendebury
Some SOCs (like pistachio, for instance) provide an 8250 compatible UART, which has the same register layout, but mapped to a bus of a different width. Instead of adding a new driver for these controllers, it is better to have coreboot report UART register width to libpayload, and have it adjust the offsets accordingly when accessing the UART. BRANCH=none BUG=chrome-os-partner:31438 TEST=with the rest of the patches integrated depthcharge console messages show up when running on the FPGA board Change-Id: I30b742146069450941164afb04641b967a214d6d Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 2c30845f269ec6ae1d53ddc5cda0b4320008fa42 Original-Change-Id: Ia0a37cd5f24a1ee4d0334f8a7e3da5df0069cec4 Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/240027 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9738 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-17spi: Add function to read flash status registerDuncan Laurie
Add a function that allows reading of the status register from the SPI chip. This can be used to determine whether write protection is enabled on the chip. BUG=chrome-os-partner:35209 BRANCH=haswell TEST=build and boot on peppy Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/240702 Reviewed-by: Shawn N <shawnn@chromium.org> (cherry picked from commit c58f17689162b291a7cdb57649a237de21b73545) Change-Id: Ib7fead2cc4ea4339ece322dd18403362c9c79c7d Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 9fbdf0d72892eef4a742a418a347ecf650c01ea5 Original-Change-Id: I2541b22c51e43f7b7542ee0f48618cf411976a98 Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/241128 Original-Reviewed-by: Shawn N <shawnn@chromium.org> Reviewed-on: http://review.coreboot.org/9730 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-17drivers/spi: Pass flash parameters from coreboot to payloadDan Ehrenberg
A payload may want to run erase operations on SPI NOR flash without re-probing the device to get its properties. This patch passes up three properties of flash to achieve that: - The size of the flash device - The sector size, i.e., the granularity of erase - The command used for erase The patch sends the parameters through coreboot and then libpayload. The patch also includes a minor refactoring of the flash erase code. Parameters are sent up for just one flash device. If multiple SPI flash devices are probed, the second one will "win" and its parameters will be sent up to the payload. TEST=Observed parameters to be passed up to depthcharge through libpayload and be used to correctly initialize flash and do an erase. TEST=Winbond and Gigadevices spi flash drivers compile with the changes; others don't, for seemingly unrelated reasons. BRANCH=none BUG=chromium:446377 Change-Id: Ib8be86494b5a3d1cfe1d23d3492e3b5cba5f99c6 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 988c8c68bbfcdfa69d497ea5f806567bc80f8126 Original-Change-Id: Ie2b3a7f5b6e016d212f4f9bac3fabd80daf2ce72 Original-Signed-off-by: Dan Ehrenberg <dehrenberg@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/239570 Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: http://review.coreboot.org/9726 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-17as3277: Fix month-off-by-one error for RTC driverJulius Werner
The AS3277 RTC code seems to closely follow the corresponding Linux driver. Unfortunately, while coreboot (and even other parts of Linux, like mktime()) directly follows the standard IBM PC RTC time representation (except for the BCD part), Linux' struct rtc_time decided to use 0-based (instead of 1-based) months instead. This patch removes the faulty month offset that was copied into our driver so that we will generate correct timestamps again. BRANCH=nyan BUG=chrome-os-partner:34108 TEST=firmware_EventLog (pre-release version) gets further than before (and then craps up on unrelated problems with suspend/resume events). Change-Id: Ica221a8bcfd7c1c6cd7ba382d760b586d511e3a3 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 5b55c3f5bbecc776a71338256b910aecccac1e04 Original-Change-Id: I163fa4778ec534cd9e6f92a6b6dc55e9871a6a82 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/238122 Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/9723 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-13tpm: Only expose base address Kconfig option when enabledPatrick Georgi
Change-Id: Ia8ddd689a3bf09ed68f94907ea19d4d2ee874542 Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-on: http://review.coreboot.org/9594 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-13spi: support controllers with limited transfer size capabilitiesVadim Bendebury
Some SPI controllers (like Imgtec Pistachio), have a hard limit on SPI read and write transactions. Limiting transfer size in the wrapper allows to provide the API user with unlimited transfer size transactions. The tranfer size limitation is added to the spi_slave structure, which is set up by the controller driver. The value of zero in this field means 'unlimited transfer size'. It will work with existion drivers, as they all either keep structures in the bss segment, or initialize them to all zeros. This patch addresses the problem for reads only, as coreboot is not expected to require to write long chunks into SPI devices. BRANCH=none BUG=chrome-os-partner:32441, chrome-os-partner:31438 TEST=set transfer size limit to artificially low value (4K) and observed proper operation on both Pistachio and ipq8086: both Storm and Urara booted through romstage and ramstage. Change-Id: Ibb96aa499c3eec458c94bf1193fbbbf5f54e1477 Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: 4f064fdca5b6c214e7a7f2751dc24e33cac2ea45 Original-Change-Id: I9df24f302edc872bed991ea450c0af33a1c0ff7b Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/232239 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/9571 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-13tpm: wait for valid bit to be set in TPM access register before using tpmSourabh Banerjee
As per the TCG PC Client TPM Interface Specification v1.2, bit 7 of the access register (tmpRegValiSts bit) stays "0" until the TPM has complete through self test and initialization. This bit is set "1" to indicate that the other bits in the register are valid. BRANCH=chromeos-2013.04 BUG=chrome-os-partner:35328 TEST=Booted up storm p0.2 and whirwind sp3. Verified TPM chip is detected and reported in coreboot logs. Change-Id: I1049139fc155bfd2e1f29e3b8a7b9d2da6360857 Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: 006fc93c6308d6f3fa220f00708708aa62cc676c Original-Change-Id: I9df3388ee1ef6e4a9d200d99aea1838963747ecf Original-Signed-off-by: Sourabh Banerjee <sbanerje@codeaurora.org> Original-Reviewed-on: https://chromium-review.googlesource.com/242222 Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org> Original-Commit-Queue: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: http://review.coreboot.org/9567 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-13elog: Fix regression that caused elog to omit "System boot" eventJulius Werner
CL:243671 moved the initialization of elog_initialized around, which is now unfortunately so late that the ELOG_TYPE_BOOT event gets omitted because the code believes the log to be broken at that time. Good thing we now have a FAFT test for these things that I had of course been too lazy to run. -.- The real reason for moving that line was to put it after any point in elog_init() that could still error out. The problem is that we might add the "cleared" event before we try to shrink (which can fail and cause an error)... but those two things cannot happen at the same time, so it should be okay to flip them around and mark the elog as initialized in between. BRANCH=none BUG=chrome-os-partner:35940 TEST=Ran firmware_EventLog on a Pinky, manually confirmed that I once again get "System boot" events. Change-Id: I12dcf4a8e47d302f6cd317194912c31db502bbaf Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: 4a1c0b861017ca25229b1042c4b37dda33e869f9 Original-Change-Id: I4103779790e1a8a53ecabffd4316724035928ce6 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/246715 Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/9503 Tested-by: build bot (Jenkins) Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-13elog: Correct behavior when FMAP section doesn't exist on ChromeOSJulius Werner
The elog driver has a really stupid bug that checks a result which is stored in an unsigned variable for < 0. Surprisingly GCC does not catch this nonsense right now, and I spent an hour trying out different warning options without finding one that doesn't also bring a load of stupid and unavoidable false positives (the biggest offender being -Wtype-limits, which does exactly what we'd want except for flagging things like if ((u8)var >= CONFIG_VAR_MIN) where the VAR_MIN Kconfig may or may not be 0). So, the only thing we can do is fix this one and wait for the next time something like that blows up. -.- Also change some more code to make the behavior more explicit (the old code already intended to work this way since flash_base is statically initialized to 0, never assigned in the error path and checked later in elog_init()... but there was an error message that incorrectly claimed a different fallback behavior, and explicitly assigning the values makes this easier to see). Finally, add another state to the elog_initialized variable to avoid trying to reinitialize a broken eventlog on every event (if it doesn't work the first time, chances are that it won't work later on during the same boot either). BRANCH=None BUG=chrome-os-partner:35940 TEST=Flashed Jerry with RO 6588.4 and RW 6588.23, observed how it now cleanly enters recovery mode without blowing its bootblock away with stray eventlog entries. Change-Id: I0e5348ba961ce4835c30f7108a2453522095f2ee Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: f9798dbf0c2b2e337062ecd84d0f45434343c0d9 Original-Change-Id: I4d93f48d2d01d75a04550d419e023aa42ca95a7a Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/243671 Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/9557 Tested-by: build bot (Jenkins) Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-10TPM: Reduce buffer size to fix stack overflowJulius Werner
The TPM driver by default allocates a 4K transfer buffer on the stack, which leads to lots of fun on boards with 2K or 3K stack sizes. On RK3288 this ends up writing over random memory sections which dependent on the memlayout of the day might contain timestamp data (no big deal) or page tables (-> bad time). This patch fixes the problem by reducing the buffer size to slightly above 1K, which still seems to work as far as I can tell. There was already some really odd code that #undef'ed this value and redefined it with the lower number in one .c file (unfortunately not the one with the buffer declaration), with no explanation whatsoever... I'm removing that and just assume the smaller value will be fine for everything. BRANCH=veyron BUG=None TEST=Booted Pinky and Falco. Change-Id: I440a5662b41cbd8b7becab3113262e1140b7f763 Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: 3d3288041b6629b7623b9d58816e782e72836b81 Original-Change-Id: Idf80f44cbfb9617c56b64a5c88ebedf7fcb4ec71 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/236976 Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/9481 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-10tpm: Remove error message for unknown resource typeDuncan Laurie
This is being triggered because the base address is added, but there is nothing that needs done with it in set_resources step and the ERROR message is tripping suspend resume test scripts. BUG=chrome-os-partner:33385 BRANCH=samus,auron TEST=boot on samus and check for ERROR strings, successfully run suspend_stress_test without failures Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/231603 (cherry picked from commit bb789492965d92e309a913dc7b9f09f7036c5480) Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Change-Id: I565c8af954f1c5a406d2c65f01c274e9259e43ec Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: 9062734d884f814dc880589ee615b4d7e1fdc61a Original-Change-Id: I2b5f44795f1ee445d509b29bd56f498aea7b7fe3 Original-Reviewed-on: https://chromium-review.googlesource.com/231604 Original-Commit-Queue: Duncan Laurie <dlaurie@chromium.org> Original-Tested-by: Duncan Laurie <dlaurie@chromium.org> Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9476 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-10tpm: Add ramstage driver and interrupt configurationDuncan Laurie
This adds a ramstage driver for the TPM and allows the interrupt to be configured in devicetree.cb. The interrupt vector is set like other PNP devices, and the interrupt polarity is set with a register configuration variable. These values are written into locality 0 TPM_INT_VECTOR and TPM_INT_ENABLE and then all interrupts are disabled so they are not used in firmware but can be enabled by the OS. It also adds an ACPI device for the TPM which will configure the reported interrupt based on what has been written into the TPM during ramstage. The _STA method returns enabled if CONFIG_LPC_TPM is enabled, and the _CRS method will only report an interrupt if one has been set in the TPM itself. The TPM memory address is added by the driver and declared in the ACPI code. In order to access it in ACPI a Kconfig entry is added for the default TPM TIS 1.2 base address. Note that IO address 0x2e is required to be declared in ACPI for the kernel driver to probe correctly. BUG=chrome-os-partner:33385 BRANCH=samus,auron TEST=manual testing on samus: 1) Add TPM device in devicetree.cb with configured interrupt and ensure that it is functional in the OS. 2) Test with active high and active low, edge triggered and level triggered setups. 3) Ensure that with no device added to devicetree.cb that the TPM is still functional in polling mode. Change-Id: Iee2a1832394dfe32f3ea3700753b8ecc443c7fbf Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: fc2c106caae939467fb07f3a0207adee71dda48e Original-Change-Id: Id8a5a251f193c71ab2209f85fb470120a3b6a80d Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/226661 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9469 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-10tpm: Move the LPC TPM driver to a subdirectoryDuncan Laurie
This moves the LPC TPM driver to drivers/pc80/tpm so it can be turned into a ramstage driver with a chip.h It includes no other changes yet. BUG=chrome-os-partner:33385 BRANCH=samus,auron TEST=emerge-samus coreboot Change-Id: Iac83e52db96201f37a0086eae9df244f8b8d48d9 Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: be2db391f9da80b8b75137af0fe81dc4724bc9d1 Original-Change-Id: I60ddd1d2a3e72bcf169a0b44e0c7ebcb87f4617d Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/226660 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9468 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-10rtc: Add an RTC driver for the TI TPS65913 PMIC.Furquan Shaikh
The TPS65913 PMIC has an RTC built into it. This change adds a driver for it which implements the new RTC API. BUG=chrome-os-partner:33764 BRANCH=None TEST=Compiles and boots to kernel prompt on ryu. Timestamps for event log verified across multiple boots. Change-Id: I49ec9b78afc53f1cbd4be09e448cdae6077fb710 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: c16c11e620c830e7a73a2a24fe4823ccea0f3c39 Original-Change-Id: If1d549ea2361d0de6be75fd24b9e9810a6df7457 Original-Signed-off-by: Furquan Shaikh <furquan@google.com> Original-Reviewed-on: https://chromium-review.googlesource.com/229414 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Original-Tested-by: Furquan Shaikh <furquan@chromium.org> Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org> Reviewed-on: http://review.coreboot.org/9425 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-10elog: Hide elog_flash_offset_to_address() from SMMFurquan Shaikh
Change-Id: Iaef9d4755f07ca03ca823831c3272183b5d6aed1 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 7c3db3d5c8e00b6c273ae240da137062597749aa Original-Change-Id: I5e38966fe06aa3302a7c1b536f5ffd8bb22d4947 Original-Signed-off-by: Furquan Shaikh <furquan@google.com> Original-Reviewed-on: https://chromium-review.googlesource.com/229413 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org> Original-Tested-by: Furquan Shaikh <furquan@chromium.org> Reviewed-on: http://review.coreboot.org/9450 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-10elog: Fix typecast issues related to 64-bit compilation.Furquan Shaikh
BUG=chrome-os-partner:33764 BRANCH=None TEST=Compiles successfully for ryu and nyan. Change-Id: I036fd42d5cd4b71bcb68eea0fdd9a4e1aa4711e9 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 7c3db3d5c8e00b6c273ae240da137062597749aa Original-Change-Id: I5e38966fe06aa3302a7c1b536f5ffd8bb22d4947 Original-Signed-off-by: Furquan Shaikh <furquan@google.com> Original-Reviewed-on: https://chromium-review.googlesource.com/229413 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org> Original-Tested-by: Furquan Shaikh <furquan@chromium.org> Reviewed-on: http://review.coreboot.org/9424 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2015-04-10tpm: allow 0 as valid i2c bus numberDaisuke Nojiri
tpm driver uses bus=0 as indication of uninitialized tpm device. this change allows 0 as a valid i2c bus number. BUG=None BRANCH=ToT TEST=Built cosmos. Change-Id: Ie8d285abff11643cc3efc0fa30e4afcc3ca1c0d5 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 493077b68cf46b08f0d1ddfe57bf6064d714d537 Original-Change-Id: Iac55e88db4ef757a292270e7201d8fdd37a90b50 Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/226294 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9405 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-09 15:10:43 +0000