summaryrefslogtreecommitdiff
path: root/util/stm32mon.c
Commit message (Collapse)AuthorAgeFilesLines
* ish: Trim down the release branchstabilize-wristpin-14469.59.B-ishstabilize-voshyr-14637.B-ishstabilize-quickfix-14695.187.B-ishstabilize-quickfix-14695.124.B-ishstabilize-quickfix-14526.91.B-ishstabilize-14695.85.B-ishstabilize-14695.107.B-ishstabilize-14682.B-ishstabilize-14633.B-ishstabilize-14616.B-ishstabilize-14589.B-ishstabilize-14588.98.B-ishstabilize-14588.14.B-ishstabilize-14588.123.B-ishstabilize-14536.B-ishstabilize-14532.B-ishstabilize-14528.B-ishstabilize-14526.89.B-ishstabilize-14526.84.B-ishstabilize-14526.73.B-ishstabilize-14526.67.B-ishstabilize-14526.57.B-ishstabilize-14498.B-ishstabilize-14496.B-ishstabilize-14477.B-ishstabilize-14469.9.B-ishstabilize-14469.8.B-ishstabilize-14469.58.B-ishstabilize-14469.41.B-ishstabilize-14442.B-ishstabilize-14438.B-ishstabilize-14411.B-ishstabilize-14396.B-ishstabilize-14395.B-ishstabilize-14388.62.B-ishstabilize-14388.61.B-ishstabilize-14388.52.B-ishstabilize-14385.B-ishstabilize-14345.B-ishstabilize-14336.B-ishstabilize-14333.B-ishrelease-R99-14469.B-ishrelease-R98-14388.B-ishrelease-R102-14695.B-ishrelease-R101-14588.B-ishrelease-R100-14526.B-ishfirmware-cherry-14454.B-ishfirmware-brya-14505.B-ishfirmware-brya-14505.71.B-ishfactory-kukui-14374.B-ishfactory-guybrush-14600.B-ishfactory-cherry-14455.B-ishfactory-brya-14517.B-ishJack Rosenthal2021-11-051-1758/+0
| | | | | | | | | | | | | | | | | | | | | | In the interest of making long-term branch maintenance incur as little technical debt on us as possible, we should not maintain any files on the branch we are not actually using. This has the added effect of making it extremely clear when merging CLs from the main branch when changes have the possibility to affect us. The follow-on CL adds a convenience script to actually pull updates from the main branch and generate a CL for the update. BUG=b:204206272 BRANCH=ish TEST=make BOARD=arcada_ish && make BOARD=drallion_ish Signed-off-by: Jack Rosenthal <jrosenth@chromium.org> Change-Id: I17e4694c38219b5a0823e0a3e55a28d1348f4b18 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/3262038 Reviewed-by: Jett Rink <jettrink@chromium.org> Reviewed-by: Tom Hughes <tomhughes@chromium.org>
* util/stm32mon: Prefix unrecognized bootloader cmds with 0xCraig Hesling2021-07-281-1/+1
| | | | | | | | | | | | | | BRANCH=none BUG=none TEST=# Force cmd_lookup_name to return NULL make proj-bloonchipper -j ./util/flash_ec --board=bloonchipper Change-Id: I5fe3588a9e15b19585c6f8ed005d58f5aed36a75 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/3056331 Tested-by: Craig Hesling <hesling@chromium.org> Reviewed-by: Aseda Aboagye <aaboagye@chromium.org> Commit-Queue: Craig Hesling <hesling@chromium.org>
* util/stm32mon: Move read unprotect before reading valuesCraig Hesling2021-07-281-5/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The 3 read_* functions attempt to read from areas that are protected by RDP on the STM32F412. This results in many read failures before we get to the unprotect function. These are not needed before attempting the unprotect, so move them to after the unprotect sequence. The unwanted sequence looks like the following, every time: Waiting for the monitor startup ...Done. ChipID 0x441 : STM32F412 | 0%NACK Failed to get command READMEM ACK NACK Failed to get command READMEM ACK NACK Failed to get command READMEM ACK NACK Failed to get command READMEM ACK Cannot read 21 bytes from address 0x1FFF7A0FUnable to read flash size register (0x1FFF7A22). / 0%NACK Failed to get command READMEM ACK NACK Failed to get command READMEM ACK NACK Failed to get command READMEM ACK NACK Failed to get command READMEM ACK Cannot read 13 bytes from address 0x1FFF7A0FUnable to read unique device ID register (0x1FFF7A10). Ignoring non-critical failure. Bootloader v3.1, commands : GETCMD GETVER GETID READMEM GO WRITEMEM EXTERASE WP WU RP RU Unprotecting flash read... Now, the output looks like: Waiting for the monitor startup ...Done. ChipID 0x441 : STM32F412 Bootloader v3.1, commands : GETCMD GETVER GETID READMEM GO WRITEMEM EXTERASE WP WU RP RU Unprotecting flash read... Timeout Timeout Timeout Flash read unprotected. Waiting for the monitor startup ...Done. | 0%Flash size: 1024 KB / 0%Unique Device ID: 0x383939313138511900038016 Flash write unprotected. Waiting for the monitor startup ...Done. Erasing... Timeout Timeout Timeout Flash erased. Writing 1047992 bytes at 0x08000000 1047992 bytes written. Done. BRANCH=none BUG=b:143374692 TEST=make proj-bloonchipper -j ./test/run_device_tests.py --flasher=servo_micro --tests\ flash_write_protect # This sets RDP ./util/flash_ec --board=bloonchipper TEST=# Tried flash_fp_mcu on dratini(F412/SPI) and bard(H732/SPI). Signed-off-by: Craig Hesling <hesling@chromium.org> Change-Id: I9b9ba2ecd3797cb1a98d7bcd7b226cdbc7872217 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/3054465 Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
* util/stm32mon: Fix Readout Unprotect for STM32F412Craig Hesling2021-07-271-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After sending CMD_RU, the MCU will send one ACK immediately and then another one when it is finished erasing all of flash. We currently only wait MAX_RETRY_COUNT (3) timeouts for that seconds ACK, which is not enough for the STM32F412 most fo the time. This means that it requires two invocations of stm32mon to flash a protected chip. * First unprotects and erases, then stm32mon aborts * Second sees an erased and unprotected chip which flashes correctly. We only need a few more attempts. It happens to be that MAX_ACK_RETRY_COUNT is designed for this type of situation where we are waiting for a long ACK. It provides 5 vs the old 3. BRANCH=none BUG=b:143374692 TEST=./test/run_device_tests.py --flasher=servo_micro --tests \ flash_write_protect # FPMCU is now readout protected ./test/run_device_tests.py --flasher=servo_micro --tests \ flash_write_protect # This should succeed the first time stm32mon is run, not the second. TEST=# Tried flash_fp_mcu on dratini(F412/SPI) and bard(H732/SPI). Signed-off-by: Craig Hesling <hesling@chromium.org> Change-Id: I225fa7560fd485e5df601378998f2853b351324c Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/3054464 Reviewed-by: Patryk Duda <patrykd@google.com> Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
* util/stm32mon: Fix cmd_lookup_nameCraig Hesling2021-07-271-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, the bootloader commands would be printed like the following, where the RP (0x82) and RU (0x92) commands would not be identified: Bootloader v3.1, commands : GETCMD GETVER GETID READMEM GO WRITEMEM \ EXTERASE WP WU 82 92 I believe this is because |cmd| and |cmd_lookup_table[i].cmd| were being "integer promoted" to accommodate all values. This would result in both values being converted to 32bit ints. This means that the char |cmd| could be sign extended and maintain a negative value and |cmd_lookup_table[i].cmd| would maintain a large unsigned value. Now, all the commands are recognized: Bootloader v3.1, commands : GETCMD GETVER GETID READMEM GO WRITEMEM \ EXTERASE WP WU RP RU BRANCH=none BUG=none TEST=make proj-bloonchipper -j ./util/flash_ec --board=bloonchipper Signed-off-by: Craig Hesling <hesling@chromium.org> Change-Id: I07ad35fe7e6b69c57f7f69bce3c694c2f887beef Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/3054820 Reviewed-by: Patryk Duda <patrykd@google.com> Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
* util: Add explicit castsTom Hughes2021-05-061-9/+12
| | | | | | | | | | | | | | When compiling with C++, the implicit casting that is performed in C is disallowed. Add casts in preparation for C++ compatibility. BRANCH=none BUG=b:144959033 TEST=make buildall Signed-off-by: Tom Hughes <tomhughes@chromium.org> Change-Id: I5c25440819428db65225c772c1c5115a735db58a Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2864519 Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
* util/stm32mon: Give names to byte commandsCraig Hesling2021-02-031-2/+43
| | | | | | | | | | | | | | | | | | This replaces the stm32mon console output with more useful command name, instead of the command byte codes. BRANCH=none BUG=b:176500425 TEST=make -j buildall TEST=make -j proj-bloonchipper ./util/flash_ec --board=bloonchipper --verbose TEST=emerge-strongbad ec-devutils # Ran on CoachZ with patched flash_fp_mcu Signed-off-by: Craig Hesling <hesling@chromium.org> Change-Id: I6a8c7861ad1629ed2253c120ae38d4a1e1820dad Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2234744 Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
* ec: change usage of dummySam Hurst2020-08-051-1/+1
| | | | | | | | | | | | | | | | | | Google is working to change its source code to use more inclusive language. To that end, replace the term "dummy" with inclusive alternatives. BUG=b:162781382 BRANCH=None TEST=make -j buildall `grep -ir dummy *` The only results are in "private/nordic_keyboard/sdk8.0.0" which is not our code. Signed-off-by: Sam Hurst <shurst@google.com> Change-Id: I6a42183d998e4db4bb61625f962867fda10722e2 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2335737 Reviewed-by: Tom Hughes <tomhughes@chromium.org>
* utils: fix uninitialized variable in newer versions of gccJack Rosenthal2020-01-111-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If we ever decide to upgrade GCC (or, for example, someone comes along wanting to build EC outside of the chroot) we are going to hit a snag where newer versions of GCC will consider certain variables to never be initialized. util/ectool.c: In function ‘cmd_mkbp_get’: util/ectool.c:8147:3: error: ‘supported’ may be used uninitialized in this function [-Werror=maybe-uninitialized] printf("MKBP switches state: 0x%04x (supported: 0x%04x)\n", ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ r.switches, supported); ~~~~~~~~~~~~~~~~~~~~~~ Adding an else in ectool fixes it with no effect to compiled output. In stm32mon, res may not be initialized: util/stm32mon.c: In function ‘init_monitor’: util/stm32mon.c:826:5: error: ‘res’ may be used uninitialized in this function [-Werror=maybe-uninitialized] if (IS_STM32_ERROR(res)) { ^ So fix by using success as an identity. BUG=none BRANCH=none TEST="make utils" outside of chroot Change-Id: Ib57479894111a1e7626999ecc3a150daef4b124d Signed-off-by: Jack Rosenthal <jrosenth@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1995722 Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
* stm32mon: Add connect retries parameterCraig Hesling2019-11-271-5/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, stm32mon will try to get the attention of the stm32 bootloader for forever ("Starting monitor"). Retrying forever is odd behavior, in general. Furthermore, this behavior does not allow wrapper scripts to observe the failure and try other retry mechanisms, like resetting the chip. TL;DR This CL sets a default 40 retries for the bootloader connect/sync and adds the "--retries <num-retries>" and "-R <num-retries>" argument for adjustments. Note, this is simply the retry limit for connecting/syncing-with the bootlodaer. You can specify "-R -1" to try forever. BRANCH=nocturne,hatch BUG=b:143374692,b:144729003 TEST=cros_workon --board=nocturne start chromeos-base/ec-devutils emerge-nocturne chromeos-base/ec-devutils cros deploy --root=/usr/local dut1 chromeos-base/ec-devutils # Bind spidev for fpmcu # Enable hardware wp time stm32mon -U -u -p -s /dev/spidev32765.0 -e -w \ /opt/google/biod/fw/nocturne_fp_v2.2.110-b936c0a3c.bin # Check that it tries forever?? time stm32mon -R 10 -U -u -p -s /dev/spidev32765.0 -e -w \ /opt/google/biod/fw/nocturne_fp_v2.2.110-b936c0a3c.bin # Check that is only makes 11 attempts Signed-off-by: Craig Hesling <hesling@chromium.org> Change-Id: I925466fb892b0d17a7ff8b354e3cee302d167d3c Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1913332 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>
* stm32mon: Added declarations for stm32g0 seriesJes Klinke2019-06-151-0/+44
| | | | | | | | | Bug: 132247842 Change-Id: Ib1defbabd6e2835d8ce8485c80f22254d2b49db7 Signed-off-by: jbk@chromium.org Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1620789 Reviewed-by: Aseda Aboagye <aaboagye@chromium.org> Reviewed-by: James Deng <jaamesd@chromium.org>
* stm32mon: : fix coverity scan issue on a write_wrapper() callNamyoon Woo2019-05-211-1/+7
| | | | | | | | | | | | | | | | | | | This CL fixes coverity scan check issue, which points that there is a call to write_wrapper() missing return value checking. This was added by crrev.com/c/1540496, which is about a sending garbage byte to DUT to avoid reTIMEOUT response repeating. BUG=b:131231369 BRANCH=none TEST=ran flash_ec on scarlet at 9600 bps. flash_ec --board scarlet --image ${IMG} --bitbang_rate 9600 Change-Id: I25ea43ae13d9fbf16b90fba4030c9bb640498453 Signed-off-by: Namyoon Woo <namyoon@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1588497 Legacy-Commit-Queue: Commit Bot <commit-bot@chromium.org> Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
* util/stm32mon: Add cmdline option to display versionTom Hughes2019-04-241-2/+17
| | | | | | | | | | | | | | | | | | | Also display the version when running in order to make it easier to debug flashing issues in the field or factory. BRANCH=none BUG=chromium:952332 TEST=./util/flash_ec --board=hatch_fp --image=./build/hatch_fp/ec.bin => displays stm32mon version ./build/hatch_fp/util/stm32mon -v => displays version ./build/hatch_fp/util/stm32mon --version => displays version Change-Id: I43f622ed370938eeed31453d5b11806f02b47277 Signed-off-by: Tom Hughes <tomhughes@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1565462 Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
* stm32mon: retry on damaged ACK, NACK or timeoutNamyoon Woo2019-04-121-126/+253
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BUG=b:112837404 BRANCH=None TEST=manually ran stm32mon or flash_ec on scarlet and DragonTalon. 1. stm32mon via Servo V4 type-C at 57600 bps on scarlet. $ ./util/flash_ec --board scarlet --image ${IMG} \ --bitbang_rate 57600 --verbose 2. stm32mon via Servo V4 type-C at 9600 bps on scarlet. which tends to fail for NACK or timeout. $ ./util/flash_ec --board scarlet --image ${IMG} \ --bitbang_rate 9600 --verbose 3. flash_ec via Servo Micro on scarlet $ ./util/flash_ec --board scarlet --image ${IMG} --verbose 4. flash_ec on DragonTalon via Servo V2 and Servo Micro respectively. $ ./util/flash_ec --board hatch_fp --image ${IMG} --verbose Full log can be found at http://gpaste/5439133910564864 Change-Id: I3c8e8c81d9d12475f5722eaacc932dc1244625d5 Signed-off-by: Namyoon Woo <namyoon@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1540496 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Reviewed-by: Matthew Blecker <matthewb@chromium.org>
* hatch_fp: STM32F412 can have up to 1 MB Flash (some have less)Tom Hughes2019-04-091-15/+291
| | | | | | | | | | | | | | | | | | | | | | | | For sizes, see: See https://www.st.com/resource/en/reference_manual/dm00180369.pdf Section 3.3 Embedded Flash Memory We read the Flash size data register to get the actual size: See https://www.st.com/resource/en/reference_manual/dm00180369.pdf Section 31 Device electronic signature BRANCH=none BUG=b:126455006,b:124996507 TEST=make BOARD=hatch_fp -j ./build/host/util/stm32mon -b 115200 -d /dev/pts/24 \ -u -e -w ./build/hatch_fp/ec.bin Change-Id: I105840150cde68c7c7579d44c8d8c43b6b567233 Signed-off-by: Tom Hughes <tomhughes@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1541818 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
* hatch_fp: Fix flash erase in stm32monTom Hughes2019-04-031-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | hatch_fp uses STM32F412, which *does* support mass erase. The original commit that matches against STM32F41 seems to be targeted to the STM32F411 based on the commit message: 09a7fa4ae When trying to erase the STM32F412 for hatch_fp by page, the command fails: Waiting for the monitor startup ...Done. ChipID 0x441 : STM32F412 Bootloader v1.1, commands : 00 01 02 11 21 31 44 63 73 82 92 Unprotecting flash read... Flash read unprotected. Waiting for the monitor startup ...Done. Flash write unprotected. Waiting for the monitor startup ...Timeout Done. Erasing... NACK payload 0 ACK failed for CMD44 BRANCH=None BUG=b:124996507 TEST=hatch_dut> flash_fp_mcu ec.bin Change-Id: Idc800b1f3ae29f7776405b1e952f71ef2d7c8a14 Signed-off-by: Nicolas Norvez <norvez@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1539016 Commit-Ready: Tom Hughes <tomhughes@chromium.org> Tested-by: Tom Hughes <tomhughes@chromium.org> Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
* stm32mon: Add link to SPI protocolTom Hughes2018-12-171-1/+4
| | | | | | | | | | | | | Also fix misspelling. BRANCH=none BUG=none TEST=make buildall -j Change-Id: I6e17407be36abd83567a2e09ae1c2684e1bc5090 Signed-off-by: Tom Hughes <tomhughes@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1378907 Reviewed-by: Jett Rink <jettrink@chromium.org>
* stm32h7/nocturne_fp: Enable RDP level 1, tie it to flash protection statusNicolas Boichat2018-09-221-13/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Prevent flash readout, using RDP field in option byte. When RDP is defined, it makes no sense to be able to unlock RO, as that'd allow flashing arbitrary RO that could read back the rest of the flash, so we just tie EC_FLASH_PROTECT_RO_AT_BOOT and RDP protection. This also means we can't unlock the flash after it has been finalized (without removing WP and using BOOT0/stm32mon to mass erase the chip). Also, in flash_mp_mcu, call stm32mon with -U, to unlock flash for read-back first (which disables RDP and triggers a mass erase if RDP was enabled). Finally, load spidev before putting releasing reset, which makes reflashing more reliable. BRANCH=nocturne BUG=b:111330723 TEST=cp flash_mp_mcu read_mp_mcu, replace stm32mon line with: "stm32mon -u -p -s ${SPIDEV} -r rb.bin" dut-control fw_wp_state:force_off => Check that read_mp_mcu works dut-control fw_wp_state:force_on ectool --name=cros_fp flashprotect enable ectool --name=cros_fp reboot_ec => RDP is now on dut-control fw_wp_state:force_off => Check that read_mp_mcu does not work anymore TEST=Add -U to stm32mon line above in read_mp_mcu, check that readback only gets blank data. TEST=In EC console, check that RDP bits are indeed not 0xaa: Before: rw 0x5200201c => 0x07d6aaf0 After: rw 0x5200201c => 0x07d600f0 TEST=flash_mp_mcu still works (does a flash erase that removes RDP protection) Change-Id: Ifbe37ecafbf23f48d4a3cc17933130b7b104b728 Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1222094 Commit-Ready: Nicolas Norvez <norvez@chromium.org> Tested-by: Nicolas Norvez <norvez@chromium.org> Reviewed-by: Nicolas Norvez <norvez@chromium.org>
* stm32mon: don't set UART attributes when programming over Cr50Vadim Bendebury2018-08-181-14/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | When EC console is connected over a Cr50 UART to USB bridge, there is no need to try setting up UART properties of the interface device as in this case the settings will not propagate to the target. BRANCH=none BUG=b:62539385 TEST=connect a Scarlet device over SuzyQ to the host and source the following script: vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv echo gpioset EC_FLASH_SELECT 1 > /dev/ttyUSB0 echo bitbang 2 57600 even > /dev/ttyUSB0 echo ecrst pulse > /dev/ttyUSB0 sleep 2 <path to>/stm32mon -d /dev/ttyUSB2 -u -U -e -c -w <path to>/ec.bin echo gpioset EC_FLASH_SELECT 0 > /dev/ttyUSB0 echo bitbang 2 disable > /dev/ttyUSB0 echo ecrst pulse > /dev/ttyUSB0 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Change-Id: I5feeaffbc25c029fe6b5d8fa712d5927d00e26ce Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1175317 Reviewed-by: Mary Ruthven <mruthven@chromium.org>
* stm32mon: add logging capabilityVadim Bendebury2018-08-081-11/+84
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When debugging STM32 programming over UART it is very helpful to be able to analyze the log of exchanges between the programmer and the chip. This patch adds a command line option which allows to specify the name of the file to save the log in. BRANCH=none BUG=none TEST=verified that when -L option is given the appropriate log file is created: head ../../../chroot/tmp/flash.log w: 7f r: 79 w: 02 fd r: 79 r: 01 04 42 r: 79 w: 00 ff r: 79 r: 0b 31 00 01 02 11 21 31 44 63 73 82 92 r: 79 Change-Id: I78f566ce1a70d3e1a2f7df7ea4d049001a7d0b1d Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1168159 Reviewed-by: Mary Ruthven <mruthven@chromium.org>
* stm32mon: do not print zeros received when draining the input.Vadim Bendebury2018-08-081-1/+24
| | | | | | | | | | | | | | | | | | | | | | | | | When stm32mon starts up, before trying to program the EC it first drains the EC console device and displays the contents on the console. In case of programming over Cr50 the EC console device buffer could be filled up with many hundreds of zeros which were received by the Cr50 UART when the EC was held in reset, as the Cr50 UART does not process the 'break' condition properly and considers all received zeros valid data. This patch adds code to discard zeros received from the EC console before flash programming starts, so that the zeros do not flood the terminal where stm32mon is invoked. BRANCH=none BUG=none TEST=no more zeros printed when stm32mon is invoked, the number of discarded zeros is reported. Change-Id: I86c6fe45d1ef55ce7be5aa7511231edb24cfb2be Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1168158 Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
* util/stm32mon: Fix resource leakPatrick Georgi2018-07-301-0/+1
| | | | | | | | | | Change-Id: I81941a440ae0abda226795855b67c2c9b12f6686 Signed-off-by: Patrick Georgi <pgeorgi@google.com> Found-by: Coverity Scan #58166 Reviewed-on: https://chromium-review.googlesource.com/1151125 Commit-Ready: Patrick Georgi <pgeorgi@chromium.org> Tested-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
* stm32mon: terminate gracefully when failing to get commands listVincent Palatin2018-04-121-1/+3
| | | | | | | | | | | | | | | | | | | When the CMD_GETCMD transaction fails, terminate immediately rather than continuing and crashing when we use later the uninitialized 'erase' function. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=none BUG=b:77825616 TEST=flash Scarlet EC through CCD. Change-Id: Ia40107fe27d81fdb9ee8220f73f4215d936a41c1 Reviewed-on: https://chromium-review.googlesource.com/1006595 Commit-Ready: Vincent Palatin <vpalatin@chromium.org> Tested-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Aseda Aboagye <aaboagye@chromium.org> Reviewed-by: Mary Ruthven <mruthven@chromium.org>
* stm32mon: fix progressbar parameterVincent Palatin2018-03-071-1/+1
| | | | | | | | | | | | | | | | | | Ensure that the short parameter '-p' works as well as the long one '--progressbar'. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=none BUG=none TEST=run 'stm32mon -p' and 'stm32mon --progress' none of them are displaying the command usage. Change-Id: If24accf0991dc9705a1fb3e29acf12581d7ab8dc Reviewed-on: https://chromium-review.googlesource.com/952966 Commit-Ready: Vincent Palatin <vpalatin@chromium.org> Tested-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Nicolas Norvez <norvez@chromium.org>
* stm32mon: add option to replace the spinnerVincent Palatin2018-03-011-3/+19
| | | | | | | | | | | | | | | | | | | | Using only a Carriage Return as done to have a nice spinner is not terribly compatible with logging the output of the tool to a file or piping it to anything. Add another option to have a simple progress-bar instead. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=none BUG=none TEST=on Meowth, run flash_fp_mcu from the factory UI. Change-Id: I0c37689d2ed1e45dff54b7f1eb2be515ea37e004 Reviewed-on: https://chromium-review.googlesource.com/936766 Commit-Ready: Vincent Palatin <vpalatin@chromium.org> Tested-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Aseda Aboagye <aaboagye@chromium.org> Reviewed-by: Nicolas Norvez <norvez@chromium.org>
* stm32mon: skip empty blocksVincent Palatin2018-02-261-12/+18
| | | | | | | | | | | | | | | | | | | Skip the empty blocks when writing even if they are in the middle of the firmware. This greatly improves flashing speed when the firmware contains a signature at the end of the RW. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=none BUG=b:36125319 TEST=./util/flash_ec --board=meowth_fp Change-Id: I3cd1c1bd2670be23d3d9daf9b87d9af0bdfc8963 Reviewed-on: https://chromium-review.googlesource.com/880956 Commit-Ready: Vincent Palatin <vpalatin@chromium.org> Tested-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Alexandru M Stan <amstan@chromium.org>
* stm32mon: do not write trailing empty spaceVincent Palatin2018-01-101-0/+6
| | | | | | | | | | | | | | | | | | | | | Add a tweak to get faster flashing: skip writing the empty trailing space at the end of the firmware image. On the STM32H7x3, flashing 2MB of useless bytes over UART can be really slow... Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=none BUG=b:67081508 TEST=flash_ec --board=meowth_fp Change-Id: Ie396ee7d5b5771e0f6249e38da37ef8329c84ae3 Reviewed-on: https://chromium-review.googlesource.com/856978 Commit-Ready: Vincent Palatin <vpalatin@chromium.org> Tested-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-by: Shawn N <shawnn@chromium.org>
* stm32mon: add STM32H7 identifierVincent Palatin2018-01-101-0/+1
| | | | | | | | | | | | | | | | Add a new chip ID to support the STM32H7x3 parts. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=none BUG=b:67081508 TEST=flash_ec --board=meowth_fp Change-Id: I3897a74f5414e0e6b13890291706134c2d916af9 Reviewed-on: https://chromium-review.googlesource.com/856977 Commit-Ready: Vincent Palatin <vpalatin@chromium.org> Tested-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
* stm32mon: change erase timeoutVincent Palatin2018-01-101-3/+12
| | | | | | | | | | | | | | | | | | | | | On some chips, the full erase operation can take really long: e.g 13s for 2MB mass-erase on the STM32H7x3 family. Add a new mechanism retrying the ACK detection rather than extending the default timeout which would imply very slow behavior in other cases (e.g. connection). Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=none BUG=b:67081508 TEST=flash_ec --board=meowth_fp Change-Id: I428f56341c31c327debb9a3d2eba9b12c768ba86 Reviewed-on: https://chromium-review.googlesource.com/856976 Commit-Ready: Vincent Palatin <vpalatin@chromium.org> Tested-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-by: Shawn N <shawnn@chromium.org>
* stm32: add embryonic support for STM32F76xVincent Palatin2017-08-181-0/+1
| | | | | | | | | | | | | | | | | | | | | | | The STM32F76x is really close to the STM32F4 family, so the most concise implementation is just using CHIP_FAMILY_STM32F4 and adding CHIP_VARIANT_F76X. Tune the clock settings to 180 Mhz CPU clock as the goal is performance. (over-drive is not implemented yet to get to 216 Mhz) Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=none BUG=none TEST=ran on nucleo-f767zi board. 'make BOARD=nucleo-f767 flash', the red LED is on and the green LED turns on/off when pressing the user button, UART console works properly. Change-Id: I1f67df3aec874c965c81188df46c72de210728d9 Reviewed-on: https://chromium-review.googlesource.com/612750 Commit-Ready: Vincent Palatin <vpalatin@chromium.org> Tested-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Shawn N <shawnn@chromium.org>
* st32mon: Define SPI_IOC_WR_MODE32 if it's missingStefan Reinauer2017-08-161-0/+8
| | | | | | | | | | | | | | | | | | | On Goobuntu, the uapi copy of spidev.h doesnot contain SPI_IOC_WR_MODE32, however the kernel supports the IOCTL. To be able to build the tool outside of the ChromeOS chroot, define it if it's not available. Signed-off-by: Stefan Reinauer <reinauer@google.com> BRANCH=none TEST=make buildall -j outside of the chroot BUG=b:35567067 Change-Id: I04ec968e221c7d43f1bdb364a195d371370ec886 Reviewed-on: https://chromium-review.googlesource.com/614645 Commit-Ready: Stefan Reinauer <reinauer@google.com> Tested-by: Stefan Reinauer <reinauer@google.com> Reviewed-by: Martin Roth <martinroth@chromium.org> Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* stm32mon: Add support for STM32F412Gwendal Grignou2017-06-061-0/+1
| | | | | | | | | | | | | | | | | | | BRANCH=none BUG=b:38506987 TEST=On eve, where some sectors were locked, was able to unlock them: - Enter bootloader: st_flash --board=eve --enter_bootloader=true - Unlock all pages: /tmp/stm32mon -a 8 -l 0x8c -u ChipID 0x441 : STM32F412 Bootloader v1.2, commands : \ 00 01 02 11 21 31 44 63 73 82 92 32 45 64 74 83 93 00 Flash write unprotected. Change-Id: I423e4b7f235ee2c9dddf28f4166fca2a74132733 Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/511886 Reviewed-by: Alexandru M Stan <amstan@chromium.org>
* stm32mon: Add offset/length parameter to read/write a particular memory regionGwendal Grignou2017-06-021-24/+33
| | | | | | | | | | | | | Use that option to read a particular portion of the flash BUG=None BRANCH=none TEST=Check data retrieved is correct. Change-Id: Ib2bc98aa7352515c2e651443f322dd0250c72cdd Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/260886 Reviewed-by: Alexandru M Stan <amstan@chromium.org>
* stm32mon: Add support for STM32F411Gwendal Grignou2017-06-021-27/+48
| | | | | | | | | | | | | | | Add support for i2c boot protocol 1.1 and erase non-strech erase command. Add option to specify i2c slave address. TEST=Read, Erase and Write SH on Ryu P4. BUG=chrome-os-partner:36018 BRANCH=none Change-Id: Ib0649323fd8879fef6e2dc5e62001c891afe128a Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/250101 Reviewed-by: Alexandru M Stan <amstan@chromium.org>
* stm32mon: add support for SPI flashing modeVincent Palatin2017-03-281-16/+99
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Allow to flash an STM32 in bootloader mode through its SPI slave interface. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=none BUG=b:36125319 TEST=run from Eve AP: export SPIDEV="/dev/spidev32765.0" export GPIO_NRST=418 export GPIO_BOOT0=419 echo ${GPIO_BOOT0} > /sys/class/gpio/export echo "out" > /sys/class/gpio/gpio${GPIO_BOOT0}/direction echo ${GPIO_NRST} > /sys/class/gpio/export echo "out" > /sys/class/gpio/gpio${GPIO_NRST}/direction echo 1 > /sys/class/gpio/gpio${GPIO_BOOT0}/value echo 0 > /sys/class/gpio/gpio${GPIO_NRST}/value echo 1 > /sys/class/gpio/gpio${GPIO_NRST}/value stm32mon -s ${SPIDEV} -r /tmp/mcu-image.bin echo 0 > /sys/class/gpio/gpio${GPIO_BOOT0}/value echo 0 > /sys/class/gpio/gpio${GPIO_NRST}/value echo 1 > /sys/class/gpio/gpio${GPIO_NRST}/value echo "in" > /sys/class/gpio/gpio${GPIO_BOOT0}/direction echo "in" > /sys/class/gpio/gpio${GPIO_NRST}/direction re-verify UART flashing mode with 'flash_ec --board=eve_fp' Change-Id: Ic268dd9e62a2f279dd7992a4bbcf16fcf44c5f9e Reviewed-on: https://chromium-review.googlesource.com/456596 Commit-Ready: Vincent Palatin <vpalatin@chromium.org> Tested-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Todd Broch <tbroch@chromium.org>
* stm32: add support for STM32L442Vincent Palatin2017-02-171-0/+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>
* Fix various misspellings in commentsMartin Roth2016-11-151-1/+1
| | | | | | | | | | | | | No functional changes. BUG=none BRANCH=none TEST=make buildall passes Change-Id: Ie852feb8e3951975d99dce5a49c17f5f0e8bc791 Signed-off-by: Martin Roth <martinroth@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/403417 Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
* use _DEFAULT_SOURCE for newer glibcMike Frysinger2015-12-081-1/+2
| | | | | | | | | | | | | | | Newer versions of glibc have moved to _DEFAULT_SOURCE and away from _BSD_SOURCE. Trying to use the BSD define by itself leads to warnings which causes build failures. BRANCH=none BUG=None TEST=precq still works Signed-off-by: Mike Frysinger <vapier@chromium.org> Change-Id: Ice24b84dc6a540695fc7b76e8f22a4c85c301976 Reviewed-on: https://chromium-review.googlesource.com/316730 Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* stm32mon: add STM32F09X chip idRong Chang2015-04-241-0/+1
| | | | | | | | | | | | | | | | | | | | | Adds the support of STM32F09X with 256KB flash. BUG=none Test=manual Check stm32mon ChipID output: ChipID 0x442 : STM32F09x Bootloader v3.1, commands : 00 01 02 11 21 31 44 63 73 82 92 Flash read unprotected. Waiting for the monitor startup ...Done. Flash write unprotected. Waiting for the monitor startup ...Done. Flash erased. Writing 262144 bytes at 0x08000000 Change-Id: Ied967716750820a335011f244aae5885c507360a Signed-off-by: Rong Chang <rongchang@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/266972 Reviewed-by: Alec Berg <alecaberg@chromium.org>
* stm32mon: fix unable to flash to nyan board problemYen Lin2014-12-161-1/+1
| | | | | | | | | | | | | | | When comparing chip name of "STM32L15", use strncmp to compare the first 8 characters. BUG=chrome-os-partner:34558 BRANCH=none TEST=flash_ec --board nyan Change-Id: I3318385cee1d4e4c4d9688591f7a7bfd46c54dee Signed-off-by: Yen Lin <yelin@nvidia.com> Reviewed-on: https://chromium-review.googlesource.com/235511 Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
* Add stm32mon support for STM32F37xxVic Yang2014-10-211-0/+1
| | | | | | | | | | | | | This is needed for the new Ryu boards. BRANCH=none BUG=chrome-os-partner:32660 TEST=Program STM32F373 chip. Change-Id: Ib7a58826945090300b7e086e888c43c46fb499ab Signed-off-by: Vic Yang <victoryang@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/223893 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* stm32mon: add option to read firmware image from stdinVincent Palatin2014-10-021-3/+6
| | | | | | | | | | | | | | | | | | | | | Add a command-line option to ask stm32mon to read the EC firmware image to flash from the standard input when the filename is replaced by a "-". Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=none BUG=chromium:398165 chromium:396233 TEST=use the following flashing commands: cat build/fruitpie/ec.bin | ./util/flash_ec --board=fruitpie --image=- ./util/flash_ec --board=fruitpie ./util/flash_ec --board=fruitpie --image=build/fruitpie/ec.RO.flat and check the content of the flash. Change-Id: I8039ecb6910f912161a7f59c5f5e2fc80447ce7b Reviewed-on: https://chromium-review.googlesource.com/220842 Tested-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Todd Broch <tbroch@chromium.org> Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
* stm32mon: add support for i2c transport.Gwendal Grignou2014-09-041-76/+204
| | | | | | | | | | | BUG=chromium:405601 TEST=Able to read/erase/write flash on Ryu. Able to send go command. BRANCH=ToT Change-Id: I588cfee3dbbb3d8e3b66fe9d1044f3612f9b02c3 Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/214032 Reviewed-by: Vic Yang <victoryang@chromium.org>
* veyron: Modify board configzyw2014-07-231-7/+8
| | | | | | | | | | | | | | | | This patch is base on new hardware board, veyron has not some stuff, such as power led, charge en BUG=None TEST=Read log with servo board, it has reponse when type some commends BRANCH=None Change-Id: I45502fd1278f69db5e46fc9ab1deaee02fc8708f Signed-off-by: zyw <zyw@rock-chips.com> Reviewed-on: https://chromium-review.googlesource.com/209231 Reviewed-by: Alexandru Stan <amstan@google.com> Commit-Queue: Alexandru Stan <amstan@google.com> Tested-by: Alexandru Stan <amstan@google.com>
* stm32mon: fix STM32F03x flash sizeVincent Palatin2014-04-301-1/+1
| | | | | | | | | | | | | | | | | The current SKU has 32kB. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=none BUG=none TEST=read-back the flash content from a Zinger power brick using "stm32mon -r". Change-Id: Id74e585f4b49b9ef5fecdec8182f3710eb0b4960 Reviewed-on: https://chromium-review.googlesource.com/196690 Tested-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Alec Berg <alecaberg@chromium.org> Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
* stm32: add STM32F03x configurationVincent Palatin2014-03-221-0/+2
| | | | | | | | | | | | | | | | | | Add STM32F03x as part of the STM32F0 family. STM32F031 will be used for devices requiring low-end parts. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=none BUG=none TEST=along with the following CLs, run on STM32F051 Discovery with limited RAM and Flash to mimic STM32F031. Change-Id: Ie95303eaf00ce53fe7c8d2ac84c19a983aadbf0d Reviewed-on: https://chromium-review.googlesource.com/189404 Reviewed-by: Vic Yang <victoryang@chromium.org> Commit-Queue: Vincent Palatin <vpalatin@chromium.org> Tested-by: Vincent Palatin <vpalatin@chromium.org>
* stm32: add support for STM32F0xx familyVincent Palatin2014-03-111-0/+1
| | | | | | | | | | | | | | | | | | Add support for the STM32F0xx family of devices using a Cortex-M0 core and slightly newer peripherals than F1xx family. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=none BUG=none TEST=run EC console on STM32F072B Discovery board. and pass all available unit-tests on target. Change-Id: Idaa3fcbf1c0da8a8f448c0e88e58bfd976b0a735 Reviewed-on: https://chromium-review.googlesource.com/188983 Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Commit-Queue: Vincent Palatin <vpalatin@chromium.org> Tested-by: Vincent Palatin <vpalatin@chromium.org>
* cleanup: Remove checkpatch warningsRandall Spangler2013-12-191-4/+5
| | | | | | | | | | | | | | | | This make minor syntactic changes and renames some camel-cased symbols to keep checkpatch from complaining. The goal is to reduce the temptation to use 'repo upload --no-verify'. This is a big furball of find/replace, but no functional changes. BUG=chromium:322144 BRANCH=none TEST=build all boards; pass unit tests Change-Id: I0269b7dd95836ef9a6e33f88c003ab0f24f842a0 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/180495
* Tool support for STM32L-Discovery boardJeremy Thorpe2013-09-281-1/+2
| | | | | | | | | | | | | | | Add the ChipID for the stm32l152c board to stm32mon. Add discovery to the list of supported boards in flash_ec. BUG=None TEST=With modified servo connector, see that image can be loaded onto stm32l152c discovery board. BRANCH=none Change-Id: Ie16c64d17c907f7de765b09de98f534c486ae04c Signed-off-by: Jeremy Thorpe <jeremyt@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/170981 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
View Lorry Controller Status