[tbot] Testcase / Scripting JTAG Debugger

[Wolfgang Denk]

Dear Harald,

In message <1544174854.2518.6.camel at denx.de> you wrote:
> 
> > ok, what a pity. I thought tbot uses it to rescue a board after
> > installing a broken bootloader.
> 
> Hmm, maybe Heiko's version did ...

Yes, it did.

Actually opening a telnet connection to a BDI to run interactive
commands at the BDI firmware prompt is not that much different from
opening a telnet connection to a terminal server and running
onteractive commands at a boards firmware (U-Boot) prompt.

I guess Heiko's implementation does not fit nicely into hte new tbot
design, but in any case we should:

- re-add this feature asap
- maybe even provide a generic way to "open a connection" to some
  other device and run interactive commands on it.  This could abso
  be (for example) a SSH connection to some other board which serves
  as a test partner, say when running CAN or TCP/IP tests between
  two boards.

> > > So, technically you would need to implement a new machine for this.  Like
> > > a BdiMachine, that has the ip address configurable.  I don't have any
> > > documentation up for how one would go about doing this I am afraid ...
> > 
> > It is like a new channel for a board. So board has console and can have
> > a BDI attached to it. Both can be used at the same time to control the
> > board.
> > 
> > More advanced testcases can use both of them. Board is started from BDI,
> > a breakpoint is set, command are sent via the console, when break is hit
> > some BDI commands are sent, then board runs againm and so on.

I think is should be possible to have several such "connections"
open in a test case - console and BDI are just two examples of what
we frequently need.

> I think for now we should just implement BDI support, because that is what is
> used here at DENX.  If the need arises, we can add support for other debuggers
> later on.

I do not think this should be a detail we need to care about here.
Can we not keep the implementation generic and just provide some
function  create_connection(protocol, address, port) ?

That would cover telnet, SSH, gdbserver, etc. [even serial if we
define a protocol description for that].  The implementation of the
actual communication (i. e. which commands to run on the BDI) would
then be again a matter of the test case.  OK, I guess we also need
to be able to configure the prompt we expect, and a method to
trigger sending a prompt at startup.


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
When the ax entered the forest, the trees said, "The handle is one of
us!"                                               -- Turkish proverb