<div dir="ltr">Hi Chris,<div>Lurking RPi Linux user here..</div><div><br></div><div>Are you talking about having the RPI control the reset line to one or more targets?</div><div>Would a GPIO pin be sufficient for that, or would we need another output?</div><div><br></div><div>Also, what would the serial port on the Pi be used for? Would it connect to a test target serial port and host the ser2net program?</div><div><br></div><div>Alan</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 19, 2017 at 7:35 PM, Chris Johns <span dir="ltr"><<a href="mailto:chrisj@rtems.org" target="_blank">chrisj@rtems.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
I am currently looking into getting `rtems-test` to support TFTP loading of<br>
tests to targets that support networking with bootloaders like u-boot that can<br>
boot executables.<br>
<br>
I have added a TFTP server implemented in python to the `rtems-test` command and<br>
each request to the server sends the next test so the tester can cycling through<br>
all the tests. The file requested by the target is ignored.<br>
<br>
I have also added telnet as a tty console so you can get serial data via telnet.<br>
This integrates with the rather useful ser2net package that is widely available.<br>
<br>
If you combine TFTP and telnet you have a nice clean way to support target<br>
testing. The loading is fast, the connections to the testing host is all via the<br>
network and there is no extra complexity of JTAG and related software or the<br>
need to write to flash devices that can fail or wear.<br>
<br>
However there is a simple but important piece missing, recovery when a test<br>
fails due to the target locking up. There needs to be a way to reset the board.<br>
<br>
I can add support to the configuration file to use a script that can interface<br>
to networked power switches and the power can be toggled. This is support needs<br>
to be added however these devices and often slow and some targets do not take<br>
kindly to lots of power cycles. Another solution would be some way to toggle an<br>
output that can be connected to the reset of a board. Most boards have reset on<br>
a pin we could connect too.<br>
<br>
I was wondering about a RPi with a commonly available IO board and a Linux image<br>
we provide as an SD image we document as a standard test support kit. The RPi<br>
could have ser2net ready to go and a way to control outputs via telnet.<br>
<br>
I know there are RPi Linux users lurking in our community so I am wanting to<br>
draw on the expertise we have to create a small project to do this.<br>
<br>
To highlight the importance testing of master (4.12) on real hardware, I spot<br>
checked on a Beaglebone Black yesterday a few tests and I have found minimum and<br>
dl02 do not finish. That is 2 out of 10 or so tests I have tried that fails.<br>
<br>
I am after ideas for hardware, software and most all volunteers. Please join in.<br>
<br>
Chris<br>
______________________________<wbr>_________________<br>
devel mailing list<br>
<a href="mailto:devel@rtems.org">devel@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/<wbr>mailman/listinfo/devel</a><br>
</blockquote></div><br></div>