Files
OpenCellular/firmware
Duncan Laurie 534194ead7 Add new NV and GBB flag to control UDC
This change adds a new NV and GBB flag for controlling USB device
mode behavior, adding an additional step to enable UDC on systems
that support it.

Users of this feature will need to first enable developer mode and
then enable UDC separately by running "crossystem dev_enable_udc=1".

Alternatively those without write protect enabled can set a GBB
flag to have UDC enabled by default while in developer mode.

This is based on the security reviewed proposal at
https://docs.google.com/document/d/1b6avd9xvhvljN_NKtctWrClj4mSYZ_uPmp7MmAnPwqs

BUG=b:74339386
BRANCH=poppy
TEST=manual testing on Eve device

Change-Id: I6f440320f28b033639b53246d3034bc8acc37a33
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://chromium-review.googlesource.com/1010769
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
2018-04-17 15:47:13 -07:00
..
2018-04-13 10:03:37 +00:00
2018-01-05 21:14:12 -08:00
2018-01-05 21:14:12 -08:00

Here's what's what in the firmware/ directory.

bdb/

  Code for managing Boot Descriptor Blocks (BDB).

include/
lib/

  These are the original structures and APIs used in the earliest
  Chromebooks and continuing through 2014. It never had a version as such to
  begin with, but we now refer to this implementation as "vboot1" or
  "vboot version 1.0".

linktest/
stub/

  These are stubs used to link the vboot1 libraries into host-side test
  executables so we can run some tests on the build machine instead of a
  Chromebook.

2lib/

  In 2014 we began work on a new vboot API. The first step was just a
  refactoring and renaming of the verification API. The public functions and
  external headers that are exported for use by the Chrome OS firmware (or
  anything else that wants to use vboot) live in here. The internal
  structures and implementations go elsewhere.

lib20/

  This is an early implementation of the public (2lib/) API. It is
  binary-compatible with vboot1, so although the interface details are
  different, any existing on-device structures or signatures created by the
  vboot1 tools can be validated using this implementation.

  This was deployed slightly before it was ready. That's not a problem,
  thanks to the binary compatibility, but this directory will be abandoned
  Real Soon Now, except for the product support branches.

lib21/

  This is where the current development of the second-generation vboot API
  is taking place. It uses the public (2lib/) API, but will NOT be binary
  compatible with vboot1 structs. Because of the early release of the lib20
  stuff, we're actually calling this lib21.