[tbot] Testcase / Scripting JTAG Debugger
Stefano Babic
sbabic at denx.de
Mon Dec 10 08:32:22 UTC 2018
On 09/12/18 18:54, Wolfgang Denk wrote:
> Hallo Harald,
>
> In message <4c44dbd1e71be5555964e5e9a5c9fdd480590569.camel at denx.de> you wrote:
>>
>>> - 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.
>
> Hm... it's a pity that SSH is special. Can we not abstract fro the
> actual communcation media and protocol? I mean, "ssh foo", "rlogin
> bar", "telnet baz nnn" or "cu system" more or less all do the same
> thing: setting up a communication channel.
>
> I would find it really nice if we would leave the decision which
> tools [cu, kermit, minicom, ...] / media [serial, TCP/IP, CAN, ...]
> / protocols one wants to use to the end user, without needing to add
> specific code for each of these.
If I understand well, this is already done with the Channel abstraction.
We define a method connect() (but this in the board setupt) to identify
the protocol. If we think the BDI as a board to be tested, we could
write something like:
class BDI(board.board):
def connect(self) -> channel.channel
return self.lh.new_channel("telnet bdi")
However, BDI is not a board. It is (like console) just another way to
drive the device under test.
>
> Is this possible?
>
>>> 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 ...)
>
> Well, the BDI connection would use "telnet" protocol so I don;t
> think this is related to the sshd configuration?
>
>> 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 ...
>
> This is what I mean: I don;t want to add gdbserver or BDI support.
> I just want to have the ability to connect myself to such tools.
Right - anyway, we need some way to assign a BDI to a board - something
like in a testcase:
lh = cx.enter_context(tbot.acquire_lab())
b = cx.enter_context(tbot.acquire_board(lh))
bdi = lh.acquire_bdi(b)
bdi.exec (<raw command as in debugger's manual>)
> Actually I have no idea what else one might want to use - but I can
> come up with a pretty long lsit - more tools / types of coneections
> you ever want to implement as special cases :-)
Regards,
Stefano
--
=====================================================================
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================
More information about the tbot
mailing list