Skip to content
GitLab
  1. 13 Oct, 2017 1 commit
  3. 26 Sep, 2017 1 commit
  5. 19 Aug, 2017 1 commit
  7. 24 Jun, 2017 1 commit
  9. 20 Jun, 2017 1 commit
  11. 26 May, 2016 1 commit
  13. 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
  15. 24 Mar, 2016 1 commit
  17. 21 Mar, 2016 1 commit
  19. 04 Feb, 2016 1 commit
    • Naveen Krishna Chatradhi's avatar
      Kunimitsu/Lars: Workaround for silego unable to see EC reset · ac2b89a9
      Naveen Krishna Chatradhi authored 
      On skylake boards the silego chip is unable to see EC resets and
clear the latch on EC_IN_RW state.  This means that FAFT is unable
to switch to developer mode because VbExTrustEC() will always fail.

This only matters for FAFT because entering recovery mode with the
keyboard still works properly and this VbExTrustEC() callback is
only ever used in the developer mode transition screen.

As such, use the existing FAFT override GBB flag that is used for
similar workarounds in the firmware to enable FAFT testing.

This is a bit messy, using an overridden flag to check at runtime,
because GBB flags are not available in the board_setup() function
as they have not been read yet and due to the structure of RO/RW
depthcharge it is not convenient to change that behavior.

This is a port for Kunimitsu and lars boards following CL for
https://chromium-review.googlesource.com/#/c/319245/



BUG=chrome-os-partner:47648
BRANCH=none
TEST=manual testing (in additon to FAFT)
1) set GBB flag 0x300
2) enter recovery mode with: dut-control power_state:rec
3) press Ctrl+D on keyboard to transition to developer mode
4) also verify that when the GBB flag is not set that if the
EC is in RW and steps 2-3 are executed that it does not allow
entry into developer mode
5) also verify that keyboard controlled recovery mode does clear
the EC_IN_RW flag properly and does not need GBB flag to be set.

Change-Id: Icd120cbff4d19b51f193c5ed9c40ec3098820f5e
Signed-off-by: default avatarNaveen Krishna Chatradhi <naveenkrishna.ch@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/319208


Commit-Ready: Divya Jyothi <divya.jyothi@intel.com>
Tested-by: default avatarDivagar Mohandass <divagar.mohandass@intel.com>
Reviewed-by: default avatarDuncan Laurie <dlaurie@chromium.org>
      ac2b89a9
  21. 13 Jan, 2016 1 commit
  23. 03 Dec, 2015 1 commit
  25. 09 Oct, 2015 1 commit
  27. 10 Sep, 2015 1 commit
  29. 27 Aug, 2015 2 commits
  31. 21 Aug, 2015 1 commit
  33. 14 Aug, 2015 1 commit
  35. 27 May, 2015 1 commit
  37. 04 Apr, 2015 1 commit
  39. 11 Mar, 2015 1 commit
  41. 11 Feb, 2015 1 commit
  43. 02 Dec, 2014 1 commit
    • Julius Werner's avatar
      sysinfo: Allow GPIOs to be passed from coreboot to depthcharge · 139dc0e2
      Julius Werner authored 
      

We have always had a 'port' field in struct cb_gpio that contains some
kind of platform specific description of the GPIO, but until now we have
never made use of it. Instead, depthcharge just relies on the values
coreboot read and pretends they never change. For some GPIOs (especially
those which aren't actually GPIOs anymore like the dev switch), this
behavior makes sense... but for others like the power button, it
absolutely doesn't. In these cases depthcharge boards always had to
override the flag manually with another flag_replace() after
sysinfo_install_flags(), which is easy to forget. In addition, these
GPIOs often like to change with board revisions, requiring developers to
not only specify them twice (in coreboot and depthcharge) but also
remember to apply all changes on new board revisions to both
repositories.

This patch redesigns the sysinfo GPIO API. Boards can now pass a
platform-specific converter function that can create a depthcharge
GPIO from the description passed in the coreboot table. It
implements exemplary support for the new feature on Tegra- and
Rockchip-based boards, while all others will still work the old way
(emitting a warning). Over time, all current platforms should change to
the new model and redundant GPIO definitions should become a thing of
the past. (Also fix rush_ryu's explicit use of the sysinfo GPIO API to
work with the new functions, and implement a stopgap wrapper for Storm.
It's not yet possible to add full support to Storm since the Qualcomm
drivers don't support the basic depthcharge GPIO API.)

CQ-DEPEND=CL:231222
BRANCH=None
BUG=None
TEST=Booted on Veyron_Pinky, Nyan_Blaze and Falco. Made sure that the
power button shuts the system down from depthcharge. Compiled for Storm
and Rush_Ryu.

Change-Id: I532ff1e5cb0912bd2c0764deedd8448ae81023d0
Signed-off-by: default avatarJulius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/231250


Reviewed-by: default avatarAaron Durbin <adurbin@chromium.org>
      139dc0e2
  45. 23 Jan, 2014 1 commit
  47. 22 Jan, 2014 1 commit
  49. 04 Dec, 2013 1 commit
  51. 20 Sep, 2013 2 commits
  53. 11 Sep, 2013 1 commit
  55. 04 Sep, 2013 2 commits
    • Gabe Black's avatar
      storage: Simplify the storage driver interface. · c180e947
      Gabe Black authored 
      

Instead of having an init callback and a refresh callback, there is now an
update call back which is called if need_update is set to 1. Controllers that
have fixed media attached to them will set need_update when their drivers are
initially set up and clear it after the first update. Controllers that might
have removable media attached will leave need_update turned on. Both will call
their own init function when necessary, probably the first time update is
called.

Also, to avoid initializing controllers which aren't attached to the types of
media we're concerned with, the single block_dev_controller list is split into
two lists, one for controllers that have fixed media and one for those that
could have removable media. The lists are not mutually exclusive, and the
same mechanism which determines when to initialize the controller on a single
list will prevent a controller for being initialized for each list it occurs
on.

BUG=None
TEST=Built for all boards. Built and booted from emmc and sd card on snow and
pit. Booted from ahci and usb on link. Booted from USB on kirby.
BRANCH=None

Change-Id: I134c207c61fa553a759bd54dcacbf5d93efb12e4
Signed-off-by: default avatarGabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/168044


Reviewed-by: default avatarron minnich <rminnich@chromium.org>
Tested-by: default avatarGabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
      c180e947
    • Gabe Black's avatar
      Storage: Change the storage drivers to use structures of function pointers. · cf805fb9
      Gabe Black authored 
      

Switch the storage drivers (AHCI, USB, both types of MMC) over to using
structures of function pointers like most of the other drivers. This change
touches all boards and heavily affects the MMC drivers, but the other drivers
were fairly straightforward to port over.

BUG=None
TEST=Built for all boards, built and booted on Falco, pit, and snow.
BRANCH=None

Change-Id: I4d5c9259e7f97eebe9b82a3bdbe112b2e2625d34
Signed-off-by: default avatarGabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/168043


Reviewed-by: default avatarron minnich <rminnich@chromium.org>
Tested-by: default avatarGabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
      cf805fb9
  57. 31 Jul, 2013 1 commit
    • Gabe Black's avatar
      sound: Turn the sound drivers into structures with function pointers. · 3352dfb6
      Gabe Black authored 
      

Also introduce a wrapper class which represents the path audio takes through
the system called a SoundRoute. When you play a sound through the SoundRoute,
it first makes sure all of its components are enabled which would typically
include the codec, and then it calls through to the underlying sound source.

BUG=chrome-os-partner:19420
TEST=Built and booted on link and snow and verified that the developer mode
beep still works and the proceeded to the kernel. Built and booted on Falco
and saw consistent messages about not finding a beep node. Built for all other
platforms other than bolt. Built and booted on pit with no audio set up and
saw that it could still get through to the kernel with appropriate error
messages from the firmware.
BRANCH=none

Change-Id: Ifbe7909cfb632c70e6a03c2ab47f0444fdef22a9
Signed-off-by: default avatarGabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/63545


Reviewed-by: default avatarHung-Te Lin <hungte@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: default avatarGabe Black <gabeblack@chromium.org>
      3352dfb6
  59. 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
  61. 16 Jul, 2013 1 commit
  63. 10 Jul, 2013 1 commit
    • Gabe Black's avatar
      Change the GPIO drivers into structures of function pointers. · e846f1b9
      Gabe Black authored 
      

Reduce the generic GPIO interface to get and set functions, consolidate the
sysinfo functions into that interface, simplify the flag management code,
move the now extraneous GPIO functions into the driver specific driver
structures, and adjust the exynos5250 I2C driver to use the new interface.
Also, since there isn't a global and necessarily available GPIO API which can
only be implemented once, it doesn't need to be a "choice" type config option.
Since there doesn't need to be a default, inert choice any more, the stub
driver has been deleted.

BUG=None
TEST=Built and booted on link, snow, and peach pit, built for bolt, falco,
peppy and slippy.
BRANCH=None

Change-Id: Icb70b250417765ac857c8b0a7943b4e22587bf37
Signed-off-by: default avatarGabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/60984


Reviewed-by: default avatarAaron Durbin <adurbin@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: default avatarGabe Black <gabeblack@chromium.org>
      e846f1b9
  65. 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
  67. 26 Feb, 2013 2 commits
    • 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
    • Gabe Black's avatar
      depthcharge: Change the timer driver API. · 320c9f02
      Gabe Black authored 
      

Change the names of the timer driver API so that they have the prefix "timer"
at their start. It also introduces a new function called "timer_hz" to
seperate the idea of CPU frequency and the frequency of the system timer.

BUG=chrome-os-partner:17340
TEST=Built for Link and Daisy.
BRANCH=None

Change-Id: I526c6e4922653a6632fd3caabb408bfcef516a3f
Signed-off-by: default avatarGabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit-int.chromium.org/32857


Reviewed-by: default avatarStefan Reinauer <reinauer@google.com>
      320c9f02
  69. 11 Feb, 2013 1 commit