summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2015-04-15soc/baytrail: Use microcode from the blobs repositoryMarc Jones
Remove the blobs from the coreboot tree and get them from 3rdparty. Change-Id: I0798091530be9654d7e073839b4efeb3f9c0302c Signed-off-by: Marc Jones <marc.jones@se-eng.com> Reviewed-on: http://review.coreboot.org/9694 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
2015-04-15soc/broadwell: Use microcode from the blobs repositoryMarc Jones
Remove the blobs from the coreboot tree and get them from 3rdparty. Change-Id: I4938b5c47e6ae7059eda144b664aeafdd674f0fb Signed-off-by: Marc Jones <marc.jones@se-eng.com> Reviewed-on: http://review.coreboot.org/9693 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
2015-04-15veyron: Add "backlight" GPIO to coreboot tableJulius Werner
This patch adds a new "backlight" output GPIO to the coreboot table in order to avoid redundantly defining that GPIO in the payload. BRANCH=veyron BUG=chrome-os-partner:34713 TEST=Tested together with corresponding depthcharge CL. Change-Id: Ia997beb1a400136ad65d8f0217781c9782f6e8a5 Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: 04ce4c23573cf926aeef3d817d3ab00835f897c7 Original-Change-Id: I69b3c7ac6be4b9723b6a0dfecef5e1c4ea681aff Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/242400 Original-Tested-by: Lin Huang <hl@rock-chips.com> Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9652 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2015-04-15brain: remove sdmmc_power_off() in romstageDavid Hendricks
LDO4 and LDO5 are not turned on with the boot0 and boot1 RK808 strappings that we use on Brain. BUG=none BRANCH=none TEST=built and booted on brain Change-Id: I00393ca54958d9fff926606405edcd84901e4048 Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: c4c1862585fd058a8a9c8237c701b3bbf3b8aa83 Original-Signed-off-by: David Hendricks <dhendrix@chromium.org> Original-Change-Id: I846ef9d67a780cc07414d545524b9ec0b8490cf1 Original-Reviewed-on: https://chromium-review.googlesource.com/241734 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/9648 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2015-04-15veyron_danger: Enable EDP display initDavid Hendricks
Danger has EDP, the original code was copied from Brain which didn't. BUG=none BRANCH=none TEST=built and booted on danger Change-Id: Ib8e48078cc51fe0e1fb7049f70e810b8f0a7690a Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 25fc6b4d82fb4bd80798cc809af4dacc6208109e Original-Change-Id: Ic8b3f685e08bb96125c57d42db6a10e348a1a096 Original-Signed-off-by: David Hendricks <dhendrix@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/245161 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/9679 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2015-04-15Danger: Apply differences between Brain and DangerDavid Hendricks
This applies the differences between Brain and Danger: - Danger has an SDMMC slot - Danger has a USB hub (TODO) - Danger has LVDS (TODO) - Add workaround for incorrect RAM_ID strapping BUG=none BRANCH=none TEST=emerge-veyron_danger coreboot works Change-Id: Idec527744de2583613b290e3e88850b33ff1c23d Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: 89278c2eeae4bae989a3549da627c5bbd5dd0d5a Original-Signed-off-by: David Hendricks <dhendrix@chromium.org> Original-Change-Id: Iae3f85d4f41e04465a5046f2334c693337d006a4 Original-Reviewed-on: https://chromium-review.googlesource.com/241712 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/9647 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2015-04-15Danger: Initial mainboard importDavid Hendricks
This adds a directory with files copied over from Brain along with build-related changes so that emerge-veyron_danger works. The next patch will account for other differences. BUG=none BRANCH=none TEST=emerge-veyron_danger coreboot works Change-Id: I7ebd431cd48e257dfa761d32013d0e251b4f155d Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: a0f7d2f96540df6fdcd7a99d9e0fa02bbc6c1f73 Original-Signed-off-by: David Hendricks <dhendrix@chromium.org> Original-Change-Id: Id265a7715f07a647a449f00097bf40f7c9b4c068 Original-Reviewed-on: https://chromium-review.googlesource.com/241711 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/9646 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2015-04-15rk3288: send correct EDID buffer sizehuang lin
decode_edid() parses the whole EDID buffer, regardless of whether there is an extension buffer, so we pass the size of the EDID actually read to prevent EDID parser getting the wrong data. BUG=chrome-os-partner:35053 TEST=Boot from jerry BRANCH=veyron Change-Id: I5951b670f129cf4765a5199cb58ac6abff5478a6 Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: 4d508647efc0a9d48b2a4b23c12a54b63af2813e Original-Change-Id: I8cd8e09025520322461fe940b01e4af3995b5ecd Original-Signed-off-by: huang lin <hl@rock-chips.com> Original-Reviewed-on: https://chromium-review.googlesource.com/240643 Original-Reviewed-by: Daniel Kurtz <djkurtz@chromium.org> Reviewed-on: http://review.coreboot.org/9645 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2015-04-15rk808: Implement RTC driverDavid Hendricks
This adds RTC functions to the existing RK808 driver. BUG=chrome-os-partner:34436 BRANCH=none TEST=with eventlog patches applied to pinky, booted and saw eventlog entries generated with correct timestamps: localhost ~ # mosys -k eventlog list entry="0" timestamp="2015-01-06 13:45:33" type="Log area cleared" bytes="4096" entry="1" timestamp="2015-01-06 13:45:33" type="System boot" count="0" entry="2" timestamp="2015-01-06 13:45:33" type="Chrome OS Developer Mode" Change-Id: I1df70a2ca94ff463ffea8d9f02d951d6c62e6b08 Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: a304f7e6954f585f04feef54c4902dcb25a39fcc Original-Signed-off-by: David Hendricks <dhendrix@chromium.org> Original-Change-Id: I3a240e342a54b2e7023da71708d0d70f5131f0b9 Original-Reviewed-on: https://chromium-review.googlesource.com/238525 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Original-Commit-Queue: Julius Werner <jwerner@chromium.org> Original-Tested-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/9643 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2015-04-15veyron_*: Move PMIC_BUS to a Kconfig variableDavid Hendricks
This moves PMIC_BUS from each mainboard's board.h file to a per- mainboard Kconfig variable. To prevent humans from forgetting to set a valid value, an invalid default is set in the rk3288 Kconfig and checked in rk808.c so that compilation will fail if the mainboard Kconfig does not override it. Originally, PMIC_BUS was only used by mainboard code as an argument to RK808 PMIC functions. To conform to the generic RTC API, however, the RK808 code needs to have the bus number globally defined somewhere since the rtc_get() and rtc_set() functions don't take any args. Since CONFIG_PMIC_BUS is globally visible, we no longer need to pass bus number to the PMIC functions. BUG=chrome-os-partner:34436 BRANCH=none TEST=built and booted on Pinky Signed-off-by: David Hendricks <dhendrix@chromium.org> Change-Id: I73783878e507b2e7b1526dd2f81cfbdf8f1e2a55 Reviewed-on: https://chromium-review.googlesource.com/240203 Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/9642 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2015-04-15rk3288: Implement support for CRYPTO module and use it in vboot hashingJulius Werner
This patch implements support for the CRYPTO module in RK3288 and ties it into the new vboot vb2ex_hwcrypto API. We only implement SHA256 for now, since the engine doesn't support SHA512 and it's very unlikely that we'll ever use SHA1 for anything again. BRANCH=None BUG=chrome-os-partner:32987 TEST=Booted Pinky, confirmed that it uses the hardware crypto engine and that firmware body hashing time dropped to about 1.5ms (from over 70ms). Change-Id: I91d0860b42b93d690d2fa083324d343efe7da5f1 Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: e60d42cbffd0748e13bfe1a281877460ecde936b Original-Change-Id: I92510082b311a48a56224a4fc44b1bbce39b17ac Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/236436 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Original-Reviewed-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: http://review.coreboot.org/9641 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2015-04-15veyron: add H9CCNNN8GTMLAR sdram in speedyJiazi Yang
BRANCH=None TEST=emerge-veyron_speedy coreboot BUG=None Change-Id: Iab377e93472db0b7778df020afa84ee97f0e4079 Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: fedf6ed7dc220d58ad10d49ac9ea02443746e77e Original-Change-Id: Id5024bfd32a0aa1fb00f3af8dc337ccccaf40729 Original-Signed-off-by: Jiazi Yang <Tomato_Yang@asus.com> Original-Reviewed-on: https://chromium-review.googlesource.com/237544 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Original-Trybot-Ready: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/9640 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2015-04-15veyron: Support Speedy v1 hardwarehuang lin
BUG=None TEST=emerge veyron_speedy and boot the Speedy board BRANCH=None Change-Id: Ida5fd6d839a2e704760a90e9c723c1b688ea6a84 Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: 42c0d11c3ec65874986c06ca4d7b34f5987f9409 Original-Change-Id: I2f0cff74517a8c031eabb64f4f82d455195c8dd1 Original-Signed-off-by: huang lin <hl@rock-chips.com> Original-Reviewed-on: https://chromium-review.googlesource.com/234715 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/9639 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2015-04-15Brain: Apply differences between Jerry and BrainDavid Hendricks
This applies the differences between Jerry and Brain: - No EC - No SD card - Minor changes to GPIOs (no lid, power button active low) - No variations between board IDs (yet) - No backlight/display attached, but we do have some HDMI and VOP configuration (need to double check that it's right). BUG=none BRANCH=none TEST=built and booted on Brain (requires follow-up CL to get into depthcharge) Change-Id: Idbbc19856e05a145637c28d87c3e19855d13f03b Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: 67151129c28ca7dd83464e5a5c183d006299293c Original-Signed-off-by: David Hendricks <dhendrix@chromium.org> Original-Change-Id: I3c761d3d4d186a6208a772c05193bdcbd4a5c105 Original-Reviewed-on: https://chromium-review.googlesource.com/235921 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/9638 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2015-04-15Brain: Initial mainboard importDavid Hendricks
This adds a directory with files copied over from Jerry, in addition to build system related changes (configs/* and Kconfig stuff) necessary to emerge-veyron_brain coreboot. The next patch will account for differences between Jerry and Brain. BUG=none BRANCH=none TEST=emerge-veyron_brain coreboot works Change-Id: Ib0da9caf80f46991b96bcb5756f807237f0902e1 Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: 9509d6277dae25a78062c1301054a39f704b33fe Original-Signed-off-by: David Hendricks <dhendrix@chromium.org> Original-Change-Id: I972f2623d9b0a43e3ea5312b3c4cd34ab44edc36 Original-Reviewed-on: https://chromium-review.googlesource.com/236989 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/9637 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2015-04-15blaze: add new Micron 2GB BCTNeil Chen
This BCT table is the same as "ramcode == 1", and has been pass the stress test with this new Micron type. -Micron MT41K256M16LY-107:N, ramcode = 4 BUG=chrome-os-partner:32071 TEST=emerged coreboot, booted successfully into kernel. Change-Id: I80990fec6faf5dd2b8090658d865cc8dde31b753 Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: bce2bf1fd518077e06d70d78a65d58ddef7b7bc6 Original-Change-Id: I2c0b28fdafb5299784519e641aa4edb53d0c36b2 Original-Signed-off-by: Neil Chen <neilc@nvidia.com> Original-Reviewed-on: https://chromium-review.googlesource.com/236514 Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/9636 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2015-04-15veyron: Fix TPM I2C initialization and sync boardsJulius Werner
Due to a missing i2c_init(), we were actually running our TPM with default divisors at 660KHz. Oops. While it's commendable that both the TPM and our controller seem to have been running fine all this time at more than 1.5 times the maximum frequency they support, we should probably still get that fixed. Also sync Speedy back up to the other Veyron boards since it seems to have missed a recent SDMMC patch. BRANCH=None BUG=None TEST=Booted Pinky. Change-Id: I255c66624b21bf48b12f950208ba2c401a75c4e4 Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: f2bd7c8579cd90d2f800c777c1981557d81a9b49 Original-Change-Id: I43e6b5fe02aca605a5b243c5b876bd44b90b2bf9 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/236580 Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/9634 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2015-04-15veyron_*: Use common CBFS wrapperDavid Hendricks
This switches all the rk3288 platforms to use the common CBFS wrapper instead of implementing its own CBFS media driver. It also happens that veyron_* platforms use Gigadevice SPI flash (at least for now). As we use more SPI-related stuff, for example eventlog and vboot data in Brain's case, we will need to use more of the SPI API anyway. This prevents us from having to duplicate pieces of it for rk3288. BUG=none BRANCH=none TEST=built and booted on Pinky Change-Id: Ie462456814646fdc277485d9e2d8c901fd4936e7 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 2d6df2fe6d78bc8eee8689019b9aaf29c82b6b30 Original-Signed-off-by: David Hendricks <dhendrix@chromium.org> Original-Change-Id: Id307bd5fb6cc8f79411d8c66e1370e80c58d017b Original-Reviewed-on: https://chromium-review.googlesource.com/235882 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/9678 Tested-by: build bot (Jenkins) Reviewed-by: David Hendricks <dhendrix@chromium.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2015-04-15veyron: Support Mighty v1 hardwarehuang lin
BUG=None TEST=emerge veyron_mighty and boot the Mighty board BRANCH=None Change-Id: I0047569c9eed7a3881500ba3b05e6726ba8d7b8f Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: 49366e5bb3ecdec38c898c936392e5d77a91cd53 Original-Change-Id: I3fcdc837e8d7e62c145850f549662d8260aa1120 Original-Signed-off-by: huang lin <hl@rock-chips.com> Original-Reviewed-on: https://chromium-review.googlesource.com/234714 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/9633 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2015-04-15veyron: Support Jerry v3 hardwarehuang lin
BUG=None TEST=emerge veyron_jerry and boot the Jerry board BRANCH=None Change-Id: I38cb0106694ada431e6ab6194fce7ba1822bcbcf Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: 6a061072860f74874f0098062806c01bdcb447bd Original-Change-Id: I6eb0900516bcd95159c472749c54d356448d2344 Original-Signed-off-by: huang lin <hl@rock-chips.com> Original-Reviewed-on: https://chromium-review.googlesource.com/234713 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/9632 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2015-04-15veyron: Support Pinky v4 hardwarehuang lin
BUG=None TEST=emerge veyron_pinky and boot the Pinky board BRANCH=None Change-Id: I75bc1b7681c9a3d7dc2868a2b260884538587dbd Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: 66069927618924af02a4e17503fa49ae2c31fdfc Original-Change-Id: I06242ade0cabbba56b16b3832a1b4b09bec6f06b Original-Signed-off-by: huang lin <hl@rock-chips.com> Original-Reviewed-on: https://chromium-review.googlesource.com/234712 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/9631 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2015-04-15veyron: Move backlight gpio control to mainboard.chuang lin
We use the devicetree to pass the backlight control gpio before, but if there have different board version, and it uses different io to control backlight, it will hard to distinguish it. So, we move the backlight control to mainboard, and use board_id to distinguish the backlight control. BUG=None TEST=emerge veyron_pinky and Boot the pinky board BRANCH=None Change-Id: Ifa81eb2455296f4b4285b681208f4393f266fb34 Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: 2ff7f65134dcf97f97757750eab41dcf8c7765d3 Original-Change-Id: I1ec8e04f4982c3a8c7e31d8dc2c75311b7199ffc Original-Signed-off-by: huang lin <hl@rock-chips.com> Original-Reviewed-on: https://chromium-review.googlesource.com/234711 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/9630 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2015-04-15veyron: Trigger hard reset (via GPIO) if last reboot was caused by watchdogJulius Werner
Like Nyan, Veyron boards use a GPIO to reset the system so that we can make the accompanying TPM reset secure and unforgeable. The normal kernel reboot driver knows that, but the SoC-internal watchdog doesn't. This patch implements a check for the global reset status register in the early bootblock and triggers a hard_reset() when it matches "first global watchdog reset" or "second global watchdog reset". Seems that the difference between the two is is a choice controlled by wdt_glb_srst_ctrl (unconfirmed), and we want this code to run in both cases. BRANCH=None BUG=chrome-os-partner:33141 TEST=Run 'mem w 0xff800000 0x9' from the command line, watch how you end up in recovery without this patch but can boot normally with it. Change-Id: Ice79648831e1e97d22325711da9e82bbf6bf3c75 Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: 5d7cb52b2c2dcb2fff0bf83fc168439dade4b1b7 Original-Change-Id: I2581bde84f0445c15896060544e9acb60de91c8c Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/231734 Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/9629 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2015-04-15veyron_speedy: Support Samsung-4GB and Lynix-4GB LPDDRhuang lin
Add the Samsung-4GB and Hynix-4GB LPDDR inc files. Use ram_id 1000 correspond to Samsung-4GB LPDDR and use ram_id 1001 correspond to Hynix-4GB LPDDR. BUG=chrome-os-partner:33269 TEST=Boot veyron_speedy normal BRANCH=None Change-Id: I21983c48e1e99aa70ae9bb3fb6550ae9af472015 Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: d34b19dc9b57b4f31dc1b28581f3f8fc0fcc7e6b Original-Change-Id: I55b6968c642df8c1f579e518232ab5d278e7e12f Original-Signed-off-by: huang lin <hl@rock-chips.com> Original-Reviewed-on: https://chromium-review.googlesource.com/233859 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/9628 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2015-04-15veyron: Add veyron_speedy boardhuang lin
Essentially a copy of veyron_jerry for now BUG=chrome-os-partner:33269 TEST=emerge-veyron_speedy coreboot BRANCH=None Change-Id: If8f32122e301df1766bca68b11efd8afe8be5e87 Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: f49a151e1dd956ed2cf3ba0b1f9307442b61e639 Original-Change-Id: Ife457db4fd67fe69bcd4082694b3372eccfb304b Original-Signed-off-by: huang lin <hl@rock-chips.com> Original-Reviewed-on: https://chromium-review.googlesource.com/233822 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/9627 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2015-04-15veyron: Turn off SD card power in romstageJulius Werner
The only way to reliably reset an SD card in an unknown state is by power-cycling. Since a kernel may crash and reboot at any point, SD cards may be left in one of them fancy high-throughput modes that depthcharge (or, in fact, a newly booting kernel without prior knowledge) doesn't support, so we need to reset the card on every boot. This patch adds support to turn off an RK808 regulator completely and uses that to turn off SD card power rails in early romstage. The time until configure_sdmmc() in ramstage turns them back on should be more than enough to drain the power rail for an effective power-cycle. BRANCH=None BUG=chrome-os-partner:34289 TEST=Booted a Pinky from SD card, noticed that it works before and after this patch. Change-Id: Iaa5f7adaa59da69a964785c5e369ad73c6620224 Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: 95fba21907f1f3f686cb5a95b993736247db8f96 Original-Change-Id: I904b2d23ca35f765c000f9bee7637044f674eff9 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/233713 Original-Reviewed-by: Alexandru Stan <amstan@chromium.org> Original-Tested-by: Alexandru Stan <amstan@chromium.org> Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/9626 Tested-by: build bot (Jenkins) Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2015-04-15rk3288: implement spi_crop_chunk()Patrick Georgi
This function was added in upstream but was missing in Chromium OS Change-Id: I35debf65153e5f280343eebfe91438ecf665ba22 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/9677 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2015-04-15Kconfig: Fix incorrect CONFIG_STACK_SIZE values for X86 and ARM64Julius Werner
Commit 54229a7 (arm: Fix checkstack() to use correct stack size) didn't quite hit the mark. Due to the crazy way our Kconfig includes work, It accidentally set CONFIG_STACK_SIZE to 0 even on architectures that need it. This patch fixes the issue by moving everything back to a single entry in src/Kconfig, making sure we end up with the intended numbers on all architectures. BRANCH=None BUG=chrome-os-partner:34750 TEST=Built for Pinky, Urara, Falco and Ryu. Confirmed that the generated .config contained CONFIG_STACK_SIZE=0x0 for the former two, and CONFIG_STACK_SIZE=0x1000 for the latter. Original-Change-Id: Ib18561925aafe7c74e6c4f0b10b55000a785e144 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/236753 Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> (cherry picked from commit c64b127e163f98162f3f7195b6ed09bd5a4b77c4) Signed-off-by: Aaron Durbin <adurbin@chromium.org> Change-Id: I2c747b04760bc97f43523596640bfb15317e5730 Reviewed-on: http://review.coreboot.org/9696 Reviewed-by: David Hendricks <dhendrix@chromium.org> Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com> Tested-by: build bot (Jenkins)
2015-04-14Add console wrapper for UART driverVadim Bendebury
Coreboot is designed to have a single serial console at most, on top of that it may have a CBMEM (virtual) console. Matters are complicated by the fact that console interface is different between bootblock and later stages. A linker list of console driver descriptors is used to allow to determine the set and type of console drivers at compile time. Even though the upstream seems to have done away with this approach, which does not seem the best idea. As an alternative this patch introduces a common wrapper which different UART drivers can plug in into. The driver exports a single API which can be used both directly (in bootblock) and through the wrapper (in later stages). The existing drivers can be adjusted to fit this scheme one by one. The common UART driver API also aligns fine with the upstream approach. BUG=chrome-os-partner:27784 TEST=none yet Original-Change-Id: Id1fe73d29f2a3c722bd77180beebaedb9bf7d6a1 Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/196660 Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org> (cherry picked from commit 94a36ad79a96f83d283c0fd073b05f98ae48820c) Signed-off-by: Marc Jones <marc.jones@se-eng.com> Change-Id: Id1fe73d29f2a3c722bd77180beebaedb9bf7d6a1 Reviewed-on: http://review.coreboot.org/7872 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-14libpayload: avoid hanging on make junit.xmlPatrick Georgi
make oldconfig doesn't like 'y' as response to a choice item such as the architecture list. An empty response, however, is acceptable, so use that. Change-Id: Ic3164dd3f40e4a7f5d91e3a7008893655cd69ac2 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/9676 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-14storm: do not enable the ethernet switch by defaultVadim Bendebury
The ethernet switch, as soon as it is taken out of reset comes up in default (bridging) mode, which allows traffic to flow freely across the ports. Let's keep it in reset such that there is no cross port traffic happening while the device boots up. BRANCH=storm BUG=chrome-os-partner:32646 TEST=verified that the switch is held in reset during boot. Change-Id: Ia1dbb47d892d564145da17425a596bf9bad40d29 Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: 50551d8c9a44d1b63e0948070f6573adf7729d37 Original-Change-Id: I6bf698beddc98ce18fee6b3b39622e356c8cfbad Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/224989 Original-Reviewed-by: Toshi Kikuchi <toshik@chromium.org> Reviewed-on: http://review.coreboot.org/9465 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-14samus: Declare TPM in devicetree.cb and include ACPI deviceDuncan Laurie
This adds the TPM device to the devicetree and configures an active high edge triggered interrupt at IRQ10 and adds the ACPI Device for the TPM into the DSDT. It also cleans up the EC PNP ID to use the EISAID for an EC since there are now two PNP devices declared, and removes the unused ENABLE_TPM define at the top of the DSDT. BUG=chrome-os-partner:33385 BRANCH=samus TEST=build and boot on samus, ensure TPM is functional at IRQ10 CQ-DEPEND=CL:226661 Change-Id: I4b9b016014d136fbf9a37003003632821ae93a53 Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: 0420e27b05d0f1568efa9beb849e0e8ff5995c86 Original-Change-Id: I2660cb30ac535da0b255603a619b9c09681ca947 Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/226663 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9471 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-14broadwell: Remove TPM device from lpc.aslDuncan Laurie
This is not a standard feature so it should be included by the mainboard if it is actually present in a system. BUG=chrome-os-partner:33385 BRANCH=samus,auron TEST=build and boot on samus CQ-DEPEND=CL:226663, CL:226664 Change-Id: Id4d0e5ed243dcb95e64fb8c848667f651b75aa4e Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: 8909913f5c11c5805c77a3373859634b02a301e2 Original-Change-Id: Ib7c171a5a007a2dddfb3d80341c6dc488e383e99 Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/226662 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9470 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-14wtm2/samus: fix coreboot compilation error with tpmp removedHarry Pan
Since CL:226662, all TPMP accessing should be removed as well, else it will cause wtm2 coreboot failed on build. BUG=none BRANCH=none TEST=./setup_board --board=fox_wtm2 && emerge-fox_wtm2 coreboot CQ-DEPEND=CL:226662 Change-Id: Ib25f2d32997ef82b0ebf049803f2c5002a0a3abf Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: c99456bf42544518e2a36b6e0bbfe7f4ee1b4aff Original-Change-Id: Ia0eebb1924bbb23979c880f7d05600a0cf1e4ca3 Original-Signed-off-by: Harry Pan <harry.pan@intel.com> Original-Reviewed-on: https://chromium-review.googlesource.com/232165 Original-Reviewed-by: Wei Shun Chang <wei.shun.chang@intel.com> Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/9477 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-14urara: increase drive strength for SPIM1 MFIOsIonela Voinescu
This change is made only to make sure there is a good signal strength on the SPIM lines. BUG=chrome-os-partner:31438 TEST=tested on Pistachio bring up board; works properly BRANCH=none Change-Id: I5b9427b14a407746fb5b707fa3b07a1a6774bfb1 Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: e9d953283a5b43bf967128ca73db0e90c2df32df Original-Change-Id: Ia589134cf0557613697d49fb0bdb1848af66f0e8 Original-Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com> Original-Reviewed-on: https://chromium-review.googlesource.com/249732 Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/9675 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-14urara: setup I2C0 clock and MFIOsIonela Voinescu
BUG=chrome-os-partner:31438 TEST=tested on Pistachio bring up board; works properly BRANCH=none Change-Id: Ic805311d3aaf40da601c88cd05a73254088374bd Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: ad9427c069ed34ab91e93df59ec3361499b54982 Original-Change-Id: If8e142273afd2d591a975f4e7e34aa73e8d71b0c Original-Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com> Original-Reviewed-on: https://chromium-review.googlesource.com/250451 Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/9674 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-14pistachio: implement clock setup for I2C0Ionela Voinescu
BUG=chrome-os-partner:31438 TEST=tested on Pistachio bring up board; I2C0 clock is set up properly. BRANCH=none Change-Id: I15ffc5f7d8e8aadfc3cd249284bc492d0d13d9a1 Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: 6404ab6ad12ea1579eaf5ae55a9eddd9bd9f96e2 Original-Change-Id: Iafdf492291b47f0088f3b5e621d630b8d21ab106 Original-Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com> Original-Reviewed-on: https://chromium-review.googlesource.com/250450 Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/9673 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-14pistachio: modify timer to account for CPU counter overflowIonela Voinescu
Extended the 32bit CPU counter to 64bit by adding a static variable that takes into account CPU counter overflow. The varibale is updated everythime the timer_raw_value function is called so I assume that the function is called often enought to not miss an overflow of the CPU counter. BUG=chrome-os-partner:31438 TEST=tested on Pistachio bring up board; works as expected BRANCH=none Change-Id: I98bcc56e600dcff0c6da7c140dd34faec5e00885 Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: 972b105f950d800fa44f27bce090f6b89a5a84b9 Original-Change-Id: Id67b14e9d9c2354bc417b6587b615d466690c9b7 Original-Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com> Original-Reviewed-on: https://chromium-review.googlesource.com/247642 Original-Reviewed-by: Daniel Ehrenberg <dehrenberg@chromium.org> Reviewed-on: http://review.coreboot.org/9672 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-14urara: Reduce MIPS PLL jitterIonela Voinescu
The current MIPS PLL is configured in such a way that there is excessive jitter. Correct this by applying new PLL settings. The resultant frequency is 546MHz instead of 550MHz. BUG=chrome-os-partner:31438 TEST=tested on Pistachio bring up board as part of the JTAG loading script; BRANCH=none Change-Id: Ica1bfff29e01819b86cd2bb8b18d8adc9dfa3260 Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: 0c04354b49b73d234492521d81b6600d487175b0 Original-Change-Id: I28b41b1e82dbdf9da21bf0ab74f9722cdad923f1 Original-Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com> Original-Reviewed-on: https://chromium-review.googlesource.com/245620 Original-Reviewed-by: James Hartley <james.hartley@imgtec.com> Original-Reviewed-by: Andrew Bresticker <abrestic@chromium.org> Reviewed-on: http://review.coreboot.org/9671 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-14pistachio: Fix ROM clock base addressIonela Voinescu
The base address used was TOP CLOCK control address instead of the PERIPH CLOCK CONTROL. That was incorrect and is fixed with the current patch. BUG=chrome-os-partner:31438 TEST=tested on Pistachio bring up board; now the hash accelerator, fed by this clock, is correctly clocked at 200MHz. BRANCH=none Change-Id: I0ead3951dc1dfc872881b8d1ae9b63f8104af50d Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: 871cb50ca43a6c760f346eb447e8ff102d8ca0b6 Original-Change-Id: I198d64f97a85a6fcf00c3853bf23d2d767e0e631 Original-Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com> Original-Reviewed-on: https://chromium-review.googlesource.com/245313 Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/9670 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-14urara: add clock setup for MIPS CPU, ROM and EthernetIonela Voinescu
BUG=chrome-os-partner:31438 TEST=tested on Pistachio bring up board; works properly BRANCH=none Change-Id: Ie386d6af9eeba7a72b1b88d515e6cb1821569c6b Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: d4b8d8b6f965296f9ecf62da8e5f383c3667b077 Original-Change-Id: I9eb464340b0475ae735ba5573ab0841dac0d74eb Original-Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com> Original-Reviewed-on: https://chromium-review.googlesource.com/243215 Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/9669 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-14urara: remove call to printk before UART is initializedIonela Voinescu
BUG=chrome-os-partner:31438 TEST=tested in Pistachio bring up board; previous delay at the beginning of bootblock is fixed. BRANCH=none Change-Id: I30335677c96bfd651bc49e36b562c48588009d67 Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: 3d1eb117644af1323dd940e0a82a2ef44025d5b9 Original-Change-Id: I122df1f985163836bb2ddd027ef6ab2ce265d5dd Original-Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com> Original-Reviewed-on: https://chromium-review.googlesource.com/243223 Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/9668 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-14pistachio: fix clocks setup codeIonela Voinescu
Some of the asserts were not done properly: the value has to be shifted before is matched with the mask. Added condition to exit while loop for USB clock setup. BUG=chrome-os-partner:31438 TEST=tested on Pistachio bring up board; after this patch is applied none of the asserts fail and the code is executed properly. BRANCH=none Change-Id: Ib3aae9f7751a9f077bc95b6e0f9d63e3e16d8e4b Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: 96999a4322ba98e87bc6746ad05b30cc56704e2e Original-Change-Id: I8d2d468d618ca1ffcb1421409122482444e6d420 Original-Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com> Original-Reviewed-on: https://chromium-review.googlesource.com/243214 Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/9667 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-14pistachio: Use 1.8433179 MHz for UART refclkDavid Hendricks
BUG=chrome-os-partner:31438 BRANCH=none TEST=built and booted on urara w/ follow-up patches Change-Id: I3b03ce937e68539343e58b01e3bb714dd1f8c2dd Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: 9493c57a14c8ab074baac1c065c6f39050dd9b2f Original-Signed-off-by: David Hendricks <dhendrix@chromium.org> Original-Change-Id: I8e50c99913ea155ba0d5699f4789c1fe38b46808 Original-Reviewed-on: https://chromium-review.googlesource.com/243210 Original-Reviewed-by: Ionela Voinescu <ionela.voinescu@imgtec.com> Reviewed-on: http://review.coreboot.org/9666 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-14pistachio: increase size of bootblock to 18 KBIonela Voinescu
With the added code for clock and MFIOs setup, bootblock now exceeds 16KB. This patch increases the allowed limit to 18KB. BUG=chrome-os-partner:31438 TEST=tested on Pistachio bring up board; works as expected BRANCH=none Change-Id: I166f882bd3db446bcd6f9e1f828cab22266c6ac7 Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: da95db5ed348419b7905dc1ab68fd64d7b2eb5e0 Original-Change-Id: I0cacc6163f21ae3673c2716b12dde66bd48290f9 Original-Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com> Original-Reviewed-on: https://chromium-review.googlesource.com/243213 Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/9665 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-14pistachio: change memory layout as to allow bigger CBFS cacheIonela Voinescu
As the payload increases in size, a bigger CBFS cache is required. Therfore, bootblock, romstage and the cbfs cache were placed in GRAM (128 K) and the stack and cbmem console were moved to SRAM (64 K). With the exception of CBFS cache, the sizes of all the other regions remains the same. BUG=chrome-os-partner:31438 TEST=tested on Pistachio FPGA and bring up board; behavior was as expected. BRANCH=none Change-Id: I19857f785ca1514f7483d582c7ad6ee470a8fefc Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: c895660dbdcd113bdc9d832beab30886313c28d6 Original-Change-Id: I004f8f081d04f83e3f5cee969e50803685cfdf67 Original-Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com> Original-Reviewed-on: https://chromium-review.googlesource.com/236551 Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Original-Commit-Queue: David Hendricks <dhendrix@chromium.org> Original-Tested-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/9664 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-14pistachio: spi: use same clock edge for RX and TXIonela Voinescu
When using this mode data is received and transmitted on the same edge of the SPFI clock, which allows for higher frequencies of operation. In this mode the maximum supported frequency is 50Mhz. If this mode is not enabled the maximum supported frequency is 25Mhz. BUG=chrome-os-partner:31438 TEST=tested on Pistachio bring up board; the SPFI hardware block is fed by the system clock (with a fixed freqency of 400 MHz). To achieve the SPFI frequency of 50MHz the internal divider of SPFI must be set to 64. To achieve a frequency of 25 Mhz the internal divider must be set to 32. A value of 64 = division by 8 A value of 32 = division by 16 BRANCH=none Change-Id: Ifd5f739b6157b99e4c1f92b5bb72615ee610ae6c Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: 8b6cce616ec7926682d4eff096563acf1dfd6c65 Original-Change-Id: I337b6fcf462bcf6021ca77a8b1133cf49140ba76 Original-Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com> Original-Reviewed-on: https://chromium-review.googlesource.com/241425 Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/9663 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-14urara: Configure clocks and MFIOsIonela Voinescu
Set elements: - UART1 clock dividers and MFIOs - SPIM1 clock dividers and MFIOs - USB clock dividers - System clock divider - System PLL - MIPS CPU PLL BUG=chrome-os-partner:31438 TEST=tested on Pisachio bring up board; UART, SPI NOR, SPI NAND, and USB have proper functionality. BRANCH=none Change-Id: Ib01186a652fd59295a4cafc3ca99b94aa9564f74 Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: 65e68d82f34bb40ef3cfb397ecf5df0c83201151 Original-Change-Id: Ia2c31bbbfc020dc4fd71c72b877414adfdfc42a8 Original-Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com> Original-Reviewed-on: https://chromium-review.googlesource.com/241423 Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/9662 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-14arm64: Increase dma region size to 32MiBFurquan Shaikh
BUG=None BRANCH=None TEST=Download and write to kernel partition successful on ryu Change-Id: I9623a0a430e95633dabbb87537a5c70bc9619dde Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: 3ba52d7c7baa42de3149cc604423a5825988401e Original-Change-Id: Ia6ba5ad52596c32cc3ad42f98c7f4f8b3e13d6c5 Original-Signed-off-by: Furquan Shaikh <furquan@google.com> Original-Reviewed-on: https://chromium-review.googlesource.com/242205 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Original-Tested-by: Furquan Shaikh <furquan@chromium.org> Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org> Original-Trybot-Ready: Furquan Shaikh <furquan@chromium.org> Reviewed-on: http://review.coreboot.org/9661 Tested-by: build bot (Jenkins) Reviewed-by: Furquan Shaikh <furquan@google.com>
2015-04-14tegra132: lock down VPRAaron Durbin
The GPU MMU won't function properly until it sees the VPR is locked down. Therefore, do the appropriate work. BUG=None BRANCH=None TEST=Built. Change-Id: I6011c75c1e6c231f2fa416e0057cb5805a88a2bb Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: ca9cc9917b98a148442468d1d1541a0408ab6c2c Original-Change-Id: I3601f419b561cee392391577ef8db66b9fbd8c1b Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/242910 Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org> Original-Reviewed-by: Tom Warren <twarren@nvidia.com> Reviewed-on: http://review.coreboot.org/9660 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-14libpayload dwc2: use bus addresses for buffersIonela Voinescu
The address of the output buffer sent to the device should be the bus address and not the virtual address. BUG=chrome-os-partner:31438 TEST=tested on Pistachio FPGA and bring up board; USB works properly after this change BRANCH=none Change-Id: I5c9d199e17c3f4303095ad73f4980d32d04c6118 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 942c385c112c2a4e409da806548081d3e2f8f438 Original-Change-Id: I0c06196501a968a72cb3f2c7dd1027bb22cdaada Original-Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com> Original-Reviewed-on: https://chromium-review.googlesource.com/245387 Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/9455 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-14libpayload dwc2: Use a new FIFO allocation methodhuang lin
Total FIFO length is split into 512 byte blocks. Allocate these blocks to GRXFSIZ and GNPTXFSZ evenly. This method avoids hardcoding and makes the FIFO size value work for dwc2 controllers that have a different FIFO ram size. BUG=chrome-os-partner:32634 BRANCH=None TEST=Boot kernel from USB Change-Id: I78ce0fa4c4600fb56c991874a93bdd6674e648c2 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 5645a25e95f84359cd10fc9fcf56e1f73fd6ce87 Original-Change-Id: Ib50a08c193f7f65392810ca3528a97554f2c3999 Original-Signed-off-by: huang lin <hl@rock-chips.com> Original-Reviewed-on: https://chromium-review.googlesource.com/233119 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/9454 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-14libpayload: Add dwc2 usb driverhuang lin
BUG=chrome-os-partner:29778 TEST=emerge-veyron libpayload Change-Id: I33f312a939e600b8f4e50a092bb61c5d6bc6d741 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 39ffe53336a2a3b2baa067cdd3dccca5ae93f68e Original-Change-Id: Idad1ad165fd44df635a0cb13bfec6fada1378bc8 Original-Signed-off-by: huang lin <hl@rock-chips.com> Original-Reviewed-on: https://chromium-review.googlesource.com/211053 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/9453 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-14rush: Enable dp displayJimmy Zhang
Add dp/sor supporting functions to enable dp panel. BUG=chrome-os-partner:34336 BRANCH=none TEST=build rush and ryu Change-Id: I1cc5a95ef5e3ea7cc701c1cb124a7eb5a5dbd872 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 795a7cddd36bd783cfdd6f1d3f7092bf48ebd8e7 Original-Change-Id: I336336dbbc5a772eec19ba96db8e7b50f6ea1497 Original-Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com> Original-Reviewed-on: https://chromium-review.googlesource.com/238945 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9616 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-14ryu: display: Add function to pass mode info to payloadJimmy Zhang
This change is intended for code sharing. BUG=chrome-os-partner:34336 BRANCH=none TEST=build ryu and rush Change-Id: Ib83106f1c2d83c1d98b38567626f3169f2aec626 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 9f7414132aaaa6a98663852219e17acbe919d704 Original-Change-Id: Idedb0c16e33a630c954c04767592c3a75c49944b Original-Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com> Original-Reviewed-on: https://chromium-review.googlesource.com/238944 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9615 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-14ryu: display: Set display shift clock dividerJimmy Zhang
Add and call display shift clock divider function to set shift clock divider. This change is also intended for code sharing on dc settings. BUG=chrome-os-partner:34336 BRANCH=none TEST=build ryu and rush Change-Id: I9ad1b32de50395720355bb2d00f5800c7f6c4b73 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 24a72fa3411652d54ae1f7d69db0a7293aad7877 Original-Change-Id: I01582c6863d31627ac93db9fddda93f4f78249cd Original-Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com> Original-Reviewed-on: https://chromium-review.googlesource.com/238943 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9614 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-14rush: Configure display related clock, pad, and powerJimmy Zhang
BUG=chrome-os-partner:34336 BRANCH=none TEST=build rush Change-Id: I9c2235ccc5571f1919dc013c62488390fe31dcbc Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 7468c14842c680be81620ad3fd2ea9ae056d525f Original-Change-Id: Iaf7f70727fc914b9bb2d063c9a30ece4451d40da Original-Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com> Original-Reviewed-on: https://chromium-review.googlesource.com/238942 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9613 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-14rush: devicetree: Define default dp panel parametersJimmy Zhang
DP panel parameters generally can be retrieved thru edid. The parameters specified here will be used when edid fetching failed. BUG=chrome-os-partner:34336 BRANCH=none TEST=build rush and ryu Change-Id: I39e25c873561f75394408f6635aaa2e88b67d846 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: c02facb9753de08f66f3ae40d7dca1eba50febc5 Original-Change-Id: I4785eca3ec03b48e8780ebf02389e9b46317e96d Original-Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com> Original-Reviewed-on: https://chromium-review.googlesource.com/238941 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9612 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-14rush: Add dp related parametersJimmy Zhang
Add these parameters so that they can be specified in devicetree. BUG=chrome-os-partner:34336 BRANCH=none TEST=build ryu and rush Change-Id: I77ee16263e1ce6a8c32b3cd203c1b8a499514a8e Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: c3b254936e696f81ca7eeeb7f6968a5350352b59 Original-Change-Id: Iba47afe95c3889047a82582730be7a253fae76e7 Original-Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com> Original-Reviewed-on: https://chromium-review.googlesource.com/238940 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9611 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-14arm: Fix checkstack() to use correct stack sizeJulius Werner
checkstack() runs at the end of ramstage to warn about stack overflows, and it assumes that CONFIG_STACK_SIZE is always the size of the stack to check. This is only true for systems that bring up multiprocessing in ramstage and assign a separate stack for each core, like x86 and ARM64. Other architectures like ARM and MIPS (for now) don't touch secondary CPUs at all and currently don't look like they'll ever need to, so they generally stay on the same (SRAM-based) stack they have been on since their bootblock. This patch tries to model that difference by making these architectures explicitly set CONFIG_STACK_SIZE to zero, and using that as a cue to assume the whole (_estack - _stack) area in checkstack() instead. Also adds a BUG() to the stack overflow check, since that is currently just as non-fatal as the BIOS_ERR message (despite the incorrect "SYSTEM HALTED" output) but a little more easy to spot. Such a serious failure should not drown out in all the normal random pieces of lower case boot spam (also, I was intending to eventually have a look at assert() and BUG() to hopefully make them a little more useful/noticeable if I ever find the time for it). BRANCH=None BUG=None TEST=Booted Pinky, noticed it no longer complains about stack overflows. Built Falco, Ryu and Urara. Change-Id: I6826e0ec24201d4d83c5929b281828917bc9abf4 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 54229a725e8907b84a105c04ecea33b8f9b91dd4 Original-Change-Id: I49f70bb7ad192bd1c48e077802085dc5ecbfd58b Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/235894 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9610 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-14rk3288: Fix memlayout to allow a little more bootblock spaceJulius Werner
Freeing up memory on rk3288 is like squeezing water out of a stone right now, but I still managed to get a few drops here and there. Let's hope this will be enough. BRANCH=None BUG=None TEST=Pinky builds and boots again. memsz is ~15K in bootblock and ~39K in verstage. Change-Id: Icf7ff3369bf367426a34f1490e0a041ae9bd6367 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 9a3737ab535cdef228a1607433860f881db04412 Original-Change-Id: I90d9eab5b5d3af7a2e4b836a9c7b735b7c1c48e6 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/235870 Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/9609 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-14timestamps: You can never have enough of them!Julius Werner
Now that we have timestamps in pre-RAM stages, let's actually make use of them. This patch adds several timestamps to both the bootblock and especially the verstage to allow more fine-grained boot time tracking. Some of the introduced timestamps can appear more than once per boot. This doesn't seem to be a problem for both coreboot and the cbmem utility, and the context makes it clear which operation was timestamped at what point. Also simplifies cbmem's timestamp printing routine a bit, fixing a display bug when a timestamp had a section of exactly ",000," in it (e.g. 1,000,185). BRANCH=None BUG=None TEST=Booted Pinky, Blaze and Falco, confirmed that all timestamps show up and contained sane values. Booted Storm (no timestamps here since it doesn't support pre-RAM timestamps yet). Change-Id: I7f4d6aba3ebe3db0d003c7bcb2954431b74961b3 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 7a2ce81722aba85beefcc6c81f9908422b8da8fa Original-Change-Id: I5979bfa9445a9e0aba98ffdf8006c21096743456 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/234063 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9608 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-14rk3288: Add CBMEM console support and fix RETURN_FROM_VERSTAGEJulius Werner
Since we can now reduce our vboot2 work buffer by 4K, we can use all that hard-earned space for the CBMEM console instead (and 4K are unfortunately barely enough for all the stuff we dump with vboot2). Also add console_init() and exception_init() to the verstage for CONFIG_RETURN_FROM_VERSTAGE, which was overlooked before (our model requires those functions to be called again at the beginning of every stage... even though some consoles like UARTs might not need it, others like the CBMEM console do). In the !RETURN_FROM_VERSTAGE case, this is expected to be done by the platform-specific verstage entry wrapper, and already in place for the only implementation we have for now (tegra124). (Technically, there is still a bug in the case where EARLY_CONSOLE is set but BOOTBLOCK_CONSOLE isn't, since both verstage and romstage would run init_console_ptr() as if they were there first, so the romstage overwrites the verstage's output. I don't think it's worth fixing that now, since EARLY_CONSOLE && !BOOTBLOCK_CONSOLE is a pretty pointless use-case and I think we should probably just get rid of the CONFIG_BOOTBLOCK_CONSOLE option eventually.) BRANCH=None BUG=None TEST=Booted Pinky. Change-Id: I87914df3c72f0262eb89f337454009377a985497 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 85486928abf364c5d5d1cf69f7668005ddac023c Original-Change-Id: Id666cb7a194d32cfe688861ab17c5e908bc7760d Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/232614 Reviewed-on: http://review.coreboot.org/9607 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-14timer: Reestablish init_timer(), consolidate timer initialization callsJulius Werner
We have known for a while that the old x86 model of calling init_timer() in ramstage doesn't make sense on other archs (and is questionable in general), and finally removed it with CL:219719. However, now timer initialization is completely buried in the platform code, and it's hard to ensure it is done in time to set up timestamps. For three out of four non-x86 SoC vendors we have brought up for now, the timers need some kind of SoC-specific initialization. This patch reintroduces init_timer() as a weak function that can be overridden by platform code. The call in ramstage is restricted to x86 (and should probably eventually be removed from there as well), and other archs should call them at the earliest reasonable point in their bootblock. (Only changing arm for now since arm64 and mips bootblocks are still in very early state and should sync up to features in arm once their requirements are better understood.) This allows us to move timestamp_init() into arch code, so that we can rely on timestamps being available at a well-defined point and initialize our base value as early as possible. (Platforms who know that their timers start at zero can still safely call timestamp_init(0) again from platform code.) BRANCH=None BUG=None TEST=Booted Pinky, Blaze and Storm, compiled Daisy and Pit. Change-Id: I1b064ba3831c0c5b7965b1d88a6f4a590789c891 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: ffaebcd3785c4ce998ac1536e9fdd46ce3f52bfa Original-Change-Id: Iece1614b7442d4fa9ca981010e1c8497bdea308d Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/234062 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9606 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
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>