New 'labman' tool

[Heiko Schocher]

Hello Stefano,

Am 20.04.2020 um 13:03 schrieb Heiko Schocher:
> 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",

Must be

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

Forgot an example:

class Lab1Lab(connector.SSHConnector, linux.Bash, linux.Lab, linux.Builder):
[...]

     def init(self):
         # check if nfs server is running, if not start it
         ret = self.exec("systemctl", "status", "nfs-client.target")
         if ret[0] != 0:
             ret = self.exec0("sudo", "systemctl", "start", "nfs-client.target")
         # check if tftp server is running, if not start it
         ret = self.exec("systemctl", "status", "tftp.socket")
         if ret[0] != 0:
             ret = self.exec0("sudo", "systemctl", "start", "tftp.socket")

bye,
Heiko
-- 
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