From: Detlev Zundel <dzu@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] DUTS: missing pieces for a beginner
Date: Thu, 30 Jul 2009 12:14:14 +0200 [thread overview]
Message-ID: <m2ab2meavd.fsf@ohwell.denx.de> (raw)
In-Reply-To: <200907300832.15979.niklaus.giger@member.fsf.org> (Niklaus Giger's message of "Thu, 30 Jul 2009 08:32:14 +0200")
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
next prev parent reply other threads:[~2009-07-30 10:14 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-30 6:32 [U-Boot] DUTS: missing pieces for a beginner Niklaus Giger
2009-07-30 7:07 ` Wolfgang Denk
2009-07-30 10:14 ` Detlev Zundel [this message]
2009-07-30 12:27 ` Niklaus Giger
2009-07-30 16:42 ` Detlev Zundel
2009-07-30 16:53 ` Detlev Zundel
2009-07-31 8:18 ` Niklaus Giger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m2ab2meavd.fsf@ohwell.denx.de \
--to=dzu@denx.de \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.