1. 21 Jan, 2019 1 commit
    • Guillaume Tucker's avatar
      stm32usb: compare serial numbers rather than usb.util.get_string() · 3ad2d9fc
      Guillaume Tucker authored
      When several stm32usb serial consoles are present, comare each USB
      device serial number with the micro servo to find the correct one
      rather than using the usb.util.get_string() method which appears to be
      doing something completely different and never returns a matching
      serial number.  The Servo Micro uses such a console, so when
      connecting more than one to the same controller the issue occurs.
      
      This issue cannot be seen when only one servo board has a stm32usm
      serial device.
      Signed-off-by: Guillaume Tucker's avatarGuillaume Tucker <guillaume.tucker@collabora.com>
      3ad2d9fc
  2. 21 Aug, 2018 2 commits
  3. 20 Jun, 2018 2 commits
  4. 01 Feb, 2018 1 commit
  5. 31 Jan, 2018 2 commits
  6. 19 Jan, 2018 3 commits
  7. 12 Jan, 2018 1 commit
    • Vincent Palatin's avatar
      servo: fix ZerbleBarn SPI buffers · c2921749
      Vincent Palatin authored
      The ZerbleBarn board is connected behind a 'regular' Yoshi flex,
      in order to get the SPI1 flex buffers to work, we need to instantiate
      properly the flex configuration.
      
      BUG=b:67081508
      TEST=run servod with 'sudo servod -b zerblebarn -c zerblebarn_inas.xml'
      dut-control spi1_buf_on_flex_en:on (or off) does change the OE_N pin on
      U18 on the servo flex and the ZerbleBarn board is detecting the CS_L change.
      
      Change-Id: Icb404f3bc728a65b3ee14af1ba44af3ef8874846
      Reviewed-on: https://chromium-review.googlesource.com/860378
      Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
      Tested-by: default avatarVincent Palatin <vpalatin@chromium.org>
      Reviewed-by: default avatarTodd Broch <tbroch@chromium.org>
      c2921749
  8. 10 Jan, 2018 1 commit
  9. 06 Jan, 2018 1 commit
  10. 05 Jan, 2018 1 commit
  11. 03 Jan, 2018 1 commit
  12. 28 Dec, 2017 1 commit
  13. 19 Dec, 2017 2 commits
  14. 16 Dec, 2017 1 commit
    • Wai-Hong Tam's avatar
      cros_ec_softrec_power: Don't warm reset if it can't hold AP · accced2b
      Wai-Hong Tam authored
      The procedure of power_state:rec does a warm_reset:on to hold AP before
      doing the whole system reboot (cold_reset/PMIC-reset) and setting EC
      hostevent for recovery.
      
      However, it doesn't work on some new x86 devices. Even warm_reset is
      ON; AP still powers on and executes the verified-boot sequence, i.e.
       * (vboot) Read the recovery reason from NV storage (e.g. 19 for the
         test firmware_CorruptBothFwSigAB, as it failed to verify the fw
         signature in the previous boot);
       * (vboot) Clear the recovery reason in NV storage, such that it will
         do clear normal boot next time;
       * (servod) Servod performs the whole system reboot and sets the EC
         hostevent for recovery.
       * (vboot) Read the recovery reason from NV storage, i.e. 0;
       * (vboot) As no recovery reason, treats it as manual-triggered
         recovery (recovery reason: 2).
      
      So some of the FAFT tests failed, as the expected recovery reason is
      not matched, 19 -> 2.
      
      A fix to this race condition is not to do warm reset for the devices
      can't hold AP. For devices having the recent EC patch of the command
      'reboot wait-ext' command, it can hold AP off, without the warm_reset.
      
      BUG=b:70573209
      TEST=Ran firmware_CorruptBothFwSigAB and firmware_RollbackFirmware
      passed on Fizz.
      
      Change-Id: Ia8f8ac11704e5c31e195ec6a85665102634a648c
      Reviewed-on: https://chromium-review.googlesource.com/830253
      Commit-Ready: Wai-Hong Tam <waihong@google.com>
      Tested-by: default avatarWai-Hong Tam <waihong@google.com>
      Reviewed-by: default avatarRandall Spangler <rspangler@chromium.org>
      Reviewed-by: default avatarScott Collyer <scollyer@chromium.org>
      accced2b
  15. 15 Dec, 2017 1 commit
  16. 11 Dec, 2017 2 commits
  17. 06 Dec, 2017 1 commit
  18. 30 Nov, 2017 1 commit
  19. 29 Nov, 2017 4 commits
  20. 18 Nov, 2017 1 commit
  21. 16 Nov, 2017 1 commit
    • Scott Collyer's avatar
      servo: Use ec reboot wait-ext for power_state:rec · 701644a7
      Scott Collyer authored
      EC_IN_RW signal is used to determine if the switch to dev mode can be
      safely made. However, EC_IN_RW needs the EC_RST_L line driven low in
      order to be reset. In faft tests that utilize crosEcSoftrecPower
      method, EC_RST_L is not being driven by servo to fix other test
      failures related to keeping EC and AC reboots in sync.
      
      This CL modifies crosEcSoftrecPower to use the wait-ext option when
      initializing an EC reset to to enter recovery mode. If the wait-ext
      option fails, then the command 'reboot ap-off' will be issued.
      
      BUG=b:64603944
      BRANCH=coral
      CQ-DEPEND=I614f9156066d5719601ee43e29c7a064f9bba6e2
      TEST=Ran "/usr/bin/test_that --board=coral <ip addr> firmware_DevMode"
      mutliple times and verified that it passes. Previoulsy, this test
      always fails when the EC is in RW before it starts. Also verified
      platform_ServoPowerStateController_USBPluggedin passed.
      
      Change-Id: I086687c3dd7591460099267880d56ab8265d2e4b
      Signed-off-by: default avatarScott Collyer <scollyer@google.com>
      Reviewed-on: https://chromium-review.googlesource.com/738634
      Commit-Ready: Scott Collyer <scollyer@chromium.org>
      Tested-by: default avatarScott Collyer <scollyer@chromium.org>
      Reviewed-by: default avatarAseda Aboagye <aaboagye@chromium.org>
      701644a7
  22. 15 Nov, 2017 1 commit
    • Todd Broch's avatar
      servo: Deprecate unprogrammed servo V1 boards. · 2e92ed0a
      Todd Broch authored
      servo V1 boards haven't been used for quite some time and of the 50
      ever produced they really should have been programmed properly.
      
      Motivation for performing this deprecation is actually that someone
      recently found an unprogrammed servo V2 which also matches vid:0403
      pid:6011 and incorrectly enumerates as a servo V1 (actually two of
      them).  Chaos ensues from there.  By deprecating this default vid/pid
      that too will be fixed (fail hard).
      
      BUG=none
      TEST=manual,
      # connect one servo V2 that hasn't had EEPROM programmed
      sudo servod -b foo
      log message says 'no servos found'
      
      # connect servo V2 that is properly programmed
      sudo servod -b foo
      WAI
      
      Change-Id: I61fb6b3198297d249903308e7c6cc30eb87c5a0f
      Reviewed-on: https://chromium-review.googlesource.com/764384
      Commit-Ready: Todd Broch <tbroch@chromium.org>
      Tested-by: default avatarTodd Broch <tbroch@chromium.org>
      Reviewed-by: default avatarDaisuke Nojiri <dnojiri@chromium.org>
      2e92ed0a
  23. 13 Nov, 2017 1 commit
  24. 10 Nov, 2017 1 commit
  25. 09 Nov, 2017 1 commit
  26. 04 Nov, 2017 1 commit
  27. 31 Oct, 2017 1 commit
  28. 27 Oct, 2017 1 commit
  29. 25 Oct, 2017 1 commit
  30. 24 Oct, 2017 1 commit