[tbot] Testcase / Scripting JTAG Debugger

[Stefano Babic]

Hi Harald,

On 07/12/18 10:27, Harald Seiler wrote:
> Hi Stefano,
> 
> On Fri, 2018-12-07 at 10:01 +0100, Stefano Babic wrote:
>> On 06/12/18 14:51, Harald Seiler wrote:
>>> Hi Stefano,
>>>
>>> On Thu, 2018-12-06 at 14:40 +0100, Stefano Babic wrote:
>>>> Hi,
>>>>
>>>> there are some ready to use testcases for the BDI debugger ?
>>>
>>> No, unfortunately not ... Yet!
>>>
>>
>> ok, what a pity. I thought tbot uses it to rescue a board after
>> installing a broken bootloader.
>>
> 
> Hmm, maybe Heiko's version did ...

I think it could be very useful if you write (and add to doc) a roadmap
of the project, starting with the features from the old tbot that should
be done first.

> 
>>>> The debugger does not allow scripting - anyway, this is something tbot
>>>> can really help.
>>>
>>> Yes, this is exactly what tbot is supposed to automate for you.  I have had
>>> debugger support in the back of my head for a long time, but haven't yet
>>> had time to implement anything ...
>>
>> ok - I have supposed there is something.
>>
>> My current problem can be solved in other ways, Lukasz mentions one. I
>> have just to push BDI commands without checking the status of the board,
>> so I can use even ncat for it.
>>
>>>
>>>> I have an old processor where the Flash is not supported by the debugger
>>>> fw, but I can rescue the  board after bricking issueing a long list of
>>>> CFI commands. What I would like to have is a "BDI" board and a
>>>> @tbot.testcase where I can put in a list a set of commands.
>>>>
>>>> Is there something to be used ?
>>>
>>> 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 might be able to hack something basic up tomorrow that you can expand
>>> on as you need.
>>
>> Do not be in hurry.
>>
>>>
>>> Unfortunately I don't have much experience with bdi so I am not sure
>>> what would be needed.  As far as I understood it, we have two interfaces,
>>> the telnet console and a gdbserver.
>>
>> Yes, they work at the same time - but this depends on JTAG debugger.
>> Other debuggers have a different interface.
>>
>> For very low-level interaction as what I need now, telnet must be used.
> 
> 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 guess you need both to work with
>>> a BDI effectively?
>>>
>>> In that case, we'd have something like:
>>>
>>> 	with bdi.BdiMachine(lh) as dbg:
>>> 	    dbg.exec0("run", "something", "on", "telnet", "console")
>>> 	    dbg.gdb0("run", "something", "on", "gdb", "session")
>>>
>>> Does that make sense?
>>
>> Yes - this can become more complicate if debugger functionalities
>> (breakpoints,..) are used. This would require multithreading in tbot
>> (doing something while waiting that a breakpoint is hit). I do not want
>> to add so much stuff now, I think the main concern is to provide
>> functionalities and features present in the old tbot version.
> 
> Actually, it doesn't require multithreading ;) And that is very good,
> because multithreading in tbot would be horrible to deal with ... What
> we need instead is asynchronous command execution, which is not here
> yet either, sadly ...

Not really - if we set a breakpoint, this can hit at any time. This
requires a thread listening from the debugger channel. I guess this case
cannot be solved simply with async command.

Anyway, this becomes a more complex case and it is not worth to try to
implement this for just a few cases - better concentrate on other features.

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