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

older
Re: [U-Boot] U-boot hangs in mtest...

Niklaus Giger

30 Jul 2009 30 Jul '09

8:32 a.m.

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

Show replies by date

Wolfgang Denk

30 Jul 30 Jul

9:07 a.m.

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@denx.de It is dangerous to be sincere unless you are also stupid. - George Bernard Shaw

Detlev Zundel

12:14 p.m.

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@denx.de

Niklaus Giger

2:27 p.m.

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

Detlev Zundel

6:42 p.m.

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@denx.de

Detlev Zundel

6:53 p.m.

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@denx.de

Niklaus Giger

31 Jul 31 Jul

10:18 a.m.

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

5763

Age (days ago)

5764

Last active (days ago)

List overview

Download

6 comments

3 participants

tags (0)

participants (3)

Detlev Zundel
Niklaus Giger
Wolfgang Denk