[U-Boot-Users] Conditional 'hush' script examples anyone?
Greetings
I've RTFM'd and I've FAQ'd but I still can't find a single example of the use of conditionals with the u-boot hush shell command line.
I assume its only usable with an autoscript or can environmental variables hold complete conditional blocks. Most interested in this so that I can make sensible decisions about what to do if an image CRC is bad for example (or when to boot a different image after an upgrade).
Examples, examples, examples is what I'm looking for rather than a dry explanation about hush (which I can get close to from any book that documents bash!!)
Many thanks
Dear Robin,
in message 3F601160.5050803@tait.co.nz you wrote:
I've RTFM'd and I've FAQ'd but I still can't find a single example of the use of conditionals with the u-boot hush shell command line.
man sh :-)
I assume its only usable with an autoscript or can environmental
What makes you think so?
variables hold complete conditional blocks. Most interested in this so that I can make sensible decisions about what to do if an image CRC is bad for example (or when to boot a different image after an upgrade).
You can use conditionals everywhere: in interactive input, in environment variables, in scripts ....
Examples, examples, examples is what I'm looking for rather than a dry explanation about hush (which I can get close to from any book that documents bash!!)
See http://www.denx.de/twiki/bin/view/DULG/CommandLineParsing#Section_12.1.7.3.
Best regards,
Wolfgang Denk
Many thanks for that Wolfgang - most appreciated.
The only thing I find a bit odd is that on my system (0.4.0) setenv is set for 6 significant characters in the command table but presumably the example you give was with a system using only 3 characters significant (unless the 'set' command is not the same as the 'setenv' command).
I'll be parsing the command tables to remove all the commands that return "Sorry, but the xxxxx command has not been implemented" such as 'spiinfo' since they should either work or be conditionally compiled out if the user hasn't requested them. That being the case I'll send in a patch against 0.4.0 when I've tidied up these anomalies
Wolfgang Denk wrote:
See http://www.denx.de/twiki/bin/view/DULG/CommandLineParsing#Section_12.1.7.3.
Dear Robin,
in message 3F612652.1060909@tait.co.nz you wrote:
The only thing I find a bit odd is that on my system (0.4.0) setenv is set for 6 significant characters in the command table but presumably the example you give was with a system using only 3 characters significant (unless the 'set' command is not the same as the 'setenv' command).
It's the same; the whole command lookup code was completely rewritten in U-Boot 0.4.1 - the behavious changes slightly, and is now more consistent.
I'll be parsing the command tables to remove all the commands that return "Sorry, but the xxxxx command has not been implemented" such as 'spiinfo' since they should either work or be conditionally compiled out if the user hasn't requested them. That being the case I'll send in a patch against 0.4.0 when I've tidied up these anomalies
Thanks in advance, but please send a patch against a RECENT version of U-Boot. 0.4.0 is very old. A patch against 0.4.0 may be difficult to merge.
Best regards,
Wolfgang Denk
Wolfgang Denk wrote:
Thanks in advance, but please send a patch against a RECENT version of U-Boot. 0.4.0 is very old. A patch against 0.4.0 may be difficult to merge.
According to sourceforge, 0.4.0 is the latest stable release and less than 3 months old. Not ancient (compared to say the kernel update cycle) but the only thing that many people would consider using rather than an unstable* version from CVS - assuming of course they can get anything from sf CVS!!
Perhaps its time for another stable release that is easier to patch/merge against if nothing else :-))
* a matter of definition - but if its not stable it _must_ necessarily be unstable :-((
On Mon, Sep 15, 2003 at 09:41:01AM +1200, Robin Gilks wrote:
According to sourceforge, 0.4.0 is the latest stable release and less than 3 months old.
Look at ftp.denx.de, there are newer versions available.
Wolfgang, could you make an announcement from time to time on this list when you make a release? I noticed it almost by accident recently.
Robert
Dear Robert,
in message 20030914215029.GB17921@pengutronix.de you wrote:
Wolfgang, could you make an announcement from time to time on this list when you make a release? I noticed it almost by accident recently.
Releases, i. e. increments of X or Y in the U-Boot-X_Y_Z CVS tags, have always been announced here, and will be. The "minor" releases on our FTP server are merely snapshots to help work around the access and delay problems to SF's CVS server.
I think there is two groups of people on this mailing list: users and developers. For users, the "major releases" are perfectly OK to use. Developers usually can use the top-of-tree version from CVS. Except for a very few cases I always run a certain set of tests before ever checking in code to the public CVS server. This is good enough for 99% of all developers. If you feel unsafe with that, you can use a tagged version; if you need even more reliability you can use one of the "minor releases" tagged as U-Boot-X_Y_Z (with snapshots on our FTP server).
If you're interested in the development, watch the CVS. I don't intend to announce each and every check-in. If you like, you can, for example, "cvs watch add CHANGELOG".
Best regards,
Wolfgang Denk
On Mon, Sep 15, 2003 at 12:09:15AM +0200, Wolfgang Denk wrote:
If you're interested in the development, watch the CVS. I don't intend to announce each and every check-in. If you like, you can, for example, "cvs watch add CHANGELOG".
Perhaps a CVS commits mailing list that automatically got the changelogs (and possibly diffs) committed to CVS would be of use?
In message 20030915134610.GA27694@projectcolo.org.uk you wrote:
Perhaps a CVS commits mailing list that automatically got the changelogs (and possibly diffs) committed to CVS would be of use?
Sounds like a LOT of overkill to me.
Best regards,
Wolfgang Denk
On Mon, Sep 15, 2003 at 04:04:33PM +0200, Wolfgang Denk wrote:
In message 20030915134610.GA27694@projectcolo.org.uk you wrote:
Perhaps a CVS commits mailing list that automatically got the changelogs (and possibly diffs) committed to CVS would be of use?
Sounds like a LOT of overkill to me.
It's something that a lot of projects provide and it would seem to provide a way of helping with this. If people aren't interested they can always just not subscribe to the list.
On Mon, Sep 15, 2003 at 04:17:32PM +0100, Mark Brown wrote:
It's something that a lot of projects provide and it would seem to provide a way of helping with this. If people aren't interested they can always just not subscribe to the list.
Ack. Would be much easier for board maintainers to see if things have changed for them.
Robert
Robert,
in message 20030916064503.GI8367@pengutronix.de you wrote:
Ack. Would be much easier for board maintainers to see if things have changed for them.
Why do you use "would"? I think you already subscribed to the list??
Best regards,
Wolfgang Denk
On Tue, Sep 16, 2003 at 09:14:46AM +0200, Wolfgang Denk wrote:
Why do you use "would"? I think you already subscribed to the list??
FIFO reordering error: I replied before I found your announcement mail further down ;)
Robert
Hi ,
How to configure u-boot to load my Linux kernel image (/boot/image.bin) from *JFFS2 FLASH partition* ?
- - rupesh
Dear Robin,
in message 3F64E06D.6000500@tait.co.nz you wrote:
According to sourceforge, 0.4.0 is the latest stable release and less than 3 months old. Not ancient (compared to say the kernel update cycle)
Development of U-Boot happens pretty fast. _Many_ people contribute, and DENX is running quite a lot of projects, too.
but the only thing that many people would consider using rather than an unstable* version from CVS - assuming of course they can get anything
There has never been a forma declaration of whatis stable and what not. Normally you can consider each version tagges with a U-Boot-X_Y_Z label as "stable".
from sf CVS!!
I am aware of this problem. There is little I can do about it. But I regularly put tarballs of the "minor releases" on our FTP server; see ftp://ftp.denx.de/pub/u-boot/
Perhaps its time for another stable release that is easier to patch/merge against if nothing else :-))
Well, we're preparing for something, but it will take a little more time.
- a matter of definition - but if its not stable it _must_ necessarily
be unstable :-((
Has there ever been any "stable" software? Isn't "stable software" an oxymoron per se?
Best regards,
Wolfgang Denk
participants (6)
-
Mark Brown -
Robert Schwebel -
Robert Schwebel -
Robin Gilks -
Rupesh S -
Wolfgang Denk