New 'labman' tool

Heiko Schocher hs at denx.de
Mon Apr 20 13:03:55 CEST 2020


Hello Stefano,

Am 20.04.2020 um 10:47 schrieb Stefano Babic:
> Hi Simon,
> 
> On 19.04.20 20:31, Simon Glass wrote:
>> Hi,
>>
>> I have been fiddling with setting up a lab and have found it quite a
>> pain. Lots of USB connections and things sometimes break.
>>
>> The collection of pytest, udev and tbot scripts that I end up with is
>> hard to manage and error-prone. I decided that I really wanted a
>> central database to keep control of this.
>>
>> Hubs are a pain because their internal numbering does not always
>> correspond to their visible port numbers.
>>
>> Also when something goes wrong with a component in the lab, it is hard
>> to know which one is broken and which port it is on.
>>
>> So I have started something called labman to help with this. It can
>> generate simple tbot scripts, check that all components are working
>> and help with simple management tasks.
>>
>> Please see the README and let me know what you think.
>>
>> https://github.com/sglass68/u-boot/tree/labman/tools/labman
>>
> 
> Thanks to share this - I will check this in my environment. Anyway, we
> are fighting with same problems, and Wolfgang has exposed an alternative
> way to do this. So I take the occasion because I have a different way,
> too, and I would like to share - I am also not very fond of WiFI actors
> in my network, and I mostly work with USB serial adapter.
> 
> My way is to use a Raspi as terminal server with "ser2net". Because
> ttyUSB changes at each boot, I decided to detect which is the new ttyUSB
> instead of trying to force it via udev rule - let's say, if you cannot
> fight them, join them !
> 
> I built an Image for Raspberry based on OE
> (github/sbabic/meta-swupdate-boards), the image contains:
> 
> - ser2net
> - python3
> - openOCD for JTAG over Ethernet
> - Lua
> - a tool to driver a Lab PowerSupply (Power / Power off)
> 
> I wrote a small Python daemon that returns the mapping between target
> and tty. In fact, if the ttyUSBX changes, the topology is always the
> same. A target "X" that is connected to port 4 of second Hub will always
> be connected to that port.
> The small daemon checks in a file-database as "target" <--> "topology" like:
> 
> wandboard 	usb	usb1/1-1/1-1.2/1-1.2.3/1-1.2.3:1.0
> mira		usb	usb1/1-1/1-1.2/1-1.2.4/1-1.2.4:1.0
> target1		usb	usb1/1-1/1-1.2/1-1.2.7/1-1.2.7:1.0
> target2		usb	usb1/1-1/1-1.2/1-1.2.2/1-1.2.2:1.0
> target3		usb	usb1/1-1/1-1.2/1-1.2.6/1-1.2.6:1.0
> target4		usb	usb1/1-1/1-1.2/1-1.2.5/1-1.2.5:1.0
> 
> On tbot lab host, I have then just a simple script "connect":
> 
> !/bin/bash
> 
> SERVERS='raspbx.fritz.box raspberrypi3.fritz.box'
> if [ "x$2" != "x" ];then
> 	SERVERS=$2
> fi
> PORT=5005
> 
> for server in ${SERVERS};do
> 
> 	target=`echo $1 | nc ${server} ${PORT}`
> 	echo TARGET $target
> 	tserver=`echo $target| awk -F':'  '{print $1}'`.fritz.box
> 	port=`echo $target | awk -F':' '{print $2}'`
> 
> 	if [ ! -z $port ];then
> 		telnet ${tserver} ${port}
> 		exit 0
> 	fi
> done
> 
> echo "Target not found" $1
> 
> 
> And at the end, this simplifies my board setup in tbot, because I have
> the same way to connect to the board:
> 
>      def connect(self, mach):
>          return mach.open_channel("connect", self.name)

Just my 2 cents ...

I use for each customer a raspberry pi as lab pc ... (and put the complete
testsetup (board to test, PI, relais,... into a plastic box)).

Now I can use the gpios from the PI in conjunction with simple relais [1]
for powering on/off the boards or switch bootmode ... no usb/no ethernet
needed for this tasks.

For the serial console I also use usb2serial adapter, but I have
no problems after reboots because I use..

/dev/serial/by-id/...

which stay the same ... and, as I have for each customer a seperate
PI, cable mess does not grow ... This approach scales very well.
(Ok, you need some PIs ... )

BTW: tbot also runs fine on the PI ...

As I use kermit for connecting to the serial console, I only
have a kermit resource file for each board (also I use kermit because
you can test u-boots loadb command ...):

     def kermit_connect(self, mach: linux.LinuxShell) -> channel.Channel:
         KERMIT_PROMPT = b"C-Kermit>"
         ch = mach.open_channel("kermit", f"/home/{self.host.username}/kermrc_{self.name})
         try:
             yield ch
         finally:
             ch.sendcontrol("\\")
             ch.send("C")
             ch.read_until_prompt(KERMIT_PROMPT)
             ch.sendline("exit")

BTW: You can also use ssh for logging into linux console, instead serial console ...

     def ssh_connect(self) -> channel.Channel:
         return mach.open_channel("ssh", self.host.username[self.name], "@" + 
self.host.boardip[self.name])

     def connect(self, mach: linux.LinuxShell) -> channel.Channel:
         if self.name == 'piinstall':
             return self.ssh_connect(mach)
         else:
             return self.kermit_connect(mach)

with configuration:

class Lab1Lab(connector.SSHConnector, linux.Bash, linux.Lab, linux.Builder):
     [...]
     ethaddr = {
         "wandboard" = "00:1f:7b:b2:00:0f",
     }
     serverip = {
         "wandboard" : "192.168.3.1",
         "k30rf" : "192.168.7.1",
     }
     boardip = {
         "k30rf" : "192.168.7.37",
         "wandboard" : "192.168.3.21",
     }
     username = {
         "k30rf" : "root",
         "wandboard" : "root",
     }

So you can configure your stuff nicely within tbot class and in python style...

More benefit of using a pi as lab PC is, you can have for each board
a seperate tftp, nfs, dhcp server running, completly seperated from the
rest of your network in your office and connect the pi through wifi to
your office...

If you need the setup on your desk, put the plastic box on the desk, if
no longer needed, put it whereever you find a place for it... or take
it for a demo with you to the customer ... no special efforts needed here
compared against a fix setup... where you have to start fiddling out
all the cables, boards, check if all works again ...)

Also:
New customer -> clone PIs sd card -> insert it into new PI, mostly finished
with lab setup for new customer...

I am not a friend of setting up a lot of things through scripts resist
on lab PC, or better spoken out of tbot ... you should use tbot for such
tasks... thats the reason why tbot exists... if you write a script ...
write a tbot testcase instead... so we can share them...

You can add to your lab class the init function:

http://tbot.tools/modules/machine.html#tbot.machine.Machine.init

This function gets called, after tbot is connected to your lab machine,
and you can use it for checking/initialzing lab specific stuff.

May this function helps here a lot ... ?

bye,
Heiko
[1] https://www.amazon.de/gp/product/B07RNWLXJM/ref=ppx_yo_dt_b_asin_title_o06_s00?ie=UTF8&psc=1
-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: hs at denx.de


More information about the tbot mailing list