Skip to content

GitLab

Switch branch/tag
  1. 13 Oct, 2017 1 commit
  3. 26 Sep, 2017 1 commit
  5. 03 May, 2016 1 commit
    • Julius Werner's avatar
      cros_ec: Change EC interface to be fully object-oriented · 3c697995
      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: default avatarJulius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/341542

Reviewed-by: default avatarAaron Durbin <adurbin@chromium.org>
      3c697995
  7. 08 Mar, 2016 1 commit
  9. 26 Feb, 2016 1 commit
  11. 18 Dec, 2015 1 commit
  13. 28 Aug, 2015 1 commit
  15. 27 Aug, 2015 1 commit
  17. 21 Aug, 2015 1 commit
  19. 13 Jun, 2015 1 commit
  21. 27 May, 2015 1 commit
  23. 11 Feb, 2015 1 commit
  25. 16 Dec, 2014 1 commit
  27. 30 Aug, 2014 1 commit
    • Julius Werner's avatar
      net: Enable all USB dongle drivers unconditionally · 7e11da67
      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: default avatarJulius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/215498

Reviewed-by: default avatarAaron Durbin <adurbin@chromium.org>
      7e11da67
  29. 26 Aug, 2014 2 commits
  31. 09 Aug, 2014 1 commit
  33. 12 Nov, 2013 1 commit
  35. 04 Oct, 2013 1 commit
  37. 23 Jul, 2013 2 commits
    • Gabe Black's avatar
      flash: spi: Restructure the drivers. · d5e9febe
      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: default avatarGabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/62537

Reviewed-by: default avatarDavid Hendricks <dhendrix@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: default avatarGabe Black <gabeblack@chromium.org>
      d5e9febe
    • Gabe Black's avatar
      EC: Rename anything called mkbp cros_ec if it's not keyboard related. · cb4e0579
      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: default avatarGabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/62080

Reviewed-by: default avatarAaron Durbin <adurbin@chromium.org>
Tested-by: default avatarGabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
      cb4e0579
  39. 09 Jul, 2013 1 commit
    • Gabe Black's avatar
      Add board specific directories/files. · 8979e082
      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: default avatarGabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/60983

Reviewed-by: default avatarAaron Durbin <adurbin@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: default avatarGabe Black <gabeblack@chromium.org>
      8979e082
  41. 28 Jun, 2013 1 commit
  43. 23 May, 2013 1 commit
  45. 30 Apr, 2013 1 commit
  47. 14 Mar, 2013 1 commit
    • Gabe Black's avatar
      Modularize setting up data for crossystem. · 04430a2d
      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: default avatarGabe Black <gabeblack@google.com>
      04430a2d
  49. 07 Mar, 2013 1 commit
  51. 26 Feb, 2013 1 commit
    • Gabe Black's avatar
      depthcharge: Generalize and redistribute timekeeping code. · a99b8f4d
      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: default avatarGabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit-int.chromium.org/32894

Reviewed-by: default avatarStefan Reinauer <reinauer@google.com>
      a99b8f4d
  53. 21 Feb, 2013 2 commits
  55. 12 Feb, 2013 2 commits
    • Gabe Black's avatar
      depthcharge: Hook the FMAP code into the new flash driver interface. · 715d6bbe
      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: default avatarGabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit-int.chromium.org/32361

Reviewed-by: default avatarRonald G. Minnich <rminnich@google.com>
      715d6bbe
    • Gabe Black's avatar
      depthcharge: Create a "driver" interface for accessing flash contents. · dabe2d42
      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: default avatarGabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit-int.chromium.org/32350

Reviewed-by: default avatarRonald G. Minnich <rminnich@google.com>
      dabe2d42
  57. 06 Feb, 2013 2 commits
  59. 30 Jan, 2013 1 commit
    • Gabe Black's avatar
      depthcharge: Make ps/2 keyboard and USB input selectable drivers. · 83791c0c
      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: default avatarGabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit-int.chromium.org/31661
      83791c0c
  61. 29 Jan, 2013 4 commits
  63. 08 Dec, 2012 1 commit