summaryrefslogtreecommitdiff
path: root/src/lib/Makefile.inc
AgeCommit message (Collapse)Author
2016-08-19drivers/spi: move cbfs_spi.c locationAaron Durbin
The common boot device spi implementation is very much specific to SPI flash. As such it should be moved into that subdirectory. It's still a high-level option but it correctly depends on BOOT_DEVICE_SPI_FLASH. Additionally that allows the auto-selection of SPI_FLASH by a platform selecting COMMON_CBFS_SPI_WRAPPER which allows for culling of SPI_FLASH selections everywhere. BUG=chrome-os-partner:56151 Change-Id: Ia2ccfdc9e1a4348cd91b381f9712d8853b7d2a79 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/16212 Reviewed-by: Furquan Shaikh <furquan@google.com> Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Martin Roth <martinroth@google.com>
2016-07-28skylake/mainboard: Define mainboard hook in bootblockSubrata Banik
Move mainboard post console init functionality (google_chrome_ec_init & early_gpio programming) from verstage to bootblock. Add chromeos-ec support in bootblock BUG=chrome-os-partner:55357 BRANCH=none TEST=Built and boot kunimitsu till POST code 0x34 Change-Id: I1b912985a0234d103dcf025b1a88094e639d197d Signed-off-by: Barnali Sarkar <barnali.sarkar@intel.com> Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com> Signed-off-by: Subrata Banik <subrata.banik@intel.com> Reviewed-on: https://review.coreboot.org/15786 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-07-19lib: provide memrange library in romstageAaron Durbin
BUG=chrome-os-partner:52679 Change-Id: I79ffc0749fba353cd959df727fb45ca2ee5c1bf6 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/15734 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-07-15AGESA: Use common romstage ram stackKyösti Mälkki
Change-Id: Ie120360fa79aa0f6f6d82606838404bb0b0d9681 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/15466 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-07-11tpm2: add marshaling/unmarshaling layerVadim Bendebury
TPM commands need to be serialized (marshaled) to be sent to the device, and the responses need to be de-serialized (unmarshaled) to be properly interpreted by upper layers. This layer does not exist in TPM1.2 coreboot implementation, all TPM commands used there were hardcoded as binary arrays. Availability of the marshaling/unmarshaling layer makes it much easier to add new TPM commands to the code. Command and response structures used in these functions are defined in Parts 2 and 3 of the TCG issued document Trusted Platform Module Library Family "2.0" Level 00 Revision 01.16 October 30, 2014 BRANCH=none BUG=chrome-os-partner:50645 TEST=with the rest of the patches applied it is possible to successfully initialize firmware and kernel TPM spaces. Change-Id: I80b3f971e347bb30ea08f820ec3dd27e1656c060 Signed-off-by: Martin Roth <martinroth@chromium.org> Original-Commit-Id: 0782d9d452efb732e85d1503fccfcb4bf9f69a68 Original-Change-Id: I202276ef9a43c28b5f304f901ac5b91048878b76 Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/353915 Original-Reviewed-by: Bill Richardson <wfrichar@chromium.org> Original-Reviewed-by: Darren Krahn <dkrahn@chromium.org> Reviewed-on: https://review.coreboot.org/15570 Tested-by: build bot (Jenkins) Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@googlemail.com>
2016-07-11tpm2: implement tlcl layerVadim Bendebury
This is the first approximation of implementing TPM2 support in coreboot. It is very clearly incomplete, some of the larger missing pieces being: - PCR(s) modification - protection NVRAM spaces from unauthorized deletion/modification. - resume handling - cr50 specific factory initialization The existing TPM1.2 firmware API is being implemented for TPM2. Some functions are not required at all, some do not map fully, but the API is not yet being changed, many functions are just stubs. An addition to the API is the new tlcl_define_space() function. It abstracts TMP internals allowing the caller to specify the privilege level of the space to be defined. Two privilege levels are defined, higher for the RO firmware and lower for RW firmware, they determine who can write into the spaces. BRANCH=none BUG=chrome-os-partner:50645 TEST=with the rest of the patches applied Kevin/Gru devices can initialize and use firmware and kernel spaces Change-Id: Ife3301cf161ce38d61f11e4b60f1b43cab9a4eba Signed-off-by: Martin Roth <martinroth@chromium.org> Original-Commit-Id: bcc8e62604c705798ca106e7995a0960b92b3f35 Original-Change-Id: Ib340fa8e7db51c10e5080973c16a19b0ebbb61e6 Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/353914 Original-Commit-Ready: Martin Roth <martinroth@chromium.org> Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://review.coreboot.org/15569 Tested-by: build bot (Jenkins) Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@googlemail.com>
2016-07-10intel post-car: Consolidate choose_top_of_stack()Kyösti Mälkki
Change-Id: I2c49d68ea9a8f52737b6064bc4fa703bdb1af1df Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/15463 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-06-24lib: Add real-time-clock functionsSimon Glass
Add functions to convert between seconds and a struct rtc_time. Also add a function that can display the time on the console. BUG=chrome-os-partner:52220 BRANCH=none TEST=(partial) with future commits and after setting RTC on the EC: boot on gru into linux shell, check firmware log: localhost ~ # grep Date: /sys/firmware/log Date: 2016-06-20 (Monday) Time: 18:01:44 Then reboot ~10 seconds and check again: localhost ~ # grep Date: /sys/firmware/log Date: 2016-06-20 (Monday) Time: 18:01:54 Change-Id: Id148ccb7a18a05865b903307358666ff6c7b4a3d Signed-off-by: Martin Roth <martinroth@chromium.org> Original-Commit-Id: 3b02dbcd7d9023ce0acabebcf904e70007428d27 Original-Change-Id: I344c385e2e4cb995d3a374025c205f01c38b660d Original-Signed-off-by: Simon Glass <sjg@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/351782 Original-Commit-Ready: Vadim Bendebury <vbendeb@chromium.org> Original-Tested-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://review.coreboot.org/15301 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-06-09lib: Build reg_script for bootblockLee Leahy
Allow reg_script to be used during the bootblock. TEST=Build and run on Galileo Gen2 Change-Id: I55fe0be3f50116927b801ce67a3f23bb1931f6e7 Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com> Reviewed-on: https://review.coreboot.org/15131 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> 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-11lib: remove FLASHMAP_OFFSET config variableAaron Durbin
The FLASHMAP_OFFSET config variable is used in lib/fmap.c, however the fmdtool creates a fmap_config.h with a FMAP_OFFSET #define. Those 2 values are not consistent. Therefore, remove the Kconfig variable and defer to the #define generated by fmdtool. Change-Id: Ib4ecbc429e142b3e250106eea59fea1caa222917 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/14765 Reviewed-by: Patrick Georgi <pgeorgi@google.com> Tested-by: build bot (Jenkins) Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Leroy P Leahy <leroy.p.leahy@intel.com>
2016-05-03lib/cbfs: Use fmap derived information about the COREBOOT regionPatrick Georgi
It used to use CONFIG_CBFS_SIZE. The plan is that CBFS_SIZE only informs default*.fmd generation, while everything else derives its information from there. Also document the existing assumption that boot media should access the COREBOOT region (and not any other potentially existing fmap region containing a CBFS). Change-Id: I08254e4510f71edf99c2c8b56ac8f92008727c4a Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/14572 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-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-08lib: Implement framework for retrieving WiFi regulatory domainFelix Durairaj
Platforms that need to initialize WRDD package with the regulatory domain information should implement function wifi_regulatory_domain. A weak implementation is provided here. Signed-off-by: fdurairx <felixx.durairaj@intel.com> Reviewed-on: https://chromium-review.googlesource.com/314384 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Pratikkumar V Prajapati <pratikkumar.v.prajapati@intel.com> Commit-Queue: Hannah Williams <hannah.williams@intel.com> Tested-by: Hannah Williams <hannah.williams@intel.com> (cherry picked from commit c25d7221679d1fab830d614eeabfa3436bce6ac1) BUG=chrome-os-partner:50516 BRANCH=glados TEST=build and boot on chell Change-Id: I1cbdf4e940b009c74ee8ed8f4fca85f4f5c943b2 Signed-off-by: Patrick Georgi <pgeorgi@google.com> Original-Commit-Id: 27bba336e620a2d3d331e350d4f46164e337fabc Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Original-Change-Id: I84e2acd748856437b40bbf997bf23f158c711712 Original-Reviewed-on: https://chromium-review.googlesource.com/329291 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/13836 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2016-02-04lib: add bootmode.c to verstageAaron Durbin
Some of the functions within bootmode.c may be required by boards in verstage. Therefore, allow this file to be built in verstage. BUG=chrome-os-partner:44827 BRANCH=glados TEST=Built chell w/ bootmode.c dependencies in separate verstage. Change-Id: Id291c1b5cc6594c3ee16c7c3385e682addc0efb6 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 084b620e12e7f948087786c0e34d5999a73137a5 Original-Change-Id: I2207819ec1490767cb1cf4b92e34e714783c1c22 Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/324071 Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://review.coreboot.org/13581 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2016-01-28Makefile: Make full use of src-to-obj macroNico Huber
There were several spots in the tree where the path to a per class object file was hardcoded. To make use of the src-to-obj macro for this, it had to be moved before the inclusion of subdirs. Which is fine, as it doesn't have dependencies beside $(obj). Tested by verifying that the resulting coreboot.rom files didn't change for all of Jenkins' abuild configurations. Change-Id: I2eb1beeb8ae55872edfd95f750d7d5a1cee474c4 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/13180 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2016-01-23arch/x86: link bootblock like other stages for C_ENVIRONMENT_BOOTBLOCKAaron Durbin
When C_ENVIRONMENT_BOOTBLOCK is selected link bootblock using the memlayout.ld scripts and infrastructure. This allows bootblock on x86 to utilize all the other coreboot infrastructure without relying romcc. Change-Id: Ie3e077d553360853bf33f30cf8a347ba1df1e389 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/13069 Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Tested-by: build bot (Jenkins) Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
2016-01-22lib: compile mdelay for romstagePatrick Georgi
Mimicking change I7037308d2, always compile mdelay for romstage. The boards that #included delay.c in the romstage now rely on the linker instead, which is a desirable cleanup. Change-Id: I7e5169ec94e5417536e967194e8eab67381e7c98 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/13115 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2016-01-22lib/Makefile.inc: Link hexdump.c in the bootblock as wellAlexandru Gagniuc
Change-Id: Id58f252e238cc3eb3fe9632493642d2a37c2a772 Signed-off-by: Alexandru Gagniuc <alexandrux.gagniuc@intel.com> Reviewed-on: https://review.coreboot.org/12873 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-01-21*/Makefile.inc: Compile files needed by uart8250 in x86 bootblockAlexandru Gagniuc
These files provide symbols needed by console and uart drivers. This was not an issue in the past, as we were not setting up a C environment this early in the boot process. Change-Id: Ied5106ac30a68971c8330e8f8270ab060994a89d Signed-off-by: Alexandru Gagniuc <alexandrux.gagniuc@intel.com> Reviewed-on: https://review.coreboot.org/12869 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-01-20lib: compile mdelay for bootblockPatrick Georgi
Mediatek's bootblock needs mdelay, which depends on a udelay implementation. Compiling the file for bootblock poses no harm: Either udelay exists (in which case mdelay is usable) or it doesn't in which case we see exactly the same kind of build time error (just with udelay instead of mdelay). Change-Id: I7037308d2d79c5cb1b05bb2b57a0912ad11cd7a6 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/13049 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2016-01-15lib: NHLT ACPI table supportAaron Durbin
Intel's SST (Smart Sound Technology) employs audio support which may not consist of HDA. In order to define the topology of the audio devices (mics, amps, codecs) connected to the platform a NHLT specification was created to pass this information from the firmware to the OS/userland. BUG=chrome-os-partner:44481 BRANCH=None TEST=Tested on glados. Audio does get emitted and some mic recording works. Change-Id: I8a9c2f4f76a0d129be44070f09d938c28a73fd27 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 2472af5793dcffd2607a7b95521ddd25b4be0e8c Original-Change-Id: If469f99ed1a958364101078263afb27761236421 Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/312264 Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://review.coreboot.org/12935 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2015-12-10lib: remove assets infrastructureAaron Durbin
Now that only CBFS access is supported for finding resources within the boot media the assets infrastructure can be removed. Remove it. BUG=chromium:445938 BRANCH=None TEST=Built and ran on glados. Change-Id: I383fd6579280cf9cfe5a18c2851baf74cad004e9 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/12690 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-12-10cbfs/vboot: remove firmware component supportAaron Durbin
The Chrome OS verified boot path supported multiple CBFS instances in the boot media as well as stand-alone assets sitting in each vboot RW slot. Remove the support for the stand-alone assets and always use CBFS accesses as the way to retrieve data. This is implemented by adding a cbfs_locator object which is queried for locating the current CBFS. Additionally, it is also signalled prior to when a program is about to be loaded by coreboot for the subsequent stage/payload. This provides the same opportunity as previous for vboot to hook in and perform its logic. BUG=chromium:445938 BRANCH=None TEST=Built and ran on glados. CQ-DEPEND=CL:307121,CL:31691,CL:31690 Change-Id: I6a3a15feb6edd355d6ec252c36b6f7885b383099 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/12689 Tested-by: build bot (Jenkins) Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com> Reviewed-by: Patrick Georgi <pgeorgi@google.com> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-11-17arm64: tegra132: tegra210: Remove old arm64/stage_entry.SJulius Werner
This patch removes the old arm64/stage_entry.S code that was too specific to the Tegra SoC boot flow, and replaces it with code that hides the peculiarities of switching to a different CPU/arch in ramstage in the Tegra SoC directories. BRANCH=None BUG=None TEST=Built Ryu and Smaug. !!!UNTESTED!!! Change-Id: Ib3a0448b30ac9c7132581464573efd5e86e03698 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/12078 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-11-11arm/arm64: Generalize bootblock C entry pointJulius Werner
When we first added ARM support to coreboot, it was clear that the bootblock would need to do vastly different tasks than on x86, so we moved its main logic under arch/. Now that we have several more architectures, it turns out (as with so many things lately) that x86 is really the odd one out, and all the others are trying to do pretty much the same thing. This has already caused maintenance issues as the ARM32 bootblock developed and less-mature architectures were left behind with old cruft. This patch tries to address that problem by centralizing that logic under lib/ for use by all architectures/SoCs that don't explicitly opt-out (with the slightly adapted existing BOOTBLOCK_CUSTOM option). This works great out of the box for ARM32 and ARM64. It could probably be easily applied to MIPS and RISCV as well, but I don't have any of those boards to test so I'll mark them as BOOTBLOCK_CUSTOM for now and leave that for later cleanup. BRANCH=None BUG=None TEST=Built Jerry and Falco, booted Oak. Change-Id: Ibbf727ad93651e388aef20e76f03f5567f9860cb Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/12076 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins)
2015-11-07arm64: remove secmonAaron Durbin
It's been decided to only support ARM Trusted Firmware for any EL3 monitor. That means any SoC that requires PSCI needs to add its support for ATF otherwise multi-processor bring up won't work. Change-Id: Ic931dbf5eff8765f4964374910123a197148f0ff Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/11897 Tested-by: build bot (Jenkins) Reviewed-by: Julius Werner <jwerner@chromium.org>
2015-10-31tree: drop last paragraph of GPL copyright headerPatrick Georgi
It encourages users from writing to the FSF without giving an address. Linux also prefers to drop that and their checkpatch.pl (that we imported) looks out for that. This is the result of util/scripts/no-fsf-addresses.sh with no further editing. Change-Id: Ie96faea295fe001911d77dbc51e9a6789558fbd6 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/11888 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2015-10-16bootblock: Link timestamp.c only with EARLY_CBMEM_INITPaul Menzel
Commit dbeedbef (arch/x86/bootblock: Link in object files selected with bootblock-y) breaks building of x86 boards with `CONFIG_EARLY_CBMEM_INIT` *not* selected but CBMEM time stamp collection enabled. Aaron Durbin explained as below [1] and provided this patch to fix it. > That change actually processes bootblock-objs where before it never did > such a thing. I'm sure this isn’t the only issue lurking. bootblock on > x86 implied romcc and thus all the bootblock-y += rules that other > architectures use worked, but now all the implied assumptions are no > longer true on x86. > > timestamp stuff on x86 !CONFIG_EARLY_CBMEM_INIT is the issue you're > seeing. In order to compile timestamp.c for bootblock under these > conditions will mean there needs to be some more Makefile guarding. [1] http://review.coreboot.org/11864 Change-Id: I3441b9fcdbbc8bbe82b9f2075e60668a846ecf09 Fix-by: Aaron Durbin <adurbin@chromium.org> Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-on: http://review.coreboot.org/11875 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Tested-by: build bot (Jenkins)
2015-10-14x86: add standalone verstage supportAaron Durbin
To support x86 verstage one needs a working buffer for vboot. That buffer resides in the cache-as-ram region which persists across verstage and romstage. The current assumption is that verstage brings cache-as-ram up and romstage tears cache-as-ram down. The timestamp, cbmem console, and the vboot work buffer are persistent through in both romstage and verstage. The vboot work buffer as well as the cbmem console are permanently destroyed once cache-as-ram is torn down. The timestamp region is migrated. When verstage is enabled the assumption is that _start is the romstage entry point. It's currently expected that the chipset provides the entry point to romstage when verstage is employed. Also, the car_var_*() APIs use direct access when in verstage since its expected verstage does not tear down cache-as-ram. Lastly, supporting files were added to verstage-y such that an x86 verstage will build and link. BUG=chrome-os-partner:44827 BRANCH=None TEST=Built and booted glados using separate verstage. Change-Id: I097aa0b92f3bb95275205a3fd8b21362c67b97aa Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/11822 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-09-22coreboot: introduce commonlibAaron Durbin
Instead of reaching into src/include and re-writing code allow for cleaner code sharing within coreboot and its utilities. The additional thing needed at this point is for the utilities to provide a printk() declaration within a <console/console.h> file. That way code which uses printk() can than be mapped properly to verbosity of utility parameters. Change-Id: I9e46a279569733336bc0a018aed96bc924c07cdd Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/11592 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
2015-09-09x86: link ramstage the same way regardless of RELOCATABLE_RAMSTAGEAaron Durbin
Previously there were 2 paths in linking ramstage. One was used for RELOCATABLE_RAMSTAGE while the other was fixed location. Now that rmodtool can handle multiple secitons for a single proram segment there's no need for linking ramstage using lib/rmodule.ld. That also means true rmodules don't have symbols required for ramstage purposes so fix memlayout.h. Lastly add default rules for creating rmod files from the known file names and locations. BUG=chrome-os-partner:44827 BRANCH=None TEST=Built rambi. Inspected ramstage.debug as well as rmodules created during the build. Change-Id: I98d249036c27cb4847512ab8bca5ea7b02ce04bd Signed-off-by: Aaron Durbin <adubin@chromium.org> Reviewed-on: http://review.coreboot.org/11524 Tested-by: build bot (Jenkins) Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-09-09linking: add and use LDFLAGS_commonAaron Durbin
Add an LDFLAGS_common variable and use that for each stage during linking within all the architectures. All the architectures support gc-sections, and as such they should be linking in the same way. BUG=chrome-os-partner:44827 BRANCH=None TEST=Built rambi and analyzed the relocatable ramstage. Change-Id: I41fbded54055455889b297b9e8738db4dda0aad0 Signed-off-by: Aaron Durbin <adubin@chromium.org> Reviewed-on: http://review.coreboot.org/11522 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com> Reviewed-by: Julius Werner <jwerner@chromium.org>
2015-09-09verstage: use common program.ld for linkingAaron Durbin
There's no reason to have a separate verstage.ld now that there is a unified stage linking strategy. Moreover verstage support is throughout the code base as it is so bring in those link script macros into the common memlayout.h as that removes one more specific thing a board/chipset needs to do in order to turn on verstage. BUG=chrome-os-partner:44827 BRANCH=None TEST=None Change-Id: I1195e06e06c1f81a758f68a026167689c19589dd Signed-off-by: Aaron Durbin <adubin@chromium.org> Reviewed-on: http://review.coreboot.org/11516 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-09-09x86: link romstage like the other architecturesAaron Durbin
All the other architectures are using the memlayout for linking romstage. Use that same method on x86 as well for consistency. BUG=chrome-os-partner:44827 BRANCH=None TEST=Built a myriad of boards. Analyzed readelf output. Change-Id: I016666c4b01410df112e588c2949e3fc64540c2e Signed-off-by: Aaron Durbin <adubin@chromium.org> Reviewed-on: http://review.coreboot.org/11510 Tested-by: build bot (Jenkins) Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-09-09linking: move romstage and bootblock to use program.ldAaron Durbin
Instead of having separate <stage>.ld files in src/lib one file can be used: program.ld. There's now only one touch point for stage layout. BUG=chrome-os-partner:44827 BRANCH=None TEST=Built a myriad of boards. Analyzed readelf output. Change-Id: I4c3e3671d696caa2c7601065a85fab803e86f971 Signed-off-by: Aaron Durbin <adubin@chromium.org> Reviewed-on: http://review.coreboot.org/11509 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-09-09linking: lay the groundwork for a unified linking approachAaron Durbin
Though coreboot started as x86 only, the current approach to x86 linking is out of the norm with respect to other architectures. To start alleviating that the way ramstage is linked is partially unified. A new file, program.ld, was added to provide a common way to link stages by deferring to per-stage architectural overrides. The previous ramstage.ld is no longer required. Note that this change doesn't handle RELOCATABLE_RAMSTAGE because that is handled by rmodule.ld. Future convergence can be achieved, but for the time being that's being left out. BUG=chrome-os-partner:44827 BRANCH=None TEST=Built a myriad of boards. Change-Id: I5d689bfa7e0e9aff3a148178515ef241b5f70661 Signed-off-by: Aaron Durbin <adubin@chromium.org> Reviewed-on: http://review.coreboot.org/11507 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com> Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com> Reviewed-by: Julius Werner <jwerner@chromium.org>
2015-08-09Only apply libgcc workaround on x86-32Stefan Reinauer
This should probably be moved out of lib and to arch/x86, since it does not even apply on x86-64, and ARM has its own copy of libgcc. Change-Id: I4fca1323927f8d37128472ed60d059f7a459fc71 Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-on: http://review.coreboot.org/11110 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-06-30lib: add delay.c to bootblock if I2C_TPM driver is enabledPatrick Georgi
Change-Id: I752fcc3b8687e4f861c3977322ebb6439f14fac4 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/10708 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-06-05lib: Unify log2() and related functionsJulius Werner
This patch adds a few bit counting functions that are commonly needed for certain register calculations. We previously had a log2() implementation already, but it was awkwardly split between some C code that's only available in ramstage and an optimized x86-specific implementation in pre-RAM that prevented other archs from pulling it into earlier stages. Using __builtin_clz() as the baseline allows GCC to inline optimized assembly for most archs (including CLZ on ARM/ARM64 and BSR on x86), and to perform constant-folding if possible. What was previously named log2f on pre-RAM x86 is now ffs, since that's the standard name for that operation and I honestly don't have the slightest idea how it could've ever ended up being called log2f (which in POSIX is 'binary(2) LOGarithm with Float result, whereas the Find First Set operation has no direct correlation to logarithms that I know of). Make ffs result 0-based instead of the POSIX standard's 1-based since that is consistent with clz, log2 and the former log2f, and generally closer to what you want for most applications (a value that can directly be used as a shift to reach the found bit). Call it __ffs() instead of ffs() to avoid problems when importing code, since that's what Linux uses for the 0-based operation. CQ-DEPEND=CL:273023 BRANCH=None BUG=None TEST=Built on Big, Falco, Jerry, Oak and Urara. Compared old and new log2() and __ffs() results on Falco for a bunch of test values. Change-Id: I599209b342059e17b3130621edb6b6bbeae26876 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 3701a16ae944ecff9c54fa9a50d28015690fcb2f Original-Change-Id: I60f7cf893792508188fa04d088401a8bca4b4af6 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/273008 Original-Reviewed-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/10394 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-06-02assets: abstract away the firmware assets used for bootingAaron Durbin
As there can be more than one source of firmware assets this patch generalizes the notion of locating a particular asset. struct asset is added along with some helper functions for working on assets as a first class citizen. Change-Id: I2ce575d1e5259aed4c34c3dcfd438abe9db1d7b9 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/10264 Reviewed-by: Patrick Georgi <pgeorgi@google.com> Tested-by: build bot (Jenkins)
2015-06-02cbfs: new API and better program loadingAaron Durbin
A new CBFS API is introduced to allow making CBFS access easier for providing multiple CBFS sources. That is achieved by decoupling the cbfs source from a CBFS file. A CBFS source is described by a descriptor. It contains the necessary properties for walking a CBFS to locate a file. The CBFS file is then decoupled from the CBFS descriptor in that it's no longer needed to access the contents of the file. All of this is accomplished using the regions infrastructure by repsenting CBFS sources and files as region_devices. Because region_devices can be chained together forming subregions this allows one to decouple a CBFS source from a file. This also allows one to provide CBFS files that came from other sources for payload and/or stage loading. The program loading takes advantage of those very properties by allowing multiple sources for locating a program. Because of this we can reduce the overhead of loading programs because it's all done in the common code paths. Only locating the program is per source. Change-Id: I339b84fce95f03d1dbb63a0f54a26be5eb07f7c8 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9134 Tested-by: build bot (Jenkins) Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-05-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-26coreboot: introduce boot_deviceAaron Durbin
The boot_device is a region_device that represents the device from which coreboot retrieves and boots its stages. The existing cbfs implementations use the boot_device as the intermediary for accessing the CBFS region. Also, there's currently only support for a read-only view of the boot_device. i.e. one cannot write to the boot_device using this view. However, a writable boot_device could be added in the future. Change-Id: Ic0da796ab161b8025c90631be3423ba6473ad31c Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/10216 Tested-by: build bot (Jenkins) Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-05-21Remove address from GPLv2 headersPatrick Georgi
As per discussion with lawyers[tm], it's not a good idea to shorten the license header too much - not for legal reasons but because there are tools that look for them, and giving them a standard pattern simplifies things. However, we got confirmation that we don't have to update every file ever added to coreboot whenever the FSF gets a new lease, but can drop the address instead. util/kconfig is excluded because that's imported code that we may want to synchronize every now and then. $ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, *MA[, ]*02110-1301[, ]*USA:Foundation, Inc.:" {} + $ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin Street, Suite 500, Boston, MA 02110-1335, USA:Foundation, Inc.:" {} + $ find * -type f -exec sed -i "s:Foundation, Inc., 59 Temple Place[-, ]*Suite 330, Boston, MA *02111-1307[, ]*USA:Foundation, Inc.:" {} + $ find * -type f -exec sed -i "s:Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.:Foundation, Inc.:" {} + $ find * -type f -a \! -name \*.patch \ -a \! -name \*_shipped \ -a \! -name LICENSE_GPL \ -a \! -name LGPL.txt \ -a \! -name COPYING \ -a \! -name DISCLAIMER \ -exec sed -i "/Foundation, Inc./ N;s:Foundation, Inc.* USA\.* *:Foundation, Inc. :;s:Foundation, Inc. $:Foundation, Inc.:" {} + Change-Id: Icc968a5a5f3a5df8d32b940f9cdb35350654bef9 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/9233 Tested-by: build bot (Jenkins) Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
2015-05-20build system: use archives, not linker action to shorten command linesPatrick Georgi
Intermediate linking may distort linker behavior (in particular related to weak symbols). The idea is that archives are closer to 'just a list of object files', and ideally makes the linker more predictable. Using --whole-archive, the linker doesn't optimize out object files just because their symbols were already provided by weak versions. However it shouldn't be used for libgcc, because that one has some unexpected side-effects. Change-Id: Ie226c198a93bcdca2d82c02431c72108a1c6ea60 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/10139 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
2015-05-14coreboot: add memory pool infrastructureAaron Durbin
The memory pool infrastructure provides an allocator with very simple free()ing semantics: only the most recent allocation can be freed from the pool. However, it can be reset and when not used any longer providing the entire region for future allocations. Change-Id: I5ae9ab35bb769d78bbc2866c5ae3b5ce2cdce5fa Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9129 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-05-14coreboot: add region infrastructureAaron Durbin
The region infrastructure provides a means of abstracting access to different types of storage such as SPI flash, MMC, or just plain memory. The regions are represented by region devices which can be chained together forming subregions of the larger region. This allows the call sites to be agnostic about the implementations behind the regions. Additionally, this prepares for a cleaner API for CBFS accesses. Change-Id: I803f97567ef0505691a69975c282fde1215ea6da Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9128 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-05-13secmon: allow for serial consoleAaron Durbin
Add necessary checks and objects for secmon serial console. Change-Id: Ibafa19061255ef6847a424922565a866328ff34c Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/10197 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins)
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-11vboot: inject vboot loader for stage loadingAaron Durbin
As previously done the vboot loader can be optionally inserted in the stage loading logic in order to decide the source of each stage. This current patch allows for verstage to be loaded and interrogated for the source of all subsequent stages. Additionally, it's also possible to build this logic directly into one of the additional stages. Note that this patch does not allow x86 to work. Change-Id: Iece018f01b220720c2803dc73c60b2c080d637d0 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/10154 Reviewed-by: Patrick Georgi <pgeorgi@google.com> 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-05vboot: add cbfs_coreAaron Durbin
And we don't support lzma compressed data in verstage. Change-Id: I3d8d3290f147871c49e9440e9b54bbf2742aaa9e Signed-off-by: Aaron Durbin <adurbin@chromium.org> Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/10103 Tested-by: build bot (Jenkins)
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-28lib: When used, add timestamp.c to bootblock and verstage, tooPatrick Georgi
Otherwise it won't build. Change-Id: If9e1435b0dc8bfe220b3a257976e928373fbc9a5 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/10003 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2015-04-27lib/tlcl: Provide mock implementationYen Lin
It returns TPM_E_NO_DEVICE for all calls. BRANCH=None BUG=None TEST=manual MOCK_TPM=1 emerge-foster coreboot, and coreboot can boot to kernel Change-Id: Id7e79b58fabeac929b874385064b2417db49a708 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: a9a91a65af115657e7317754eda931120750c56d Original-Signed-off-by: Yen Lin <yelin@nvidia.com> Original-Change-Id: I8dcf0db14cf2bc76c67a3bd7f06114e70e08764d Original-Reviewed-on: https://chromium-review.googlesource.com/264946 Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org> Reviewed-on: http://review.coreboot.org/9983 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-22cbmem: switch over to imd-based cbmemAaron Durbin
By design, the imd library still provdes dynamic growth so that feature is consistent. The imd-based cbmem packs small allocations into a larger entry using a tiered imd. The following examples show the reduced fragmentation and reduced memory usage. Before with dynamic cbmem: CBMEM ROOT 0. 023ff000 00001000 aaaabbbb 1. 023fe000 00001000 aaaabbbc 2. 023fd000 00001000 aaaabbbe 3. 023fc000 00001000 aaaacccc 4. 023fa000 00002000 aaaacccd 5. 023f9000 00001000 ROMSTAGE 6. 023f8000 00001000 CONSOLE 7. 023d8000 00020000 COREBOOT 8. 023d6000 00002000 After with tiered imd: IMD ROOT 0. 023ff000 00001000 IMD SMALL 1. 023fe000 00001000 aaaacccc 2. 023fc000 00001060 aaaacccd 3. 023fb000 000007cf CONSOLE 4. 023db000 00020000 COREBOOT 5. 023d9000 00002000 IMD small region: IMD ROOT 0. 023fec00 00000400 aaaabbbb 1. 023febe0 00000020 aaaabbbc 2. 023feba0 00000040 aaaabbbe 3. 023feb20 00000080 ROMSTAGE 4. 023feb00 00000004 Side note: this CL provides a basis for what hoops one needs to jump through when there are not writeable global variables on a particular platform in the early stages. Change-Id: If770246caa64b274819e45a26e100b62b9f8d2db Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9169 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2015-04-22coreboot: common stage cacheAaron Durbin
Many chipsets were using a stage cache for reference code or when using a relocatable ramstage. Provide a common API for the chipsets to use while reducing code duplication. Change-Id: Ia36efa169fe6bd8a3dbe07bf57a9729c7edbdd46 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/8625 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2015-04-22coreboot: add imd libraryAaron Durbin
The imd (internal memory database) library provides a way to track memory regions by assigning ids to each region. The implementation is a direct descendant of dynamic cbmem. The intent is to replace the existing mechanisms which do similar things: dynamic cbmem, stage cache, etc. Differences between dynamic cbmem and imd: - All structures/objects are relative to one another. There are no absolute pointers serialized to memory. - Allow limiting the size of the idm. i.e. provide a maximum memory usage. - Allow setting the size of the root structure which allows control of the number of allocations to track. Change-Id: Id7438cff80d396a594d6a7330d09b45bb4fedf2e Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/8621 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2015-04-22lib: add base64 decoderVadim Bendebury
It became necessary to decode base64 data retrieved from VPD and convert it into binary for inclusion in the device tree. The patch introduces the decoder function based on the description found in http://en.wikipedia.org/wiki/Base64. An open source implementation from http://base64.sourceforge.net was considered, in the end the only thing borrowed from it is the table to translate base64 ascii characters into numbers in 0..63 range. BRANCH=none BUG=chromium:450169 TEST=created a test harness generating random contents of random size (in 8 to 32766 bytes range), then converting the contents into base64 using the Linux utility, and then converting it back to binary using this function and comparing the results. It succeeded 1700 iterations before it was stopped. Change-Id: I502f2c9494c99ba95ece37a7220c0c70c4755be2 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 6609f76e1559d3cdd402276055c99e0de7da27c8 Original-Change-Id: I5ed68af3a4daead50c44ae0f0c63d836f4b66851 Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/262945 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9892 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-10gpio: compile gpio.c at all stagesDavid Hendricks
Since gpio.c is more generic now and will be used in various stages (ie for board_id()), compile it for all stages. BUG=none BRANCH=none TEST=compiled for peppy and veyron_pinky Change-Id: Ib5c73f68db92791dd6b42369f681f9159b7e1c22 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: ef4e40ccf6510d63c4a54451bdfea8da695e387e Original-Change-Id: I77ec56a77e75e602e8b9406524d36a8f69ce9128 Original-Signed-off-by: David Hendricks <dhendrix@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/228325 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/9414 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: David Hendricks <dhendrix@chromium.org> Tested-by: build bot (Jenkins)
2015-04-10gpio: decouple tristate gpio support from board IDDavid Hendricks
This deprecates TERTIARY_BOARD_ID. Instead, a board will set BOARD_ID_SUPPORT (the ones affected already do) which will set GENERIC_GPIO_SUPPORT and compile the generic GPIO library. The user is expected to handle the details of how the ID is encoded. BUG=none BRANCH=none TEST=Compiled for peppy, nyan*, storm, and pinky Change-Id: Iaf1cac6e90b6c931100e9d1b6735684fac86b8a8 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 93db63f419f596160ce2459eb70b3218cc83c09e Original-Change-Id: I687877e5bb89679d0133bed24e2480216c384a1c Original-Signed-off-by: David Hendricks <dhendrix@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/228322 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/9413 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-10gpio: cosmetic changes to tristate_gpios.cDavid Hendricks
This patch makes a few cosmetic changes: - Rename tristate_gpios.c to gpio.c since it will soon be used for binary GPIOs as well. - Rename gpio_get_tristates() to gpio_base3_value() - The binary version will be called gpio_base2_value(). - Updates call sites. - Change the variable name "id" to something more generic. BUG=none BRANCH=none TEST=compiled for veyron_pinky and storm Change-Id: Iab7e32f4e9d70853f782695cfe6842accff1df64 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: c47d0f33ea1a6e9515211b834009cf47a171953f Original-Change-Id: I36d88c67cb118efd1730278691dc3e4ecb6055ee Original-Signed-off-by: David Hendricks <dhendrix@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/228324 Reviewed-on: http://review.coreboot.org/9411 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-08timer: Add generic udelay() implementationAaron Durbin
Add GENERIC_UDELAY Kconfig option so that a generic udelay() implementation is provided utilizing the monotonic timer. That way each board/chipset doesn't need to duplicate the same udelay(). Additionally, assume that GENERIC_UDELAY implies init_timer() is not required. BUG=None BRANCH=None TEST=Built nyan, ryu, and rambi. May need help testing. Change-Id: I7f511a2324b5aa5d1b2959f4519be85a6a7360e8 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 1a85fbcad778933d13eaef545135abe7e4de46ed Original-Change-Id: Idd26de19eefc91ee3b0ceddfb1bc2152e19fd8ab Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/219719 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org> Reviewed-on: http://review.coreboot.org/9334 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-07rmodules: fix linkingAaron Durbin
In commit ec5e5e0d the rmodules linking flags were dropped. This resulted in relocations being removed from the ELF file. The relocation information is quite valuable when needing to perform relocations at runtime. Change-Id: I699477eb023fc6132e03699992dcf81a311d2d48 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9374 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins)
2015-04-06New mechanism to define SRAM/memory map with automatic bounds checkingJulius Werner
This patch creates a new mechanism to define the static memory layout (primarily in SRAM) for a given board, superseding the brittle mass of Kconfigs that we were using before. The core part is a memlayout.ld file in the mainboard directory (although boards are expected to just include the SoC default in most cases), which is the primary linker script for all stages (though not rmodules for now). It uses preprocessor macros from <memlayout.h> to form a different valid linker script for all stages while looking like a declarative, boilerplate-free map of memory addresses to the programmer. Linker asserts will automatically guarantee that the defined regions cannot overlap. Stages are defined with a maximum size that will be enforced by the linker. The file serves to both define and document the memory layout, so that the documentation cannot go missing or out of date. The mechanism is implemented for all boards in the ARM, ARM64 and MIPS architectures, and should be extended onto all systems using SRAM in the future. The CAR/XIP environment on x86 has very different requirements and the layout is generally not as static, so it will stay like it is and be unaffected by this patch (save for aligning some symbol names for consistency and sharing the new common ramstage linker script include). BUG=None TEST=Booted normally and in recovery mode, checked suspend/resume and the CBMEM console on Falco, Blaze (both normal and vboot2), Pinky and Pit. Compiled Ryu, Storm and Urara, manually compared the disassemblies with ToT and looked for red flags. Change-Id: Ifd2276417f2036cbe9c056f17e42f051bcd20e81 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: f1e2028e7ebceeb2d71ff366150a37564595e614 Original-Change-Id: I005506add4e8fcdb74db6d5e6cb2d4cb1bd3cda5 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/213370 Reviewed-on: http://review.coreboot.org/9283 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Tauner <stefan.tauner@gmx.at> Reviewed-by: Aaron Durbin <adurbin@google.com>
2015-04-06build system: run linker scripts through the preprocessorPatrick Georgi
This allows combining and simplifying linker scripts. This is inspired by the commit listed below, but rewritten to match upstream, and split in smaller pieces to keep intent clear. Change-Id: Ie5c11bd8495a399561cefde2f3e8dd300f4feb98 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Based-On-Change-Id: I50af7dacf616e0f8ff4c43f4acc679089ad7022b Based-On-Signed-off-by: Julius Werner <jwerner@chromium.org> Based-On-Reviewed-on: https://chromium-review.googlesource.com/219170 Reviewed-on: http://review.coreboot.org/9303 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-03program loading: add prog_run() functionAaron Durbin
The prog_run() function abstracts away what is required for running a given program. Within it, there are 2 calls: 1. platform_prog_run() and 2. arch_prog_run(). The platform_prog_run() allows for a chipset to intercept a program that will be run. This allows for CPU switching as currently needed in t124 and t132. Change-Id: I22a5dd5bfb1018e7e46475e47ac993a0941e2a8c Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/8846 Tested-by: build bot (Jenkins) Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com> Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2015-03-28arm64: Add support for secure monitorFurquan Shaikh
Secure monitor runs at EL3 and is responsible for jumping to the payload at specified EL and also to manage features like PSCI. Adding basic implementation of secure monitor as a rmodule. Currently, it just jumps to the the payload at current EL. Support for switching el and PSCI will be added as separate patches. CQ-DEPEND=CL:218300 BUG=chrome-os-partner:30785 BRANCH=None TEST=Compiles succesfully and secure monitor loads and runs payload on ryu Change-Id: If0f22299a9bad4e93311154e5546f5bae3f3395c Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 5e40a21115aeac1cc3c73922bdc3e42d4cdb7d34 Original-Change-Id: I86d5e93583afac141ff61475bd05c8c82d17d926 Original-Signed-off-by: Furquan Shaikh <furquan@google.com> Original-Reviewed-on: https://chromium-review.googlesource.com/214371 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/9080 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-03-27cbfs/rmodule: add architecture specific operations at stage loadIonela Voinescu
Two weak functions were added so that architecture specific operations on each segment of payload or stage can be performed. Each architecture must define its own operations, otherwise the behavior will default to do-nothing functions. This patch has been updated by to fit more in line with how program loading is currently being done. The API is the same as the original, but all call sites to stages/payloads have been updated. This is known to break any archs that use rmodule loading that needs cache maintenance. That will be fixed in a forthcoming patch. Also, the vboot paths are left as is for easier upstreaming of the rest of the vboot patches. Original-Change-Id: Ie29e7f9027dd430c8b4dde9848fa3413c5dbfbfa Original-Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com> Original-Reviewed-on: https://chromium-review.googlesource.com/239881 Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org> (cherry picked from commit c82c21ce87a4c02bd9219548a4226a58e77beef0) Signed-off-by: Aaron Durbin <adurbin@chromium.org> Change-Id: Ifcee5cd9ac5dbca991556296eb5e170b47b77af7 Reviewed-on: http://review.coreboot.org/8837 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-03-23vboot2: read secdata and nvdataDaisuke Nojiri
This code ports antirollback module and tpm library from platform/vboot_reference. names are modified to conform to coreboot's style. The rollback_index module is split in a bottom half and top half. The top half contains generic code which hides the underlying storage implementation. The bottom half implements the storage abstraction. With this change, the bottom half is moved to coreboot, while the top half stays in vboot_reference. TEST=Built with USE=+/-vboot2 for Blaze. Built Samus, Link. BUG=none Branch=none Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> Original-Change-Id: I77e3ae1a029e09d3cdefe8fd297a3b432bbb9e9e Original-Reviewed-on: https://chromium-review.googlesource.com/206065 Original-Reviewed-by: Randall Spangler <rspangler@chromium.org> Original-Reviewed-by: Luigi Semenzato <semenzato@chromium.org> (cherry picked from commit 6b66140ac979a991237bf1fe25e0a55244a406d0) Change-Id: Ia3b8f27d6b1c2055e898ce716c4a93782792599c Signed-off-by: Aaron Durbin <adurbin@chromium.org> Signed-off-by: Marc Jones <marc.jones@se-eng.com> Reviewed-on: http://review.coreboot.org/8615 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com>
2015-03-23Publish the board ID value in coreboot table, when configuredVadim Bendebury
Board ID value is usually of interest to bootloaders. Instead of duplicating the board ID discovery code in different bootloaders let's determine it in coreboot and publish it through coreboot table, when configured. BUG=chrome-os-partner:30489 TEST=none yet Change-Id: Ia1e36b907ac15b0aafce0711f827cb83622e27bb Original-Change-Id: Iee247c44a1c91dbcedcc9058e8742c75ff951f43 Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/210116 Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> (cherry picked from commit b2057a02db9391e2085b138eea843e6bb09d3ea2) Signed-off-by: Marc Jones <marc.jones@se-eng.com> Reviewed-on: http://review.coreboot.org/8719 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-03-23Generalize revision number calculation functionVadim Bendebury
Some platforms use tertiary interpretation of GPIO input state to increase number of distinct values represented by a limited number of GPIOs. The three states are - external pull down (interpreted as 0) - external pull up (1) - not connected (2) This has been required by Nvidia devices so far, but Exynos and Ipq8086 platforms need this too. This patch moves the function reading the tertiary state into the library and exposes the necessary GPIO API functions in a new include file. The functions are still supposed to be provided by platform specific modules. The function interpreting the GPIO states has been modified to allow to interpret the state either as a true tertiary number or as a set two bit fields. Since linker garbage collection is not happening when building x86 targets, a new configuration option is being added to include the new module only when needed. BUG=chrome-os-partner:30489 TEST=verified that nyan_big still reports proper revision ID. Change-Id: Ib55122c359629b58288c1022da83e6c63dc2264d Original-Change-Id: I243c9f43c82bd4a41de2154bbdbd07df0a241046 Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/209673 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> (cherry picked from commit c79ef1c545d073eaad69e6c8c629f9656b8c2f3e) Signed-off-by: Marc Jones <marc.jones@se-eng.com> Reviewed-on: http://review.coreboot.org/8717 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-03-20verstage should include the CBFS SPI wrapper, when configuredVadim Bendebury
Vboot2 targets so far did not have COMMON_CBFS_SPI_WRAPPER configuration option enabled, so the verstage is missing the relevant files in some Makefiles. This patch fixes the problem. BRANCH=none BUG=none TEST=with the rest of the patches applied cosmos target builds fine with COMMON_CBFS_SPI_WRAPPER enabled Change-Id: I3ce78c8afc5f7d8ce822bbf8dd789c0c2ba4b99c Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: b72693c96f7d8ce94ce6fe12b316d5b88fded579 Original-Change-Id: Iab813b9f5b0156c45b007fe175500ef0de50e65c Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/223751 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/8772 Tested-by: build bot (Jenkins) Reviewed-by: David Hendricks <dhendrix@chromium.org>
2015-03-17coreboot: x86: enable gc-sectionsAaron Durbin
Garbage collected sections allow for trimming the size of the binaries as well as allowing for not needing to config off unused functions. To that end, on a rambi build the following differences are observed: $ diff -up \ <(readelf -l coreboot-builds/google_rambi/cbfs/fallback/ramstage.elf) \ <(readelf -l coreboot-builds/google_rambi_gc_sections/cbfs/fallback/ramstage.elf) --- /dev/fd/63 2015-03-10 12:07:27.927985430 -0500 +++ /dev/fd/62 2015-03-10 12:07:27.927985430 -0500 @@ -6,9 +6,9 @@ There are 4 program headers, starting at Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x001000 0x00000000 0x00000000 0x00040 0x00040 RWE 0 - LOAD 0x001040 0x00000040 0x00000040 0x34560 0x34560 RWE 0 - LOAD 0x0355a0 0x000345a0 0x000345a0 0x02578 0x02578 RWE 0 - LOAD 0x037b18 0x00036b18 0x00036b18 0x00000 0x0b560 0 + LOAD 0x001040 0x00000040 0x00000040 0x2cbf8 0x2cbf8 RWE 0 + LOAD 0x02dc38 0x0002cc38 0x0002cc38 0x02208 0x02208 RWE 0 + LOAD 0x02fe40 0x0002ee40 0x0002ee40 0x00000 0x0a888 0 Section to Segment mapping: Segment Sections... $ diff -up \ <(readelf -l coreboot-builds/google_rambi/cbfs/fallback/romstage.elf) \ <(readelf -l coreboot-builds/google_rambi_gc_sections/cbfs/fallback/romstage.elf) --- /dev/fd/63 2015-03-10 12:08:16.855985880 -0500 +++ /dev/fd/62 2015-03-10 12:08:16.851985880 -0500 @@ -5,8 +5,8 @@ There are 1 program headers, starting at Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align - LOAD 0x000060 0xfff20000 0xfff20000 0x08b81 0x08b81 R E 0x10 + LOAD 0x000060 0xfff20000 0xfff20000 0x06300 0x06300 R E 0x10 Section to Segment mapping: Segment Sections... - 00 .rom .text + 00 .rom The following warnings needed to be applied to CFLAGS_common because for some reason gcc was miraculously emitting the warnings with the unrelated *-sections options: -Wno-unused-but-set-variable Change-Id: I210784fdfc273ce4cb9927352cbd5a51be3c6929 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/8635 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2015-01-27CBMEM: Always use DYNAMIC_CBMEMKyösti Mälkki
Drop the implementation of statically allocated high memory region for CBMEM. There is no longer the need to explicitly select DYNAMIC_CBMEM, it is the only remaining choice. Change-Id: Iadf6f27a134e05daa1038646d0b4e0b8f9f0587a Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/7851 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@google.com>
2015-01-27CBMEM console: Fix and enhance pre-RAM supportKyösti Mälkki
Use the value of CONSOLE_PRERAM_BUFFER_SIZE to determine if we can do CBMEM console in bootblock and romstage. Kconfig forces it to zero if _BASE is unset or we cannot do CAR migration on x86. Add CBMEM console to bootblock, except for x86. Only one of bootblock and romstage clears the pre-RAM buffer. To start with empty console log on S3 wakeup, ramstage now clears previous contents of CBMEM buffer if there was no pre-RAM buffer. Unify Kconfig variable naming. TODO: ARM configurations do not define PRERAM_BUFFER_BASE values. Change-Id: I70d82da629529dbfd7bc9491223abd703cbc0115 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/7862 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com>
2015-01-27vboot2: implement select_firmware for pre-romstage verificationDaisuke Nojiri
This patch has a basic structure of vboot2 integration. It supports only Nyans, which have bootblock architecture and romstage architecture are compatible from linker's perspective. TEST=Built with VBOOT2_VERIFY_FIRMWARE on/off. Booted Nyan Blaze. BUG=None BRANCH=none Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> Original-Change-Id: I4bbd4d0452604943b376bef20ea8a258820810aa Original-Reviewed-on: https://chromium-review.googlesource.com/204522 Original-Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org> Original-Commit-Queue: Daisuke Nojiri <dnojiri@chromium.org> Original-Tested-by: Daisuke Nojiri <dnojiri@chromium.org> (cherry picked from commit a6bce0cbed34def60386f3d9aece59e739740c58) Signed-off-by: Marc Jones <marc.jones@se-eng.com> Change-Id: I63ddfbf463c8a83120828ec8ab994f8146f90001 Reviewed-on: http://review.coreboot.org/8160 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins)
2015-01-09Primitive memory testDavid Hendricks
This adds a generic primitive memory test. We should look into using tests in src/lib/ramtest.c, but they seem to rely too heavily on x86 asm and this test has been useful on multiple ARM platforms. BUG=none BRANCH=none TEST=builds and runs on nyan Signed-off-by: David Hendricks <dhendrix@chromium.org> Original-Change-Id: Ia0fb4e12bc59bf708be13faf63c346b531eb3aed Original-Reviewed-on: https://chromium-review.googlesource.com/186309 Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Queue: David Hendricks <dhendrix@chromium.org> Original-Tested-by: David Hendricks <dhendrix@chromium.org> (cherry picked from commit e7625c15415eaf6053ce32b67d9d6ab18d776f5f) Signed-off-by: Marc Jones <marc.jones@se-eng.com> Conflicts: src/lib/Makefile.inc Change-Id: I34e7aedfd167199fd5db4cd4a766b2b80ddda79b Reviewed-on: http://review.coreboot.org/8150 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
2015-01-07CBMEM: Rename utility fileKyösti Mälkki
This file will have CBMEM init hooks API one day. Change-Id: I0c31495d4217a5eb235b13e6d8e8c99a87a3b840 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/8031 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2014-12-30Provide a common CBFS wrapper for SPI storageVadim Bendebury
Coreboot has all necessary infrastructure to use the proper SPI flash interface in bootblock for CBFS. This patch creates a common CBFS wrapper which can be enabled on different platforms as required. COMMON_CBFS_SPI_WRAPPER, a new configuration option, enables the common CBFS interface and prevents default inclusion of all SPI chip drivers, only explicitly configured ones will be included when the new feature is enabled. Since the wrapper uses the same driver at all stages, enabling the new feature will also make it necessary to include the SPI chip drivers in bootblock and romstage images. init_default_cbfs_media() can now be common for different platforms, and as such is defined in the library. BUG=none TEST=manual . with this change and the rest of the patches coreboot on AP148 comes up all the way to attempting to boot the payload (reading earlier stages from the SPI flash along the way). Original-Change-Id: Ia887bb7f386a0e23a110e38001d86f9d43fadf2c Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/197800 Original-Tested-by: Vadim Bendebury <vbendeb@google.com> Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> (cherry picked from commit 60eb16ebe624f9420c6191afa6ba239b8e83a6e6) Signed-off-by: Marc Jones <marc.jones@se-eng.com> Change-Id: I7b0bf3dda915c227659ab62743e405312dedaf41 Reviewed-on: http://review.coreboot.org/7932 Tested-by: build bot (Jenkins) Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
2014-12-30CBMEM: Always build for x86 romstageKyösti Mälkki
Always build CBMEM for romstage, even for boards that will not use it. We further restrict car_migrate_variables() runs to non-ROMCC boards without BROKEN_CAR_MIGRATE. This fixes regression of commit 71b21455 that broke CBMEM console support for boards with a combination of !EARLY_CBMEM_INIT && !HAVE_ACPI_RESUME. Change-Id: Ife91d7baebdc9bd1e086896400059a165d3aa90f Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/7877 Tested-by: build bot (Jenkins) Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
2014-12-28RELOCATABLE_RAMSTAGE: Fix weak symbols with ramstage_cacheKyösti Mälkki
We had NULL reference with cache_loaded_ramstage() if CACHE_RELOCATED_RAMSTAGE_OUTSIDE_CBMEM was not set so boot never proceeded to ramstage. Cache implementation outside CBMEM provides means for platform-specific location so there is no need of weak attributes here. Change-Id: I1eb1a713896395c424fde23252c374f9065fe74d Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/7954 Tested-by: build bot (Jenkins) Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
2014-11-30gcc.c: Test for gcc, not for non-clangPatrick Georgi
This is gcc specific, not necessary-everywhere-but-on-clang. Change-Id: Ie02587bd41c856cbf730ea2f72f594a20b5fefbe Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: http://review.coreboot.org/7609 Tested-by: build bot (Jenkins) Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2014-11-30Introduce halt()Patrick Georgi
It's a portable and generic way to halt the system. Useful when waiting for the platform to reset. Change-Id: Ie07f3333d294a4d3e982cbc2ab9014c94b39fce0 Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: http://review.coreboot.org/7605 Tested-by: build bot (Jenkins) Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
2014-11-25build system: unify linker use across gcc and clangPatrick Georgi
Let's just call ld directly for gcc, too. Change-Id: I305eb92ed0d21b098134a7eb5a9f9fe3b126aeea Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-on: http://review.coreboot.org/7553 Tested-by: build bot (Jenkins) Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
2014-11-25build system: use a single variable name for compiler runtimesPatrick Georgi
We build with either gcc or clang, no need to keep both around Change-Id: I9af2cc7636bdc791a68ba8ed6e7c5a81973c5dfd Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-on: http://review.coreboot.org/7552 Tested-by: build bot (Jenkins) Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2014-11-20Replace includes of build.h with version.hKyösti Mälkki
As build.h is an auto-generated file it was necessary to add it as an explicit prerequisite in the Makefiles. When this was forgotten abuild would sometimes fail with following error: fatal error: build.h: No such file or directory Fix this error by compiling version.c into all stages. Change-Id: I342f341077cc7496aed279b00baaa957aa2af0db Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/7510 Tested-by: build bot (Jenkins) Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
2014-11-19lib/lzma.c: Use header over .c includeEdward O'Callaghan
Change-Id: I904eb1703eaf4f8de1b4ec443173686c7985be12 Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-on: http://review.coreboot.org/7427 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Marc Jones <marc.jones@se-eng.com> Tested-by: build bot (Jenkins)
2014-11-19lib/cbfs: Use linker symbols over .c include in cbfs.cEdward O'Callaghan
Change-Id: Ieb7f383c84401aab87adc833deebf289cd0c9a0f Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-on: http://review.coreboot.org/7426 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2014-11-12src/lib/Makefile.inc: Allow rmodules to link under ClangEdward O'Callaghan
rmodules were getting linked with libgcc and not libcompiler-rt. Unfortunately this is pretty ugly however we do this else where in the build system so its consistently ugly. The build system will later need a unification pass between compilers once we are tree stable on Clang. Change-Id: I380f7386de2c5adfa9036311323ad9f703b6e712 Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-on: http://review.coreboot.org/7440 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2014-10-22reg_script: include in romstageIsaac Christensen
The new broadwell support uses the reg_script functions in romstage. Change-Id: Ic040bf947d35854711f4c1547858b0e4378ef759 Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/7003 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2014-08-25delay: Have mdelay() / delay() available in romstage, tooStefan Reinauer
Some drivers (like the I2C TPM driver) call mdelay instead of udelay. While it's a shame that these chips are so slow, the overhead of having those functions available in romstage is minimal. Signed-off-by: Stefan Reinauer <reinauer@google.com> Change-Id: I1fa888fc5ca4489def16ac92e2f8260ccc26d792 Reviewed-on: https://chromium-review.googlesource.com/167542 Reviewed-by: Stefan Reinauer <reinauer@google.com> Tested-by: Stefan Reinauer <reinauer@google.com> Commit-Queue: Stefan Reinauer <reinauer@google.com> (cherry picked from commit 7083b6b843d803bd4ddbd8a5aaf9c5c05bad2044) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6531 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2014-08-11coreboot classes: Add dynamic classes to corebootFurquan Shaikh
Provide functionality to create dynamic classes based on program name and architecture for which the program needs to be compiled/linked. define_class takes program_name and arch as its arguments and adds the program_name to classes-y to create dynamic class. Also, compiler toolset is created for the specified arch. All the files for this program can then be added to program_name-y += .. Ensure that define_class is called before any files are added to the class. Check subdirs-y for order of directory inclusion. One such example of dynamic class is rmodules. Multiple rmodules can be used which need to be compiled for different architectures. With dynamic classes, this is possible. Change-Id: Ie143ed6f79ced5f58c200394cff89b006bc9b342 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: http://review.coreboot.org/6426 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2014-06-27lib/Makefile.inc: Stop gcc.c getting into SMM clang buildsEdward O'Callaghan
The libgcc runtime workarounds found in gcc.c are not needed for compiler-rt used by the Clang toolchain. Stop gcc.c from sneaking into Clang builds while processing boards that use SMM code. Change-Id: I51e8d517784721d28b4d951bd0bebc8b52682a8e Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-on: http://review.coreboot.org/6121 Tested-by: build bot (Jenkins) Reviewed-by: Idwer Vollering <vidwer@gmail.com>
2014-06-06build: Drop libgcc runtime wrapper in Clang buildsEdward O'Callaghan
This GCC specific workaround of wrapping of libgcc runtime symbols with gcc.c is not nessary with libcompiler-rt linkage. Change-Id: I50a2bc99d97f68a2ad2b51a92ea0e7086bab35fe Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-on: http://review.coreboot.org/5812 Tested-by: build bot (Jenkins) Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2014-05-06Introduce stage-specific architecture for corebootFurquan Shaikh
Make all three coreboot stages (bootblock, romstage and ramstage) aware of the architecture specific to that stage i.e. we will have CONFIG_ARCH variables for each of the three stages. This allows us to have an SOC with any combination of architectures and thus every stage can be made to run on a completely different architecture independent of others. Thus, bootblock can have an x86 arch whereas romstage and ramstage can have arm32 and arm64 arch respectively. These stage specific CONFIG_ARCH_ variables enable us to select the proper set of toolchain and compiler flags for every stage. These options can be considered as either arch or modes eg: x86 running in different modes or ARM having different arch types (v4, v7, v8). We have got rid of the original CONFIG_ARCH option completely as every stage can have any architecture of its own. Thus, almost all the components of coreboot are identified as being part of one of the three stages (bootblock, romstage or ramstage). The components which cannot be classified as such e.g. smm, rmodules can have their own compiler toolset which is for now set to *_i386. Hence, all special classes are treated in a similar way and the compiler toolset is defined using create_class_compiler defined in Makefile. In order to meet these requirements, changes have been made to CC, LD, OBJCOPY and family to add CC_bootblock, CC_romstage, CC_ramstage and similarly others. Additionally, CC_x86_32 and CC_armv7 handle all the special classes. All the toolsets are defined using create_class_compiler. Few additional macros have been introduced to identify the class to be used at various points, e.g.: CC_$(class) derives the $(class) part from the name of the stage being compiled. We have also got rid of COREBOOT_COMPILER, COREBOOT_ASSEMBLER and COREBOOT_LINKER as they do not make any sense for coreboot as a whole. All these attributes are associated with each of the stages. Change-Id: I923f3d4fb097d21071030b104c372cc138c68c7b Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: http://review.coreboot.org/5577 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@gmail.com>
2014-05-01Declare recovery and developer modes outside ChromeOSKyösti Mälkki
Move the implementation for recovery and developer modes from vendorcode/google/chromes to lib/. Change-Id: I33335fb282de2c7bc613dc58d6912c47f3b5c06c Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/4308 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com>
2014-04-01Static CBMEM / CAR: Flag boards with BROKEN_CAR_MIGRATEKyösti Mälkki
Use of CAR_GLOBAL is not safe after CAR is torn down, unless the board properly implements EARLY_CBMEM_INIT. Flag vulnerable boards that only do cbmem_recovery() in romstage on S3 resume and implementation with Intel FSP that invalidates cache before we have a chance to copy the contents. Change-Id: Iecd10dee9b73ab3f1f66826950fa0945675ff39f Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/5419 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com>
2014-03-20rmodules: use rmodtool to create rmodulesAaron Durbin
Start using the rmodtool for generating rmodules. rmodule_link() has been changed to create 2 rules: one for the passed in <name>, the other for creating <name>.rmod which is an ELF file in the format of an rmodule. Since the header is not compiled and linked together with an rmodule there needs to be a way of marking which symbol is the entry point. __rmodule_entry is the symbol used for knowing the entry point. There was a little churn in SMM modules to ensure an rmodule entry point symbol takes a single argument. Change-Id: Ie452ed866f6596bf13f137f5b832faa39f48d26e Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/5379 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins)