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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox