summaryrefslogtreecommitdiff
path: root/chip/stm32/system.c
Commit message (Collapse)AuthorAgeFilesLines
* chip/stm32: Add initial support for STM32L5xx seriesJes B. Klinke2021-08-251-2/+16
| | | | | | | | | | | | | | | | Introduce L5xx mostly as copy of L4xx, though registers-stm32l5.c is extensively modified. BUG=b:192262089 TEST=Compile and upload board/hyperdebug to Nucleo board BRANCH=none Signed-off-by: Jes B. Klinke <jbk@opentitan.org> Change-Id: Iccc7b05e4f2dfa732559b8099cf856882401e31c Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/3086362 Tested-by: Jes Klinke <jbk@chromium.org> Reviewed-by: Scott Collyer <scollyer@chromium.org> Commit-Queue: Jes Klinke <jbk@chromium.org>
* system: fix system_get_scratchpad APIYuval Peress2021-08-201-2/+3
| | | | | | | | | | | | | | | The current API for system_get_scratchpad mixes the status and the value being read. Update the signature to allow both. BRANCH=none BUG=b:195481980 TEST=make testall && zmake testall Signed-off-by: Yuval Peress <peress@chromium.org> Change-Id: I3a5f5ad523d507c53a5d474806f58afafb82e70c Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/3074828 Commit-Queue: Denis Brockus <dbrockus@chromium.org> Reviewed-by: Denis Brockus <dbrockus@chromium.org>
* stm32: add stm32l431 ec in chip/stm32 : flashBossen WU2021-07-011-2/+2
| | | | | | | | | | | | | | | stm32l431 related driver: flash-stm32g4-l4.c system.c The stm32l476g-eval is the only board which would be possibly impacted. BRANCH=main BUG=b:188117811 TEST=make buildall Signed-off-by: Bossen WU <bossen.wu@stmicro.corp-partner.google.com> Change-Id: I273954c75651b20de58db53eba7e7d0e4553763d Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2978652 Reviewed-by: Ting Shen <phoenixshen@chromium.org> Reviewed-by: Eric Yilun Lin <yllin@google.com>
* stm32: add stm32l431 ec in chip/stm32 : system / clock / timerBossen WU2021-06-301-0/+16
| | | | | | | | | | | | | | stm32l431 related driver: system / clock / timer. The stm32l476g-eval is the only board which would be impacted. BRANCH=main BUG=b:188117811 TEST=make buildall Signed-off-by: Bossen WU <bossen.wu@stmicro.corp-partner.google.com> Change-Id: Idf335005d8188f6959835aa40179a6bd771c5114 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2905165 Reviewed-by: Eric Yilun Lin <yllin@google.com>
* stm32/system: Disable caches before rebootPatryk Duda2021-06-101-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Affected boards (only STM32H7): - nocturne_fp (dartmonkey) - nucleo-h743zi This fixes problem with jumping to RW when reboot to RO was requested. Log from reproduction on dartmonkey (only relevant parts): --- UART initialized after reboot --- [Image: RO, dartmonkey_v2.0.8961+9a30ce07ee] [Reset cause: reset-pin power-on soft ap-off] ... [1.045743 Jumping to image RW] *** We are in RW. Jump data are initialized and contains correct *** set of reset flags. Reset flags from backup RAM are cleared. reset flags from chip: unknown reset flags from jump data: reset-pin power-on soft sysjump ap-off [1.056198 UART initialized after sysjump] [Image: RW, dartmonkey_v2.0.8961+9a30ce07ee] [Reset cause: reset-pin power-on soft sysjump ap-off] ... > > reboot ro reboot ro Rebooting! *** Now we are in RO. RW saved reset cause in backup RAM (with *** stay-in-ro). Please note that RO also finds jump data and *** report that was sysjump! reset flags from chip: reset-pin power-on soft ap-off stay-in-ro reset flags from jump data: reset-pin power-on soft sysjump ap-off [1.056198 UART initialized after sysjump] [Image: RO, dartmonkey_v2.0.8961+9a30ce07ee] [Reset cause: reset-pin power-on soft sysjump ap-off] When RO is doing sysjump to RW, jump data structure is created in jump_to_image() function. The structure contains information about reset flags. When RW finds jump data in system_common_pre_init() magic field of the structure is set to zero to prevent detecting sysjump accidentally. Nevertheless, when reboot to RO is requested, RO is able to find the structure. As a result, correct reset flags from backup RAM are overwritten by incorrect reset flags from jump data. This happens because we are not flushing D-cache before reboot. All changes in RW which lives in cache (not saved in RAM) will be lost after reboot because cache is always disabled (even if it was previously enabled and we didn't turned it off). To enable cache we need to invalidate it first (see cpu_enable_caches()). Issue reproduces also with debugger connected, except situation when watchpoint is set on jump data magic field. BUG=b:170432597 b:188934337 BRANCH=none TEST=Compile dartmonkey firmware and run it on eg. icetower. In RW, issue 'reboot ro'. Make sure that jump to RO is not performed. TEST=Run flash_write_protect hardware unit test on icetower board using `./test/run_device_tests.py --board dartmonkey \ --tests flash_write_protect` Make sure that after reboot to RO, 'stay-in-ro' reset cause is printed Signed-off-by: Patryk Duda <pdk@semihalf.com> Change-Id: If56153a1a3ac7ae05700eac9ca60e398cf35f182 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2922145 Reviewed-by: Craig Hesling <hesling@chromium.org>
* include/flash: rename the APIsTim Lin2021-06-091-1/+1
| | | | | | | | | | | | | | | | The names conflict when enabling both Zephyr's flash driver and CONFIG_FLASH_CROS option. Rename all the APIs in include/flash.h BUG=b:187192628 BRANCH=none TEST=make buildall -j4 Signed-off-by: Tim Lin <tim2.lin@ite.corp-partner.google.com> Change-Id: If1fd0ea28fa9f5cec1c1daa8f72f63eb7a0e6500 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2931749 Commit-Queue: Keith Short <keithshort@chromium.org> Reviewed-by: Keith Short <keithshort@chromium.org> Reviewed-by: Denis Brockus <dbrockus@chromium.org>
* stm32/system: Wait for RVU bit clear before updating IWDG_RLRPatryk Duda2021-05-261-1/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | EC is not waiting for IWDG_RLR value to be updated in watchdog_init() function. It's intended behaviour because updating value can take much time (even 48ms) which is not desired during initialization. It's also allowed by documentation too: RM0433 Rev 7 Section 45.4.4 Page 1920 https://www.st.com/resource/en/reference_manual/dm00314099.pdf If several reload, prescaler, or window values are used by the application, it is mandatory to wait until RVU bit is reset before changing the reload value, to wait until PVU bit is reset before changing the prescaler value, and to wait until WVU bit is reset before changing the window value. However, after updating the prescaler and/or the reload/window value it is not necessary to wait until RVU or PVU or WVU is reset before continuing code execution except in case of low-power mode entry. Documentation clearly states that before next Reload Register update we are obligated to wait until RVU bit in IWDG_SR register is cleared. Setting IWDG_RLR register when RVU bit is set causes new value to be ignored. This is exactly the behaviour observed while running flash_write_protect hardware unit test. Time of Step 2 execution is short enough to perform hard reboot (all reboots between test steps are hard) when RVU bit is set. As a result setting IWDG_RLR to 1 is ignored and watchdog is reloaded with old value. This is why it takes very long to perform hard reset and watchdog trace is printed. Platforms affected by this change: STM32H7: nocturne_fp (dartmonkey) nucleo-h743zi STM32F4: hatch_fp (bloonchipper) nucleo-f411re nucleo-f412zg polyberry sweetberry stm32f446e-eval BUG=b:170432597 BRANCH=none TEST=Run flash_write_protect hardware unit test on icetower board using `./test/run_device_tests.py --board dartmonkey \ --tests flash_write_protect` Make sure that test passes and no watchdog traces appear. TEST=Run flash_write_protect hardware unit test on dragonclaw 0.2 board using `./test/run_device_tests.py --board bloonchipper \ --tests flash_write_protect` Make sure that test passes and no watchdog traces appear. Signed-off-by: Patryk Duda <pdk@semihalf.com> Change-Id: I2585dcbf3cb1a14107c7ae674c51999f082e3df7 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2917115 Reviewed-by: Craig Hesling <hesling@chromium.org>
* stm32g4: Add USB endpoint supportScott Collyer2021-03-041-1/+8
| | | | | | | | | | | | | | | | | | | This CL enables USB-EP for the STM32G4 family. It also fixes backup domain register access issues which are required for fw updates via USB. BUG=b:148493929 BRANCH=None TEST=Verified on quiche that STM32G4 enumerates as an USB endpoint and can be used successfully with fwupd. Signed-off-by: Scott Collyer <scollyer@google.com> Change-Id: I75e6b6e70e9ca2589ace76f0aa0facadd9e94142 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2268139 Tested-by: Scott Collyer <scollyer@chromium.org> Reviewed-by: Aseda Aboagye <aaboagye@chromium.org> Reviewed-by: Diana Z <dzigterman@chromium.org> Commit-Queue: Scott Collyer <scollyer@chromium.org>
* panicinfo: fix panicinfo double reportEric Yilun Lin2021-03-041-2/+7
| | | | | | | | | | | | | | | | | | | | | | Panicinfo is double report due to the panic flags is reset whenever a hard-reset triggered. This makes AP thinks there is a new panic happened, and reports it to the crashmon. We've seen a lot of crash reports due to the false alarms. The solution is recording the panic flags across hard-reset so we won't keep alarming the old panicinfo. BUG=b:181108236 TEST=1)test that on juniper with new EC RO/RW, and AP reboot won't cause the EC alarming a new panicinfo. 2)test that on juniper with soft-sync RW, and old RO, and AP reboot won't cause the EC alarm a new panicinfo BRANCH=kukui Change-Id: I6e0c33a1fcf210d9aa03ebd1cd79b84a7744c386 Signed-off-by: Eric Yilun Lin <yllin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2721327 Reviewed-by: Ting Shen <phoenixshen@chromium.org>
* stm32: assume no vbnvJack Rosenthal2021-02-031-2/+0
| | | | | | | | | | | | | | | | | | CONFIG_HOSTCMD_VBNV_CONTEXT is deprecated and removed. Cleanup preprocessor statements to assume it's never defined. This makes CONFIG_STM32_RESET_FLAGS_EXTENDED obsolete, since it's now always defined, so that gets removed too. BUG=b:178689388 BRANCH=none TEST=buildall Signed-off-by: Jack Rosenthal <jrosenth@chromium.org> Change-Id: Id040ce2ceca95ecde37de0014aafdbfd3087e00d Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2668688 Reviewed-by: Edward Hill <ecgh@chromium.org> Reviewed-by: Craig Hesling <hesling@chromium.org>
* version: Rename version.h to cros_version.hYuval Peress2021-01-071-1/+1
| | | | | | | | | | | | | | | This change simply moves the include/version.h file over to avoid a naming collision with zephyr's version.h. BRANCH=none BUG=b:167392037 TEST=make buildall -j Signed-off-by: Yuval Peress <peress@chromium.org> Change-Id: Ib41b3c21817d5f81e713d3b550bc46a0d1c55cf8 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2612772 Reviewed-by: Jack Rosenthal <jrosenth@chromium.org> Commit-Queue: Jack Rosenthal <jrosenth@chromium.org>
* stm32g4: Modifications required for system.cScott Collyer2020-07-291-1/+15
| | | | | | | | | | | | | | | | | This CL updates stm32 specific system.c for the stm32g4 chip family. A comment was added to clarify what's required for enabling the backup domain. In addition, debug mode and detection of a warm boot. BUG=b:148493929 BRANCH=None TEST=verfied that the GPIO, clocks, and EC console over LPUART Signed-off-by: Scott Collyer <scollyer@google.com> Change-Id: I8b5063419ae6dc1be165b8bb3754703c1e728ae9 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2195544 Tested-by: Scott Collyer <scollyer@chromium.org> Commit-Queue: Scott Collyer <scollyer@chromium.org> Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
* chip/stm32: Save STAY_IN_RO flag if set during resetTom Hughes2020-05-141-0/+4
| | | | | | | | | | | | | | | This matches the behavior of system_encode_save_flags() and allows us to reboot into RO for testing. BRANCH=none BUG=b:156401765 TEST=make buildall -j Signed-off-by: Tom Hughes <tomhughes@chromium.org> Change-Id: Ibbb95ca81fb87eaa48639dea99be1bd0e35ea230 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2197621 Reviewed-by: Nicolas Boichat <drinkcat@chromium.org> Reviewed-by: Craig Hesling <hesling@chromium.org>
* stm32: Add chip_read_reset_flags and chip_save_reset_flagsDaisuke Nojiri2020-05-061-3/+13
| | | | | | | | | | | | | | | | | | | | | Battery backed up RAM is used to store the reset flags. This patch wraps the code reading and writing the reset flags with APIs for the consistency and make it available to external callers. Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> BUG=chromium:1078470 BRANCH=none TEST=buildall Change-Id: Ica31008b8f0f89f6804002c2c796e3b3c117e06a Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2182563 Commit-Queue: Daisuke Nojiri <dnojiri@chromium.org> Tested-by: Daisuke Nojiri <dnojiri@chromium.org> Auto-Submit: Daisuke Nojiri <dnojiri@chromium.org> Reviewed-by: Craig Hesling <hesling@chromium.org>
* cleanup: move voltage rail detection to commonJett Rink2020-02-251-3/+17
| | | | | | | | | | | | | | Single source the VDD rail sagging reset interrupt Add VDD detection to C2D2 as well. BRANCH=servo BUG=none TEST=builds Change-Id: Iceac7d9fa7a9bde5a3c23c36e63b6d635d8812a3 Signed-off-by: Jett Rink <jettrink@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2064593 Reviewed-by: Diana Z <dzigterman@chromium.org>
* nocturne_fp: Add fix for legacy reset loopCraig Hesling2020-02-061-16/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch mitigates an infinite reset loop caused by an RO bug. The reset occurs in RO when hardware write protect (wp_gpio_asserted) is disabled, but software write protect (ro_now) is still enabled. This can be seen by disabling hardware write protect and issuing a soft reset. There is one case where RO will forgo issuing this system reset. That is when it detects a power on reset. Furthermore, it retrieves its reset flags from the main system_get_reset_flags function, which combines hardware reset registers AND a special RTC backup register designed to preserve reset flags. We exploit this reset backup register mechanism to inject a fake power-on flag before resetting. As an added bonus, we also inject an ap-off flag so that we can determine on startup if the power-on flag is real or forged by this mechanism. If we detect that the power-on flag was forged, we print a warning and fix the current reset flags. In order to ensure that a power-on will be forged when a spurious reset happens (exception or pin reset), we keep the backup register loaded with the power-on and ap-off reset flags, when the hardware write protect is disabled. In order to keep the typical code path (HW+SW WP enabled) clear of complexity and false power-on reports, we only forge the power-on flag when hardware write protect is disabled. Thus, we conditionally setup the forge on startup and setup an interrupt handler to catch changes to the hardware write protect status. It is safe to use ap-off flag for our nefarious purposes, since the fingerprint controller has no functionality to control an AP and has no included code that uses this reset flag. Review: * Normal power on reset --> The ap-off flag should be cleared * Forged power on reset --> We set the ap-off flag Scenarios covered: * True power on --> No reset loop and ap-off would not be set * HW reset pulse --> We preloaded ap-off and power-on flags in the reset backup register * Exception/Watchdog --> Same as above * System reboot --> We modified the system_reset function to add ap-off and power-on to reset backup register BRANCH=nocturne,hatch BUG=b:146428434 TEST=make buildall -j TEST=Checked all of the scenarios mentioned above in the [SW-WP off + HW-WP off], [SW-WP on + HW-WP on], and [SW-WP on + HW-WP off] situations using the nucleo-h743zi board (https://crrev.com/c/1994624). TEST=Checked all of the previous using nocturne_fp board on nucleo-h743zi TEST=Checked stable RO+fixed-RW on Kohaku Change-Id: I89361fa95be8eafe78c80c30f5b3195d7a724f81 Signed-off-by: Craig Hesling <hesling@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1992740 Reviewed-by: Tom Hughes <tomhughes@chromium.org>
* chip/stm32: Stop timers and watchdogs on STM32F4 when debuggingCraig Hesling2020-01-211-1/+8
| | | | | | | | | | | | | BRANCH=none BUG=none TEST=make buildall -j TEST=Attach SWD to dragonclaw v0.2 Change-Id: I7bd5741c4862bb2f134ae3067715d2301a18ea78 Signed-off-by: Craig Hesling <hesling@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1962974 Reviewed-by: Jett Rink <jettrink@chromium.org> Tested-by: Tom Hughes <tomhughes@chromium.org>
* ServoMicro: Enable Brownout detection with PVD circuitBrian J. Nemec2020-01-181-0/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Enables the programmable voltage detector (PVD) interrupt in ServoMicro. This interrupt fires when the supply voltage drops from the expected 3.3V to under 2.3V after power on. This gives several hundred microseconds of time for the device to respond to the power reduction. In order to ensure that the ServoMicro does not enter a non-responsive state, it triggers a reboot of the system to restore it to a good configuration. BRANCH=servo BUG=chromium:1023715 TEST=Configured GPIO output to trigger on pvd_interrupt() and verified the interrupt fires during the following situations using Saleae analyzer: * USB Power removed from working device * Ramping supply voltage from 1.5V to 5V with a DC supply * Repoducing failure condition from crbug/1016051 1 Connect ServoMicro to Cyan board 2 dut-control power_state:on 3 dut-control fw_wp_vref:pp3300 4 dut-control power_state:off 5 GPIO toggles and system reset occurs Change-Id: I721f48ab84b01d52a5f98747cc9d879ff2876a07 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1911759 Reviewed-by: Ruben Rodriguez Buchillon <coconutruben@chromium.org> Tested-by: Brian Nemec <bnemec@chromium.org> Commit-Queue: Brian Nemec <bnemec@chromium.org> Auto-Submit: Brian Nemec <bnemec@chromium.org>
* stm32: Factor our bkpdata functionalityCraig Hesling2020-01-151-117/+1
| | | | | | | | | | | | | | | | | | | | | This commit simply refactors the bkpdata functionality, common to all stm32s, into its own source and header files. Same code, different place. This allows for the use of stm32 backup register functionality outside of stm32/system.c. The targeted usage is in https://crrev.com/c/1992740 , a bug fix that is limited to a board's scope. BRANCH=nocturne,hatch BUG=b:146428434 TEST=make buildall -j TEST=Ensured that reset flag preservation works across resets. Change-Id: Id2ba570949e0e7bb3a1faf64e625e122aa3b4ed5 Signed-off-by: Craig Hesling <hesling@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1992488 Reviewed-by: Jett Rink <jettrink@chromium.org>
* core/system: Extract and doc cortex constCraig Hesling2020-01-131-1/+3
| | | | | | | | | | | | | | | | | | | | | | BRANCH=none BUG=none TEST=make buildall -j TEST=make BOARD=nucleo-h743zi # Reboot H743 into bootloader using boot0 pin and reset # Flash nucleo over FTDI and STM32 bootloader stm32mon -u -U -w build/nucleo-h743zi/ec.bin -d /dev/ttyUSB0 -b 115200 # Reset without boot0 # Open console minicom -D/dev/ttyACM0 reboot soft # Verify soft reset was used reboot hard # Verify hard reboot was used Change-Id: If211198b853ad97cb96b39c063d3e04bfce68179 Signed-off-by: Craig Hesling <hesling@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1988232 Reviewed-by: Jett Rink <jettrink@chromium.org>
* chip/stm32/system: Fix the BUILD_ASSERT for CONFIG_USB_PD_PORT_MAX_COUNTKarthikeyan Ramasubramanian2019-11-091-1/+1
| | | | | | | | | | | | | | | | | Some boards have CONFIG_USB_PD_PORT_MAX_COUNT defined as 3. Fix the concerned build assert. BUG=None BRANCH=None TEST=make -j buildall; Boot to ChromeOS in bobba(2A + 2C config) and garg(2A + 1C + 1HDMI config). Change-Id: I4dc949b69dbb3986acc5aa0444c6056268f815f7 Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1898686 Tested-by: Karthikeyan Ramasubramanian <kramasub@chromium.org> Commit-Queue: Karthikeyan Ramasubramanian <kramasub@chromium.org> Reviewed-by: Jett Rink <jettrink@chromium.org>
* stm32f4: Enable gpio port clocks that are usedCraig Hesling2019-11-081-1/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We can reduce the power draw of the MCU by limiting which GPIO port clocks are enabled. This CL uses the gpio.inc to determine the minimal set of GPIO ports that need to be enabled/clocked. Only these ports have their clocks enabled at boot. Other stm32 chip variants in EC simply enabled all GPIO port clocks at boot init. Thank you to Ravi Chandra Sadineni for identifying this optimization and validating. For more context, see crrev.com/c/1888116, which this CL replaces. BRANCH=nocturne,hatch BUG=b:130561737 TEST=make buildall -j TEST=make BOARD=bloonchipper # Connect dragonclaw dev board over servo micro sudo servod --board=bloonchipper --config bloonchipper_rev0.1.xml & ./util/flash_ec --board=bloonchipper minicom -D $(dut-control raw_fpmcu_uart_pty | cut -d: -f2) > sysinfo # Check that we are in RW Signed-off-by: Craig Hesling <hesling@chromium.org> Change-Id: Iad51b11eb5959b5d502320560b9ebda7e614d97e Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1890924 Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
* Rename CONFIG_USB_PD_PORT_COUNT as CONFIG_USB_PD_PORT_MAX_COUNTKarthikeyan Ramasubramanian2019-11-011-1/+1
| | | | | | | | | | | | | | | | | Certain SKUs of certain boards have lesser number of USB PD ports than defined by CONFIG_USB_PD_PORT_COUNT. Hence rename CONFIG_USB_PD_PORT_COUNT as CONFIG_USB_PD_PORT_MAX_COUNT. BUG=b:140816510, b:143196487 BRANCH=octopus TEST=make -j buildall; Boot to ChromeOS Change-Id: I7c33b27150730a1a3b5813b7b4a72fd24ab73c6a Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1879337 Tested-by: Karthikeyan Ramasubramanian <kramasub@chromium.org> Reviewed-by: Jett Rink <jettrink@chromium.org> Commit-Queue: Jett Rink <jettrink@chromium.org>
* cleanup: fix byte access and ifdefs for BBRAM_PD2Jett Rink2019-09-301-0/+3
| | | | | | | | | | | | | | Ensure that PD2 is accessed as a single byte instead of 4 bytes and remove unnecessary ifdef guards in all chip implementations. BRANCH=none BUG=none TEST=builds Change-Id: I319d8d6a8456662235ab4d8dcda6bda7e8ed7c15 Signed-off-by: Jett Rink <jettrink@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1809938 Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
* include: Move RESET_FLAG_* into ec_commands.h as EC_RESET_FLAG_*You-Cheng Syu2019-08-261-13/+13
| | | | | | | | | | | | | | | | | | | | | | | RESET_FLAGS_* are used when setting/reading the field ec_reset_flags of struct ec_response_uptime_info, which is defined in ec_commands.h. So it might be better to put those macros there. To be consistent with the other macros in the file, add "EC_" prefixes to them. BUG=b:109900671,b:118654976 BRANCH=none TEST=make buildall -j Cq-Depend: chrome-internal:1054910, chrome-internal:1054911, chrome-internal:1045539 Change-Id: If72ec25f1b34d8d46b74479fb4cd09252102aafa Signed-off-by: You-Cheng Syu <youcheng@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1520574 Tested-by: Yu-Ping Wu <yupingso@chromium.org> Commit-Ready: Yu-Ping Wu <yupingso@chromium.org> Legacy-Commit-Queue: Commit Bot <commit-bot@chromium.org> Reviewed-by: Yilun Lin <yllin@chromium.org> Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
* stm32: Make sure watchdog is enabled when using it to resetTom Hughes2019-07-101-0/+30
| | | | | | | | | | | | | | | | | | | | | On hatch (using hatch_fp), the watchdog appears to never fire when issuing the following commands: ectool --name=cros_fp flashprotect enable ectool --name=cros_fp reboot_ec Adding the explicit enable of the watchdog here fixes that. BRANCH=none BUG=b:137045370 TEST=On hatch: ectool --name=cros_fp flashprotect enable ectool --name=cros_fp reboot_ec Change-Id: Ib42b67a2c88a5c11e3064523d74c9ded51f71379 Signed-off-by: Tom Hughes <tomhughes@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1692078 Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
* LICENSE: remove unnecessary (c) after CopyrightTom Hughes2019-06-191-1/+1
| | | | | | | | | | | | | | | | Ran the following command: git grep -l 'Copyright (c)' | \ xargs sed -i 's/Copyright (c)/Copyright/g' BRANCH=none BUG=none TEST=make buildall -j Change-Id: I6cc4a0f7e8b30d5b5f97d53c031c299f3e164ca7 Signed-off-by: Tom Hughes <tomhughes@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1663262 Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org> Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
* common: replace 1 << digits, with BIT(digits)Gwendal Grignou2019-03-261-6/+6
| | | | | | | | | | | | | | | | Requested for linux integration, use BIT instead of 1 << First step replace bit operation with operand containing only digits. Fix an error in motion_lid try to set bit 31 of a signed integer. BUG=None BRANCH=None TEST=compile Change-Id: Ie843611f2f68e241f0f40d4067f7ade726951d29 Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1518659 Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
* system: Remember if reset was due to AP watchdog triggeringNicolas Boichat2018-10-291-0/+32
| | | | | | | | | | | | | | | | | On MT8183, when EC detects a watchdog reset, EC needs to reboot itself in preparation for the next boot. This means that AP loses the reset cause (as AP system reset is toggled), and, therefore, we need to save the reset reason in the EC. BRANCH=none BUG=b:109900671 TEST=apshutdown, powerb, see that reset reason is: reset-pin TEST=Use test-wd from bug. Reset reason: reset-pin ap-watchdog Change-Id: I2e30306db5727a22de930f00dc30de40b9695bef Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1295890 Reviewed-by: Jett Rink <jettrink@chromium.org>
* stm32/system: Fix watchdog-initiated resetNicolas Boichat2018-07-131-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Reference Manuals for STM32H7 and STM32F4 makes it clear that, when updating the watchog reload value, one needs to wait until IWDG_SR bit RVU is reset before reloading the watchdog. (the code in question is only used on STM32H7 and STM32F4, as other variants use OBL_LAUNCH to reset themselves, so I didn't check the other RMs). This probably has not been seen before, as, normally, we use a 1s watchdog timeout, so the EC would reset anyway after a second (since it is stuck in the while loop below). On meowth_fp, however, we use a 10 seconds watchdog, and the EC takes too _long_ time to reboot, which breaks things like flashrom. BRANCH=none BUG=b:111144409 TEST=On nocturne_fp, run: for i in `seq 1 1000`; do echo $i; \ ./ectool --name=cros_fp reboot_ec cold; sleep 1; done No watchdog warning, no error. Change-Id: I110fa9873ed974bfafce23389866aac8cabb662a Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1134631 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* cortex-m: add D-cache supportVincent Palatin2018-06-041-4/+0
| | | | | | | | | | | | | | | | | | | | Add support to enable the architectural D-cache on ARMv7-M CPU supporting it. Update the MPU code in order to be able to declare an 'uncached' RAM region (e.g. to store the DMA buffer). Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=poppy BUG=b:78535052, b:75068419 TEST=with the following CL, on ZerbleBarn, boot and capture a finger image. Change-Id: I275445e7c0b558cedc3e7d6fc6840ff9b4b76285 Reviewed-on: https://chromium-review.googlesource.com/1032776 Commit-Ready: Vincent Palatin <vpalatin@chromium.org> Tested-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
* stm32: implement reboot wait-extNick Sanders2018-04-101-0/+9
| | | | | | | | | | | | | | This was missed on stm32, but is helpful for servod to work reliably. BUG=b:77830536 TEST=it waits 10 sec for external reboot. Change-Id: Ic4c905846c41b43f3b8542d70e021744716bd0c2 Signed-off-by: Nick Sanders <nsanders@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1004437 Reviewed-by: Aseda Aboagye <aaboagye@chromium.org> Reviewed-by: Scott Collyer <scollyer@chromium.org>
* cortex-m: enable I-cache on ARMv7-MVincent Palatin2018-03-021-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The ARMv7-M ISA defines standard (and optional) mechanism to manage the CPU caches through the SCB (System Control Block) registers. So far, only the Cortex-M7 core implements such as a mechanism (e.g. the Cortex-M4 with caches we have are using a proprietary mechanism for the management). Define the functions to use the I-Cache, and enable them on STM32H7 which is our only supported Cortex-M7 core. The D-Cache mechanism is still To Be Done, as it involves a bit more support in the firmware for the DMA memory areas. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=none BUG=b:67081508 TEST=on ZerbleBarn, verify manually that the 'IC' bit is set in the CCR (e.g. 'rw 0xe000ed14' returns 0x60218), and runs some CPU workload without crash and with a speed-up. Change-Id: I6af1021d65048b787630387f7d95797db15d069c Reviewed-on: https://chromium-review.googlesource.com/943445 Commit-Ready: Vincent Palatin <vpalatin@chromium.org> Tested-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* stm32: fix RTC configuration on STM32H7Vincent Palatin2018-03-021-2/+0
| | | | | | | | | | | | | | | | | | The DBP bit needs to be set in the PWR_CR1 register before doing the RTC configuration (in order to be able to right RTC registers). Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=none BUG=b:67081508 TEST=on ZerbleBarn, dump the RTC_TR register and it is incrementing every second, e.g. 'rw 0x58004000'. Change-Id: I02dc6c6f1852ced934bccf3e401f4fdc1aad57d9 Reviewed-on: https://chromium-review.googlesource.com/941224 Commit-Ready: Vincent Palatin <vpalatin@chromium.org> Tested-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
* stm32: trigger watchdog hard reset immediatelyVincent Palatin2018-02-261-2/+2
| | | | | | | | | | | | | | | | | | | | | | When using the watchdog (IWDG) to perform the cold reset, set the Key register to 'RELOAD' (0xAAAA) rather than 'START' (0xCCCC) to ensure that the reset is performed immediately rather than at the end of the current watchdog period (which might be 1 to 5s away). Replace the Key register special values by their symbolic constants. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=none BUG=b:67081508 TEST=On ZerbleBarn using a STM32H7, run 'ectool reboot_ec cold' and see the MCU rebooting immediately rather than after 5s. Change-Id: Ib49c703e3ec973389e4d774eda53f3be7ec4dd2e Reviewed-on: https://chromium-review.googlesource.com/936764 Commit-Ready: Vincent Palatin <vpalatin@chromium.org> Tested-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
* stm32: Fix bkpdata accountingShawn Nematbakhsh2018-01-301-10/+26
| | | | | | | | | | | | | | | | | | stm32f0 has 20 bytes (not 20 words) of VBAT-backed RAM. Make more efficient use of our limited storage to prevent trying to use storage that doesn't exist. BUG=b:71333840 BRANCH=None TEST=Negotiate PD, run "reboot" on scarlet EC console, verify reset path is taken in pd_partner_port_reset(). Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org> Change-Id: Ie4c303b74a1b82b84ec971cdcc19c2b21a0032e7 Reviewed-on: https://chromium-review.googlesource.com/885461 Commit-Ready: Shawn N <shawnn@chromium.org> Tested-by: Shawn N <shawnn@chromium.org> Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* stm32: Add STM32H7 familyVincent Palatin2018-01-081-11/+24
| | | | | | | | | | | | | | | | | | Start adding support for the STM32H7 family of device and the first available one the STM32H743. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=none BUG=b:67081508 TEST=manual, run on stm32h743i-eval and zerblebarn boards get a stable serial console. Change-Id: I9ae10f0d843e5318451713c21ed22d455a23758c Reviewed-on: https://chromium-review.googlesource.com/806168 Commit-Ready: Vincent Palatin <vpalatin@chromium.org> Tested-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Shawn N <shawnn@chromium.org>
* stm32: jtag: Enable clock to debug module on stm32f0xMoritz Fischer2017-11-151-0/+3
| | | | | | | | | | | | | | | Enables the clock to the debug module so that when connecting via SWD debugger the watchdog and timers are stopped. BRANCH=master TEST=Build on stm32f0x board and connect via SWD, observe no watchdog reset. Change-Id: Ic40b16c09acc5920da2c1a39e9391a6b21849d2c Signed-off-by: Moritz Fischer <moritz.fischer@ettus.com> Reviewed-on: https://chromium-review.googlesource.com/765290 Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* chip/stm32/clock: Optionally use LSE as RTCCLKPhilip Chen2017-10-111-6/+26
| | | | | | | | | | | | | | | | | | | | The default RTCCLK comes from LSI, which can vary from 30kHz to 60kHz. To use stm32 RTC for applications requiring accurate timing, let's setup LSE (a more accurate clock source) as RTCCLK. Also fix a typo in register.h as 'BCDR' should be 'BDCR' globally. BUG=b:63908519 BRANCH=none TEST=boot scarlet rev1 and wait for an hour, confirm rtc time == kernel system time. Change-Id: If4728bdd3b6384316e5337004a49c172eaec869d Signed-off-by: Philip Chen <philipchen@google.com> Reviewed-on: https://chromium-review.googlesource.com/679601 Commit-Ready: Philip Chen <philipchen@chromium.org> Tested-by: Philip Chen <philipchen@chromium.org> Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* cleanup: Remove jtag_pre_init()Shawn Nematbakhsh2017-09-071-0/+41
| | | | | | | | | | | | | | | Use our newly-created chip_pre_init() for doing JTAG initialization. BUG=chromium:747629 BRANCH=None TEST=`make buildall -j` Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org> Change-Id: Ic5771895a214a9f1aa9bd289eef576f52adf973f Reviewed-on: https://chromium-review.googlesource.com/629676 Commit-Ready: Shawn N <shawnn@chromium.org> Tested-by: Shawn N <shawnn@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* stm32: Add function to fetch unique idNicolas Boichat2017-06-121-0/+6
| | | | | | | | | | | | | | BRANCH=none BUG=b:62280271 TEST=Flash hammer lsusb -d 18d1:5022 -v -v | grep iSerial shows different chip IDs on different boards. Change-Id: Id56b4509f184eb722d04fef94079c150dc2016e2 Reviewed-on: https://chromium-review.googlesource.com/523044 Commit-Ready: Nicolas Boichat <drinkcat@chromium.org> Tested-by: Nicolas Boichat <drinkcat@chromium.org> Reviewed-by: Nick Sanders <nsanders@chromium.org>
* stm32: cleanup flash-f by using constant from register.hGwendal Grignou2017-06-021-1/+1
| | | | | | | | | | | | | | Use constants from registers.h, to easily support other ECs. Fix indentation in registers.h BRANCH=none TEST=compile + following patches tested on STM32F411 BUG=None Change-Id: Iecb3ce759a5c4ff13463e7df1cb7e03fc1ce6f69 Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/264030 Reviewed-by: Alexandru M Stan <amstan@chromium.org>
* Revert "system: Shutdown AP before entering hibernate mode"Duncan Laurie2017-04-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 20c439be209a9cc0bb949ad21f289c453126395f. Reason for revert: This breaks hibernate on skylake boards and needs to be tested on more than just kevin before submitting. BUG=chromium:702451 BRANCH=none TEST=power down and successfully hibernate on Eve Original change's description: > system: Shutdown AP before entering hibernate mode > > BUG=chromium:702451 > BRANCH=none > TEST=manually test on gru: confirm > 'Alt+VolUp+h' puts gru in hibernate mode and > AC plug-in wakes it up. > > Change-Id: I3e1134b866dea5d3cc61f9b3dad31c3ff0bd9096 > Reviewed-on: https://chromium-review.googlesource.com/470787 > Commit-Ready: Philip Chen <philipchen@chromium.org> > Tested-by: Philip Chen <philipchen@chromium.org> > Reviewed-by: Aseda Aboagye <aaboagye@chromium.org> > TBR=rspangler@chromium.org,aaboagye@chromium.org,philipchen@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. BUG=chromium:702451 Change-Id: Ie847a5e3efb28256b00ddc6534d8ae6bbbba7121 Reviewed-on: https://chromium-review.googlesource.com/482989 Commit-Ready: Duncan Laurie <dlaurie@chromium.org> Tested-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-by: Philip Chen <philipchen@chromium.org> Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
* system: Shutdown AP before entering hibernate modePhilip Chen2017-04-141-1/+1
| | | | | | | | | | | | | | BUG=chromium:702451 BRANCH=none TEST=manually test on gru: confirm 'Alt+VolUp+h' puts gru in hibernate mode and AC plug-in wakes it up. Change-Id: I3e1134b866dea5d3cc61f9b3dad31c3ff0bd9096 Reviewed-on: https://chromium-review.googlesource.com/470787 Commit-Ready: Philip Chen <philipchen@chromium.org> Tested-by: Philip Chen <philipchen@chromium.org> Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
* stm32: add internal flash support for STM32L4 familyVincent Palatin2017-03-241-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a flash driver for the STM32L4 family. For write and erase, the code is very similar to other variants excepted the 'normal' writes need to be perform 2 aligned 32-bit words at a time. Option bytes are a sligthly easier business since the hardware deals with the option bytes page preserving and erasing for us. For the write-protection, the STM32L4 is slightly different from the other variants. The write-protection granularity is still a 2-kB block (2kB here) but instead of having a 'bitmap' of the protected blocks, it defines 2 write-protection ranges (WRP1AR and WRP1BR). For the EC code base, we are using WRP1AR to protect the Read-Only regions and WRP1BR to protect the Rollback and RW regions (if they exist). Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=none BUG=b:35648258 TEST=On Eve, run 'flashrom -p ec:type=fp -w /tmp/ec.bin' and 'flashrom -p ec:type=fp --wp-enable --wp-range 0x0 0x20000' Change-Id: Iaa98c1b4d3b07de2923ac076624bd4601c31a600 Reviewed-on: https://chromium-review.googlesource.com/456711 Commit-Ready: Vincent Palatin <vpalatin@chromium.org> Tested-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org> Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
* pd: Store PD active state in battery-backed memoryShawn Nematbakhsh2017-02-251-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | Our previous idea to cut Rd for many reset cases cannot work if cr50 consistently resets the EC by asserting the reset pin shortly after power-on. Therefore, make a decision based upon whether battery-backed memory indicates we previously negotiated a PD power contract as a sink. If we previously did not negotiate a contract, or if power was removed from the device (causing battery-backed memory to wipe) then we can assume that we don't have an active power contract. BUG=chrome-os-partner:62952 BRANCH=reef TEST=On reef, run "cutoff" on the console, reattach AC, and verify device successfully wakes. Also verify Rp is dropped on console 'reboot' and F3 + power from RW. Change-Id: Ie300b9589cac6be7a69b77678bea6b1b6b25578c Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/443356 Commit-Ready: Shawn N <shawnn@chromium.org> Tested-by: Shawn N <shawnn@chromium.org> Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org> Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* system: Add generic bbram read / write routinesShawn Nematbakhsh2017-02-241-22/+33
| | | | | | | | | | | | | | | | | | Add generic routines to read or write a byte to battery-backed RAM, and implement vbnvcontext get/set using these routines. BUG=chrome-os-partner:62952 BRANCH=reef TEST=On reef, with subsequent commit, run "cutoff" on the console, reattach AC, and verify device successfully wakes. Also verify Rp is dropped on console 'reboot' and F3 + power from RW. Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org> Change-Id: I14691923f2e5198e901b6b5199e92c58c68cd18d Reviewed-on: https://chromium-review.googlesource.com/444444 Commit-Ready: Shawn N <shawnn@chromium.org> Tested-by: Shawn N <shawnn@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* stm32: add support for STM32L442Vincent Palatin2017-02-171-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | Should be close to the STM32L476 in the STM32L4 family. Slightly different flash/RAM. It's currently running from the internal clock (HSI) at 16Mhz, we need to upgrade to 80Mhz (or 48Mhz if this is fast enough to save us the PLL locking time). The internal flash write/erase/protection is still not implemented for the whole STM32L4 family. Upgrade the SPI master support and verify that the TX works. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=none BUG=chrome-os-partner:62893 TEST=make BOARD=eve_fp run it on Nucleo-L432KC (STM32L432KC is mostly the same MCU without AES) Change-Id: I87be7d4461aedfbd683ff7bb639c3a6005ee171e Reviewed-on: https://chromium-review.googlesource.com/442466 Commit-Ready: Vincent Palatin <vpalatin@chromium.org> Tested-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
* Remove unused CONFIG_CONSOLE_RESTRICTED_INPUT optionBill Richardson2016-08-241-34/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | Nothing has used this config option since Spring and Skate, back in early 2014. There's nothing in ToT that uses it at all. I want to add something similar for other purposes, and having two similar-sounding options will just cause confusion. NOTE: Although the comments in include/system.h said that the two functions system_get_console_force_enabled() system_set_console_force_enabled() were only useful when CONFIG_CONSOLE_RESTRICTED_INPUT is defined, they were being used in chip/stm32/system.c. But since the bkpdata registers are only accessible to the EC, there was no way to initialize or modify the one relevant bit that those functions cared about, so they almost certainly had no effect. BUG=chrome-os-partner:55322 BRANCH=none TEST=make buildall Change-Id: Id41541193d4559f5c507bdd0268b049166af4497 Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/374525
* stm32f446e-eval: add support for stm32f446Nick Sanders2016-08-171-2/+10
| | | | | | | | | | | | | | | | | | This adds basic support for the stm32f446. This consists of: * New DMA model for stm32f4 * New clock domain support. * MCO oscillator gpio export support. * Flash support for irregular blocks. BUG=chromium:608039 TEST=boots w/ correct clock, stm32f0 also boots. BRANCH=None Change-Id: I1c5cf6ddca09009c9dac60da8a3d0c5ceedfcf4d Signed-off-by: Nick Sanders <nsanders@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/363992 Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
View Lorry Controller Status