[U-Boot] DUTS: missing pieces for a beginner

[U-Boot] DUTS: missing pieces for a beginner

[Niklaus Giger]

Hi

I would like to do some more extensive tests with the U-boot and took a look 
at http://www.denx.de/wiki/DUTS/DUTSDocs

I think that the wiki is somehow out of date as examples as the following
a) ./duts b should be rewritten to /duts -showconfig ?
Is this true?

b) ./duts  -showconfig v38b gives on my system the following output:
>Skipping testcase UBootDateHelp because of unfulfilled requirement 'rtc'
>Skipping testcase UBootDate because of unfulfilled requirement 'rtc'
>Skipping testcase UBootSleepRTC because of unfulfilled requirement 'rtc'
>Skipping testcase UBootCmdDttHelp because of unfulfilled requirement 'dtt'
>Skipping testcase UBootCmdDtt because of unfulfilled requirement 'dtt'
>Skipping testcase UBootI2cHelp because of unfulfilled requirement 'i2c'
>Skipping testcase UBootIdeHelp because of unfulfilled requirement 'ide'
>Skipping testcase UBootDiskbootHelp because of unfulfilled requirement 'ide'
>Skipping testcase UBootNandHelp because of unfulfilled requirement 'nand'
>Skipping testcase UBootNandInfo because of unfulfilled requirement 'nand'
>Skipping testcase UBootNandBad because of unfulfilled requirement 'nand'
>Skipping testcase UBootNandErase because of unfulfilled requirement 'nand'
>Skipping testcase UBootNandWrite because of unfulfilled requirement 'nand'
>Skipping testcase UBootNandRead because of unfulfilled requirement 'nand'
>Details for configuration view '_default'
>Kernel context 'linux'
>
>                prompt "# "
>                alt_prompt "~> "
>                image "/tftpboot/$BOARD/uImage-duts"
>                descr "config/VL_linux_context.tcl"
>
>Firmware context 'u-boot'
>
>                prompt "=> "
>                image "/tftpboot/$BOARD/u-boot.bin-duts"
>                descr "config/VL_uboot_context.tcl"
>
>Host context 'host'
>
>                prompt "]$ "
>                descr "config/VL_host_context.tcl"
>                shell "bash"

c) "./duts lt" should be rewritten as "./duts -tc ? v38b"
d) "./duts -d testsystems/ltp/ lt" shoud be rewritten to
"./duts -td testsystems/ltp -tc ? v38b"

I would volunteer to update the wiki if somebody can confirm that my 
observations are correct.

Even looking for an hour or so at the sources. I am unable to find an answer 
which files I should modify to run tests for my sequoia board.

My setup ist that 
$ /user/local/bin power 1 on
powers up the 5V input of my sequoia board and under /dev/ttyUSB3 I see the U-
Boot output after power on.

I would like to start with a  simple testcase and tried running
>This gives me the following output
>
>Testcases directory: ./testsystems/dulg
>Selected config: _default
>List of selected test cases:
>UBootBaseHelp
>
>
>
>#####################################
># running test case: UBootBaseHelp
>#####################################
>
>ERROR: couldn't spawn 'connect'?!

I would appreciate any hints. As the section "I"ntroducing suppport for a new 
VL " is just a little be too small for me. E.g. how can I add a new VL. Is 
there an example I just can copy and adjust it? Where do I specify the tty 
device for the sequoia?

Best regards
-- 
Niklaus Giger

[U-Boot] DUTS: missing pieces for a beginner

[Wolfgang Denk]

Dear Niklaus,

In message <200907300832.15979.niklaus.giger@member.fsf.org> you wrote:
> 
> I would like to do some more extensive tests with the U-boot and took a look 
> at http://www.denx.de/wiki/DUTS/DUTSDocs
> 
> I think that the wiki is somehow out of date as examples as the following
> a) ./duts b should be rewritten to /duts -showconfig ?
> Is this true?

I think this is easily possible. Detlev and Vitaly have been working
heavily on DUTS in the past months, and I can imagine they did not
always update the documentation.

Detlev, maybe you can comment here?

> b) ./duts  -showconfig v38b gives on my system the following output:

Again, this is better for Detlev to comment...

> I would volunteer to update the wiki if somebody can confirm that my 
> observations are correct.

Cool - thank in advance. Detlev, say yes, and quickly :-)

> >ERROR: couldn't spawn 'connect'?!
> 
> I would appreciate any hints. As the section "I"ntroducing suppport for a new 
> VL " is just a little be too small for me. E.g. how can I add a new VL. Is 
> there an example I just can copy and adjust it? Where do I specify the tty 
> device for the sequoia?

"connect" is a small shell script we use internally:

===============================================================================
#!/bin/bash

if [ $# != 1 ] ; then
	echo "Usage: $0 target" >&2
	exit 1
fi

###	Server	Target
LIST="
	ts2	acadia		7029
	ts0	ads5121
	ts0	ads8272
	ts0	arches
	ts0	aria
	ts1	bamboo
	ts0	beagle
	ts9	bifas
	ts1	bubinga
	ts2	canyonlands	7009
[... list truncated ...]
	ts1	walnut
	ts2	yellowstone	7019
	ts2	yosemite	7022
	ts0	yucca
	ts0	yucca_a
	ts2	mgcoge11	7026
"

CMD=''
TRG=''

case "$1" in

-l|-h|--help|-?)
	echo 'Known targets:'
	while read srv trg prt
	do
		[ "$trg" ] && echo $trg
	done <<_E_O_F_ | \
	pr -o 4 -t -5 -w76
$LIST
_E_O_F_
	exit 0
	;;

*)	while read srv trg port
	do
		tmp1=`echo $trg | tr '[:upper:]' '[:lower:]'`
		tmp2=`echo  $1  | tr '[:upper:]' '[:lower:]'`
		if [ "$tmp1" = "$tmp2" ]
		then 
			TRG=$trg
			if [ -z "$port" ]
			then
				CMD="/usr/bin/rlogin $srv -l $trg"
			else
				CMD="/usr/bin/telnet $srv $port"
			fi
		fi
	done <<_E_O_F_
$LIST
_E_O_F_
	;;
esac

if [ -z "$CMD" ]
then
	echo "Unknown target: $1" >&2
	exit 1
fi
echo "### Connect to \"$TRG\" using command: $CMD"
exec $CMD
=========================================================================

We are using two types of terminal servers here: one type (for
example Lantronix ETS types, or Linux boxen with multiport serial
cards running our "tserver" package, see
ftp://ftp.denx.de/pub/tools/tserver-0.17-4.src.rpm) can be connected
using a "rlogin server_name port_name" command, while the other type
(for example Cyclades TS2000 / TS3000) require a "telnet server_name
port_number" command).

In your setup you could use our connect script, and install the
"tserver" package on your host system; then use an entry like

	# port  device          parameters
	#
	sequoia	/dev/ttyUSB3	115200,8,N,1

in  your  /etc/tserver.conf  file  -  then  you  can  use  a  "rlogin
server_name  sequoia"  command  to  attach  to  this port which works
nicely with the above tools.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
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
It is dangerous to be sincere unless you are also stupid.
                                                - George Bernard Shaw

[U-Boot] DUTS: missing pieces for a beginner

[Detlev Zundel]

Hi Niklaus,

> I would like to do some more extensive tests with the U-boot and took a look 
> at http://www.denx.de/wiki/DUTS/DUTSDocs

Oh, this is most welcome.

> I think that the wiki is somehow out of date as examples as the following
> a) ./duts b should be rewritten to /duts -showconfig ?
> Is this true?

I guess there is no way I can deny this ;)

> b) ./duts  -showconfig v38b gives on my system the following output:
>>Skipping testcase UBootDateHelp because of unfulfilled requirement 'rtc'
>>Skipping testcase UBootDate because of unfulfilled requirement 'rtc'
>>Skipping testcase UBootSleepRTC because of unfulfilled requirement 'rtc'
>>Skipping testcase UBootCmdDttHelp because of unfulfilled requirement 'dtt'
>>Skipping testcase UBootCmdDtt because of unfulfilled requirement 'dtt'
>>Skipping testcase UBootI2cHelp because of unfulfilled requirement 'i2c'
>>Skipping testcase UBootIdeHelp because of unfulfilled requirement 'ide'
>>Skipping testcase UBootDiskbootHelp because of unfulfilled requirement 'ide'
>>Skipping testcase UBootNandHelp because of unfulfilled requirement 'nand'
>>Skipping testcase UBootNandInfo because of unfulfilled requirement 'nand'
>>Skipping testcase UBootNandBad because of unfulfilled requirement 'nand'
>>Skipping testcase UBootNandErase because of unfulfilled requirement 'nand'
>>Skipping testcase UBootNandWrite because of unfulfilled requirement 'nand'
>>Skipping testcase UBootNandRead because of unfulfilled requirement 'nand'
>>Details for configuration view '_default'
>>Kernel context 'linux'
>>
>>                prompt "# "
>>                alt_prompt "~> "
>>                image "/tftpboot/$BOARD/uImage-duts"
>>                descr "config/VL_linux_context.tcl"
>>
>>Firmware context 'u-boot'
>>
>>                prompt "=> "
>>                image "/tftpboot/$BOARD/u-boot.bin-duts"
>>                descr "config/VL_uboot_context.tcl"
>>
>>Host context 'host'
>>
>>                prompt "]$ "
>>                descr "config/VL_host_context.tcl"
>>                shell "bash"

Looks ok to me, what is the question? ;)

> c) "./duts lt" should be rewritten as "./duts -tc ? v38b"


A general warning - most of my recent changes went into making calling
duts more consistent with other Unix utilities.  Personally I think I
made good progress here, but if changes are needed here I am still open
for them.  That is one reason why I wasn't so sure on updating the docs
as the work is not completely finished.

> d) "./duts -d testsystems/ltp/ lt" shoud be rewritten to
> "./duts -td testsystems/ltp -tc ? v38b"

Yes indeed.  I tried to have this '?' functionality for all possible
parameters to be able to inspect the possible values.

> I would volunteer to update the wiki if somebody can confirm that my 
> observations are correct.

Please do - I'm more than happy to work with you in this respect.
Thanks in advance for tackling this job!

> Even looking for an hour or so at the sources. I am unable to find an answer 
> which files I should modify to run tests for my sequoia board.

Indeed, I know.  If you take a look at the changes in git that we did in
recent months, you will notice that a lot of cleanup has already been
done making the code more transparent, but some areas are still way too
opaque.  I'm more than happy to change this however, as I _do_ know that
people will only start using and contributing once the design is somehow
easy to grasp.

So to answer your question - if you had a setup comparable to our VL,
you shouldn't need to modify anything.  But as you need to use other
commands to control power and connect to a board, you will need to
implement a new (what is currently called a) "context".

> My setup ist that 
> $ /user/local/bin power 1 on
> powers up the 5V input of my sequoia board and under /dev/ttyUSB3 I see the U-
> Boot output after power on.
>
> I would like to start with a  simple testcase and tried running
>>This gives me the following output
>>
>>Testcases directory: ./testsystems/dulg
>>Selected config: _default
>>List of selected test cases:
>>UBootBaseHelp
>>
>>
>>
>>#####################################
>># running test case: UBootBaseHelp
>>#####################################
>>
>>ERROR: couldn't spawn 'connect'?!
>
> I would appreciate any hints. As the section "I"ntroducing suppport for a new 
> VL " is just a little be too small for me. E.g. how can I add a new VL. Is 
> there an example I just can copy and adjust it? Where do I specify the tty 
> device for the sequoia?

Clone config/self-hosted* to config/<whatever>* and work from there.
Then use "duts -c <whatever> sequoia" and dive in :)

The "context" stuff is definitely something we need to work on.  It
wasn't on my top-priority list as it currently works for us and
generalizations are only done correctly when we have multiple test
cases... 

Cheers
  Detlev

-- 
Insider comment on Microsoft releasing Linux Hyper-V driver code under GPLv2:
             "It looks like hell just froze over."
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de

[U-Boot] DUTS: missing pieces for a beginner

[Niklaus Giger]

Hi Detlev and Wolfgang

Thanks for your quick answer and I got a few steps further.

First I created my own version of "connect" (see attached Ruby script).

Now at least I can connect and it seems to work.

Am Donnerstag 30 Juli 2009 12.14:14 schrieb Detlev Zundel:
> Hi Niklaus,
<..>
> > I would appreciate any hints. As the section "I"ntroducing suppport for a
> > new VL " is just a little be too small for me. E.g. how can I add a new
> > VL. Is there an example I just can copy and adjust it? Where do I specify
> > the tty device for the sequoia?
>
> Clone config/self-hosted* to config/<whatever>* and work from there.
> Then use "duts -c <whatever> sequoia" and dive in :)
>
> The "context" stuff is definitely something we need to work on.  It
> wasn't on my top-priority list as it currently works for us and
> generalizations are only done correctly when we have multiple test
> cases...
@Detlev:

I think that my config files don't get loaded (seen with -v and verify by 
putting "p_err "was in ngiger_uboot_context.tcl" into my files.
Here is my snippet:
> ./duts -v  -c ngiger -tc UBootVersion sequoia
><..>
>DUTS: no such directory: './testsystems/dulg/testcases/sequoia'
>DUTS: no target specific TCs for sequoia
>DUTS: Date is 073014232009
>DUTS: ./config exists
>DUTS: './config' exists and accessible, OK
>DUTS: loading configs from ./config/configs.cfg
>DUTS: Loading config description: _default
>DUTS: validating: './config/VL_uboot_context.tcl'
>DUTS: file exists and accessible, OK
>DUTS: validating: './config/VL_linux_context.tcl'
>DUTS: file exists and accessible, OK
>DUTS: validating: './config/VL_host_context.tcl'
>DUTS: file exists and accessible, OK
>DUTS: validating: './config/VL_ops.tcl'
>DUTS: file exists and accessible, OK
>DUTS: loaded 1 config decriptions
>DUTS: method '_device_power_on' found, OK
>DUTS: method '_device_power_off' found, OK
>DUTS: method '_device_connect_target' found, OK
>DUTS: method '_device_connect_host' found, OK
>Selected config: ngiger
>List of selected test cases:
>UBootVersion
>
>confirm to start execution? [y]

And I am not good at hacking using TCL. I do most of my scripting in Ruby as 
it is one of the few languages I have a chance to read my old code and still 
understand it.

Is this a easy fix for you? 

Best regards

Niklaus

> Cheers
>   Detlev

-- 
Niklaus Giger

-------------- next part --------------
A non-text attachment was scrubbed...
Name: connect
Type: application/x-ruby
Size: 915 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20090730/9540febd/attachment.bin 

[U-Boot] DUTS: missing pieces for a beginner

[Detlev Zundel]

Hi Niklaus,

> Thanks for your quick answer and I got a few steps further.

Excellent.

> First I created my own version of "connect" (see attached Ruby script).
>
> Now at least I can connect and it seems to work.

Right - if you only reimplement the methods that we use locally then you
should not need to touch anything basically.  This boils down to
providing a "remote_power" and "connect" utility.

> I think that my config files don't get loaded (seen with -v and verify by 
> putting "p_err "was in ngiger_uboot_context.tcl" into my files.
> Here is my snippet:

[...]

> And I am not good at hacking using TCL. I do most of my scripting in Ruby as 
> it is one of the few languages I have a chance to read my old code and still 
> understand it.

;)

> Is this a easy fix for you? 

It seems like this is a good opportunity to work on this end of duts.
Looking at the code it was pretty clear that it could not work as
expected, so I started somewhat cleaning up around here and freshened my
memory on how this is supposed to work at all.  So do a "git remote
update" on your git tree and pull in the latest changes...

In spite of what I wrote earlier - the whole 'configuration' stuff
pivots on config/configs.tcl.  In here we have configuration
descriptions.  The _default must be first and initializes all "slots"
which can be overriden in subsequent duts_configs.

So If you want to only swap in your operatios, do something in there
like: 

duts_config {
            cfg_device_ops "config/my_ops.tcl"
}

and provide the config/my_ops.tcl.

Sorry my previous answer were based on incorrect memories.

Cheers
  Detlev

-- 
Indeed, the author firmly believes that the best serious work is also
good fun.   We needn't apologize if we enjoy doing research.
                                        -- Donald Knuth
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de

[U-Boot] DUTS: missing pieces for a beginner

[Detlev Zundel]

Hi,

> In spite of what I wrote earlier - the whole 'configuration' stuff
> pivots on config/configs.tcl.  In here we have configuration
> descriptions.  The _default must be first and initializes all "slots"
> which can be overriden in subsequent duts_configs.
>
> So If you want to only swap in your operatios, do something in there
> like: 
>
> duts_config {

That should be a "duts_config my_config {" of course :(

>             cfg_device_ops "config/my_ops.tcl"
> }
>
> and provide the config/my_ops.tcl.

Then run "duts -c my_config ...".

Cheers
  Detlev

-- 
Wissenschaft ohne Verstand ist doppelte Narrheit.
                                    --- Baltasar Gracian
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de

[U-Boot] DUTS: missing pieces for a beginner

[Niklaus Giger]

Hi Detlev
Am Donnerstag 30 Juli 2009 18.53:22 schrieb Detlev Zundel:
> Hi,
>
> > In spite of what I wrote earlier - the whole 'configuration' stuff
> > pivots on config/configs.tcl.  In here we have configuration
> > descriptions.  The _default must be first and initializes all "slots"
> > which can be overriden in subsequent duts_configs.
> >
> > So If you want to only swap in your operatios, do something in there
> > like:
> >
> > duts_config {
>
> That should be a "duts_config my_config {" of course :(
>
> >             cfg_device_ops "config/my_ops.tcl"
> > }
> >
> > and provide the config/my_ops.tcl.
>
> Then run "duts -c my_config ...".
>
> Cheers
>   Detlev
Thanks a lot. Now my TCL-Code is used.
But now I am having problems connecting. I think somehow the pipe|files are 
getting messed up and/or that the power state is not correctly deternined.

I tried picocom and cu. With picocom I did see output, but duts kept
complaing that it had a timeout and couln't spawn DUTS: method
> '_device_connect_host' found, OK
>Selected config: ngiger
>List of selected test cases:
>UBootVersion
>
>confirm to start execution? [y]
>
>####################################
># running test case: UBootVersion
>####################################
>DUTS: current context: 'off', required by the TC: 'u-boot (firmware)'
>DUTS: Niklaus connect
>DUTS: ngiger _device_power_on /usr/local/bin/power
>DUTS: powered on, OK
>Connect to sequoia using command 'picocom  -b 115200 /dev/ttyUSB3 '.
>picocom v1.4
>
>port is        : /dev/ttyUSB3
>flowcontrol    : none
>baudrate is    : 115200
>parity is      : none
>databits are   : 8
>escape is      : C-a
>noinit is      : no
>noreset is     : no
>nolock is      : no
>send_cmd is    : ascii_xfr -s -v -l10
>receive_cmd is : rz -vv
>
>Terminal ready
>
>
>U-Boot 2009.01-rc1 (Dez 20 2008 - 17:09:46)
<..>
> ERROR: ngiger: powered_on ist yes timed out during connection to target 
'sequoia'?!
Then I installed the cu package and tried it like this
>DUTS: Date is 073109322009
>DUTS: ../config exists
>DUTS: '../config' exists and accessible, OK
>DUTS: loading configs from ../config/configs.cfg
>DUTS: Loading config description: _default
>DUTS: validating: '../config/VL_uboot_context.tcl'
>DUTS: file exists and accessible, OK
>DUTS: validating: '../config/VL_linux_context.tcl'
>DUTS: file exists and accessible, OK
>DUTS: validating: '../config/VL_host_context.tcl'
>DUTS: file exists and accessible, OK
>DUTS: validating: '../config/VL_ops.tcl'
>DUTS: file exists and accessible, OK
>DUTS: Loading config description: ngiger
>DUTS: validating: '../config/ngiger_ops.tcl'
>DUTS: file exists and accessible, OK
>DUTS: loaded 2 config decriptions
>DUTS: method '_device_power_on' found, OK
>DUTS: method '_device_power_off' found, OK
>DUTS: method '_device_connect_target' found, OK
>DUTS: method '_device_connect_host' found, OK
>Selected config: ngiger
>List of selected test cases:
>UBootVersion
>
>confirm to start execution? [y]
>
>####################################
># running test case: UBootVersion
>####################################
>DUTS: current context: 'off', required by the TC: 'u-boot (firmware)'
>DUTS: Niklaus connect via 'cu -l /dev/ttyUSB3 -s 115200 powered_on' no
>
>ERROR: couldn't spawn 'connect'?!
A question here: while does duts sometimes connect even when the global 
power_on status is no? Where does it get stored? I think my local procedure 
is_powered_on in ngiger_ops.tcl never gets called.

Thanks again for your help.

Best regards

---
Niklaus Giger