Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Implement reset for ARC development boards #26665

Closed
abrodkin opened this issue Jul 6, 2020 · 1 comment · Fixed by #27793
Closed

Implement reset for ARC development boards #26665

abrodkin opened this issue Jul 6, 2020 · 1 comment · Fixed by #27793
Assignees
@abrodkin
Labels
area: ARC ARC Architecture area: Boards Enhancement Changes/Updates/Additions to existing features

Comments

@abrodkin
Copy link
Collaborator

abrodkin commented Jul 6, 2020 •
edited
Loading

Originated from #25022.
Short story is: in some cases the board might enter non-recoverable state from which we may only recover with help of real HW reset. And fortunately this is easily doable on most of ARC development boards. Read-on...

Most of ARC development boards (excluding just a legacy EM StarterKit) have global board's reset wired to the same FTDI IC which is used for both JTAG connection & UART. And what we do internally we use a simple homebrew rff-reset utility (see https://github.com/foss-for-synopsys-dwc-arc-processors/rff-ftdi-reset, kudos to @Palmyr3) to cold-reset our boards.

What we may do is to integrate its utilization by the sanitycheck script, for example we tried it that way:

--- a/scripts/sanity_chk/sanitylib.py
+++ b/scripts/sanity_chk/sanitylib.py
@@ -545,6 +545,10 @@ class DeviceHandler(Handler):
 
     def handle(self):
         out_state = "failed"
+        os.system('rff-reset --serial 251642000087')
+        time.sleep(5)
 
         if self.suite.west_flash:
             command = ["west", "flash", "--skip-rebuild", "-d", self.build_dir]

Indeed that's just a mock-up and we should do it more-elegant and still quite universal because upcoming MDB-runner (#24806) will also benefit from this feature.

Also if we need to package rff-reset in the Zephyr's SDK. That we may do super-easy via https://github.com/zephyrproject-rtos/sdk-ng/tree/master/meta-zephyr-sdk or in any other way given simplicity of the utility and not that many dependencies (just libftdi & libusb). Here I guess @stephanosio might suggest what's the best option ATM and looking forward.
@abrodkin abrodkin added Enhancement Changes/Updates/Additions to existing features area: Boards area: ARC ARC Architecture Hardware Support labels Jul 6, 2020
@abrodkin abrodkin self-assigned this Jul 6, 2020
@abrodkin abrodkin mentioned this issue Jul 6, 2020
Closed
IRISZZW added a commit to foss-for-synopsys-dwc-arc-processors/zephyr that referenced this issue Aug 25, 2020
@IRISZZW
sanitycheck: run custom pre script before open the serial port
49d055b 
In some cases it might be a good idea to reset the board for real to
make sure it is completely recovered from some failed state (simple
re-loading of the application binary or even Elf file contents doesn't
affect most of internal CPU states so doesn't help in recovery,
see zephyrproject-rtos#25022 &
zephyrproject-rtos#26665).
And so we may want to utilize some external utility which triggers the
hard reset (in case of ARC boards it is
https://github.com/foss-for-synopsys-dwc-arc-processors/rff-ftdi-reset).
So we need to have a way to execute an external command before each and
every test.

Now given we already have quite some call-backs we try to use them
before re-inventing the wheel. And pre_script seem to be a good option
with just on minor note - it is called after serial port gets open.
And while in some cases it might be OK if serial port on the board is
not affected by the board's reset, if it is affected we'll be losing
connection on reset (and that's the case with ARC boards BTW as the
FTDI USB-to-Serial IC is also wired to the reset signal on most of
the boards). That said we just move invocation of pre_script before
opening the serial port and everything should be good now.

Signed-off-by: Watson Zeng <[email protected]>
@IRISZZW IRISZZW mentioned this issue Aug 26, 2020
Merged
carlescufi pushed a commit that referenced this issue Aug 31, 2020
@IRISZZW @carlescufi
sanitycheck: run custom pre script before open the serial port
3b43d94 
In some cases it might be a good idea to reset the board for real to
make sure it is completely recovered from some failed state (simple
re-loading of the application binary or even Elf file contents doesn't
affect most of internal CPU states so doesn't help in recovery,
see #25022 &
#26665).
And so we may want to utilize some external utility which triggers the
hard reset (in case of ARC boards it is
https://github.com/foss-for-synopsys-dwc-arc-processors/rff-ftdi-reset).
So we need to have a way to execute an external command before each and
every test.

Now given we already have quite some call-backs we try to use them
before re-inventing the wheel. And pre_script seem to be a good option
with just on minor note - it is called after serial port gets open.
And while in some cases it might be OK if serial port on the board is
not affected by the board's reset, if it is affected we'll be losing
connection on reset (and that's the case with ARC boards BTW as the
FTDI USB-to-Serial IC is also wired to the reset signal on most of
the boards). That said we just move invocation of pre_script before
opening the serial port and everything should be good now.

Signed-off-by: Watson Zeng <[email protected]>
@abrodkin
Copy link
Collaborator Author

@nashif, @galak is there any interest in bundling rdd-reset (https://github.com/foss-for-synopsys-dwc-arc-processors/rff-ftdi-reset) utility for resetting ARC devboards in the Zephyr SDK?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@abrodkin abrodkin

Labels
area: ARC ARC Architecture area: Boards Enhancement Changes/Updates/Additions to existing features
Projects
None yet
Milestone
No milestone
1 participant
@abrodkin