summaryrefslogtreecommitdiff
path: root/common/build.mk
Commit message (Collapse)AuthorAgeFilesLines
* led: Board-defined tables for LED statesBen Chen2018-09-271-0/+1
| | | | | | | | | | | | | | | | | Add common code to support GPIO-controlled LEDs for common battery/power states through a board-defined lookup table. BUG=b:113611642 BRANCH=none TEST=Correct charge states shown on Aleena LED Change-Id: Id3ab88965e67d170bdc875112475565ab2dca542 Signed-off-by: Ben Chen <ben.chen2@quanta.corp-partner.google.com> Reviewed-on: https://chromium-review.googlesource.com/1233093 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Tested-by: Ryan Zhang <ryan.zhang@quanta.corp-partner.google.com> Reviewed-by: Edward Hill <ecgh@chromium.org> Reviewed-by: Jett Rink <jettrink@chromium.org>
* aes-gcm: Adapt AES-GCM to build for ECNicolas Boichat2018-09-211-0/+6
| | | | | | | | | | | | | | | | | | | | | Update header, C code, trim unnecessary bits. Also add a test with vectors taken from BoringSSL tests. BRANCH=none BUG=b:111160949 TEST=make run-aes -j TEST=make BOARD=nocturne_fp test-aes -j flash_fp_mcu aes.bin runtest => pass (C implementation speed: 909555 us for 1000 iterations) (ASM implementation speed: 596690 us for 1000 iterations) Change-Id: Ief54a8441d26ba44de4c3ac81e203cab7472269f Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1141446 Commit-Ready: Nicolas Norvez <norvez@chromium.org> Reviewed-by: Nicolas Norvez <norvez@chromium.org>
* aes: Adapt AES code to build for ECNicolas Boichat2018-09-201-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Update header, C code, and tweak the assembly for ARMv7-M. Rename aes_now_* functions to AES_* to avoid the need for a separate wrapper. Also add a test with FIPS-197 test vectors, and speed test. BRANCH=none BUG=b:111160949 TEST=make run-aes -j TEST=make BOARD=nocturne_fp test-aes -j flash_fp_mcu aes.bin runtest => pass (C implementation speed: 11977 us for 1000 iterations) (ASM implementation speed: 5815 us for 1000 iterations) Signed-off-by: Vincent Palatin <vpalatin@chromium.org> Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Change-Id: I2048aae73decccb893bc1724b2617b0b902dd992 Reviewed-on: https://chromium-review.googlesource.com/1120340 Commit-Ready: Nicolas Boichat <drinkcat@chromium.org> Tested-by: Nicolas Boichat <drinkcat@chromium.org> Reviewed-by: Adam Langley <agl@chromium.org> Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
* base_detect: Expose console command to force state.RaviChandra Sadineni2018-09-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In an effort to test wake sources on any given platform, this CL exposes console command to set the base state. This console command can then be invoked by autottests from the uart interface. We have two implementations for managing base status. One is interrupt driven while the other is a polling via a task. Boards current implementations then are: interrupts: lux, soraka, cheza polling task: nocturne, zoombini For forcing base connect and disconnect, interrupts: Disable interrupts and set forced base state. polling task: Stop periodic task and set forced base state. On reset, interrupts: Schedule deferred task immediately and enable interrupts. polling task: Clear forced base state and begin rescheduling periodic task. Signed-off-by: RaviChandra Sadineni <ravisadineni@google.com> BRANCH=poppy,nocturne BUG=chromium:820668, b:37223093 TEST=Tested on lux, soraka and nocturne basestate a : attaches the lid, reflected in ui. basestate d : detaches the lid, reflected in ui. basestate r : resets to the correct state. Wakes the device up on lux and nocturne and soraka. Change-Id: Iab698e103a50b8d22bf216a6f816998cb158e38a Reviewed-on: https://chromium-review.googlesource.com/1184172 Commit-Ready: Ravi Chandra Sadineni <ravisadineni@chromium.org> Tested-by: Ravi Chandra Sadineni <ravisadineni@chromium.org> Reviewed-by: Aseda Aboagye <aaboagye@chromium.org> Reviewed-by: Furquan Shaikh <furquan@chromium.org> Reviewed-by: Nicolas Boichat <drinkcat@chromium.org> Reviewed-by: Todd Broch <tbroch@chromium.org>
* CEC: Make buffer handling code unit testableStefan Adolfsson2018-08-221-0/+1
| | | | | | | | | | | | | | | | | | | Moving code to common/ to be able to write some unit test. The API in cec.h will be refactored in a later commit since it does not look so nice for a common API. However, it is better to do the refactoring after the unit tests are in place Signed-off-by: Stefan Adolfsson <sadolfsson@chromium.org> BUG=b:80288314 BRANCH=none TEST=emerge-fizz chromeos-ec Change-Id: I2d675689cc40248d74bf812bd6c86125d681767d Reviewed-on: https://chromium-review.googlesource.com/1073414 Commit-Ready: Stefan Adolfsson <sadolfsson@chromium.org> Tested-by: Stefan Adolfsson <sadolfsson@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* common: add API to expose detachable "base" stateDmitry Torokhov2018-08-221-0/+1
| | | | | | | | | | | | | | | | | | On some detachables, when base is attached, we know right away that the device should transition from tablet to clamshell mode. However on other detachables we need additional information (i.e. base position) before we decide whether to transition in/out of tablet mode. For such detachables let's allow them to signal a new "base attached" switch event, so that the rest of the stack is not confused. BUG=b:73133611 BRANCH=nocturne TEST=Build and boot Change-Id: I9be3450cba52bf9f0bad8333402f68b0c7903090 Signed-off-by: Dmitry Torokhov <dtor@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1176801 Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
* common/bootblock: Pack bootblock in EC image.Yilun Lin2018-07-021-0/+24
| | | | | | | | | | | | | | | | | | | Packs a bootblock into EC image. The bootblock content will be firstly tranlated to eMMC emulated data, and then been packed to the RO image. Getting idear from: CL:1039105(which generates eMMC data as a header file). BRANCH=none BUG=b:80159522 TEST=BOOTBLOCK=xyz make BOARD=kukui -j BOOTBLOCK=xyz make BOARD=kukui -j # check it doesn't repack. BOOTBLOCK=abc make BOARD=kukui -j # check it repacks the bootblock. Change-Id: Ia1564d6c54aed7a91fc42210d6247bdecfd82f4e Signed-off-by: Yilun Lin <yllin@google.com> Reviewed-on: https://chromium-review.googlesource.com/1075907 Commit-Ready: Yilun Lin <yllin@chromium.org> Tested-by: Yilun Lin <yllin@chromium.org> Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
* cr50: prepare for supporting both x25519 and p256 test keysVadim Bendebury2018-06-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | | The signer script is checking the elf files for presence of test RMA keys, currently hardcoded to be x25519 keys. The algorithm (x25519 vs p256) is going to become a compile time option, the script should be prepared to determine the type of the key at run time, because the script could be used for signing images from different branches, compiled with different config options. The prod p256 key does not yet exist. BRANCH=none BUG=b:73296606 TEST=verified that prod signing images including x25519 keys is still working as expected. Change-Id: Icf48845279912ecc9ccdecec1764fcb5f85d22bd Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1079698 Reviewed-by: Randall Spangler <rspangler@chromium.org> Reviewed-by: Mary Ruthven <mruthven@chromium.org>
* battery: Move fuel gauge code to commonEdward Hill2018-06-011-0/+1
| | | | | | | | | | | | | | | | | Move fuel gauge code to common to avoid duplication in octopus and grunt baseboards. BUG=b:79704826,b:74018100 BRANCH=none TEST=make -j buildall Change-Id: I58a615c9ed7906cb19b49c2baa36aaa619838cf1 Signed-off-by: Edward Hill <ecgh@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1072637 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Reviewed-by: Furquan Shaikh <furquan@chromium.org> Reviewed-by: Vijay Hiremath <vijay.p.hiremath@intel.corp-partner.google.com> Reviewed-by: Jett Rink <jettrink@chromium.org>
* cr50: refactor rma mode into factory modeMary Ruthven2018-05-301-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | We're doing a bit of refactoring to break out factory mode into its own file. Now factory reset and rma reset will be two methods of entering factory mode. Factory mode can be disabled with the disable_factory vendor command. Factory mode means all ccd capabilities are set to Always and WP is permanently disabled. When factory mode is disabled, all capabilities are reset to Default and WP is reset to follow battery presence. This adds 56 bytes. BUG=none BRANCH=cr50 TEST=verify rma reset will enable factory mode. Change-Id: I21c6f7b4341e3a18e213e438bbd17c67739b85fa Signed-off-by: Mary Ruthven <mruthven@google.com> Reviewed-on: https://chromium-review.googlesource.com/1069789 Commit-Ready: Mary Ruthven <mruthven@chromium.org> Tested-by: Mary Ruthven <mruthven@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* cr50: move RMA challenge-response to P256Vadim Bendebury2018-05-301-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Using the p256 curve is beneficial, because RMA feature is currently the only user of the x25519 curve in Cr50, whereas p256 support is required by other subsystems and its implementation is based on dcrypto. The p256 public key is 65 bytes in size, appropriate adjustments are being made for the structure storing the server public key and the key ID. The compact representation of the p256 public key requires 33 bytes, including the X coordinate and one extra byte used to communicate if the omitted Y coordinate is odd or even. The challenge structure communicated to the RMA server allows exactly 32 bytes for the public key. To comply, the generated ephemeral public key is used in compressed form (only the X coordinate is used). For the server to properly uncompress the public key one extra bit is required, to indicate if the original key's Y coordinate is odd or even. Since there is no room for the extra bit in the challenge structure, a convention is used where the generated ephemeral public key is guaranteed to have an odd Y coordinate. When generating the ephemeral key, the Y coordinate is checked, and if it is even, generation attempt is repeated. Some clean up is also included: even with debug enabled, generated challenge is displayed only once as a long string, convenient for copying and pasting. The new feature is not yet enabled, p256 support on the RMA server side is not yet available. Enabling p256 curve for RMA authentication saves 5336 bytes of the flash space. BRANCH=cr50, cr50-mp BUG=b:73296606 TEST=enabled CONFIG_RMA_AUTH_USE_P256 in board.h, generated challenge and verified matching auth code generated by the rma_reset utility. Change-Id: I857543c89a7c33c6fc2dc00e142fe9fa6fc642cf Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1074743 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* lpc/espi: convert remaning CONFIG_LPC to CONFIG_HOSTCMD_X86Jett Rink2018-05-221-1/+1
| | | | | | | | | | | | | | We have converted all LPC-only configs to HOSTCMD_LPC so the remaining CONFIG_LPC defines represent the common case. BRANCH=none BUG=chromium:818804 TEST=Full stack builds and works on yorp (espi) and grunt (lpc) Change-Id: Iba9a48f2cab12fadd0d9ab8eab0d5d5476eab238 Signed-off-by: Jett Rink <jettrink@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1067503 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* lpc/espi: convert ec chip code to use granular optionJett Rink2018-05-221-1/+1
| | | | | | | | | | | | | | Break the ec chip code up with the more granular CONFIG_HOSTCMD_(X86|LPC|ESPI) options. BRANCH=none BUG=chromium:818804 TEST=Full stack builds and works on yorp (espi) and grunt (lpc) Change-Id: Ie272787b2425175fe36b06fcdeeee90ec5ccbe95 Signed-off-by: Jett Rink <jettrink@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1067502 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* charge_state_v2: Throttle AP in low battery voltagePhilip Chen2018-05-211-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | When EC sees voltage drops below BAT_LOW_VOLTAGE_THRESH, we kick off a timer and ask AP to throttle. When the timer expires which means EC hasn't seen under-voltage for BAT_UVP_TIMEOUT_US, we ask AP to stop throttling. We reset the throttling status and do nothing when AP is off (S5). BUG=b:73050145, chromium:838754 BRANCH=scarlet TEST=manually test on scarlet, confirm EC sends EC_HOST_EVENT_THROTTLE_START and EC_HOST_EVENT_THROTTLE_STOP host events when entering/exiting UVP. Change-Id: Ia760989f760f95549f7a8a8acb1d01de23feab5a Signed-off-by: Philip Chen <philipchen@google.com> Reviewed-on: https://chromium-review.googlesource.com/1064983 Commit-Ready: Philip Chen <philipchen@chromium.org> Tested-by: Philip Chen <philipchen@chromium.org> Reviewed-by: David Schneider <dnschneid@chromium.org> Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
* kblight: Add keyboard backlight control moduleDaisuke Nojiri2018-05-111-0/+1
| | | | | | | | | | | | | | | | | | | | | | | This patch promotes board/nami/keyboard_backlight.c to common directory. Board customization is done via board_kblight_init callback. It currently supports two drivers: direct PWM control and lm3509. Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> BUG=b:78360907,b:78141647 BRANCH=none TEST=On Nami (for lm3509) and Sona (pwm), verify the followings: 1. Alt + brightness up/down works 2. After suspend-resume, brightness is restored 3. Lid close/open 4. After screen is off, keyboard backlight is turned off Change-Id: I584c06e8702fe7b289999698f277311cfd3400bd Reviewed-on: https://chromium-review.googlesource.com/1051027 Commit-Ready: Daisuke Nojiri <dnojiri@chromium.org> Tested-by: Daisuke Nojiri <dnojiri@chromium.org> Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
* charge_state_v2: Throttle AP in high battery discharge currentPhilip Chen2018-05-101-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | When EC sees discharge current hit BAT_MAX_DISCHG_CURRENT, we kick off a timer and ask AP to throttle. Then EC keeps monitoring discharge current. If the current doesn't drop below BAT_MAX_DISCHG_CURRENT - BAT_OCP_HYSTERESIS, we restart the timer and notify AP again, which shouldn't happen unless AP misses or ignores the first notification. When the timer expires, which means EC hasn't seen over-current for BAT_OCP_TIMEOUT_US, we ask AP to stop throttling. BUG=b:74321682, chromium:838754 BRANCH=scarlet TEST=manually test on scarlet, confirm EC sends EC_HOST_EVENT_THROTTLE_START and EC_HOST_EVENT_THROTTLE_STOP host events when entering/exiting OCP. Change-Id: I1e55fc23249596d8afec52a3885655ca9c1f2151 Signed-off-by: Philip Chen <philipchen@google.com> Reviewed-on: https://chromium-review.googlesource.com/994188 Commit-Ready: Philip Chen <philipchen@chromium.org> Tested-by: Philip Chen <philipchen@chromium.org> Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
* Cr50: Added Pinweaver base implementation.Allen Webb2018-04-271-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds some of the ground work for hardware backed brute force resistance on Cr50. The feature is called Pinweaver. It will initially be used to enable PIN authentication on CrOS devices without reducing the security of the platform. A Merkle tree is used to validate encrypted metadata used to track login attempts. The metadata tracks counts of failed attempts, a timestamp of the last failed attempt, the secrets, and any associated parameters. Instead of storing the metadata on Cr50 an AES-CTR is used with an HMAC to encrypt the data so it can be stored off-chip and loaded when needed. The Merkle tree is used to track the current state of all the metadata to prevent replay attacks of previously exported copies. It is a tree of hashes whose root hash is stored on Cr50, and whose leaves are the HMACs of the encrypted metadata. BRANCH=none BUG=chromium:809730, chromium:809741, chromium:809743, chromium:809747 TEST=cd ~/src/platform/ec && V=1 make run-pinweaver -j Change-Id: Id10bb49d8ebc5a487dd90c6093bc0f51dadbd124 Signed-off-by: Allen Webb <allenwebb@google.com> Reviewed-on: https://chromium-review.googlesource.com/895395 Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
* cr50: use run time generated public RMA key definitionVadim Bendebury2018-04-041-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | Use RMA public key definition generated based on the binary blob containing the key and key ID. Key generation is controlled by the make file in common/, but actual key blob comes from the board directory. The structure holding the key and key ID is being modified to allow initialization using a flat array. No more need in defining CONFIG_RMA_AUTH_SERVER_PUBLIC_KEY and CONFIG_RMA_AUTH_SERVER_KEY_ID. BRANCH=cr50, cr50-mp BUG=b:73296144, b:74100307 TEST='make buildall' still succeeds. test RMA server generated authentication codes are accepted when unlocking RMA. Change-Id: I8ade94de6eb69b3e49bc5b948dbac20e59962acf Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/990783 Reviewed-by: Randall Spangler <rspangler@chromium.org> Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* common: Add support for PWM LEDs.Aseda Aboagye2018-02-051-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit adds support for a common framework for PWM controlled LEDs. If there are multiple LEDs, they will all follow the same pattern. The pattern is such that it follows the Chrome OS LED behaviour specification, essentially a similar version of led_policy_std.c but for PWM controlled LEDs. To use this framework, a board must do the following: - First, define the number of logical PWM LEDs which will be controlled by this common policy, CONFIG_LED_PWM_COUNT. - Then declare those logical LEDs and define the PWM channels that comprise those LEDs. (struct pwm_led pwm_leds[]). - Next, define what each color should look like (struct pwm_led led_color_map[]). By default, the colors follow the recommended colors in the LED behaviour spec, which assume an LED with a red and green channel. If a board differs or wishes to change the colors in general, they can redefine the colors (CONFIG_LED_PWM_*_COLOR) as they see fit. The colors must be one in enum ec_led_colors. These colors are the ones that can represent the charging state, SoC state, etc. BUG=b:69138917,chromium:752553 BRANCH=None TEST=make -j buildall TEST=Enable led_pwm for meowth, and verify that LEDs behave as expected. Change-Id: I945b86a7f8ed30df58d7da835d83577192548bea Signed-off-by: Aseda Aboagye <aaboagye@google.com> Reviewed-on: https://chromium-review.googlesource.com/888220 Commit-Ready: Aseda Aboagye <aaboagye@chromium.org> Tested-by: Aseda Aboagye <aaboagye@chromium.org> Reviewed-by: Edward Hill <ecgh@chromium.org>
* samus_pd: Remove 'adc' console commandShawn Nematbakhsh2018-01-301-1/+1
| | | | | | | | | | | | | | | Remove console command for flash / RAM savings. BUG=None TEST=`make buildall -j` BRANCH=None Change-Id: Ibfccbdf45e5c86260cc55237387994fdf094c19c Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/885463 Commit-Ready: Shawn N <shawnn@chromium.org> Tested-by: Shawn N <shawnn@chromium.org> Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* Make CONFIG_MALLOC partition-specificVincent Palatin2018-01-261-4/+3
| | | | | | | | | | | | | | | | | | | Allow to have CONFIG_MALLOC defined for one partition and not the other. The typical use-case is asymetric firmware whose small RO is typically just an updater/verifier (and RW signature verification currently doesn't like malloc as the memory initialization is done too late). Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=none BUG=b:72360575 TEST=make buildall Change-Id: I67cc04cd11385d4c05556ea41ef674cb7a232e65 Reviewed-on: https://chromium-review.googlesource.com/885820 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Tested-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* CBI: Read board info from EEPROMDaisuke Nojiri2018-01-181-0/+1
| | | | | | | | | | | | | | | This patch adds Cros Board Info APIs. It reads board info from EEPROM. This patch sets CONFIG_CBI for Fizz to make it use CBI. BUG=b:70294260 BRANCH=none TEST=Read data from EEPROM. Change-Id: I7eb4323188817d46b0450f1d65ac34d1b7e4e220 Reviewed-on: https://chromium-review.googlesource.com/707741 Commit-Ready: Daisuke Nojiri <dnojiri@chromium.org> Tested-by: Daisuke Nojiri <dnojiri@chromium.org> Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
* ec_ec_comm_master: Functions for EC-EC communication masterNicolas Boichat2018-01-051-0/+1
| | | | | | | | | | | | | | This adds functions required for the master in EC-EC communication, requesting base battery static and dynamic information, and charger control. BRANCH=none BUG=b:65526215 TEST=Flash lux and wand, EC-EC communication works. Change-Id: I7a46ee3f5848d22c2c9bea7870cbd7e74141cf3d Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/839201
* espi: Add API to test if signal is eSPI virtual wireScott Worley2018-01-021-0/+1
| | | | | | | | | | | | | | | | | | | | | | Add espi_signal_is_vw in new file common/espi.c for testing if a signal is an eSPI virtual wire. API used in power common and intel_x86. Fix CONFIG_BRINGUP support for eSPI (off by default). Add espi_vw_get_wire_name returning a pointer to constant string. Chip modules do not need to maintain names of eSPI signals. BRANCH=none BUG= TEST=Build poppy and other eSPI enabled boards. Test power state machine. Change-Id: I13319e79d208c69092a02ec3ac655477d3043d61 Signed-off-by: Scott Worley <scott.worley@microchip.corp-partner.google.com> Reviewed-on: https://chromium-review.googlesource.com/836818 Commit-Ready: Randall Spangler <rspangler@chromium.org> Tested-by: Randall Spangler <rspangler@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* ec_ec_comm_slave: EC-EC communication slave task and functionsNicolas Boichat2017-12-201-0/+1
| | | | | | | | | | | | | | | | | This adds functions required for the slave in EC-EC communication, including the task that processes requests from the master. This also adds required CONFIG_EC_EC_COMM_SLAVE/MASTER/BATTERY config options. BRANCH=none BUG=b:65697962 TEST=Build wand and lux boards, flash it, EC-EC communication works. Change-Id: I772d9023a830f4fbc37316ca31e4da8240de7324 Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/828180 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* eve_fp: update fingerprint architectureVincent Palatin2017-12-061-0/+1
| | | | | | | | | | | | | | | | | split the common FP sensor code and use the updated private driver. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=none BUG=b:69460856 TEST=do a finger capture on Eve EVT. CQ-DEPEND=CL:*520759 Change-Id: I8b46762218eed0773a4c49a02c2ee6c3966cfa60 Reviewed-on: https://chromium-review.googlesource.com/806166 Commit-Ready: Vincent Palatin <vpalatin@chromium.org> Tested-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Shawn N <shawnn@chromium.org>
* ppc: Create generic PPC driver framework.Aseda Aboagye2017-12-061-0/+1
| | | | | | | | | | | | | | | | | | | | | This commit introduces a driver framework for power path controllers. It provides some common PPC APIs as well as allowing a board to use multiple different PPCs drivers/parts. This should make it easier to add PPC drivers in the future. BUG=None BRANCH=None TEST=`make -j buildall` TEST=Flash zoombini; verify PPC works as expected. TEST=Flash meowth; verify PPC works as expected. Change-Id: Icfb99f384610590b431456cfd28d4aff18442cb2 Signed-off-by: Aseda Aboagye <aaboagye@google.com> Reviewed-on: https://chromium-review.googlesource.com/807630 Commit-Ready: Aseda Aboagye <aaboagye@chromium.org> Tested-by: Aseda Aboagye <aaboagye@chromium.org> Reviewed-by: Edward Hill <ecgh@chromium.org> Reviewed-by: Shawn N <shawnn@chromium.org>
* buttons: Make buttons[] common.Aseda Aboagye2017-11-171-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | Nearly every board had a buttons array defined in which its contents had the standard volume buttons. This commit creates a single common buttons array that can contain the standard volume buttons and recovery buttons. If a board has volume up and down buttons, they can simply define CONFIG_VOLUME_BUTTONS and it will populate the buttons array with the standard definition. The buttons are active low and have a 30 ms debounce period. Similiarly, if a board has a dedicated recovery button, defining CONFIG_DEDICATED_RECOVERY_BUTTON will also populate the buttons array with a recovery button. BUG=chromium:783371 BRANCH=None TEST=make -j buildall. TEST=Flash a device with CONFIG_VOLUME_BUTTONS, verify pressing volume buttons still work. Change-Id: Ie5d63670ca4c6b146ec8ffb64d40ea9ce437b913 Signed-off-by: Aseda Aboagye <aaboagye@google.com> Reviewed-on: https://chromium-review.googlesource.com/773794 Commit-Ready: Aseda Aboagye <aaboagye@chromium.org> Tested-by: Aseda Aboagye <aaboagye@chromium.org> Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org> Reviewed-by: Shawn N <shawnn@chromium.org>
* motion_sense: Put set_range in common codeGwendal Grignou2017-11-171-2/+1
| | | | | | | | | | | | | | | | At the end of the sensor initialization, all _init sensor routines set the range to the default value from board.c file. Put all the code in a single place, move it from sensor_common.c to motion_sense.c. BUG=none BRANCH=none TEST=compile Change-Id: If89cf27c6438e0f215c193d68a480e027110174c Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/767610 Reviewed-by: Shawn N <shawnn@chromium.org>
* common: Add software CTZ implementation when needeedGwendal Grignou2017-11-161-0/+1
| | | | | | | | | | | | | | | | | CTZ - Count Trailing Zero - is not implemented in hardware on cortex0 or nds32. Used in ST sensor drivers. BUG=none BRANCH=none TEST=compile Change-Id: I2d62fd60f05169189b24ba2a3308bec69ed9de9c Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/767609 Commit-Ready: Ely Vazquez <nadia198877@gmail.com> Reviewed-by: Shawn N <shawnn@chromium.org>
* cleanup: Use CONFIG_BATTERY to indicate whether a board has a batteryShawn Nematbakhsh2017-10-131-8/+1
| | | | | | | | | | | | | BUG=b:35528297 BRANCH=None TEST=`make buildall -j` Change-Id: I9e4814b4172f20711f7edd691c9569f9130aec8e Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/713395 Commit-Ready: Shawn N <shawnn@chromium.org> Tested-by: Shawn N <shawnn@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* charge_ramp: Move ramp allowed / ilim callbacks to common codeShawn Nematbakhsh2017-10-061-1/+2
| | | | | | | | | | | | | | | | | | | | | The decision on whether to ramp (and how high) depends on the quirks of charger identification, so move the decision out of board, into the drivers that implement usb_charger. Also, rename CONFIG_CHARGE_RAMP to CONFIG_CHARGE_RAMP_SW, to better contrast with the existing CONFIG_CHARGE_RAMP_HW. BUG=None TEST=Manual on kevin, verify ramp occurs when port plugged into Z840 workstation. BRANCH=None Change-Id: I5b395274133837a18a4f4ac34b59b623287be175 Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/702681 Commit-Ready: Shawn N <shawnn@chromium.org> Tested-by: Shawn N <shawnn@chromium.org> Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* cleanup: pd: Remove CONFIG_CASE_CLOSED_DEBUGShawn Nematbakhsh2017-10-051-1/+0
| | | | | | | | | | | | | | | | | | CONFIG_CASE_CLOSED_DEBUG (CCD functionality implemented by EC) is no longer used in conjunction with CONFIG_USB_POWER_DELIVERY, and the common routines are only used by one board. BUG=chromium:737755 BRANCH=None TEST=`make buildall -j` Change-Id: Idc3d2fccef6cbec2af786cef634d752a02a0e859 Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/656315 Commit-Ready: Shawn N <shawnn@chromium.org> Tested-by: Shawn N <shawnn@chromium.org> Reviewed-by: Nick Sanders <nsanders@chromium.org> Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* rtc: Add functions and tests for time conversionPhilip Chen2017-09-261-0/+1
| | | | | | | | | | | | | | | | | | | | | To implement rtc driver for some ec chips, we need to convert between calandar date and seconds (since epoch time, 01-01-1970 00:00:00). Sicne these functions are HW-independent, let's add common/rtc.c, include/rtc.h, and unit test for this. BUG=b:63908519 BRANCH=none TEST=make buildall test -j Change-Id: Icb1e768d2b3674d5225b83e09475e984eb104d06 Signed-off-by: Philip Chen <philipchen@google.com> Reviewed-on: https://chromium-review.googlesource.com/666985 Commit-Ready: Philip Chen <philipchen@chromium.org> Tested-by: Philip Chen <philipchen@chromium.org> Reviewed-by: Shawn N <shawnn@chromium.org> Reviewed-by: Brian Norris <briannorris@chromium.org>
* Add WebUSB descriptor supportVincent Palatin2017-09-221-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | The WebUSB specification defines a specific Platform Descriptor in the Binary Object Store: https://wicg.github.io/webusb/#webusb-platform-capability-descriptor This descriptor provides a special 'Landing page' URL to the host browser and associated privileges for it. Bump the USB version for BOS descriptors to 2.1 to be compatible with Chrome implementation. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BUG=none BRANCH=twinkie TEST=manual: on Twinkie (chip/stm32) and HG proto2 (chip/g), enumerate WebUSB descriptors with lsusb and connect to a WebUSB page in Chrome R61+. Change-Id: I7211ab554f4a6c156c1e8e79a3d9f0d6644217c6 Reviewed-on: https://chromium-review.googlesource.com/664813 Commit-Ready: Vincent Palatin <vpalatin@chromium.org> Tested-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* Makefile: Generate hashes for the touchpad FWNicolas Boichat2017-09-151-0/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Based on the passed TOUCHPAD_FW parameter to the make command, the build system generates hashes for the touchpad FW. To generate the hashes, gen_touchpad_hash splits the touchpad FW in blocks of CONFIG_UPDATE_PDU_SIZE, that are hashed individually (SHA-256), and then stored in the EC image. This will allow the USB updater code to verify the integrity of the touchpad firmware being flashed. When no FW is provided, zeros are output, which do not match any valid data. BRANCH=none BUG=b:63993173 TEST=make TOUCHPAD_FW=SA459C-1211_ForGoogleHammer_3.0.bin \ BOARD=hammer -j TEST=Using variations of make TOUCHPAD_FW=SA459C-1211_ForGoogleHammer_3.0.bin \ BOARD=hammer -j make TOUCHPAD_FW=SA459C-1211_ForGoogleHammer_4.0.bin \ BOARD=hammer -j make BOARD=hammer -j Check that TPHASH touchpad_fw_hash.h is only regenerated when the parameter changes. Change-Id: Ie347270aa9c00342de13489c9422e45e681b94c2 Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/615321 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* acpi: Map EC features into ACPI EC memory spacePatrick Georgi2017-08-301-1/+1
| | | | | | | | | | | | | | | | | Reserve EC address space offset 0x0a-0x0d for device features. Same value as with the host command, just different way to access it. BUG=b:64705535 BRANCH=none TEST=none Change-Id: I420aed1ae8d0fb7da477fc72ac55ea75a9f9350b Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: https://chromium-review.googlesource.com/626976 Commit-Ready: Patrick Georgi <pgeorgi@chromium.org> Tested-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Duncan Laurie <dlaurie@google.com>
* ec_features: Move feature flags out of ec_command into its own unitPatrick Georgi2017-08-301-1/+1
| | | | | | | | | | | | | | | | | | Prepare for exposing the feature flags through EC ACPI memory space by moving the definitions and collection function into its own unit. BUG=b:64705535 BRANCH=none TEST=builds and returns the same value Change-Id: I66eabebe0d039fdcd14d11b9ecf77c0f1040d006 Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: https://chromium-review.googlesource.com/633925 Commit-Ready: Patrick Georgi <pgeorgi@chromium.org> Tested-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-by: Aseda Aboagye <aaboagye@chromium.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* EFS: Rename CONFIG_VBOOT_EC to _EFSDaisuke Nojiri2017-08-291-1/+1
| | | | | | | | | | | | | | This patch renames CONFIG_VBOOT_ET to CONFIG_VBOOT_EFS. It also adds the macro to config.h. BUG=none BRANCH=none TEST=make buidlall Change-Id: I7cb9f4c73da635b36119db74bac6fe26e77a07d2 Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/639955 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* tpm: Add optional event loggingShawn Nematbakhsh2017-08-101-0/+1
| | | | | | | | | | | | | | | | | | Allow TPM to log events in a circular buffer through tpm_log_event(). Logs can be retrieved through a new vendor command VENDOR_CC_POP_LOG_ENTRY. BUG=b:63760920 TEST=On eve, store TPM logs through 'logentry' cr50 console command, verify logs are fetched correctly through 'trunks_send --pop_logentry'. BRANCH=None Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org> Change-Id: Idbc405728c0ba68078447fb59717d6115830e3d8 Reviewed-on: https://chromium-review.googlesource.com/599352 Commit-Ready: Shawn N <shawnn@chromium.org> Tested-by: Shawn N <shawnn@chromium.org> Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
* pd_log: Make PD logging more generic for general purpose loggingShawn Nematbakhsh2017-08-021-1/+1
| | | | | | | | | | | | | | | | | | We can re-use our pd_log FIFO for other purposes, such as TPM logging. Carve out event_log, a generic logging module which pd_log is compatible with. BUG=b:63760920 TEST=On kevin, verify PD logging is still functional and entries are seen in dmesg. BRANCH=None Change-Id: I8e6ad6f93e9eebc676aca64652c60f81da471a94 Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/597314 Commit-Ready: Shawn N <shawnn@chromium.org> Tested-by: Shawn N <shawnn@chromium.org> Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* battery/max17055: Add max17055 fuel gauge driverPhilip Chen2017-07-271-0/+1
| | | | | | | | | | | | | | | | | BUG=chromium:736603 BRANCH=none TEST=Follow the steps below 1) add MAX17055 config to Scarlet and build the code 2) hook up max17055 eval board and a single cell battery 3) battery command from ec console shows reasonable numbers for temperature, voltage, and charge percentage Change-Id: I3f838ff92c591665e9f1d0a7ba636ff83d9b7612 Signed-off-by: Philip Chen <philipchen@google.com> Reviewed-on: https://chromium-review.googlesource.com/578300 Commit-Ready: Philip Chen <philipchen@chromium.org> Tested-by: Philip Chen <philipchen@chromium.org> Reviewed-by: Shawn N <shawnn@chromium.org>
* cr50: Add case closed debugging V1 configurationRandall Spangler2017-07-201-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds the CCD configuration module, and the console commands to control it. It is not wired up to any of the CCD capabilities; that's coming in the next CL. Briefly: * CCD configuration is persistently stored in nvmem_vars. Use ccdinfo to print it. * CCD can be Locked, Unlocked (some capabilities), or Opened (all capabilities), using the ccdlock / ccdunlock / ccdopen commands. * CCD config can be restricted by setting a password via ccdpass. * Individual config capabilities can be set via ccdset. Some of those will be used to gate access to things like write protect and UARTs. Others affect the requirements for ccdunlock / ccdopen (for example, is physical presenc required). * The entire config can be reset via ccdreset. If only unlocked, config that is restricted to Opened is not reset. * If CR50_DEV=1, ccdoops will force-reset and open the config. See go/cr50-ccd-wp for more information. BUG=b:62537474 BRANCH=none TEST=manual with CR50_DEV=1 build gpioget # make sure GPIO_BATT_PRES_L=0 ccdlock # lock, because CR50_DEV=1 builds start unlocked ccdinfo # locked, flags=0, all capabilities default ccdpass # access denied (we're locked) ccdreset # access denied ccdset flashap always # access denied ccdunlock ccdinfo # unlocked ccdpass foo ccdinfo # flags=2 (password set when unlocked) ccdset flashap always # access denied ccdset uartectx unlesslocked ccdinfo # yes, uartectx permission changed ccdlock ccdunlock # fails without password ccdunlock bar # wrong password ccdunlock foo # busy (wait 3 sec) ccdunlock foo ccdreset ccdinfo # no password, flags 0, capabilities all default ccdopen # requires physical presence; tap power or use 'pp' ccdset uartectx unlesslocked ccdset batterybypasspp ifopened ccdpass baz ccdinfo # password set, flag 0, ccdset changes worked ccdunlock ccdreset ccdinfo # uartectx back to ifopened, password still set ccdopen baz # still requires physical presence ccdset opennolongpp always ccdlock ccdopen baz # no pp required ccdset unlocknoshortpp unlesslocked ccdlock ccdopen baz # short pp sequence required (3 taps) ccdlock ccdunlock baz # short pp sequence required ccdopen baz # pp not required ccdset unlocknoshortpp always ccdlock testlab open # access denied testlab enable # access denied ccdunlock baz testlab open # access denied testlab enable # access denied ccdopen baz testlab enable # requires short pp ccdinfo # flags 1 ccdreset ccdinfo # no password, flags=1, caps all default ccdlock testlab open ccdinfo # opened testlab disable # requires short pp; let it time out ccdinfo # still opened, flags=1 ccdlock ccdoops # backdoor in CR50_DEV images to force-reset CCD ccdinfo # opened, flags=0, all defaults (yes, oops wipes out testlab) ccdreset rma ccdinfo # flags = 0x400000, everything but Cr50FullConsole always ccdreset # back to flags=0, all default Change-Id: I24e8d8f361874671e6e94f27492ae00db919bea9 Reviewed-on: https://chromium-review.googlesource.com/569439 Commit-Ready: Randall Spangler <rspangler@chromium.org> Tested-by: Randall Spangler <rspangler@chromium.org> Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
* cr50: Add physical presence state machineRandall Spangler2017-07-191-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This will be used as part of case closed debugging configuration. Currently, this only adds the state machine, and a test command which is available when CR50_DEV=1. It also adds a new sleep mask flag for physical presence detect, instead of oveloading FORCE_NO_DSLEEP. The physical presence state machine supports both short (tap 5 times in 15 seconds) and long (short, followed by 4 more taps 1-5 minutes apart) sequences. It will call a callback function at the end of the sequence, so that multiple things can each request physical presence in turn. This will be used by ccdopen / ccdunlock / testlab commands for CCD V1. Eventually, CCD config will replace the unlock sequence handling in wp.c. But for now, we don't touch that. See go/cr50-ccd-wp for more information. BUG=b:62537474 BRANCH=none TEST=manual Short sequence: pp short pp pp pp # See "Physical presence good" Timeout pp short pp # 15 sec later, get timeout error Long sequence: pp long pp pp pp (wait 2 sec) pp (wait 2 sec) pp # See "PP good" Long sequence, presses too fast: pp long pp pp pp pp # See "PP L too soon" (wait 2 sec) pp (wait 2 sec) pp # See "Physical presence good" Abort: pp short pp abort # See "Physical presence aborted" Change-Id: I09da81ad11d328e7d7740c3fe838a5f67d7b8708 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/568796 Reviewed-by: Aseda Aboagye <aaboagye@chromium.org> Reviewed-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-by: Mary Ruthven <mruthven@chromium.org>
* vboot: Move common code under common/vbootDaisuke Nojiri2017-07-131-2/+3
| | | | | | | | | | | | | | | This patch moves the code which can be shared with other data verification schemes (e.g. RWSIG) under common/vboot. It also adds unit tests for it. BUG=b:38462249 BRANCH=none TEST=make run-vboot. Verify verification succeeds on Fizz. Change-Id: Icab4d96dd2c154a12b01c41ebe9b46286b4b590e Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/563463 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* core/cortex-m0/curve25519: Integrate fast curve25519 implementationNicolas Boichat2017-07-031-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - Move generic implementation to curve25519-generic.o - Always use optimized version on cortex-m0. - Rename .s files to .S, remove unnecessary lines in assembly files. - Rename crypto_scalarmult_curve25519 to x25519_scalar_mult to match the signature provided by the generic implementation. - Replace some handcoded memcpy with function calls - Remove unnecessary "volatile" specifications in the code. BRANCH=none BUG=b:62813194 TEST=To test old implementation only: - Increase CONFIG_RO_SIZE to 60kb - Increase console stack size to 2048 make BOARD=hammer PROJECT=x25519 TEST_BUILD=y ./util/flash_ec --board=hammer --image=build/hammer/x25519.bin EC console: runtest, taskinfo => Used to takes ~4'17" to run (X25519 duration 256347 us). 1496/2048 stack size usage in CONSOLE task => Now takes ~1'25" to run (X25519 duration 84520 us) 732/2048 stack size usage in CONSOLE task TEST=In test/x25519.c, uncomment #define TEST_X25519_1M_ITERATIONS make BOARD=hammer PROJECT=x25519 TEST_BUILD=y ./util/flash_ec --board=hammer --image=build/hammer/x25519.bin EC console: runtest, wait ~23 hours, test passes. TEST=- Define CONFIG_CURVE25519_CORTEXM0 (next patch) makes newsizes build/hammer/RW/ec.RW.flat shrank by 1888 bytes: (52208 to 50320) Change-Id: Icce38d3c32f431a85ac0f951cf34456b490dc665 Reviewed-on: https://chromium-review.googlesource.com/540962 Commit-Ready: Nicolas Boichat <drinkcat@chromium.org> Tested-by: Nicolas Boichat <drinkcat@chromium.org> Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
* common: Add RMA reset auth challenge-response cryptoRandall Spangler2017-06-301-0/+1
| | | | | | | | | | | | | | | | RMA auth uses X25519 to generate a relatively small challenge and response. Currently, nothing calls the rma_auth code. We'll need console and TPM vendor commands to do so. BUG=b:37952913 BRANCH=none TEST=make buildall Change-Id: Iec7f2d0e3dc8243f79b009ead16bb3ba9f1bef9d Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/544184
* Add support for reporting device eventsDuncan Laurie2017-06-301-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | In order to report specific wake events from differernt devices add a host command that allows setting device event mask, and triggering a host event when that device event is set. This is done as a separate command and mask because we are running out of host events, and it takes over the unused thermal overload event that was never used in EC or BIOS. The first use case for this is platforms that have AP wake events that go to the EC, for instance devices that use Deep S3 and have a limited set of wake pins. (such as Eve) This allows the AP to determine the exact wake source for an event so it can be logged and acted on by the AP if necessary. BUG=b:36024430 BRANCH=eve TEST=manual testing on eve with trackpad and dsp wake events Change-Id: I48d94014c00dc1dad098ab96af0ddc7860229762 Signed-off-by: Duncan Laurie <dlaurie@google.com> Reviewed-on: https://chromium-review.googlesource.com/555632 Reviewed-by: Scott Collyer <scollyer@chromium.org>
* Add U2F implementationVincent Palatin2017-06-291-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | Add the common code to support FIDO U2F (Universal second factor authentication) protocol implementation: the APDU parsing and standard commands execution, plus a few non-standard flags and hooks. The u2f.h header is the unmodified copy from the U2F v1.1 Specifications archive. Mostly copied over from the cr52 code-base. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=cr50 BUG=b:35545754 TEST=with follow-up CLs, run U2FTest on Eve. CQ-DEPEND=CL:*390230 Change-Id: I636d4a77ea69d69b5ab18a958e58ee6fcb2476bc Reviewed-on: https://chromium-review.googlesource.com/518136 Commit-Ready: Vincent Palatin <vpalatin@chromium.org> Tested-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* common: Add base32 encodingRandall Spangler2017-06-281-0/+1
| | | | | | | | | | | | | | Base32 encoding is used to turn the RMA reset binary challenge/response into less-typo-prone text, at 5 bits per character. BUG=b:37952913 BRANCH=none TEST=make runtests Change-Id: I474750a20204ba353cea1e91982aa03e8071c0c2 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/544177 Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
View Lorry Controller Status