- 13 Oct, 2017 1 commit
-
-
Bora Guvendik authored
TEST=Boot to OS using Intel NVMe SSD Pro 6 Change-Id: I01da152eae5ef640613c2f94d176d33f24a09530 Signed-off-by:
Bora Guvendik <bora.guvendik@intel.com> Reviewed-on: https://chromium-review.googlesource.com/706106 Reviewed-by:
Aaron Durbin <adurbin@chromium.org>
-
- 26 Sep, 2017 1 commit
-
-
Bora Guvendik authored
Add cnl rvp board and config files BRANCH=None BUG=None TEST=Boot to OS via SATA/eMMC/USB on cnl-u rvp Change-Id: I7c75e47f7d90a22ce34bb1b62d3b54a2eab71ad7 Signed-off-by:
Bora Guvendik <bora.guvendik@intel.com> Reviewed-on: https://chromium-review.googlesource.com/667873 Reviewed-by:
Aaron Durbin <adurbin@chromium.org> Reviewed-by:
Furquan Shaikh <furquan@chromium.org> Reviewed-by:
Nick Vaccaro <nvaccaro@chromium.org>
-
- 03 May, 2016 1 commit
-
-
Julius Werner authored
Depthcharge's current cros_ec code doesn't really match the object-oriented one-instance-per-device design of its other drivers. Instead, it is a singleton design with hardcoded support for only up to one additional chip by passing devidx=1 to certain functions. In addition, the vboot callback implementations for EC software sync are tightly interwoven with the cros_ec driver. This patch changes that code to be more in line with depthcharge's other drivers. EC and PD chips are represented as separate objects (sharing the same bus object), and the connection to vboot callbacks is abstracted in a VbootEcOps superclass. This is intended to make it easier to hook up other embedded controllers that don't run the Chrome EC embedded OS to vboot's software sync mechanism, such as the ANX7688 used on Elm. (This is intended to be the first step. We may or may not decide that it makes sense to also make changes to vboot code and the callback interface later.) Also try to clean up namespacing a bit (cros_ec_... only for exported functions), only export functions that are really needed by other files, and remove some unused code. BUG=chrome-os-partner:52434 TEST=FAFT on Oak. Manually triggered software sync both after cold reboot and when the EC was already in RW. Change-Id: I6666c4382ef40d1211995101c97a52346963fa4a Signed-off-by:
Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/341542 Reviewed-by:
Aaron Durbin <adurbin@chromium.org>
-
- 08 Mar, 2016 1 commit
-
-
Duncan Laurie authored
Enable the config option to indicate that graphics init requires a special reboot. This will make the netboot images reboot with the flag set to init graphics. BUG=chrome-os-partner:50864 BRANCH=glados TEST=boot netboot image on chell and see working display Signed-off-by:
Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/331309 Reviewed-by:
Aaron Durbin <adurbin@chromium.org> (cherry picked from commit eef88e748da2c29e3df42fb56479eee1996b6285) Change-Id: I2f3143fbc4232538635d1a8c662153bb255b32c7 Reviewed-on: https://chromium-review.googlesource.com/331295
-
- 26 Feb, 2016 1 commit
-
-
Aaron Durbin authored
Legacy payloads may rely on the 8254 programmable interrupt timer. Therefore, always re-enable the 8254 timer by masking off the static clock gating enable bit. All existing skylake boards were adjusted to select DRIVERS_SOC_SKYLAKE and the PCR access was moved into drivers/soc/skylake. The soc driver subsystem infrastructure was added to more accurately reflect broader SoC support instead of jamming that information into an unrelated subsystem. BUG=chrome-os-partner:50214 BRANCH=glados TEST=Confirmed 8254 static clock gate bit cleared in legacy path. Change-Id: I161f331121f236cfdea3542f2d0649e2a81beda9 Signed-off-by:
Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/329158 Reviewed-by:
Duncan Laurie <dlaurie@chromium.org>
-
- 18 Dec, 2015 1 commit
-
-
Rohit Ainapure authored
Add support for using GPIO based I2S output to MAX98357A and PDM output to SSM4567 audio amplifiers. GPP_F0, GPP_F1, GPP_F2 are used to drive the I2S signals. GPP_F23 is used to activate the buffer and isolate I2S signals. BUG=chrome-os-partner:47124 BRANCH=None TEST=test audio beep on kunimitsu CQ-DEPEND=CL:317567, CL:317568 Change-Id: Ie0a4935848beb315a91996d289017607e704d727 Signed-off-by:
Rohit Ainapure <rohit.m.ainapure@intel.com> Reviewed-on: https://chromium-review.googlesource.com/317569 Commit-Ready: Rohit M Ainapure <rohit.m.ainapure@intel.com> Tested-by:
Michael Rang <michael.rang@intel.com> Reviewed-by:
Duncan Laurie <dlaurie@chromium.org>
-
- 28 Aug, 2015 1 commit
-
-
Naveen Krishna Chatradhi authored
BRANCH=none BUG=chrome-os-partner:40629 TEST=built for kunimitsu; CQ-DEPEND=CL:295717,CL:*228427 Change-Id: I83d68f1918af02c364d615fd0a263a8baa727055 Signed-off-by:
Naveen Krishna Chatradhi <naveenkrishna.ch@intel.com> Reviewed-on: https://chromium-review.googlesource.com/295744 Commit-Ready: Wenkai Du <wenkai.du@intel.com> Tested-by:
Wenkai Du <wenkai.du@intel.com> Reviewed-by:
Robbie Zhang <robbie.zhang@intel.com> Reviewed-by:
Duncan Laurie <dlaurie@chromium.org>
-
- 27 Aug, 2015 1 commit
-
-
Naveen Krishna Chatradhi authored
This patch install the flag for EC_IN_RW for kunimitsu board. While at it, remove the AHCI initialization for Kunimitsu. BRANCH=none BUG=chrome-os-partner:43707 TEST=built for kunimitsu ran test_that --board=kunimitsu 10.223.211.42 firmware_DevMode Pass Change-Id: I62f940f4a24ec6f158513ec00b303dd02992cb53 Signed-off-by:
Naveen Krishna Chatradhi <naveenkrishna.ch@intel.com> Reviewed-on: https://chromium-review.googlesource.com/294749 Commit-Ready: Wenkai Du <wenkai.du@intel.com> Tested-by:
Wenkai Du <wenkai.du@intel.com> Reviewed-by:
Aaron Durbin <adurbin@chromium.org>
-
- 21 Aug, 2015 1 commit
-
-
Wenkai Du authored
Fixed TPM and incorrectly configured EC driver. BUG=chrome-os-partner:44214 TEST=Verify depthcharge prints EC ID on boot up BRANCH=None Change-Id: I4875abf1489ce7353ad9d72733a42315d49bd67f Signed-off-by:
Wenkai Du <wenkai.du@intel.com> Reviewed-on: https://chromium-review.googlesource.com/294764 Reviewed-by:
Duncan Laurie <dlaurie@chromium.org> Reviewed-by:
Aaron Durbin <adurbin@chromium.org>
-
- 13 Jun, 2015 1 commit
-
-
Neeraj Tayal authored
BRANCH=None BUG=chrome-os-partner:40452 TEST=Built for Kunimitsu & tested EMMC boot. Change-Id: Iad9be05f45387d3d4f59e4bebedcbd9587e34572 Signed-off-by:
Neeraj Tayal <neeraj.tayal@intel.com> Reviewed-on: https://chromium-review.googlesource.com/275081 Reviewed-by:
Aaron Durbin <adurbin@chromium.org>
-
- 27 May, 2015 1 commit
-
-
Neeraj Tayal authored
BRANCH=None BUG=chrome-os-partner:40452 TEST=With other pending SKL RVP patches in series, built & booted on Kunimitsu Fab 2 board Change-Id: Ief734f7d9e58e5c03cfa45864418ec4c4f773f39 Signed-off-by:
Neeraj Tayal <neeraj.tayal@intel.com> Reviewed-on: https://chromium-review.googlesource.com/272777 Reviewed-by:
Aaron Durbin <adurbin@chromium.org>
-
- 11 Feb, 2015 1 commit
-
-
Erik Bjorge authored
Initial files for the glados board. BRANCH=None BUG=None TEST=Build depthcharge for glados Change-Id: I59e7edf34db4a40401b7ceaf91405f1278f27e03 Signed-off-by:
Erik Bjorge <erik.c.bjorge@intel.com> Reviewed-on: https://chromium-review.googlesource.com/248302 Reviewed-by:
Shawn N <shawnn@chromium.org>
-
- 16 Dec, 2014 1 commit
-
-
Julius Werner authored
Having a CONFIG_RO_NORMAL_SUPPORT option is pointless: depthcharge has always supported RO_NORMAL in the legacy (trampoline) vboot case, which is the only one where it actually calls VbInit() and has to indicate this support. Let's remove one more line of pointless boilerplate from our defconfigs. BRANCH=None BUG=None TEST=None Change-Id: Ica02b84199eaf3b73a5d6ea0125c25520184e904 Signed-off-by:
Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/235712 Reviewed-by:
Aaron Durbin <adurbin@chromium.org>
-
- 30 Aug, 2014 1 commit
-
-
Julius Werner authored
Like all drivers, USB dongles currently need to be activated in the defconfig. This repeatedly causes issues because drivers are forgotten when creating or merging a new board. There is no good reason to ever not activate these options: since they are USB devices, any dongle can be connected to a port on any board, so every board with USB support (which is all of them by definition, even in the latest ChromeOS Core design docs) will want to have them. BUG=None TEST=Compiled on Blaze, confirmed that dev images still had ASIX and SMSC driver code in the binary, and normal images still hadn't. Change-Id: Ic98b042e37e5adc1e598328481b671b5861f17ba Signed-off-by:
Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/215498 Reviewed-by:
Aaron Durbin <adurbin@chromium.org>
-
- 26 Aug, 2014 2 commits
-
-
Shawn Nematbakhsh authored
This board enables XHCI mode in coreboot so it should not send the SMI again to try and re-route the ports to XHCI. BUG=chrome-os-partner:31286 TEST=Build+boot Auron. BRANCH=None. Change-Id: I667271b69ee35e6306fedcf1d499268d80a062e7 Signed-off-by:
Shawn Nematbakhsh <shawnn@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/213691 Reviewed-by:
Bernie Thompson <bhthompson@chromium.org> Commit-Queue: Bernie Thompson <bhthompson@chromium.org>
-
Shawn Nematbakhsh authored
Cloned entirely from Peppy, with only string / copyright date changes. BUG=chrome-os-partner:31286 TEST=Compile only. BRANCH=None. Change-Id: I768c780165edaa2ea6e109eed813c1ce51ce4397 Signed-off-by:
Shawn Nematbakhsh <shawnn@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/213700 Reviewed-by:
Bernie Thompson <bhthompson@chromium.org> Commit-Queue: Bernie Thompson <bhthompson@chromium.org>
-
- 09 Aug, 2014 1 commit
-
-
Miriam Gershenson authored
Partially based on U-Boot's SMSC 95xx driver. Enables netboot through servo without a separate Ethernet dongle. BUG=None TEST=Booted into the netboot payload on panther using SMSC 9514 on servo. Change-Id: I715c944a14b570775ace377c83149bc328aae621 Signed-off-by:
Miriam Gershenson <mgersh@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/210062 Reviewed-by:
Julius Werner <jwerner@chromium.org> Reviewed-by:
Vadim Bendebury <vbendeb@chromium.org> Reviewed-by:
Stefan Reinauer <reinauer@google.com>
-
- 12 Nov, 2013 1 commit
-
-
Julius Werner authored
This patch replaces the existing CONFIG_BOARD_<boardname> boolean Kconfigs with a single CONFIG_BOARD="<boardname>". This has the benefit that you can easily use the board name in debug output, and also makes the Makefile a little cleaner. BUG=None TEST=None Change-Id: Ie5815e990e98cacbfb5392bcb6a25f24ccc3c620 Signed-off-by:
Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/176374 Reviewed-by:
Gabe Black <gabeblack@chromium.org>
-
- 04 Oct, 2013 1 commit
-
-
Duncan Laurie authored
BUG=chrome-os-partner:20448 BRANCH=bolt TEST=manual: build and boot on bolt Change-Id: I5670926b94d1c0fbdd0c5a795b5780cb2bb42812 Signed-off-by:
Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/171678 Reviewed-by:
Aaron Durbin <adurbin@chromium.org>
-
- 23 Jul, 2013 2 commits
-
-
Gabe Black authored
Separate the Exynos SPI driver from the flash drivers. The ICH drivers are still flash drivers since they can't really be used for anything else, and there's now a flash driver which calls into an underlying SPI driver for the actual bus transactions. The ICH flash, memory mapped flash, SPI flash, and exynos SPI drivers are now all organized as structures of function pointers who's parameters are set when structure is set up. Also, the interface to SPI drivers is more in line with what's provided by the hardware, so the code in the exynos SPI driver needed to be redistributed. In the process the transfer function can now send, receive, or both, and it decides whether to use 4 byte packets or not based on whether the total size divides evenly by 4. To keep the SPI bus running with 4 byte packets when loading from flash, the SPI flash wrapper rounds the region being requested outward (start down, end up) to ensure that the size is a multiple of 4 and you're getting at least the data you're asking for. Ideally the driver would keep track of what it's already loaded and not load it again, but that's not implemented as of now. BUG=chrome-os-partner:19420 TEST=Built for all platforms except bolt. Booted on snow with the exynos SPI driver, on Link with the memory mapped flash driver and also the ICH SPI flash driver, booted RW on Link, and booted on Lumpy. BRANCH=None Change-Id: Ib0348bd468896a569288d3ca2dfca534569195b9 Signed-off-by:
Gabe Black <gabeblack@google.com> Reviewed-on: https://gerrit.chromium.org/gerrit/62537 Reviewed-by:
David Hendricks <dhendrix@chromium.org> Commit-Queue: Gabe Black <gabeblack@chromium.org> Tested-by:
Gabe Black <gabeblack@chromium.org>
-
Gabe Black authored
The term MKBP actually refers to the keyboard protocol implemented by the ChromeOS EC, but it ended up being used for all ChromeOS EC related bits. BUG=chrome-os-partner:19420 TEST=Built for all supported boards. BRANCH=None Change-Id: Ic275fc3ce990695c6da0a0329911b3f79fcb7cde Signed-off-by:
Gabe Black <gabeblack@google.com> Reviewed-on: https://gerrit.chromium.org/gerrit/62080 Reviewed-by:
Aaron Durbin <adurbin@chromium.org> Tested-by:
Gabe Black <gabeblack@chromium.org> Commit-Queue: Gabe Black <gabeblack@chromium.org>
-
- 09 Jul, 2013 1 commit
-
-
Gabe Black authored
The idea is that the board.c in each of these directories will have an init func in it which will instantiate and interconnect driver instances which fit with that particular board. That will make things more flexible for drivers, and avoid having to have hacks and board specifics wedged into drivers to support specific boards. For instance, on snow, one of the I2C busses is shared with the EC, and is arbitrated using a request/grant pair of GPIOs. Instead of having the driver know about that arbitration mechanism and which bus it goes with and which GPIOs to use, the GPIOs could be instantiated as instances of the exynos GPIO driver, the I2C driver can drive the most busses directly, and a wrapper which handles the arbitration can be implemented which is called into by the device driver on the I2C bus and which, after arbitration, then calls into the generic driver. Another example would be if there are two different types of I2C busses like on both Exynos chips. There actually are two types of busses on both those chips, but we've been able to ignore that by either turning off one type, or only attaching devices to one type. If we can't or don't want to work around the problem any more, we could implement drivers for both types of controller and then pass the right instance to the right driver for the devices on those busses. BUG=None TEST=Built for all supported boards. Booted on Link. BRANCH=None Change-Id: I349ebf4df1fc8d5763aa7d49fd70c85cc333c9f3 Signed-off-by:
Gabe Black <gabeblack@google.com> Reviewed-on: https://gerrit.chromium.org/gerrit/60983 Reviewed-by:
Aaron Durbin <adurbin@chromium.org> Commit-Queue: Gabe Black <gabeblack@chromium.org> Tested-by:
Gabe Black <gabeblack@chromium.org>
-
- 28 Jun, 2013 1 commit
-
-
Duncan Laurie authored
BUG=chrome-os-partner:20448 BRANCH=none TEST=manual: emerge-bolt depthcharge Change-Id: I41992244a2d2c87e4b3d51a8b4cbc1a9836a0fbf Signed-off-by:
Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/59793 Reviewed-by:
Aaron Durbin <adurbin@chromium.org>
-
- 23 May, 2013 1 commit
-
-
Duncan Laurie authored
Add board config and FMAP layout for Falco. BUG=chrome-os-partner:19637 BRANCH=none TEST=manual: emerge-falco depthcharge Change-Id: If941a464a937a2a9c0a381f23e5cf217746700bd Signed-off-by:
Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/56327 Reviewed-by:
Aaron Durbin <adurbin@chromium.org>
-
- 30 Apr, 2013 1 commit
-
-
Duncan Laurie authored
BUG=chrome-os-partner:19035 BRANCH=none TEST=manual: build depthcharge for slippy board Change-Id: Ie0346e4996e152ea862458fd99b4848ccf866688 Signed-off-by:
Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/49535 Reviewed-by:
Aaron Durbin <adurbin@chromium.org>
-
- 14 Mar, 2013 1 commit
-
-
Gabe Black authored
Setting up the crossystem data isn't always necessary, and exactly how it works can vary from system to system. BUG=chrome-os-partner:16688 TEST=Built and booted on Link and ran crossystem to verify that the data looked reasonable. BRANCH=None Change-Id: I3e56573f901c7d5c5d15f1a02ab154fbed1ba0fb Signed-off-by:
Gabe Black <gabeblack@google.com>
-
- 07 Mar, 2013 1 commit
-
-
Gabe Black authored
These were both copied out of U-Boot and reworked a bit. Also, the config option for turning on the HDA codec driver was renamed to be consistent with the other options, and the dummy driver is no longer the default for ARM and has to be configured explicitly. BUG=chrome-os-partner:17340 TEST=Built and booted into depthcharge on daisy. With this driver turned on and code added to ro_main to call it, made the speakers beep. BRANCH=None Change-Id: I2a2f759cffe67364dc6bdb4053e367e3e0efff97 Signed-off-by:
Gabe Black <gabeblack@google.com> Reviewed-on: https://gerrit-int.chromium.org/33364
-
- 26 Feb, 2013 1 commit
-
-
Gabe Black authored
The timekeeping code in libpayload was dependent on rdtsc, and when it was split up by arch, that code was duplicated even though it was mostly the same. This change factors out actually reading the count from the timer and the speed of the timer and puts the definitions of ndelay, udelay, mdelay and delay into generic code. Then, in x86, the timer_hz and timer_get_raw_value functions which used to be in depthcharge were moved over to libpayload's arch/x86/timer.c. In ARM where there isn't a single, canonical timer, those functions are omitted with the intention that they'll be implemented by a specific timer driver chosen elsewhere. BUG=chrome-os-partner:17340 BUG=chrome-os-partner:17334 TEST=Built and booted depthcharge on Link and Daisy. BRANCH=None CQ-DEPEND=CL:*32858 Change-Id: If1b18658deb9fffd38c70920e2b16f8e184e410d Signed-off-by:
Gabe Black <gabeblack@google.com> Reviewed-on: https://gerrit-int.chromium.org/32894 Reviewed-by:
Stefan Reinauer <reinauer@google.com>
-
- 21 Feb, 2013 2 commits
-
-
Gabe Black authored
Also rename the existing x86 TPM driver to lpctpm to distinguish it from other implementations. BUG=chrome-os-partner:17340 TEST=Built and booted into depthcharge on Daisy and saw the dummy driver report that it doesn't do anything. Built and booted on Link. BRANCH=None Change-Id: I22b9d58d132e1b16d5ab6d32d457aff6f95b5e0c Signed-off-by:
Gabe Black <gabeblack@google.com> Reviewed-on: https://gerrit-int.chromium.org/32777 Reviewed-by:
Ronald G. Minnich <rminnich@google.com>
-
Gabe Black authored
This driver will only be built into the netbooting payload. BUG=chrome-os-partner:16688 TEST=Built and booted into the netbooting payload on Link. BRANCH=None Change-Id: I66df43a885aaf3fa6d05a3dcc394b05a9184e845 Signed-off-by:
Gabe Black <gabeblack@google.com> Reviewed-on: https://gerrit-int.chromium.org/32737
-
- 12 Feb, 2013 2 commits
-
-
Gabe Black authored
Now initialize the FMAP code on demand as well. BUG=chrome-os-partner:16683 TEST=Built and booted on Link. BRANCH=None Change-Id: I39526c17bfad0070ff08886d32790ee347ddad82 Signed-off-by:
Gabe Black <gabeblack@google.com> Reviewed-on: https://gerrit-int.chromium.org/32361 Reviewed-by:
Ronald G. Minnich <rminnich@google.com>
-
Gabe Black authored
On our x86 systems flash is memory mapped which makes it convenient to get to. Because it's so convenient, there hasn't been a need for a more formal interface to get at data stored there, you just had to compute a pointer and grab what you wanted. To support systems without memory mapped flash, and to facilitate better performance if using the programmer interface directly is faster, this change creates an interface which abstracts out exactly how flash is read or where the contents are stored. The new interface supports a single function, flash_read, which takes the offset into the flash and a size and returns a pointer to the requested data in memory. If the flash is memory mapped, the "driver" is just computing the pointer which points to the data you want and tells you to access it in place. If the driver actually goes out and reads the flash, it should put the data into a buffer which will act as a cache and return a pointer to that. A memory mapped flash driver and a dummy driver are provided as well. BUG=chrome-os-partner:16683 TEST=With this and other changes, moved over to using this interface to access flash. Built and booted on Link, built for Daisy, Lumpy and Haswell. BRANCH=None Change-Id: I455ea6edca3987b38fbb9580286158e8272f5391 Signed-off-by:
Gabe Black <gabeblack@google.com> Reviewed-on: https://gerrit-int.chromium.org/32350 Reviewed-by:
Ronald G. Minnich <rminnich@google.com>
-
- 06 Feb, 2013 2 commits
-
-
Gabe Black authored
There's no need to explicitly specify options which agree with the defaults. Remove a header from when the configs were originally generated which is very out of date. Put comments in that delimit different areas of the config, and put things in sections into alphebetical order. BUG=chrome-os-partner:8339 TEST=Built for Link, Haswell, Daisy, and Lumpy. Verified that the right thing was built into each. BRANCH=None Change-Id: I7fc00b4545487d38a54c8b9ebee6bc8e1070a8f7 Signed-off-by:
Gabe Black <gabeblack@google.com> Reviewed-on: https://gerrit-int.chromium.org/31901 Reviewed-by:
Ronald G. Minnich <rminnich@google.com>
-
Gabe Black authored
These are the "safe"/inert/neutral settings, if such a thing exists. They can then be overridden in per board configs, or ignored if they're not applicable. BUG=chrome-os-partner:8339 TEST=Built for Link, Haswell, Lumpy, and Daisy, and verified that the right things were built into each. Booted on Link. BRANCH=None Change-Id: I7a370fe414c901aac34b273035bd5484dc0332ea Signed-off-by:
Gabe Black <gabeblack@google.com> Reviewed-on: https://gerrit-int.chromium.org/31900 Reviewed-by:
Ronald G. Minnich <rminnich@google.com>
-
- 30 Jan, 2013 1 commit
-
-
Gabe Black authored
ARM systems generally won't have a PS/2 compatible keyboard controller, so we need to be able to disable support for them. While we're at it, make the USB keyboard input selectable as well. There will need to be an MKBP adapter driver at some point too. BUG=chrome-os-partner:17340 TEST=Built for Haswell and Lumpy. Built for Daisy and saw some linker errors go away. Built and booted on Link and verified that local and USB keyboard input still work. BRANCH=None Change-Id: I4e2517b648e55473696279f99842fb54b8498be9 Signed-off-by:
Gabe Black <gabeblack@google.com> Reviewed-on: https://gerrit-int.chromium.org/31661
-
- 29 Jan, 2013 4 commits
-
-
Gabe Black authored
Because each ARM SOC probably has its own system timer, a driver makes more sense than a per architecture utility function. BUG=chrome-os-partner:17340 TEST=Built and booted on Link and used cbmem to verify that the times made sense. Built for Lumpy, Haswell. Attempted to build for Daisy and saw consistent errors. BRANCH=None Change-Id: Ic4fd4e61480903754fdb4db4232ef0ea1f06224a Signed-off-by:
Gabe Black <gabeblack@google.com> Reviewed-on: https://gerrit-int.chromium.org/31653
-
Gabe Black authored
And turn it on for everything except Daisy. BUG=chrome-os-partner:17340 TEST=Built and booted on Link. Built for Daisy and saw errors from the AHCI driver go away. BRANCH=None Change-Id: I0fb516e187d0ca8bd004e95672d7013f15e6fc0f Signed-off-by:
Gabe Black <gabeblack@google.com> Reviewed-on: https://gerrit-int.chromium.org/31651
-
Gabe Black authored
BUG=chrome-os-partner:17340 TEST=Built for daisy, haswell, link and lump. Booted on Link. Saw missing symbol errors from the driver were replaced by missing symbol errors from other things that expect symbols from the driver. BRANCH=None Change-Id: I73efb9b14e6cc7b96cc124f748e7c76ad31c1fa8 Signed-off-by:
Gabe Black <gabeblack@google.com> Reviewed-on: https://gerrit-int.chromium.org/31647
-
Gabe Black authored
Put the MKBP and its various bus flavors behind some config options, and the PCH GPIO driver. Currently the MKBP driver is compiled in even on Lumpy and Haswell where it doesn't belong because without it things don't link properly. That will be fixed in future commits. BUG=chrome-os-partner:17340 TEST=Built and booted on Link. Built on Daisy and saw some errors from building inappropriate drivers go away. BRANCH=None Change-Id: I4ff51b7502f38fe40f9ca29a145fbf2e5e942689 Signed-off-by:
Gabe Black <gabeblack@google.com> Reviewed-on: https://gerrit-int.chromium.org/31644
-
- 08 Dec, 2012 1 commit
-
-
Gabe Black authored
Make them configurable instead of hardcoded on. BUG=chrome-os-partner:8339 TEST=Built and booted on Link to the recovery screen and in normal mode. Built for Lumpy. BRANCH=None Change-Id: I93e1cc3dfbba9b5d73881a10fd7064e4600014f4 Signed-off-by:
Gabe Black <gabeblack@google.com> Reviewed-on: https://gerrit-int.chromium.org/29665
-