summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2015-04-14CBFS: Automate ROM image layout and remove hardcoded offsetsJulius Werner
Non-x86 boards currently need to hardcode the position of their CBFS master header in a Kconfig. This is very brittle because it is usually put in between the bootblock and the first CBFS entry, without any checks to guarantee that it won't overlap either of those. It is not fun to debug random failures that move and disappear with tiny alignment changes because someone decided to write "ORBC1112" over some part of your data section (in a way that is not visible in the symbolized .elf binaries, only in the final image). This patch seeks to prevent those issues and reduce the need for manual configuration by making the image layout a completely automated part of cbfstool. Since automated placement of the CBFS header means we can no longer hardcode its position into coreboot, this patch takes the existing x86 solution of placing a pointer to the header at the very end of the CBFS-managed section of the ROM and generalizes it to all architectures. This is now even possible with the read-only/read-write split in ChromeOS, since coreboot knows how large that section is from the CBFS_SIZE Kconfig (which is by default equal to ROM_SIZE, but can be changed on systems that place other data next to coreboot/CBFS in ROM). Also adds a feature to cbfstool that makes the -B (bootblock file name) argument on image creation optional, since we have recently found valid use cases for CBFS images that are not the first boot medium of the device (instead opened by an earlier bootloader that can already interpret CBFS) and therefore don't really need a bootblock. BRANCH=None BUG=None TEST=Built and booted on Veyron_Pinky, Nyan_Blaze and Falco. Change-Id: Ib715bb8db258e602991b34f994750a2d3e2d5adf Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: e9879c0fbd57f105254c54bacb3e592acdcad35c Original-Change-Id: Ifcc755326832755cfbccd6f0a12104cba28a20af Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/229975 Reviewed-on: http://review.coreboot.org/9620 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-14CBFS: Correct ROM_SIZE for ARM boards, use CBFS_SIZE for cbfstoolJulius Werner
Some projects (like ChromeOS) put more content than described by CBFS onto their image. For top-aligned images (read: x86), this has traditionally been achieved with a CBFS_SIZE Kconfig (which denotes the area actually managed by CBFS, as opposed to ROM_SIZE) that is used to calculate the CBFS entry start offset. On bottom-aligned boards, many define a fake (smaller) ROM_SIZE for only the CBFS part, which is not consistently done and can be an issue because ROM_SIZE is expected to be a power of two. This patch changes all non-x86 boards to describe their actual (physical) ROM size via one of the BOARD_ROMSIZE_KB_xxx options as a mainboard Kconfig select (which is the correct place to declare unchangeable physical properties of the board). It also changes the cbfstool create invocation to use CBFS_SIZE as the -s parameter for those architectures, which defaults to ROM_SIZE but gets overridden for special use cases like ChromeOS. This has the advantage that cbfstool has a consistent idea of where the area it is responsible for ends, which offers better bounds-checking and is needed for a subsequent fix. Also change the FMAP offset to default to right behind the (now consistently known) CBFS region for non-x86 boards, which has emerged as a de-facto standard on those architectures and allows us to reduce the amount of custom configuration. In the future, the nightmare that is ChromeOS's image build system could be redesigned to enforce this automatically, and also confirm that it doesn't overwrite any space used by CBFS (which is now consistently defined as the file size of coreboot.rom on non-x86). CQ-DEPEND=CL:231576,CL:231475 BRANCH=None BUG=chromium:422501 TEST=Built and booted on Veyron_Pinky. Change-Id: I89aa5b30e25679e074d4cb5eee4c08178892ada6 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: e707c67c69599274b890d0686522880aa2e16d71 Original-Change-Id: I4fce5a56a8d72f4c4dd3a08c129025f1565351cc Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/229974 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9619 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-14chromeec: Fix printf formatting warningAnatol Pomozov
src/ec/google/chromeec/ec_lpc.c: In function ‘google_chromeec_command_v3’: src/ec/google/chromeec/ec_lpc.c:88:3: error: format ‘%ld’ expects argument of type ‘long int’, but argument 3 has type ‘unsigned int’ [-Werror=format=] printk(BIOS_ERR, "EC cannot send %ld bytes\n", ^ cc1: all warnings being treated as errors Signed-off-by: Anatol Pomozov <anatol.pomozov@gmail.com> Change-Id: I0d47350f00102a959d54a64b8f932099fc13f886 Reviewed-on: http://review.coreboot.org/9558 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-14storm: add ipq8064 blobs to the CBFSVadim Bendebury
Files necessary for the SOC bringup are added to the CBFS as raw blobs. Ipq8064 specific MBN header will allow to determine were the blobs should be loaded and what start address should be used. BRANCH=storm BUG=chrome-os-partner:34161 TEST=build storm firmware and verify that the right components are added: $ emerge-storm coreboot chromeos-bootimage $ cbfstool /build/storm/firmware/image.bin print image.bin: 8192 kB, bootblocksize 32488, romsize 2883584, offset 0x7f40 alignment: 64 bytes, architecture: arm Name Offset Type Size cdt.mbn 0x7f40 raw 376 ddr.mbn 0x8100 raw 25820 rpm.mbn 0xe640 raw 78512 tz.mbn 0x21940 raw 85360 fallback/verstage 0x36700 stage 39500 fallback/romstage 0x401c0 stage 15652 fallback/ramstage 0x43f40 stage 24328 config 0x49e80 raw 2701 fallback/payload 0x4a940 payload 65592 u-boot.dtb 0x5a9c0 (unknown) 2922 (empty) 0x5b580 null 2509336 $ Change-Id: I967cd20364c90a1ef7add959621992c2356f158d Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: 6b5238d47da417b8b1993ad3348f4c32381cd0e4 Original-Change-Id: Id642ae68ef07750624f85b31ad891752d8af99bf Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/233672 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9577 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2015-04-14ipq8064: use the new utility to build bootblockVadim Bendebury
The first blob in the Storm bootimage is a concatenation of the Uber-sbl produced by the qca-firmware ebuild and the coreboot bootblock. The new tool is used to add the bootblock to uber-sbl and update the size values in the combined header. BRANCH=storm BUG=chrome-os-partner:34161 TEST=no execution tests yet, the build succeeds. Change-Id: I4f1fe8a97ffab04eee4f82bc43e6f5406dd9bb42 Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: a126a62f65a568d62fe35bdcf27eaec38fd1a997 Original-Change-Id: Iec3c1e943f1f9ee5ca20320a6365fc4aa5516e38 Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/232310 Original-Reviewed-by: Manoj Juneja <mjuneja@qti.qualcomm.com> Original-Reviewed-by: Trevor Bourget <tbourget@codeaurora.org> Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/9573 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2015-04-143rdparty: move checkout marker forwardStefan Reinauer
Move the 3rdparty marker to blobs.git commit 892a697 Change-Id: I8a51f301e08e49970b4747f004e0752617de8005 Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-on: http://review.coreboot.org/9625 Reviewed-by: Marc Jones <marc.jones@se-eng.com> Tested-by: build bot (Jenkins)
2015-04-13ti/am335x: switch to generic udelayPatrick Georgi
Change-Id: Iac1ddbb95768dea98917211aa995f4111bf82647 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/9617 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-13arch/mips: provide proper cache primitivesIonela Voinescu
This provides the opportunity to remove the kludge of disabling caches altogether in the bootblock. [pg: originally, this commit also provided automatic cache management after loading stages, ie. flush dcache, so code ends up in icache. This is done differently in upstream, so it's left out here] BUG=chrome-os-partner:34127, chrome-os-partner:31438 TEST=with this fix romstage, ramstage and payload are executed properly BRANCH=none Change-Id: I568c68d02b2cd9c1c2c9c1495ba3343c82509ccc Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 95ab0f159cabf21fc100f371d451211e7d113761 Original-Change-Id: Iaf90b052073dd355ab9114e8dba9f5ef76188c94 Original-Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com> Original-Reviewed-on: https://chromium-review.googlesource.com/232410 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9618 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-13broadwell: Work around VBIOS framebuffer issueDuncan Laurie
The first 64 bytes of the framebuffer contain garbage after running the option rom and after calling the VBE mode set with the flag to clear the framebuffer. Work around this issue by clearing the first 64 bytes in the framebuffer in the broadwell graphics setup code after it executes the VBIOS. BUG=chrome-os-partner:32771 BRANCH=samus,auron TEST=build and boot on samus in dev mode, check for graphical corruption Change-Id: I0381e32a5ea17e13c4ed598835999c12136418cf Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: f29c1b0b7c100cf290f82de671042823032f71c9 Original-Change-Id: I072bc913f7daea16e4861a7549e1b4ec85cde4cd Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/222676 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9464 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2015-04-13rk3288/exynos5250/exynos5420: Consolidate timer filesJulius Werner
Some boards spread their timer implementation out in multiple files with one function each for no discernable reason. Let's clean that up to make things a little simpler to find. BRANCH=None BUG=None TEST=Booted Pinky, compiled Daisy and Pit. Change-Id: I8b543d1a0d9af37bde5433b0c9271d687b2404b2 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 887765e1bd88d7aa49ad9a5e98b8831c10da6c10 Original-Change-Id: I43d29cd1b4a1d89cfd40f6cba5ca99ada3b00f82 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/234061 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9601 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-13rk3288: Increase PD_BUS_ACLK (SRAM clock) to improve boot speedJulius Werner
This patch doubles the ACLK peripheral clock for the PD_BUS power domain to 297MHz, which is the closest to the maximum of 300MHz we can reach by dividing GPLL. This frequency directly translates into SRAM speed, so maximizing it has a huge impact on boot speed (especially with the lack of SRAM caching). BUG=chrome-os-partner:32987 TEST=Booted Veyron_Pinky. Hacked timestamps into vboot and confirmed that the (visibly) long signature verification times are nearly halved. Change-Id: Iafa3044854a4058a7f885c775119d964a6295de4 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: c230585f4344d0eab4f8eeaa761869965f2da08a Original-Change-Id: I3f19eaa3d97dcc6235d820c71eb5edf2ae87d647 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/224524 Original-Trybot-Ready: Doug Anderson <dianders@chromium.org> Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/9600 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-13storm: Fix timer init order problemJulius Werner
Commit 257aaee9e3a (arm: Add bootblock_mainboard_early_init() for pre-console initialization) inadvertently moved the timer initialization after console initialization for IPQ806x, which is apparently not a good idea for this platform. This patch solves the issue by moving init_timer() to bootblock_mainboard_early_init(), which is the new hook explicitly provided to perform pre-console tasks. BRANCH=None BUG=None TEST=Built and booted Storm with 257aaee9e reverted. Noticed that it was already broken. Bisected coreboot and tracked down breakage to commit a126a62f (ipq8064: use the new utility to build bootblock). Built and booted successfully with this patch and a revert of a126a62f to confirm that the bug in question here is fixed. Change-Id: I4a3faa2aec8ff1fbbe6c389f1d048475aa944418 Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: 752d1f879f9bd841f18bd84842491f747458cf52 Original-Change-Id: Ie4aa2d06cb6fda6d5ff8dd5ea052257fb7b8a24b Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/233290 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: http://review.coreboot.org/9574 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-13ipq806x: copy i2c, qup, and gsbi drivers from depthchargeDaisuke Nojiri
this is a preparation for porting these drivers to coreboot. the code will be modified by the following patches. BUG=chrome-os-partner:33647 BRANCH=ToT TEST=None Change-Id: I2baeed5b6130ace2515d6e28115f8d1008004976 Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: 7c03a186a599be9d274c6fcdea1906529cc117d7 Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> Original-Change-Id: I9f3428ef02d2ba15ae63c99b10fe0605dd595313 Original-Reviewed-on: https://chromium-review.googlesource.com/231461 Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org> Original-Commit-Queue: Vadim Bendebury <vbendeb@chromium.org> Original-Tested-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: http://review.coreboot.org/9582 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-13storm: add hard_reset templateDaisuke Nojiri
this is required to do early firmware selection using vboot2. actual implementation can be done later. BUG=chrome-os-partner:33755 BRANCH=ToT TEST=Booted storm. Change-Id: I8e9e168ea6fa3af149d5ad4ca51c5c9bba4d986d Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: 611c24773478c8c212d567bb4f2cb9a09898ddc8 Original-Change-Id: Idd1a1de4991a19902ffe45f01be89d47f4413779 Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/229425 Original-Commit-Queue: Vadim Bendebury <vbendeb@chromium.org> Original-Tested-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: http://review.coreboot.org/9581 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-13util/ipqheader: Add utility to create uber-SBL for IPQ8064Vadim Bendebury
With the Storm image layout reworked, the very first blob read out of NOR SPI flash by the IPQ8064 maskrom is supposed to be a concatenation of three binaries: one to run on RPM, another one to run on AP, and the third one - the actual coreboot bootblock. This layout allows to greatly reduce the size and complexity of the two first blobs, as they do not need to include the SPI driver. The first binary in the input file list starts with the combined header, describing the rest of the blob. This utility copies the first input file into output, updating the combined header with the total size of the concatenated binaries. The second and third binaries in the combined image are required to be aligned at 256 byte offsets in the file as counted from the end of the combined header. The new utility allows to concatenate two or three files, always expecting the first file to be prepended by the combined header. For further reference below is the utility's help message: mbncat.py: [-v] [-h] [-o Output MBN] sbl1 sbl2 [bootblock] Concatenates up to three mbn files: two SBLs and a coreboot bootblock -h This message -v verbose -o Output file name, (default: sbl-ro.mbn) BRANCH=none BUG=chrome-os-partner:34161 TEST=run the new utility and compare the result with the output of the vendor provided tool. The output files are exactly the same. Change-Id: I1d3b3634ecc3f46ea88adb9b6c4fbfc017cc06ac Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: 94008340bc5eaf19d286b3feaa4091e5c5e285aa Original-Change-Id: I00724f7c75703fc90d7971c3cb337c33ca96f2b5 Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/232047 Original-Reviewed-by: Manoj Juneja <mjuneja@qti.qualcomm.com> Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/9572 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-13mips: disable caches in bootblock startup codeVadim Bendebury
Until proper MIPS cache management is available it is necessary to disable data and instruction caches, otherwise code placed in memory stays in data cache and is not available for instruction fetched. BRANCH=none BUG=chrome-os-partner:31438,chrome-os-partner:34127 TEST=coreboot loading rombase and rambase now succeeds. Change-Id: I4147e1325edc0b9bb951cd7ce18d5f104f3eaec0 Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: 93d5bfa1d01fbbabbabef33a22287ceeea28b15b Original-Change-Id: Ib195ed6e5f08ccaa6bbe3325c2199171bfb63b88 Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/232191 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9569 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
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-13rk3288: Move UART initialization to bootblock_mainboard_early_init()Julius Werner
This patch uses the new bootblock_mainboard_early_init() hook to run the UART pinmuxing on rk3288-based boards before initializing the console. This allows us to get rid of the hacky second console_init() call in bootblock_soc_init(). We can also simplify the pinmux selection a bit since we know that a given board always uses the same UART (still keep an assert around to be sure, though). BRANCH=None BUG=chrome-os-partner:32123 TEST=Booted on Pinky. Change-Id: I3da8b0e4bd609f33cedd934ce51cb20b1190024b Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: caabda8fc1ddb4805d86fd9a0d5d2f3cf738bfaf Original-Change-Id: Ia56c0599a15f966d087ca39181bfe23abd262e72 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/231942 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9604 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-13arm: Add bootblock_mainboard_early_init() for pre-console initializationJulius Werner
On most platforms, enabling the console and exception handlers are amongst the very first things you want to do, as they help you see what's going on and debug errors in other early init code. However, most ARM boards require some small amount of board-specific initialization (pinmuxing, maybe clocks) to get the UART running, which is why bootblock_mainboard_init() (and with it almost all of the actual bootblock code) always had to run before console initialization for now. This patch introduces an explicit bootblock_mainboard_early_init() hook for only that part of initialization that absolutely needs to run before console output. The other two hooks for SoC and mainboard are moved below console_init(). This model has already proven its worth before in the tegra124 and tegra132 custom bootblocks. BRANCH=None BUG=chrome-os-partner:32123 TEST=Booted on Pinky. Compiled for Daisy, Storm and Ryu. Change-Id: I510c58189faf0c08c740bcc3b5a654f81f892464 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: f58e84a2fc1c9951e9c4c65cdec1dbeb6a20d597 Original-Change-Id: I4257b5a8807595140e8c973ca04e68ea8630bf9a Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/231941 Reviewed-on: http://review.coreboot.org/9603 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-13arm: Redesign mainboard and SoC hooks for bootblockJulius Werner
This patch makes some slight changes to the way bootblock_cpu_init() and bootblock_mainboard_init() are used on ARM. Experience has shown that nearly every board needs either one or both of these hooks, so having explicit Kconfigs for them has become unwieldy. Instead, this patch implements them as a weak symbol that can be overridden by mainboard/SoC code, as the more recent arm64_soc_init() is also doing. Since the whole concept of a single "CPU" on ARM systems has kinda died out, rename bootblock_cpu_init() to bootblock_soc_init(). (This had already been done on Storm/ipq806x, which is now adjusted to directly use the generic hook.) Also add a proper license header to bootblock_common.h that was somehow missing. Leaving non-ARM32 architectures out for now, since they are still using the really old and weird x86 model of directly including a file. These architectures should also eventually be aligned with the cleaner ARM32 model as they mature. [pg: this was already partly upstreamed. These are the remains. Further cleanup is necessary and on the short-term TODO, but beyond the scope of this commit] BRANCH=None BUG=chrome-os-partner:32123 TEST=Booted on Pinky. Compiled for Storm and confirmed in the disassembly that bootblock_soc_init() is still compiled in and called right before the (now no-op) bootblock_mainboard_init(). Change-Id: Idf655894c4fec8fce7d3348d3b3e43b1613b35db Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 257aaee9e3aeeffe50ed54de7342dd2bc9baae76 Original-Change-Id: I57013b99c3af455cc3d7e78f344888d27ffb8d79 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/231940 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9602 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-13rush: Add and select DO_SOR_INIT config optionJimmy Zhang
Select DO_SOR_INIT to enable dp display api BUG=chrome-os-partner:34336 BRANCH=none TEST=build rush Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com> Change-Id: Iddf19195722856865a7c06ce96492012ab729184 Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: 31492f51c030aeb7a3ac792a02665642ec999405 Original-Change-Id: I4daca43239235ca6d233c4457096d3b98fcaf65c Original-Reviewed-on: https://chromium-review.googlesource.com/234274 Original-Tested-by: Jimmy Zhang <jimmzhang@nvidia.com> Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Original-Commit-Queue: Jimmy Zhang <jimmzhang@nvidia.com> Reviewed-on: http://review.coreboot.org/9586 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-13ryu: Add and select DO_DSI_INIT config optionJimmy Zhang
Enable display supporting functions by select DO_DSI_INIT BUG=chrome-os-partner:34336 BRANCH=none TEST=build ryu and rush Change-Id: Ie0e03506702ddab03d7f3fd2528c67c02126c7be Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: 7133dfcd1afa221be92c6398221cf210d9eddf17 Original-Change-Id: I3a9f93107333ebf83ff235eb1b1e02fc747df3c6 Original-Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com> Original-Reviewed-on: https://chromium-review.googlesource.com/234272 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9585 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-13ryu: display: Move display api to mainboardJimmy Zhang
Display configuration is board specific. The change here is preparing for supporting other than dsi interface. BUG=chrome-os-partner:34336 BRANCH=none TEST=build ryu and test dev/rec mode, also build rush ok Change-Id: Ied39d5d539d2be4983ab70976bffbe51fccba276 Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: 36be6b2e35c6246d5384d71b9ab9d4ddbf17764a Original-Change-Id: I494a04f7d6c0dbad2d472f4c2cd0aabfb23b8c97 Original-Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com> Original-Reviewed-on: https://chromium-review.googlesource.com/234271 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9584 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-13ryu: display: Split dc functions from dsi display codeJimmy Zhang
dc supporting functions can be used for other than dsi display interfaces. This change is preparing for supporting sor display interface. BUG=chrome-os-partner:34336 BRANCH=none TEST=build ryu and test dev/rec mode, also build rush ok Change-Id: I8a310e188fae70d7726c4360894b392c4546e105 Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: a7ab7225e3419a0fd93894dbb9a959390f29945b Original-Change-Id: Id14cbd89457cb91c23526927a432f4eb7cc6291b Original-Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com> Original-Reviewed-on: https://chromium-review.googlesource.com/234270 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9583 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-13ryu: audio: Setup I2S1/DAP2 and EXTPERIPH1/MCLK muxes correctlyTom Warren
This configures I2S1 and the codec MCLK muxes to pass the PCM audio data to the RT5677 codec. Once depthcharge RT5677 codec driver changes are in, audio 'beeps' should be heard on boot (Ctrl-U / devmode/recmode). BUG=chrome-os-partner:32582 BRANCH=none TEST=Built and booted Ryu/A44. Change-Id: I2143d544c75ee7e03ffc809561171920650e8d7d Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: 600c12ddf3543d2dcb47fd3e2f0704803dac5957 Original-Change-Id: Ib071bcb41fba8f6d628a386ed233ec84a54b0323 Original-Signed-off-by: Tom Warren <twarren@nvidia.com> Original-Reviewed-on: https://chromium-review.googlesource.com/233945 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9580 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-13rush: audio: Setup I2S1/DAP2 and EXTPERIPH1/MCLK muxes correctlyTom Warren
With this change, audio 'beeps' are heard on boot if Ctrl-U is pressed, or devmode/recmode is entered. I also tested via an explicit call to VbExBeep in the kernel boot path. Note that a couple of Rush CLs for depthcharge are needed for audio, too. BUG=chrome-os-partner:32582 BRANCH=none TEST=as above. Built and booted Rush/Norrin64. Change-Id: I43c65a4d11c5ab7b16289e19f3b42cfc0300ea7c Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: 4a682fb2403f7c6d53e74bfa945481242577f6c3 Original-Change-Id: Ia37f077569afd806ce6574c4c58813fd7aca1644 Original-Signed-off-by: Tom Warren <twarren@nvidia.com> Original-Reviewed-on: https://chromium-review.googlesource.com/233671 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9579 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-13rk3288: Increase the delay after DDR reset de-assert to 10us.Dailunxue
After DDR PHY reset de-asserted, DLL automatically starts to lock, and the lock time is maximum 5.12us. The output clock of DLL supplies the clocks of DDR controller and PHY digital logic. So before DLL lock, the clocks of DDR controller and PHY digital logic are indeterminate. When programming DDR in the period of DLL unlock, the programming maybe unstable because of the indeterminate clocks. So we need wait for at least 5.12us after de-asserting reset, then start to program DDR registers. 10us provide some safety margin. BUG=chrome-os-partner:33148 TEST=I'm using the following command line test ok(15000 cycles). "while sleep 4 && dut-control cold_reset:on sleep:.1 cold_reset:off; do : ; done" BRANCH=None Change-Id: Ie7d615f5a2264c615c4b4413d6b828cd3d78cd2b Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: 54e1a439c0e29aaf4fc542ae756f7bb036ceaf3e Original-Change-Id: I55f8cb11ed3d7962567c5f40a31e6c8aed8fdcb0 Original-Signed-off-by: DaiLunXue <dlx@rock-chips.com> Original-Reviewed-on: https://chromium-review.googlesource.com/232894 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Original-Commit-Queue: Lunxue Dai <lunxue.dai@rock-chips.com> Original-Tested-by: Lunxue Dai <lunxue.dai@rock-chips.com> Reviewed-on: http://review.coreboot.org/9578 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-13t132: Add I2S1 support to funitTom Warren
Used for audio on Rush/Ryu. I2S1/DAP2 provides the audio 'stream' for the dev/rec mode 'beeps'. BUG=chrome-os-partner:32582 BRANCH=none TEST=With follow-on CLs that make use of this support, audio beeps (via VbExBeep) can be heard on Rush. Built both Rush and Ryu OK. Change-Id: Iea5559db4431e48001adbbce17fa0f3aaaf8387c Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: 2bd701a5f4186e49739b25f4afd5000d5d9b4970 Original-Change-Id: Ia8c32303979f25300e22b5a14609d9d9d5ce3132 Original-Signed-off-by: Tom Warren <twarren@nvidia.com> Original-Reviewed-on: https://chromium-review.googlesource.com/233670 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9576 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-13rush: Add gpio config for PWR button and LID open switchJimmy Zhang
Due to CL https://chromium-review.googlesource.com/231250, depthcharge now detects gpio state based on gpio configurations done by coreboot instead of redoing configuration at depthcharge. However, PWR button and LID open pins have not been configured in coreboot. So, add the missing code here. Otherwise, TOT coreboot/depthcharge rush build can not load in kernel. BUG=chrome-os-partner:34336 BRANCH=none TEST=build rush and test with pwr button press and lid switch Change-Id: I7acc5e021fa769f68d4cbfd7202df325d4ea73c2 Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: a25dff24a2dcd33fcd15eb766432414af215c3ab Original-Change-Id: I6c322cd987967920f236aae653294db079678408 Original-Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com> Original-Reviewed-on: https://chromium-review.googlesource.com/233322 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9575 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-13nyan/rush/veyron: Align ChromeOS GPIOs to new modelJulius Werner
This CL makes slight changes to the ChromeOS-specific GPIO definitions of Tegra and Rockchip boards to prepare them for new features in depthcharge. It adds descriptions for the EC in RW and reset GPIOs, changes the value Tegra writes into the (previously unused) 'port' field to describe the complete GPIO information, and removes code to sample some GPIOs that don't need to be sampled at coreboot time (to help depthcharge detect errors and avoid using a stale value for something that should always represent the current state). BRANCH=None BUG=None TEST=None (tested together with depthcharge patches) Change-Id: I3774979dbe7cacce4932c85810596d80e5664028 Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: df295d0432fbf623597cf36ebb170bd4f63ee08d Original-Change-Id: I36bb16c8d931f862bf12a5b862b10cf18d738ddd Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/231222 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9570 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-13Fix dependency issue in Chrome OS vendor codeStefan Reinauer
make *config was complaining about mainboards selecting a virtual dev switch when CONFIG_CHROMEOS is not enabled. While the long term cleanup should be to move the option out of CONFIG_CHROMEOS and make it not be a user changeable option, this approach is contained to vendorcode/ and gets rid of the warning. Change-Id: Id090eb31d1307af7a0d1f9fbe641534dc24b24a9 Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-on: http://review.coreboot.org/9301 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
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-13broadwell: Fix incorrect SATA port map maskWenkai Du
WPT-LP has 4 SATA ports. Current code assumes 6 SATA ports and as a result, some reserved bits are written with 1. No specific issue has been observed so far. BUG=None BRANCH=None TEST=Verify SATA PCI configure space dump on Auron Change-Id: I737719b3d5cd788158cd5b6991405ba098be4078 Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: 2b55587a74ac5d45354dc123937b562290468855 Original-Change-Id: I9c53ac86e2bf72901647bd2cfa48ac0ce31abea0 Original-Signed-off-by: Wenkai Du <wenkai.du@intel.com> Original-Reviewed-on: https://chromium-review.googlesource.com/233661 Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/9479 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-13vboot: remove vboot_handoff.h from chromeos.hDaisuke Nojiri
chromeos.h includes vboot_handoff.h, which includes vboot_api.h. since vboot_api.h is not available to non-chromeos projects, build fails for some boards (e.g. glados). this change removes (unnecessary) inclusion of vboot_handoff.h in chromeos.h and fixes other files which rely on indirect inclusion of vboot_handoff.h by making it direct. BUG=none BRANCH=tot TEST=built for cosmos, falco, lumpy, nyan_blaze, parrot, rambi, rush_ryu, samus, storm, veyron_pinky Change-Id: I465e3657c6a0944bc75a669e5e52e74d46b3ec6c Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: 6ace70d721aceae9257288815ce8fd7c6c74b8f5 Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> Original-Change-Id: I12612773372e358584d12fffaf5f968a46083fab Original-Reviewed-on: https://chromium-review.googlesource.com/245864 Original-Tested-by: Leroy P Leahy <leroy.p.leahy@intel.com> Original-Reviewed-by: Leroy P Leahy <leroy.p.leahy@intel.com> Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/9566 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-13vboot2: Fill vboot1 handoff with correct TPM firmware versionJulius Werner
sd->fw_version represents the version of the *current* firmware, which is not necessarily the same as the one stored in the TPM (and may be 0 in recovery mode). Use the newly added sd->fw_version_secdata instead which contains a more correct value. CQ-DEPEND=CL:244601 BRANCH=veyron BUG=chrome-os-partner:35941 TEST=Booted Jerry in recovery mode, confirmed crossystem tpm_fwver was corrent (and not 0). Change-Id: I30f5998da5ac518d6fcb7a651eba4e1fabc14478 Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: eb8142f69cea34e11f9081caafcaae7a15cc3801 Original-Change-Id: Id95bd8c6412f2e8b2ae643c3b5a3dee13d0d47be Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/244591 Original-Reviewed-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: http://review.coreboot.org/9565 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-13The vboot_reference fwlib2 target has changed to fwlib20Bill Richardson
There are multiple vboot APIs (1.0, 2.0, 2.1). We have to be explicit about which library we want to link with. When building firmware, the vboot_reference Makefile should be invoked in one of three ways: TARGET OUTPUT VERSION fwlib vboot_fw.a 1.0 fwlib20 vboot_fw20.a 2.0 fwlib21 vboot_fw21.a 2.1 BUG=chromium:228932 BRANCH=ToT CQ-DEPEND=CL:243980 TEST=manual emerge-veyron_pinky vboot_reference coreboot emerge-samus vboot_reference coreboot emerge-daisy_spring vboot_reference chromeos-u-boot Change-Id: I7dde513c49b8148bf46e8768ae438e1a85af4243 Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: 5e339cadad4815f061d4e5e20a9c9733f64cc90b Original-Change-Id: I850646117211930d9215693c48f2c30d55a984d3 Original-Signed-off-by: Bill Richardson <wfrichar@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/243981 Original-Reviewed-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: http://review.coreboot.org/9564 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-13chromeos: add get_recovery_mode_from_vbnv() to vbnv_flashDavid Hendricks
The first platform that used flash-backed VBNV data has a physical recovery switch, get_recovery_mode_from_vbnv() was never implemented. This patch adds get_recovery_mode_from_vbnv() similarly to how it's implemented for other vbnv storage in other places. BUG=chrome-os-partner:34436 BRANCH=none TEST=needs testing Change-Id: Ifd795c5c1ff0f23619fd2125b4795571af03ece1 Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: 09f1bf96089bf9d159e4220c1f4d99388d709545 Original-Signed-off-by: David Hendricks <dhendrix@chromium.org> Original-Change-Id: I9cf18c988eaa4b7e720d6c66a02b1c5c63b473e9 Original-Reviewed-on: https://chromium-review.googlesource.com/239978 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/9563 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-13chromeos: Reverse FMAP signature constant to avoid having it in .rodataJulius Werner
Even though coreboot always hardcodes the FMAP offset, the same is not possible for all other tools that manipulate ROM images. Some need to manually find the FMAP by searching for it's magic number (ASCII "__FMAP__"). If we do something like 'memcmp(fmap_buffer, "__FMAP__", ...) in coreboot code, it has the unfortunate side effect that the compiler will output that very same magic number as a constant in the .rodata section to compare against. Other tools may mistake this for the "real" FMAP location and get confused. This patch reverses the constant defined in coreboot and changes the only use of it correspondingly. It is not impossible but extremely unlikely (at the current state of the art) that any compiler would be clever enough to understand this pattern and optimize it back to a straight memcmp() (GCC 4.9 definitely doesn't), so it should solve the problem at least for another few years/decades. BRANCH=veyron BUG=chromium:447051 TEST=Made sure the new binaries actually contain "__PAMF__" in their .rodata. Booted Pinky. Independently corrupted both the first and the last byte of the FMAP signature with a hex editor and confirmed that signature check fails in both cases. Change-Id: I314b5e7e4d78352f409e73a3ed0e71d1b56fe774 Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: 1359d2d4502eb34a043dffab35cf4a5b033ed65a Original-Change-Id: I725652ef2a77f7f99884b46498428c3d68cd0945 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/240723 Original-Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org> Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/9562 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-13vbnv flash: use proper SPI flash offset for NVRAMVadim Bendebury
The current vbnv flash code mistakenly uses the offset into the NVRAM area as the absolute offset into the SPI NOR. This causes overwrites RO section of the flash (when it is not protected) and causes failures to retrieve the NVRAM contents by the user space apps. This patch makes sure that the correct offset is used when accessing NVRAM area in the SPI flash. BRANCH=storm BUG=chrome-os-partner:35316 TEST=run the update code on storm. - no more RO section corruption observed - running 'crossystem recovery_request=1' at Linux prompt causes the next boot happen in recovery mode Change-Id: Iba96cd2e0e5e01c990f8c1de8d2a2233cd9e9bc9 Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: 9fd15ff4b7aa77536723edbb94fa81f0ae767aed Original-Change-Id: I86fe4b9a35f7c16b72abf49cfbfcd42cc87937e3 Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/240143 Original-Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org> Reviewed-on: http://review.coreboot.org/9561 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-13chromeos: Move common VBNV offsets to a headerDavid Hendricks
Some common VBNV variable offsets were defined in multiple vbnv_* source files. This moves them to a header so that we can avoid duplicating them in the future. BUG=none BRANCH=none TEST=compiled for nyan_blaze and rambi Change-Id: Ic292e546b665b40678b4de598783c1f6bfa35426 Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: fd776f303a3d057d4b70997e7bb6bc85767e2278 Original-Signed-off-by: David Hendricks <dhendrix@chromium.org> Original-Change-Id: Ifcc13c90a910b86d4f9bb0027d913572c1d6d00b Original-Reviewed-on: https://chromium-review.googlesource.com/239977 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: http://review.coreboot.org/9560 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-13vboot1: Set BEFORE_OPROM_LOAD flag for VbInit()Duncan Laurie
This sets the new VB_INIT_FLAG_BEFORE_OPROM_LOAD flag for VbInit() to indicate that we are running from early firmware before option rom loading has occurred so it can do the right thing when it checks whether or not to tell the system to reboot after setting the VbNv flag. BUG=chrome-os-partner:32379 BRANCH=samus TEST=pass FAFT tests on samus Change-Id: Id432dc154736baa799d9ddf5a6a25bccc66217ef Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: 8a576b0bf4b912f85a4e82bfe2cf13c838a069cc Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Original-Change-Id: I6968fcb6cda74e88f56bea6ea9bbf77cc795b8d6 Original-Reviewed-on: https://chromium-review.googlesource.com/230887 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9559 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-13urara: add support for DMA coherent memory areaIonela Voinescu
The information about the DMA memory area is further passed through the coreboot table to the payload. BUG=chrome-os-partner:31438 TEST=tested on Pistachio FPGA; DMA memory area was used to test the functionality of the DWC2 USB controller driver; behavior was as expected. BRANCH=none Change-Id: I658e32352bd5fab493ffe15ad9340e19d02fd133 Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: 0debc105b072a37e2a8ae4098a9634d841191d0a Original-Change-Id: Icf69835dc6a385a59d30092be4ac69bc80245336 Original-Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com> Original-Reviewed-on: https://chromium-review.googlesource.com/235910 Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org> Original-Commit-Queue: Vadim Bendebury <vbendeb@chromium.org> Original-Tested-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: http://review.coreboot.org/9593 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-13t132: add RAM repair to cluster 1Yen Lin
RAM repair has to be performed to cluster 1 also. BRANCH=none BUG=none TEST=Test on Rush and make sure RAM repair completes Change-Id: I0daf969a995a2be152270bc06501eaf086a13a97 Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: 6b07894cc737cb192f68e254d522b55d8ca3b2f3 Original-Change-Id: I458e0a66d76318c6a4aa82547c9037c7b969f1e1 Original-Signed-off-by: Yen Lin <yelin@nvidia.com> Original-Reviewed-on: https://chromium-review.googlesource.com/239360 Original-Reviewed-by: Tom Warren <twarren@nvidia.com> Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9592 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-13vboot1: Fix compilation error with CONFIG_ARCH_ROMSTAGE_ARM64 enabledYidi Lin
make: *** No rule to make target `build/lib/memset.rmodules.o', needed by `build/vendorcode/google/chromeos/vboot1/vbootstub.elf'. Stop. Fix the error by refering to ./src/arch/arm64/Makefile.inc: rmodules_arm64-y += ../../lib/memset.c rmodules_arm64-y += ../../lib/memcpy.c BRANCH=none BUG=none TEST=build pass on our own MT8173 board Change-Id: Ic870136db1ec9405e3d30caf6085f056bc46a5c2 Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: d317dbe8732abbf7e785466e7d1e07425aac326f Original-Change-Id: I69a7db83154a23f7878e9c604c9b541fb6fa308d Original-Reviewed-on: https://chromium-review.googlesource.com/237974 Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org> Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org> Original-Commit-Queue: Yidi Lin <yidi.lin@mediatek.com> Original-Tested-by: Yidi Lin <yidi.lin@mediatek.com> Reviewed-on: http://review.coreboot.org/9591 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-13broadwell: Enable double self refresh by defaultDuncan Laurie
Rather than enable this in every mainboard just enable it by default for all broadwell devices and let a specific mainboard disable it if needed. BUG=chrome-os-partner:34420 BRANCH=samus,auron TEST=build and boot on samus Change-Id: I6e47c20abf29abfbd1f4b7905914b4c9fadb0ae7 Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: 25d3a685893e1c85f7b78e302da3187947a1f84f Original-Change-Id: I26d9f2e2a12d3f2f888ecb5af0d949eec5928f57 Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/238400 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9590 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-13pistachio: increase the size of romstage to 36KIonela Voinescu
This is necessary for the subsequent changes that will add to the size of romstage. BUG=chrome-os-partner:31438 TEST=coreboot builds successfully;tested on Pistachio FPGA BRANCH=none Change-Id: I132215bd44708913d878bbd8b6147bef535b52df Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: 00f73f9d80a36fc43735f093365564b9d74ed7f7 Original-Change-Id: Ie858416a1c9ab63cfe85eea40a76a093cbd2c79c Original-Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com> Original-Reviewed-on: https://chromium-review.googlesource.com/233871 Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Original-Commit-Queue: Vadim Bendebury <vbendeb@chromium.org> Original-Tested-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: http://review.coreboot.org/9589 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-13vboot2: use offset to vboot2 work buffer instead of absolute addressDaisuke Nojiri
this change makes vb2_working_data struct point to the vboot work buffer by the offset instead of by the absolute address, which can be different depending on the context (e.g. subprocessor v.s. main cpu). BUG=none BRANCH=tot TEST=booted veyron pinky Change-Id: I2191ca756c4f49441b3a357338f9c84564b58918 Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: 93f8b1da2b2c81aa3a33892987a71e9e1e7a8eff Original-Change-Id: I4e4c12613304586b7395c5173cf08b8093f59521 Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/236583 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/9588 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-12-30 14:43:23 +0000