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

[Wolfgang Denk]

Dear Ulf,

in message <008401c6c5f5$cb2e5af0$104765d5 at 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 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...

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
1st Old Man:  Gee, its windy today.
2nd Old Man:  No it's not... it's Thursday.
3rd Old Man:  Yeh, me too.  Let's go for a beer.