Dear Ulf,
in message 008401c6c5f5$cb2e5af0$104765d5@atmel.com you wrote:
This is a list of MANY different topics. Please split these into individual, orthogonal patches as requested in the README.
OK, will do.
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).
Please make sure your partitioning code uses and works with the "mtdparts" command.
Most of this is just changing the table values
OK.
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?
IIRC, For the the 2.4 kernel only supports the AT91RM9200DK and the 2.6 kernel separates the AT91RM9200DK and EK. so if you run on the EK (which most do, since the DK is obsolete) you have a problem doing both.
But the mach ID's for the AT91RM9200DK are the same in 2.4 and 2.6, right? So what is the problem? That there is no EK support in the 2.4 kernel? Well, many other recent processors / boards are not supported in 2.4 either. So use the kernel where the EK is supported - 2.6. I think it would be wrong to use fake mach ID's.
The 2.4 kernel is ín a maintenance phase, and I doubt that anyone will merge the AT91RM9200 patches into the 2.4 kernel ever. Whatif the patch depend on the AT91RM9200?
Sorry, I still don't understand what exactly is the problem.
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.
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?
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?
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?
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.
you can lose this function.
That's what I mean. You're probably just adding overhead to duplicate functions that have been in place and working for years.
Maybe there is a way to avoid this typing, but I have not found it.
Did you read the manual?
What does this mean? We have been supporting this for years?
It just means that the additional default environment (to save typing) is not all hardcoded into the file.
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/ ?).
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...
Best regards,
Wolfgang Denk