[tbot] Testcase / Scripting JTAG Debugger
Wolfgang Denk
wd at denx.de
Fri Dec 7 14:31:17 UTC 2018
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
More information about the tbot
mailing list