summaryrefslogtreecommitdiff
path: root/src/mainboard/google/veyron
AgeCommit message (Collapse)Author
2019-03-08coreboot: Replace all IS_ENABLED(CONFIG_XXX) with CONFIG(XXX)Julius Werner
This patch is a raw application of find src/ -type f | xargs sed -i -e 's/IS_ENABLED\s*(CONFIG_/CONFIG(/g' Change-Id: I6262d6d5c23cabe23c242b4f38d446b74fe16b88 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/31774 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2019-03-05mainboard: Enable PRESERVE flag in all vboot/chromeos FMD filesHung-Te Lin
For Chrome OS (or vboot), The PRESERVE flags should be applied on following sections: RO_PRESERVE, RO_VPD, RW_PRESERVE, RW_ELOG, RW_NVRAM, RW_SMMSTORE, RW_VPD, RO_FSG (b:116326638), SI_GBE (chromium:936768), SI_PDR (chromium:936768) With the new PRESERVE flag, we don't need RO_PRESERVE and RW_PRESERVE in the future. But it's still no harm to use it if there are multiple sections all needing to be preserved. BUG=chromium:936768 TEST=Builds google/eve and google/kukui inside Chrome OS source tree. Also boots successfully on eve and kukui devices. Change-Id: I6664ae3d955001ed14374e2788d400ba5fb9b7f8 Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/31709 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2019-03-04device/mmio.h: Add include file for MMIO opsKyösti Mälkki
MMIO operations are arch-agnostic so the include path should not be arch/. Change-Id: I0fd70f5aeca02e98e96b980c3aca0819f5c44b98 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/31691 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-03-04arch/io.h: Drop unnecessary includeKyösti Mälkki
Change-Id: I91158452680586ac676ea11c8589062880a31f91 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/31692 Reviewed-by: Patrick Georgi <pgeorgi@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-02-22symbols.h: Add macro to define memlayout region symbolsJulius Werner
When <symbols.h> was first introduced, it only declared a handful of regions and we didn't expect that too many architectures and platforms would need to add their own later. However, our amount of platforms has greatly expanded since, and with them the need for more special memory regions. The amount of code duplication is starting to get unsightly, and platforms keep defining their own <soc/symbols.h> files that need this as well. This patch adds another macro to cut down the definition boilerplate. Unfortunately, macros cannot define other macros when they're called, so referring to region sizes as _name_size doesn't work anymore. This patch replaces the scheme with REGION_SIZE(name). Not touching the regions in the x86-specific <arch/symbols.h> yet since they don't follow the standard _region/_eregion naming scheme. They can be converted later if desired. Change-Id: I44727d77d1de75882c72a94f29bd7e2c27741dd8 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/c/31539 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2019-01-09Veyron: fix sdram config for Hynix H9CCNNNBKTMLBR-NTDLoop_Wu
Sdram config sdram-lpddr3-hynix-4GB.inc for H9CCNNNBKTMLBR-NTD can't boot on Mickey. It's confirmed that the right config for Hynix H9CCNNNBKTMLBR-NTD is sdram-lpddr3-hynix-2GB-BK.inc. BUG=b:122239609 BRANCH=master TEST=boot on mickey Change-Id: Ifeaadda50d939e0c118cb7fe3964dcd08b709c2a Signed-off-by: Loop_Wu <Loop_Wu@asus.com> Reviewed-on: https://review.coreboot.org/c/30761 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Julius Werner <jwerner@chromium.org>
2018-12-28arch/x86: Drop spurious arch/stages.h includesKyösti Mälkki
Change-Id: I3b9217a7d9a6d98a9c5e8b69fe64c260b537bb64 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/30388 Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2018-11-28mb/*/*/Kconfig: Remove useless commentElyes HAOUAS
Change-Id: Ibdff50761a205d936b0ebe067f418be0a2051798 Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/29871 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Hellsenberg <th3fanbus@gmail.com> Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: David Guckian Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
2018-11-21(console,drivers/uart)/Kconfig: Fix dependenciesNico Huber
The dependencies of CONSOLE_SERIAL and DRIVERS_UART were somehow backwards. Fix that. Now, CONSOLE_SERIAL depends on DRIVERS_UART, because it's using its interface. The individual UART drivers select DRIVERS_UART, because they implement the interface and depend on the common UART code. Some guards had to be fixed (using CONSOLE_SERIAL now instead of DRIVERS_UART). Some other guards that were only about compilation of units were removed. We want to build test as much as possible, right? Change-Id: I0ea73a8909f07202b23c88db93df74cf9dc8abf9 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/c/29572 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2018-11-16src: Remove unneeded include <cbfs.h>Elyes HAOUAS
Change-Id: Iab0bd1c5482331a0c048a05ab806bf5c4dbda780 Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/29303 Reviewed-by: Patrick Georgi <pgeorgi@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2018-11-05mainboard: Remove unneeded include <console/console.h>Elyes HAOUAS
Change-Id: Ib3aafcc586b1631a75f214cfd19706108ad8ca93 Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/29285 Reviewed-by: Patrick Rudolph <siro@das-labor.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2018-10-31Veyron: add Hynix H9CCNNNBKTMLBR-NTD ddr with RAMID '00Z1'Loop_Wu
Confirm with RK, H9CCNNNBKTMLBR-NTD uses this sdram config. sdram-lpddr3-hynix-4GB.inc BUG=b:117967129 BRANCH=master TEST=None Change-Id: I98afc33fd2cb61343be0dcdc007add75bee9c2af Signed-off-by: Loop_Wu <Loop_Wu@asus.com> Reviewed-on: https://review.coreboot.org/29366 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2018-10-22reset: Convert individual boards to `board_reset()`Nico Huber
Change-Id: I6182da172ae2f4107a9b5d8190e4b3b10ed2f0b9 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/29048 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2018-06-04security/tpm: Unify the coreboot TPM software stackPhilipp Deppenwiese
* Remove 2nd software stack in pc80 drivers directory. * Create TSPI interface for common usage. * Refactor TSS / TIS code base. * Add vendor tss (Cr50) directory. * Change kconfig options for TPM to TPM1. * Add user / board configuration with: * MAINBOARD_HAS_*_TPM # * BUS driver * MAINBOARD_HAS_TPM1 or MAINBOARD_HAS_TPM2 * Add kconfig TPM user selection (e.g. pluggable TPMs) * Fix existing headers and function calls. * Fix vboot for interface usage and antirollback mode. Change-Id: I7ec277e82a3c20c62a0548a1a2b013e6ce8f5b3f Signed-off-by: Philipp Deppenwiese <zaolin@das-labor.org> Reviewed-on: https://review.coreboot.org/24903 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2018-05-08mb/google: Get rid of device_tElyes HAOUAS
Use of device_t has been abandoned in ramstage. Change-Id: I8e549e4222ae2ed6b9c46f81c5b5253e8b227ee8 Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/26086 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2018-05-04mainboard/google: Comment variant names in KconfigMartin Roth
It's very confusing trying to find the google platform names, because they seem all unsorted in Kconfig. They're actually sorted according to the variant name, but previously, that was impossible to tell. - Add a comment to the top of variants in Kconfig.name - Inset each variant name. If you start a prompt with whitespace, it gets ignored, so after trying various ways to indent, the arrow was the option I thought looked the best. It now looks like this: *** Beltino *** -> Mccloud (Acer Chromebox CXI) -> Monroe (LG Chromebase 22CV241 & 22CB25S) -> Panther (ASUS Chromebox CN60) -> Tricky (Dell Chromebox 3010) -> Zako (HP Chromebox G1) Butterfly (HP Pavilion Chromebook 14) Chell (HP Chromebook 13 G1) Cheza *** Cyan *** Change-Id: I35cb16b040651cd1bd0c4aef98494368ef5ca512 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/26020 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2017-12-07boardid: Switch from Kconfig to weak functionsJulius Werner
This patch switches the board_id and ram_code helper framework to use weak functions rather than Kconfigs to determine whether the board supplies these IDs. This cuts down on the amount of boilerplate Kconfigs many boards have to set and also gives them more flexibility, such as being able to determine at runtime whether a given ID is present. Change-Id: I97d6d1103ebb2a2a7cf1ecfc45709c7e8c1a5cb0 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/22695 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2017-12-07boardid: Minor clean up and standardizationJulius Werner
Merge the different coreboot table strapping ID structures into one because they're really just all the same, and I want to add more. Make the signature of the board_id() function return a uint32_t because that's also what goes in the coreboot table. Add a printk to the generic code handling strapping IDs in ramstage so that not every individual mainboard implementation needs its own print. (In turn, remove one such print from fsp1_1 code because it's in the way of my next patch.) Change-Id: Ib9563edf07b623a586a4dc168fe357564c5e68b5 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/22741 Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2017-11-22chromeec: Change the API for hostevent/wake masks to handle 64-bitFurquan Shaikh
ChromeEC is getting ready to bump up the hostevents and wake masks to 64-bits. The current commands to program hostevents/wake masks will still operate on 32-bits only. A new EC host command will be added to handle 64-bit hostevents/wake masks. In order to prevent individual callers in coreboot from worrying about 32-bit/64-bit, the same API provided by google/chromeec will be updated to accept 64-bit parameters and return 64-bit values. Internally, host command handlers will take care of masking these parameters/return values to appropriate 32-bit/64-bit values. BUG=b:69329196 Change-Id: If59f3f2b1a2aa5ce95883df3e72efc4a32de1190 Signed-off-by: Furquan Shaikh <furquan@chromium.org> Reviewed-on: https://review.coreboot.org/22551 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2017-11-17mb/google: Add Chromebook marketing namesJonathan Neuschäfer
It's sometimes hard to find the code name of a Chromebook. Add the marketing names to Kconfig, since they are easily available. Information (mostly) taken from: https://www.chromium.org/chromium-os/developer-information-for-chrome-os-devices Unknown boards (unreleased, etc.): * Fizz * Foster * Nasher, Coral * Purin * Rotor * Rowan * Scarlet, Nefario * Soraka * Urara * Veyron_Rialto Baseboards: * Glados * Gru * Jecht * Kahlee * Nyan * Oak * Poppy * Rambi * Zoombini White label boards: * Enguarde * Heli * Relm, Wizpig TODO: How does this interact with the board_status code? Change-Id: I20a36e23bd3eea8c526a0b3b53cd676cebf9cd86 Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net> Reviewed-on: https://review.coreboot.org/22404 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2017-08-18include/device: Split i2c.h into threeNico Huber
Split `i2c.h` into three pieces to ease reuse of the generic defi- nitions. No code is changed. * `i2c.h` - keeps the generic definitions * `i2c_simple.h` - holds the current, limited to one controller driver per board, devicetree independent I2C interface * `i2c_bus.h` - will become the devicetree compatible interface for native I2C (e.g. non-SMBus) controllers Change-Id: I382d45c70f9314588663e1284f264f877469c74d Signed-off-by: Nico Huber <nico.huber@secunet.com> Reviewed-on: https://review.coreboot.org/20845 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2017-06-13Consolidate reset API, add generic reset_prepare mechanismJulius Werner
There are many good reasons why we may want to run some sort of generic callback before we're executing a reset. Unfortunateley, that is really hard right now: code that wants to reset simply calls the hard_reset() function (or one of its ill-differentiated cousins) which is directly implemented by a myriad of different mainboards, northbridges, SoCs, etc. More recent x86 SoCs have tried to solve the problem in their own little corner of soc/intel/common, but it's really something that would benefit all of coreboot. This patch expands the concept onto all boards: hard_reset() and friends get implemented in a generic location where they can run hooks before calling the platform-specific implementation that is now called do_hard_reset(). The existing Intel reset_prepare() gets generalized as soc_reset_prepare() (and other hooks for arch, mainboard, etc. can now easily be added later if necessary). We will also use this central point to ensure all platforms flush their cache before reset, which is generally useful for all cases where we're trying to persist information in RAM across reboots (like the new persistent CBMEM console does). Also remove cpu_reset() completely since it's not used anywhere and doesn't seem very useful compared to the others. Change-Id: I41b89ce4a923102f0748922496e1dd9bce8a610f Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/19789 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Furquan Shaikh <furquan@google.com>
2017-06-02Kconfig: Introduce HAVE_(VBE_)LINEAR_FRAMEBUFFERNico Huber
Like HAVE_VGA_TEXT_FRAMEBUFFER, these are selected by graphics drivers that support a linear framebuffer. Some related settings moved to the drivers (i.e. for rockchip/rk3288 and nvidia/tegra124) since they are hardcoded. Change-Id: Iff6dac5a5f61af49456bc6312e7a376def02ab00 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/19800 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2017-03-28vboot: Move remaining features out of vendorcode/google/chromeosJulius Werner
This patch attempts to finish the separation between CONFIG_VBOOT and CONFIG_CHROMEOS by moving the remaining options and code (including image generation code for things like FWID and GBB flags, which are intrinsic to vboot itself) from src/vendorcode/google/chromeos to src/vboot. Also taking this opportunity to namespace all VBOOT Kconfig options, and clean up menuconfig visibility for them (i.e. some options were visible even though they were tied to the hardware while others were invisible even though it might make sense to change them). CQ-DEPEND=CL:459088 Change-Id: I3e2e31150ebf5a96b6fe507ebeb53a41ecf88122 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/18984 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2017-03-28vboot: Assume EC_SOFTWARE_SYNC and VIRTUAL_DEV_SWITCH by defaultJulius Werner
The virtualized developer switch was invented five years ago and has been used on every vboot system ever since. We shouldn't need to specify it again and again for every new board. This patch flips the Kconfig logic around and replaces CONFIG_VIRTUAL_DEV_SWITCH with CONFIG_PHYSICAL_DEV_SWITCH, so that only a few ancient boards need to set it and it fits better with CONFIG_PHYSICAL_REC_SWITCH. (Also set the latter for Lumpy which seems to have been omitted incorrectly, and hide it from menuconfig since it's a hardware parameter that shouldn't be configurable.) Since almost all our developer switches are virtual, it doesn't make sense for every board to pass a non-existent or non-functional developer mode switch in the coreboot tables, so let's get rid of that. It's also dangerously confusing for many boards to define a get_developer_mode() function that reads an actual pin (often from a debug header) which will not be honored by coreboot because CONFIG_PHYSICAL_DEV_SWITCH isn't set. Therefore, this patch removes all those non-functional instances of that function. In the future, either the board has a physical dev switch and must define it, or it doesn't and must not. In a similar sense (and since I'm touching so many board configs anyway), it's annoying that we have to keep selecting EC_SOFTWARE_SYNC. Instead, it should just be assumed by default whenever a Chrome EC is present in the system. This way, it can also still be overridden by menuconfig. CQ-DEPEND=CL:459701 Change-Id: If9cbaa7df530580a97f00ef238e3d9a8a86a4a7f Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/18980 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2017-03-17google/veyron: Clean out unused board variantsJulius Werner
We have code for certain Veyron variant names that were either never made into an actual board (Gus, Nicky, Thea) or used for Google-internal test boards that no longer exist (Pinky, Shark). Let's clean them out to avoid confusing people. Change-Id: Icdce5f0f3613e089d0994318b02dba54170f0c42 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/18860 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2017-03-17google/veyron: Work around RAM code strapping errorJulius Werner
With a recent patch (google/veyron_*: Add new Micron and Hynix modules) we switched RAM codes for Veyron boards to tri-state since we were running out of binary numbers. Unfortunately we only tested that change on Minnie and Speedy, and it turns out that it broke Jaq, Jerry and Mighty. The "high" RAM code pins on those boards were incorrectly strapped with 100Kohm resistors (as opposed to 1Kohm on Minnie and Speedy), which is too high to overpower the SoC-internal pull-down we use to differentiate "high" from "tri-state". Since we already used tri-state codes on some Minnie and Speedy SKUs we have to hack up the code to work differently on these two groups of boards to keep everything working. BRANCH=veyron BUG=b:36279493 TEST=Compiled, confirmed ram_code called the right function depending on board. Change-Id: I253b213ef7ca621ce47a7a55a5119a167d944078 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/18859 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2017-03-07google/veyron: add K4B4G1646E-BYK0 ddr with ramid 000ZShunqian Zheng
The K4B4G1646E-BYK0 shares sdram config with K4B4G1646D-BYK0. For clarity, sdram-ddr3-samsung-2GB now is used by - K4B4G1646D-BYK0 - K4B4G1646E-BYK0 - K4B4G1646Q-HYK0 BUG=chrome-os-partner:62131 BRANCH=veyron TEST=emerge Change-Id: Ie43f23bf8f5f5b1acbb74c85cac17fe181c841c4 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 46d62d87101e0ee1050b00db02b3ecaa4587e9f4 Original-Change-Id: I461c6f36c28ea0eeaf7d64292c9c87ab0c9de443 Original-Signed-off-by: Shunqian Zheng <zhengsq@rock-chips.com> Original-Reviewed-on: https://chromium-review.googlesource.com/446197 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Original-(cherry picked from commit f98251a4a4fe4d49721a936a684f6ac80f3f6405) Original-Reviewed-on: https://chromium-review.googlesource.com/446300 Reviewed-on: https://review.coreboot.org/18519 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Martin Roth <martinroth@google.com>
2017-03-07google/veyron_*: Add new Micron and Hynix modulesDavid Hendricks
This adds SDRAM entries for the following modules: - Micron: DDMT52L256M64D2PP-107 - Hynix: H9CCNNNBKTALBR-NUD They are compatible with Samsung K4E8E324EB-EGCF, so this just copies sdram-lpddr3-samsung-2GB-24EB.inc and changes the name used in the comment near the top. Notes on our "special snowflake" boards: - veyron_danger's RAM ID is hard-coded to zero, so I skipped changes involving the binary first numbering scheme. - Rialto's SDRAM mapping is different, so I padded its SDRAM entries to 24 to match other boards. - veyron_mickey requires different MR3 and ODT settings than other boards due to its unique PCB (chrome-os-partner:43626). BUG=chrome-os-partner:59997 BRANCH=none TEST=Booted new modules on Mickey (see BUG) Change-Id: If2e22c83f4a08743f12bbc49b3fabcbf1d7d07dd Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 35cac483e86e57899dbb0898dad3510f4c2ab2d3 Original-Change-Id: I22386a25b965a4b96194d053b97e3269dbdea8c7 Original-Signed-off-by: David Hendricks <dhendrix@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/412328 Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Queue: Jiazi Yang <Tomato_Yang@asus.com> Original-Tested-by: Jiazi Yang <Tomato_Yang@asus.com> Original-(cherry picked from commit bd5aa1a5488b99f2edc3e79951064a1f824062f6) Original-Reviewed-on: https://chromium-review.googlesource.com/446299 Original-Commit-Ready: Shunqian Zheng <zhengsq@rock-chips.com> Original-Tested-by: Shunqian Zheng <zhengsq@rock-chips.com> Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/18518 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Martin Roth <martinroth@google.com>
2017-01-31google/veyron*: mark GPIO array non-staticPatrick Georgi
That status isn't needed and making it non-static helps gcc 4.9.2 (or any compiler that insists on "standard C" behaviour with global const initializers) Change-Id: Ib1fbd5213d262e653f31564b106095b4a28292f6 Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: https://review.coreboot.org/18266 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-12-13vendorcode/google/chromeos: Fill in firmware ID regionsPatrick Georgi
Chrome OS images have three firmware ID regions, to store version information for the read-only and the two read-write areas. Fill them with a suitable default and allow configuring a different scheme. There's already an override in google/foster and google/rotor to match the naming scheme used so far (in depthcharge). BUG=chromium:595715 BRANCH=none TEST=/build/$board/firmware/coreboot.rom has the expected values in the regions. Change-Id: I5fade5971135fa0347d6e13ec72909db83818959 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: d2e3be81faa8d21f92325294530714a4b18a1b3e Original-Change-Id: I2fa2d51eacd832db6864fb67b6481b4d27889f52 Original-Signed-off-by: Patrick Georgi <pgeorgi@google.com> Original-Reviewed-on: https://chromium-review.googlesource.com/417320 Original-Commit-Ready: Patrick Georgi <pgeorgi@chromium.org> Original-Tested-by: Patrick Georgi <pgeorgi@chromium.org> Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org> Reviewed-on: https://review.coreboot.org/17788 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2016-11-03google/veyron*: change .ddrconfig from 14 to 3ZhengShunQian
There are two configs, sdram-lpddr3-hynix-2GB.inc and sdram-lpddr3-samsung-2GB-24EB.inc that use .ddrconfig = 14. Changing .ddrconfig from 14 to 3 improves performance especially on contiguous memory accesses. Comparing the .ddrconfig: - if .ddrconfig = 3, C RDRR RRRR RRRR RRRR RBBB CCCC CCCC C--- - if .ddrconfig = 14, C DRBB BRRR RRRR RRRR RRRR CCCC CCCC C--- where - R: indicates Row bits - B: indicates Bank bits - C: indicates Column bits - D: indicates Chip selects bits .ddrconfig = 3 has multiple banks switching which improves DDR timing. BUG=chrome-os-partner:57321 TEST=Boot from fievel and play video BRANCH=veyron Change-Id: Ifdcedc28e84429b8b79c7553b38b667631d29c09 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 93882e4f2000d93c9dae5e6d4b2e1f4b7bc9489e Original-Change-Id: Ic98ebae48609a7604ec678b6bd14dd2b29b669c4 Original-Signed-off-by: ZhengShunQian <zhengsq@rock-chips.com> Original-Reviewed-on: https://chromium-review.googlesource.com/404691 Original-Commit-Ready: Shunqian Zheng <zhengsq@rock-chips.com> Original-Tested-by: Shunqian Zheng <zhengsq@rock-chips.com> Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/17210 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Martin Roth <martinroth@google.com>
2016-11-03google/veyron*: add DDR configs for new samsung DDRZhengShunQian
Add the new samsung DDR configs for all veyron except veyron_rialto: * K4E6E304EB-EGCE, ramid = 0010, 4GB * K4E8E324EB-EGCF, ramid = 1100, 2GB BRANCH=veyron BUG=none TEST=boot fievel board Change-Id: I747aa86f8c93174651a28face63b3386e22b23b3 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 5f55462e71bd481eda85af3d582cfe5b9873cc9c Original-Change-Id: I19123634c994f685683323f7d85cc4d35814e2ab Original-Signed-off-by: ZhengShunQian <zhengsq@rock-chips.com> Original-Reviewed-on: https://chromium-review.googlesource.com/345748 Original-Commit-Queue: Ren Kuo <ren.kuo@quantatw.com> Original-Reviewed-by: Philip Chen <philipchen@chromium.org> Original-(cherry-pick from cc990f27024255a326fd9fa9644deb28b01a31a7) Original-Reviewed-on: https://chromium-review.googlesource.com/404690 Original-Commit-Ready: Shunqian Zheng <zhengsq@rock-chips.com> Original-Tested-by: Shunqian Zheng <zhengsq@rock-chips.com> Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/17209 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Martin Roth <martinroth@google.com>
2016-10-02Kconfig: Update default hex values to start with 0xMartin Roth
Kconfig hex values don't need to be in quotes, and should start with '0x'. If the default value isn't set this way, Kconfig will add the 0x to the start, and the entry can be added unnecessarily to the defconfig since it's "different" than what was set by the default. A check for this has been added to the Kconfig lint tool. Change-Id: I86f37340682771700011b6285e4b4af41b7e9968 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/16834 Tested-by: build bot (Jenkins) Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2016-09-20Veyron: Increase bit-per-pixel to 32Daisuke Nojiri
This enhances gradation of some icons on vboot screens. BUG=chrome-os-partner:56056 BRANCH=none TEST=Booted Jerry Change-Id: Ia19d585b69e7701040209e8bf0b8a6990a166c95 Signed-off-by: Martin Roth <martinroth@chromium.org> Original-Commit-Id: 4e7a42c999673ebd89c5b30845a4a5ec93852166 Original-Change-Id: I126cb7077c834e1a8b0a625a592dce8789b5876c Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/376884 Reviewed-on: https://review.coreboot.org/16581 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2016-08-18Kconfig: rename BOOT_MEDIA_SPI_BUS to BOOT_DEVICE_SPI_FLASH_BUSAaron Durbin
Provide a default value of 0 in drivers/spi as there weren't default values aside from specific mainboards and arch/x86. Remove any default 0 values while noting to keep the option's default to 0. BUG=chrome-os-partner:56151 Change-Id: If9ef585e011a46b5cd152a03e41d545b36355a61 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/16192 Tested-by: build bot (Jenkins) Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Martin Roth <martinroth@google.com>
2016-08-01Remove non-ascii & unprintable charactersMartin Roth
These non-ascii & unprintable characters aren't needed. Change-Id: I129f729f66d6a692de729d76971f7deb7a19c254 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/15977 Tested-by: build bot (Jenkins) Reviewed-by: Omar Pakker Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2016-08-01Add newlines at the end of all coreboot filesMartin Roth
Change-Id: I7930d5cded290f2605d0c92a9c465a3f0c1291a2 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/15974 Tested-by: build bot (Jenkins) Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2016-07-28chromeos: Clean up elog handlingFurquan Shaikh
1. Currenty, boot reason is being added to elog only for some ARM32/ARM64 platforms. Change this so that boot reason is logged by default in elog for all devices which have CHROMEOS selected. 2. Add a new option to select ELOG_WATCHDOG_RESET for the devices that want to add details about watchdog reset in elog. This requires a special region WATCHDOG to be present in the memlayout. 3. Remove calls to elog add boot reason and watchdog reset from mainboards. BUG=chrome-os-partner:55639 Change-Id: I91ff5b158cfd2a0749e7fefc498d8659f7e6aa91 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/15897 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins)
2016-07-28vboot: Separate vboot from chromeosFurquan Shaikh
VBOOT_VERIFY_FIRMWARE should be independent of CHROMEOS. This allows use of verified boot library without having to stick to CHROMEOS. BUG=chrome-os-partner:55639 Change-Id: Ia2c328712caedd230ab295b8a613e3c1ed1532d9 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/15867 Tested-by: build bot (Jenkins) Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
2016-06-08veyron: Add exception_init() to romstageJulius Werner
I'm not even sure how this slipped through... looks like it had never been there in the first place. Anyway, on ARM exceptions should always be reinitialized in all stages to make sure the handlers are still around (especially in an OVERLAP_VERSTAGE_ROMSTAGE board like this one). Change-Id: Ic74ea1448d63b363f2ed59d9e2529971b3d32d9a Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/15099 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2016-04-13mainboard/google: Update license headersMartin Roth
Update all of the license headers to make sure they are compliant with coreboot's license header policy. Change-Id: Ied67c5079a7f49594edb39caf61fe7f386c3f80d Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/14323 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2016-04-05chromeos.fmd: Mark RW_LEGACY as CBFSPatrick Georgi
Change the existing chromeos.fmd files and the dts-to-fmd script to mark RW_LEGACY as CBFS, so it's properly "formatted". BUG=chromium:595715 BRANCH=none TEST=none Change-Id: I76de26032ea8da0c7755a76a01e7bea9cfaebe23 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 717a00c459906fa87f61314ea4541c31b50539f4 Original-Change-Id: I4b037b60d10be3da824c6baecabfd244eec2cdac Original-Signed-off-by: Patrick Georgi <pgeorgi@google.com> Original-Reviewed-on: https://chromium-review.googlesource.com/336403 Original-Commit-Ready: Patrick Georgi <pgeorgi@chromium.org> Original-Tested-by: Patrick Georgi <pgeorgi@chromium.org> Original-Reviewed-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/14240 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2016-04-05chromeos: Simplify fill_lb_gpios even furtherJulius Werner
A long time ago many Chrome OS boards had pages full of duplicated boilerplate code for the fill_lb_gpios() function, and we spent a lot of time bikeshedding a proper solution that passes a table of lb_gpio structs which can be concisely written with a static struct initializer in http://crosreview.com/234648. Unfortunately we never really finished that patch and in the mean time a different solution using the fill_lb_gpio() helper got standardized onto most boards. Still, that solution is not quite as clean and concise as the one we had already designed, and it also wasn't applied consistently to all recent boards (causing more boards with bad code to get added afterwards). This patch switches all boards newer than Link to the better solution and also adds some nicer debug output for the GPIOs while I'm there. If more boards need to be converted from fill_lb_gpio() to this model later (e.g. from a branch), it's quite easy to do with: s/fill_lb_gpio(gpio++,\n\?\s*\([^,]*\),\n\?\s*\([^,]*\),\n\?\s*\([^,]*\),\n\?\s*\([^,]*\));/\t{\1, \2, \4, \3},/ Based on a patch by Furquan Shaikh <furquan@google.com>. BUG=None BRANCH=None TEST=Booted on Oak. Ran abuild -x. Change-Id: I449974d1c75c8ed187f5e10935495b2f03725811 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/14226 Tested-by: build bot (Jenkins) Reviewed-by: David Hendricks <dhendrix@chromium.org>
2016-03-25google/intel mainboards: Add missing board_info.txt filesMartin Roth
The lint script didn't catch that these mainboard directories didn't have board_info files. Add all missing board_info.txt files Change-Id: Ib1d61a3c04e91b22480527885faf60c22093d98a Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/14117 Reviewed-by: Furquan Shaikh <furquan@google.com> Tested-by: build bot (Jenkins)
2016-02-12chromebooks: Define GBB hardware IDsPatrick Georgi
This makes the test IDs the default, taken from depthcharge master (board/*/fmap.dts, hwid property). Change-Id: I25793962ac16f451f204dbba6ede6a64c847cfd5 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/13634 Reviewed-by: Martin Roth <martinroth@google.com> Tested-by: build bot (Jenkins)
2016-02-09chromebooks: Configure Chrome EC board namesPatrick Georgi
For devices with Chrome EC, state the "board" name(s), so they're built as part of the image. A number of EC boards aren't supported in the Chrome EC master branch, they're brought along but commented out, waiting for a port to master in the Chrome EC code base. Change-Id: Ic6ab821de55cf9b4e8b48fe5ebc603adeb8bb28b Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/13548 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2016-01-22google/veyron_*: Add dual-rank 2GB Hynix module to SDRAM configsDavid Hendricks
This is a follow-up to CL:320623 to make veyron DRAM configs uniform (except for Rialto). As discussed in chrome-os-partner:43626, the mr[3] value and ODT are set diffently for Mickey, thus the .inc files for other boards have mr[3] = 1 and ODT disabled. BUG=none BRANCH=veyron TEST=compile tested for veyron Change-Id: I61798cfef779b0a3a510fd354ab53ffc63ca6c95 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 3b7cea6331bcec8aba09a204060e093d3dd732cb Original-Signed-off-by: David Hendricks <dhendrix@chromium.org> Original-Change-Id: Iacf821645a2dcceaed1c1c42e3e1b1c312b31eab Original-Reviewed-on: https://chromium-review.googlesource.com/321870 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/13109 Tested-by: build bot (Jenkins) Reviewed-by: David Hendricks <dhendrix@chromium.org>
2016-01-21chromeos: import Chrome OS fmapsPatrick Georgi
These are generated from depthcharge's board/*/fmap.dts using the dts-to-fmd.sh script. One special case is google/veyron's chromeos.fmd, which is used for a larger set of boards - no problem since the converted fmd was the same for all of them. Set aside 128K for the bootblock on non-x86 systems (where the COREBOOT region ends up at the beginning of flash). This becomes necessary because we're working without a real cbfs master header (exists for transition only), which carved out the space for the offset. Change-Id: Ieeb33702d3e58e07e958523533f83da97237ecf1 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/12715 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2015-12-17google/veyron: Add commercial board names in Kconfig.nameDenis 'GNUtoo' Carikli
The correspondence between engineering code names and commercial names can be found on chromium.org website at: https://www.chromium.org/chromium-os/developer-information-for-chrome-os-devices This it to make the names more relevant: towiki (in util/board_status/to-wiki/towiki.sh) will pick such names, which end up in the supported board list at: http://www.coreboot.org/Supported_Motherboards Change-Id: I2d705672d7202964fea3f62a5bd61a231d3f14c0 Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org> Reviewed-on: https://review.coreboot.org/12652 Reviewed-by: Patrick Georgi <pgeorgi@google.com> Tested-by: build bot (Jenkins)
2015-12-17google/veyron: Indicate which boards are laptops.Denis 'GNUtoo' Carikli
This is to make towiki pick that information, to make these boards end up in the laptop list at: http://www.coreboot.org/Supported_Motherboards Change-Id: Ibf8bf4bf6566080a34687e36675d4c4c8b89f334 Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org> Reviewed-on: https://review.coreboot.org/12716 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-10-31tree: drop last paragraph of GPL copyright headerPatrick Georgi
It encourages users from writing to the FSF without giving an address. Linux also prefers to drop that and their checkpatch.pl (that we imported) looks out for that. This is the result of util/scripts/no-fsf-addresses.sh with no further editing. Change-Id: Ie96faea295fe001911d77dbc51e9a6789558fbd6 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/11888 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2015-09-24coreboot: move TS_END_ROMSTAGE to one spotAaron Durbin
While the romstage code flow is not consistent across all mainboards/chipsets there is only one way of running ramstage from romstage -- run_ramstage(). Move the timestamp_add_now(TS_END_ROMSTAGE) to be within run_ramstage(). BUG=chrome-os-partner:44827 BRANCH=None TEST=Built and booted glados. TS_END_ROMSTAGE still present in timestamp table. Change-Id: I4b584e274ce2107e83ca6425491fdc71a138e82c Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/11700 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-09-23google: veyron: CBFS_SIZE to match the available size for Coreboot in ChromeOSPaul Kocialkowski
When building for ChromeOS, it is expected that Coreboot will only occupy the first MiB of the SPI flash, according to the veyron fmap description. Otherwise, it makes sense to use the full ROM size. Change-Id: I168386a5011222866654a496d8d054faff7a9406 Signed-off-by: Paul Kocialkowski <contact@paulk.fr> Reviewed-on: http://review.coreboot.org/11117 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-09-08rk3288: Allow board-specific APLL (CPU clock) settingsDavid Hendricks
This changes the API to rkclk_configure_cpu() such that we can pass in the desired APLL frequency in each veyron board's bootblock.c. Devices with a constrainted form facter (rialto and possibly mickey) will use this to run firmware at a slower speed to mitigate risk of thermal issues (due to the RK808, not the RK3288). BUG=chrome-os-partner:42054 BRANCH=none TEST=amstan says rialto is noticably cooler (and slower) Change-Id: I28b332e1d484bd009599944cd9f5cf633ea468dd Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: d10af5e18b4131a00f202272e405bd22eab4caeb Original-Change-Id: I960cb6ff512c058e72032aa2cbadedde97510631 Original-Signed-off-by: David Hendricks <dhendrix@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/297190 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/11582 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-09-08veyron: Unify identical mainboardsJulius Werner
This patch removes a lot of code duplication between the virtually identical Veyron Chromebook variants by merging the code into a single directory and handling the different names solely within Kconfig. This also allows us to easily add all the other Chromebook variants that have only been kept in Google's firmware branch to avoid cluttering coreboot too much, making it possible to build these boards with upstream coreboot out of the box. The only effective change this will have on the affected boards is removing quirks for early board revisions (since revision numbers differ between variants). Since all those quirks concerned early pre-MP revisions, I doubt this will bother anyone (and the old code is still available through the Google firmware branch if anyone needs it). It will also expand a recent fix in Jerry that increased an LCD power-on delay to make it compatible with another kind of panel to all boards, which is probably not a bad idea anyway. Leaving all non-Chromebook boards as they are for now since they often contain more extensive differences. BRANCH=None BUG=None TEST=Booted Jerry. Change-Id: I4bd590429b9539a91f837459a804888904cd6f2d Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 10049a59a34ef45ca1458c1549f708b5f83e2ef9 Original-Change-Id: I6a8c813e58fe60d83a0b783141ffed520e197b3c Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/296053 Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/11555 Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-03-24veyron: Rename "veyron" board to "veyron_pinky"Julius Werner
We retroactively decided to use the variant name "pinky" for the Rk3288 board we're currently bringing up, and retcon the unadorned "veyron" name to refer to the Rockchip evaluation board. Since we currently have no interest to maintain coreboot support for that board in our tree, let's rename everything to "veyron_pinky" and forget about "veyron". CQ-DEPEND=CL:217592 BUG=chrome-os-partner:30167 TEST='emerge-veyron libpayload coreboot' fails but 'emerge-veyron_pinky libpayload coreboot' succeeds. Change-Id: I88bf5cc2da7c2f969ea184b5f12affaa94045a06 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: aa8ec24b63d11798fec1993091b113a0c0938c7a Original-Change-Id: I366391efc8e0a7c610584b50cea331a0164da6f3 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/217674 Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/8869 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-03-24rk3288: update romstage & mainboardhuang lin
BUG=chrome-os-partner:29778 TEST=Build coreboot Change-Id: I877b4bf741f45f6cfd032ad5018a60e8a1453622 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 640da5ad5597803c62d9374a1a48832003077723 Original-Change-Id: I805d93e94f73418099f47d235ca920a91b4b2bfb Original-Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com> Original-Signed-off-by: huang lin <hl@rock-chips.com> Original-Reviewed-on: https://chromium-review.googlesource.com/209469 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Original-Tested-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/8867 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-03-24rk3288: add ddr driverJinkun Hong
Supports DDR3 and LPDDR3.Supports dual channel.ddr max freq is 533mhz. ddr timing config file in src\mainboard\google\veyron\sdram_inf Remove dpll init in rk clk_init(), add rkclk_configure_ddr(unsigned int hz). BUG=chrome-os-partner:29778 TEST=Build coreboot Change-Id: I429eb0b8c365c6285fb6cfef008b41776cc9c2d9 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 52838c68fe6963285c974af5dc5837e819efc321 Original-Change-Id: I6ddfe30b8585002b45060fe998c9238cbb611c05 Original-Signed-off-by: jinkun.hong <jinkun.hong@rock-chips.com> Original-Reviewed-on: https://chromium-review.googlesource.com/209465 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Original-Commit-Queue: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/8865 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins)
2015-03-24add make_idb.py & update bootblockhuang lin
BUG=chrome-os-partner:29778 TEST=Build coreboot Change-Id: Ica7b2bf2cf649c2731933ce59a263692bb2c0282 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: ba9c36daedc749748f45e68a84f8c34c636adb1c Original-Change-Id: Ia0e4e39d4391674f25e630b40913eb99ff3f75c4 Original-Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com> Original-Signed-off-by: huang lin <hl@rock-chips.com> Original-Reviewed-on: https://chromium-review.googlesource.com/209427 Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Original-Commit-Queue: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/8862 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-03-20romstages: use common run_ramstage()Aaron Durbin
Instead of sprinkling the cbfs calls around (as well as getting return values incorrect) use the common run_ramstage() to perform the necessary work to load and run ramstage. Change-Id: I37b1e94be36ef7a43efe65b2db110742fa105169 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/8710 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-03-16coreboot: rk3288: Add a stub implementation of the rk3288 SOCjinkun.hong
Most things still needs to be filled in, but this will allow us to build boards which use this SOC. BUG=chrome-os-partner:29778 TEST=emerge-veyron coreboot Original-Change-Id: If643d620c5fb8951faaf1ccde400a8e9ed7db3bc Original-Signed-off-by: jinkun.hong <jinkun.hong@rock-chips.com> Original-Reviewed-on: https://chromium-review.googlesource.com/205069 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Original-Commit-Queue: David Hendricks <dhendrix@chromium.org> Original-Tested-by: David Hendricks <dhendrix@chromium.org> (cherry picked from commit 2f72473a8c2b3fe21d77b351338e6209035878fb) Signed-off-by: Marc Jones <marc.jones@se-eng.com> Change-Id: I53fd0ced42f6ef191d7bf80d8b823bb880344239 Reviewed-on: http://review.coreboot.org/8653 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-09 21:48:32 +0000