From: Martin Egholm Nielsen <martin@egholm-nielsen.dk>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] Re: Using u-boot as application-firmware upgrader / Performing logical operations?
Date: Thu, 23 Dec 2004 10:14:28 +0100 [thread overview]
Message-ID: <cqe29k$bj8$1@sea.gmane.org> (raw)
In-Reply-To: <20041222162357.E6E4DC1430@atlas.denx.de>
Hi,
>>Ohh, of course - that's the way I'll do it. That is, saving it in an
>>environment-variable.
>>In order to change it from Linux, access to the NOR-flash is required,
>>right?! I'm not quite sure I have that?
> Of course yoiu have - through the MTD layer (and the stuff in the
> tools/env directory).
Ok, then I'm sure my board's kernel dosn't detect the NOR. The only
mtd-messages I get concerns the NAND.
>>Dooh! I forgot that tftp use UDP. Then "responding" means one correct
>>response from the tftp-server within x seconds. I guess there is a
> Define "correct" response. What about time outs later?
That would be ok.
What I want is u-boot to try to see if there is a tftp-server connected
(meaning that someone is trying to upgrade the firmware). If not:
continue rapidly into Linux and launch the application. I don't wanna
spend too much time hanging in u-boot if the reboot were, say, due to a
powerfailure.
>>Hence, what I want is perhaps (?) environment variables controlling how
>>how many retries, the interval between each "T"-try, and the amount of
>>tries before abondoning...
> Perhaps.
:-)
I know that is exactly what I'm looking for...
>>>>Hence, what I'd like, was a way to determine if the download was
>>>>successfull - e.g. by comparing the return value for the command.
>>>You can do that easily - just not by timeout only.
>>How?
> Use the return code in some conditional, like an "if tftp ... ; then
> ... ; fi" or some "tftp ... && ..." - whatever you use in other shell
> scripts, too.
>>Is there a document describing these scripting possibilities?
> man sh? Ok, ok, the hush shell does not provide every bell and
> whistle the bash has, but it's a pretty complete thing. See the
> busybox docs for more information.
Ahaaaaa!!! There we have it!
If one does not know the name of it - one (me) will look under
"5.11. U-Boot Scripting Capabilities" (which is empty).
and not in the correct (faq-) section:
"14.2.10. How the Command Line Parsing Works"
That title is not intuitive to me. I read: "How the 'Old, simple command
line parser' works".
IMHO that beautiful section shouldn't be in a FAQ... :o)
Now, I just need to recompile with the enabling parameter (CFG_HUSH_PARSER).
BR,
Martin
next prev parent reply other threads:[~2004-12-23 9:14 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-12-22 9:23 [U-Boot-Users] Using u-boot as application-firmware upgrader / Performing logical operations? Martin Egholm Nielsen
2004-12-22 10:57 ` Wolfgang Denk
2004-12-22 12:29 ` [U-Boot-Users] " Martin Egholm Nielsen
2004-12-22 14:17 ` Wolfgang Denk
2004-12-22 15:57 ` Martin Egholm Nielsen
2004-12-22 16:23 ` Wolfgang Denk
2004-12-23 9:14 ` Martin Egholm Nielsen [this message]
2004-12-22 14:44 ` Wolfgang Denk
2004-12-22 15:17 ` Martin Egholm Nielsen
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='cqe29k$bj8$1@sea.gmane.org' \
--to=martin@egholm-nielsen.dk \
--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