Is poppy ec an stm32? I'm currently fixing this in another bug.

No, it seems that poppy EC is a NPCX chip.

Does servo micro have the ability to change UART settings?

This is the same issue as https://b.corp.google.com/issues/37513705

Err, no that does not look like the same issue.

BTW, NPCX chips are using a separate SPI flash so the programming is not done over UART (so saving and restoring those baudrate parameters is not actually needed AFAICT)...

Ah, seems like it's a scripting problem in flash_ec then. There's also a --raiden flag which may be necessary?

'ec_uart_baudrate', 'ec_uart_en', 'ec_uart_parity', 'spi1_buf_on_flex_en' are all inappropriate for servo_micro, and the spi interface needs to use raiden rather than ftdi flash. 

Aseda had a cl that covered most of it for cr50, maybe he can tweak the last bits.

Yeah, let me clean it up a bit. My goal is that it should be as easy as './util_/flash_ec --board $BOARD'. 

Should servo_micro be using the raiden_debug_spi flashrom programmer? If I do, I get the following error.

(cr) (flash_ec-servo-micro-support)  /work2/cros aaboagye@lithium ~/trunk/src/platform/ec $ ./util/flash_ec --board kevin
INFO: Using servo_micro
INFO: Using ec image : /mnt/host/source/src/platform/ec/build/kevin/ec.bin
INFO: Flashing chip npcx_spi.
INFO: Using raiden debug cable.
flashrom v0.9.4  : 0662f2e : May 13 2017 02:18:12 UTC on Linux 4.4.0-72-generic (x86_64)
flashrom v0.9.4  : 0662f2e : May 13 2017 02:18:12 UTC on Linux 4.4.0-72-generic (x86_64)
Calibrating delay loop... OK.
libusb error: raiden_debug_spi.c:351 libusb error code -9
Raiden: Failed to enable SPI bridge
Error: Programmer initialization failed.
(cr) (flash_ec-servo-micro-support)  /work2/cros aaboagye@lithium ~/trunk/src/platform/ec $ 


My servo micro version is: servo_micro_v1.1.5690-46ed8a0.

Yes, servo micro uses raiden_debug_spi. Can you paste the actual flashrom command? Servo micro doesn't use the target= command, maybe that's the issue.

Ah, the command is indeed using the target= param. Here's the command being executed:


sudo timeout -k 10 -s 9 600 /usr/sbin/flashrom -p raiden_debug_spi:target=EC -i EC_RW -i WP_RO -l /tmp/flash_spi_layout_15248 --ignore-fmap --fast-verify -w /tmp/flash_spi_15248

Yeah you'd want to take out ":target=EC" and make sure to call 
dut-control spi_vref:pp3000 spi_buf_en:on beforehand.

CL posted here: https://chromium-review.googlesource.com/c/572142

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform/ec/+/3a7a739b38b566bddb4f97755a699b3688a8744c

commit 3a7a739b38b566bddb4f97755a699b3688a8744c
Author: Aseda Aboagye <aaboagye@google.com>
Date: Thu Jul 20 02:03:54 2017

flash_ec: Add support for servo micro.

BUG= chromium:740026 
BRANCH=maybe some FW branches.
TEST=Use a servo_micro, flash kevin, verify kevin boots.
TEST=Repeat above test with a servo_v2.

Change-Id: I377384f44e85c4a6032871aa4eebd208fd6e3336
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/572142
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>

[modify] https://crrev.com/3a7a739b38b566bddb4f97755a699b3688a8744c/util/flash_ec

Changed merged to ToT. Will merge to some firmware branches with some other changes to make life easier.

Verified in CL.

This actually broke STM32 EC flashing using servov2. For example:
# util/flash_ec --board=hammer --port=9000
util/flash_ec: line 438: ec_uart_baudrate: command not found
util/flash_ec: line 292: _ec_hard_reset: command not found

I tried looking into this, but I'm not sure what's going on.

First, the multiline initializer for common_stm32_VARS does not work. One needs to do:

--- a/util/flash_ec
+++ b/util/flash_ec
@@ -435,8 +435,8 @@ servo_v4_with_ccd_cr50_VARS=
 # Flashing an STM32 over the UART requires modifying the UART properties along
 # with the boot mode pin.
 if [ "${CHIP}" = "stm32" ] ; then
-       common_stm32_VARS=" ${MCU}_uart_en ${MCU}_uart_parity " \
-                         "${MCU}_uart_baudrate"
+        common_stm32_VARS=" ${MCU}_uart_en ${MCU}_uart_parity"
+        common_stm32_VARS+=" ${MCU}_uart_baudrate"
        servo_v2_VARS+=$common_stm32_VARS
        servo_v2_VARS+=" ${MCU}_boot_mode"
        servo_micro_VARS+=$common_stm32_VARS

With this, claim_pty is called without parameters, which locks many processes in creative ways. This helps:

@@ -473,6 +476,10 @@ function claim_pty() {
                    "'cros_sdk --no-ns-pid' (see  crbug.com/444931  for details)"
        fi
 
+        if [ -z "$1" ]; then
+            die "claim_pty called without parameters?!"
+        fi
+
        # Disconnect the EC-3PO interpreter from the UART since it will
        # interfere with flashing.
        dut_control ${MCU}_ec3po_interp_connect:off || \

Revert here, until we figure this out? https://chromium-review.googlesource.com/c/583298

Thanks for the pointer. Hmm, with just the following diff, I can flash an elm with a servo v2 with no problem.

aaboagye@lithium:/work2/cros/src/platform/ec$ g diff
diff --git a/util/flash_ec b/util/flash_ec
index ecf3611b7..6ec1b2095 100755
--- a/util/flash_ec
+++ b/util/flash_ec
@@ -434,8 +434,8 @@ servo_v4_with_ccd_cr50_VARS=
 # Flashing an STM32 over the UART requires modifying the UART properties along
 # with the boot mode pin.
 if [ "${CHIP}" = "stm32" ] ; then
-       common_stm32_VARS=" ${MCU}_uart_en ${MCU}_uart_parity " \
-                         "${MCU}_uart_baudrate"
+       common_stm32_VARS=" ${MCU}_uart_en ${MCU}_uart_parity"
+       common_stm32_VARS+=" ${MCU}_uart_baudrate"
        servo_v2_VARS+=$common_stm32_VARS
        servo_v2_VARS+=" ${MCU}_boot_mode"
        servo_micro_VARS+=$common_stm32_VARS


Also, what servo were you using that you saw claim_pty called with no parameters? I didn't see that on mine.

Oh, I think I may have done something a bit weird by accident, try to call flash_ec without any servod running.

Ah, that might do it. I found some more issues:

- servo_micro doesn't work with flashing stm32 over the UART yet. (baud rate control is missing...)
- Some more nits needed with flash_ec (EC_UART isn't defined for servo_micro, it should). 

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform/ec/+/15c3bec8a52fae390cb759c6eba7f52216319b54

commit 15c3bec8a52fae390cb759c6eba7f52216319b54
Author: Aseda Aboagye <aaboagye@google.com>
Date: Tue Jul 25 03:32:48 2017

flash_ec: Fix common_stm32_VARS definition.

In the recent change to flash_ec, there was a problem with they way that
common_stm32_VARS was defined.  This commit fixes the issue.

BUG= chromium:740026 
BRANCH=potentially some FW branches.
TEST=Using servo_v2, flash elm.

Change-Id: I2e14f1f45525f494d9912b420d36d02d89b9dc5a
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/583540
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>

[modify] https://crrev.com/15c3bec8a52fae390cb759c6eba7f52216319b54/util/flash_ec

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform/ec/+/7ed19ed220b795f9bc28832e7bddb891c383b4b2

commit 7ed19ed220b795f9bc28832e7bddb891c383b4b2
Author: Aseda Aboagye <aaboagye@google.com>
Date: Wed Aug 02 19:47:50 2017

flash_ec: Update method of retrieving serial num.

There have been some new methods added to servod to retrieve the serial
numbers of the servos attached.  Prior to this, with a servo micro
connected to a servo v4, retrieving the serial number would always
return that of the servo v4.  This would cause flashing to fail.  This
change updates the method to retrieve the serial numbers.

CQ-DEPEND=CL:597209

BUG= chromium:740026 
BRANCH=maybe some fw branches.
TEST=With updated hdctools, flash a kevin using a servo micro connected
to a servo v4.
TEST=Flash kevin with a servo v2.
TEST=Attempt to flash a hammer and verify that the only issue is
stm32mon not being able to determine the startup of the monitor mode
(since I don't actually have a hammer).

Change-Id: I82c2907d689311fe65717a833390b8d0f6e15a94
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/597211
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>

[modify] https://crrev.com/7ed19ed220b795f9bc28832e7bddb891c383b4b2/util/flash_ec