[tbot] Testcase / Scripting JTAG Debugger

[Harald Seiler]

Hi Wolfgang,

On Fri, 2018-12-07 at 15:31 +0100, Wolfgang Denk wrote:
> 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.

SSH connections are already possible[1], they are used for example for the
build-host.

> > > > 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.

Yes, you can have as many connections as you want! (Actually, at the moment it
is limited by the number of channels configured for your sshd but if that ever
gets to be a problem, I could implement opening secondary sessions ...)

> > 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.

In tbot's design this looks a little different, but essentially this
is what is planned.  At the moment I only have Linux and U-Boot, as
soon as we add gdbserver, BDIs, etc, I need to refactor that code a
little, but that's not a big deal ...

> 
> Best regards,
> 
> Wolfgang Denk
> 

[1]: https://rahix.de/tbot/module-linux.html#tbot.machine.linux.SSHMachine
-- 
Harald

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-62  Fax: +49-8142-66989-80   Email: hws at denx.de