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@dof.se,
I just use "reply" to the messages you post on this mailing list.
My email address is ulf@atmel.com
Ummm... Your postings include:
From: "Ulf Samuelsson" ulfs@dof.se Return-path: ulfs@dof.se
This leaves no doubt...
Sorrry about that: My setup is ulf@atmel.com goes to a POP3 server, which forwards to an IMAP server with the account ulfs@dof.se. The mobile phone does not support "Return Path". Atmels firewall does not accept that incoming mail are xxx@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@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