[U-Boot-Users] Submitting Patch at sourceforge fails

Ulf Samuelsson ulfs at dof.se
Tue Aug 22 21:02:17 CEST 2006


> Dear Ulf,
> 
> Thanks. Ideally, you have these patches somewhere in a git repo  from
> where I can pull from (assuming that these are the *same* patches you
> post here on the mailing list).
> 

No can do unfortunately, (this is not an official Atmel activity) and I don't run any personal servers.
Never used git, but I guess it is time to start.

Is it possible to run git on a Windows machine w Cygwin?
Have a dual boot laptop with a Linux incompatible soft modem in the laptop, so when Linux is running, no access)

>> >> Ethinit command
> ...
>> The patch just calls ethinit repeatedly until it succeeds, so I think
>> there is no problem.
> 
> I'm not sure I want to have this. Is there a way to  specify  a  time
> out?  Couldn't  /  shouldn't  this  be  implemented on CLI level, for
> example by repeating the failed TFTP command? If  necessary  using  a
> hush script?

You may be right about that, then again, hush adds code ;-( as well.

>> >> Install feature:
>> >>   Copies the resulting binary to /tftpboot
>> > 
>> > Rejected. This may be OK for you,  I  have  other  ideas,  and  other
>> people still other needs.
>> 
>> Would a more generic patch where the user can supply a target directory
>> be of interest?
> 
> The act of having a user "supply a target directory" is probably  not
> less effort than adding your own make target or just write a "make &&
> cp" on the command line.
> 

I usually differ between things I have to do once and things I have to do repeatedly
and the attempts are to put some effort in reducing the things that needs to be done repeatedly.
The target directory would be supplied once and thats it.
The split into "make & make install" causes you to lose time when you forget to do the make install



>> >> X-Modem tool
>> >>   sx-at91 (pinched from from www.at91.com forum)
>> > 
>> > Please explain what this is needed for, and why it should be included
>> with U-Boot.
> ...
>> The sx-at91 binary is not a part of the u-boot file, but if everyting
>> needed to boot the AT91RM9200
> 
> We typically don't include any binaries  in  the  U-Boot  tree,  just
> source  code.  Is the source code for this tool included, and does it
> come under a GPL compatible license?

Yes, the source code is there, but the patch generates a binary as part of the
build process and this binary is totally separated from the u-boot binary. 
It is released to GPL level 2 and later.

>> > Please use appropriate tools for such purposes, like expect.
>> 
>> Thanks for the tip. 
>> Expect looks to make life very complex.
>> Has anyone developed any expect scripts which would do the same thing then?
> 
> Yes, of course, And for many other things, too. 
>> If you work with several files and download them from the tftpboot
>> directory then you want to have different names for the files.
> 
> Yes, of course, but do we need special commands for that?

It is not a special command, it is a tool outside the u.boot binary.

> 
>> These things are mainly there to save a lot of typing 
>> if you play around with different versions of the disks and kernels.
>> They can be explicitly configured away.
> 
> I still fail to see  any  advantage  over  just  using  the  existing
> mechanisms  of  environment variables and variable substitution - for
> which nothing new needs to be added.
> 
>> The patch will collect a number of environment variables to form the
>> bootcmd and bootargs
>> By setting one of those environment variables to a new value you can
>> change one parameter
>> without having to retype the complete line (often several times because
>> of syntax errors).
> 
> Ummm.... did you read the manual?  For  example  section  "7.3.  Boot
> Arguments Unleashed" ?

> What does your patch give which is not already present?
> 

Thanks, I have read it, and it partly solves the problem.
I still fail to see how I can to a table lookup easily.
I guess it would be possible with hush to do a long if statement.

>> A more generic solution would be to extend the parsing of environment
>> variables.
>> 
>> If you can do the following:
>> setenv xxx 111
>> setenv yyy 222
>> setenv zzz  333
>> setenv bootarg1   setenv bootarg ${xxx}-${yyy},${zzz}
>> run bootarg1
>> print bootarg   
>> $  111-222,333
>> setenv xxx 444
>> run bootarg1
>> print bootarg
>> $ 444-222,333
> 
> No problem. You just need to add some escape characters:
> 
> => setenv xxx 111
> => setenv yyy 222
> => setenv zzz  333
> => setenv bootarg1 'setenv bootarg ${xxx}-${yyy},${zzz}'
> => run bootarg1
> => print bootarg
> bootarg=111-222,333
> => setenv xxx 444
> => run bootarg1
> => print bootarg
> bootarg=444-222,333
> 
>> OR
>> 
>> setenv rd     ${rd-${ver}}
> 
> We cannot do this in a single step, we need two.
> 

Can you show how this is done, I do not see how.
setenv rd-1 xxx
setenv rd-2 yyy
setenv ver 1
<magic>
print  rd
$ xxx
setenv ver 2
<magic>
$ yyy

Please explain how to implement <magic>


I can see that the following is possible.
setenv rd1 'setenv rd ${rd-1}'
setenv rd2 'setenv rd ${rd-2}'
setenv rd3 'setenv rd ${rd-3}'
setenv rd4 'setenv rd ${rd-4}'
setenv rd5 'setenv rd ${rd-5}'
setenv rd6 'setenv rd ${rd-6}'
setenv lx1  'setenv  lx ${lx-1}'
setenv lx2 'setenv  lx  ${lx-2}'
setenv lx3  'setenv  lx ${lx-3}'
setenv lx4 'setenv  lx  ${lx-4}'
setenv lx5  'setenv  lx ${lx-5}'
setenv lx6 'setenv  lx  ${lx-6}'
setenv v1 'run rd1 ; run lx1'
setenv v2 'run rd1 ; run lx2'
setenv v3 'run rd1 ; run lx3'
setenv v4 'run rd1 ; run lx4'
setenv v5 'run rd1 ; run lx5'
setenv v6 'run rd1 ; run lx6'

setenv rd-1 xxx
setenv rd-2 yyy
setenv lx-1 XXX
setenv lx-2 YYY
run v1
print  rd
$ xxx
run v2
$ yyy

The environment becomes cluttered and it becomes complex/error-prone to add extra versions.


> Use a script which can be loaded and executed. 
> Or use  some  external tool  that  automates  console  input  
> (expect, or kermit's scripting capabilities, etc. 
> -- did you for example have a look at the scripts under tools/scripts/ ?).

raw-at91 is a tool which automates console input, admittedly in a stupid way,and relies on minicom.
The advantage of minicom is that I do not have to type any filenames, since I can select the file using up/downarrow and space.
and I do not have to generate any scripts,since I just type in the commands I want as is in a file and send it down
without having to type the file name of the environment file which I have to do for "expect" and "kermit".
To use a script I have to type the file name, unless a compile time environment variable is setup to do the autoscript.

On windows Atmel has the SAM-BA tool for this, but this does not run under Linux.
SAM-BA under Linux would be the best idea and no patch for u-boot.


>> Please do not send mails or "reply" to ulfs at dof.se, 
> 
> I just use "reply" to the messages you post on this mailing list.
> 
>> My email address is ulf at atmel.com
> 
> Ummm... Your postings include:
> 
> From: "Ulf Samuelsson" <ulfs at dof.se>
> Return-path: <ulfs at dof.se>
> 
> This leaves no doubt...


Sorrry about that:
My setup is ulf at atmel.com goes to a POP3 server, which forwards to an IMAP server with the account ulfs at dof.se.
The mobile phone does not support "Return Path".
Atmels firewall does not accept that incoming mail are xxx at atmel.com even as "Return Path".
This somewhat limits my options.

I sometimes, when travelling , use the IMAP server from a PC but 
still I think the only option is to request people to avoid sending the stuff to the IMAP server.
The drawback of that, is that there is a limited amount of storage on the IMAP server, so I need to delete frequently
POP3 mails are stored permanently, and also often sorted by a mail rule.
Any important mails are better of sent to ulf at atmel.com

This small request is in the signature, so there was nothing personal.
I do delete it from time to time, especially when sending to lists, but I missed it this time.
(Any reply is bound to go to the atmel.com list anyway)
/Best Regards 
Ulf





More information about the U-Boot mailing list