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

[Ulf Samuelsson]

> 
> This is a list of MANY different  topics.  Please  split  these  into
> individual, orthogonal patches as requested in the README.
> 
OK, will do.

>> 
>>   If there are two dataflashes in the system
>>   they can have different partitions.
>>   Second dataflash has a single partition
>>   at the moment.
> 
> Please make sure your partitioning code uses and works with the
> "mtdparts" command.
> 

Most of this is just changing the table values

>> Ethinit command
>>   Waits until there is a valid link on network.
>>   Solves a problem when trying to tftp from slow booting PCs (Booting at th=
>> e same time).
>>   "ethinit ; tftp 21000000 <myfile>" =
>> 
>>   will guarantee that the tftp occurs at the right time
> 
> Please chose a different name for this command (like  ethwaitlink  or
> ethwait  or  so),  and  make  sure it can be used with other ethernet
> drivers as well.
> 

The patch just calls ethinit repeatedly until it succeeds, so I think there is no problem.

>> Dynamic Machine-Ids
>>   setenv machid <value>
>>   if "machid" exists, U-boot will pass on this value instead of the precomp=
>> iled value
>>   allowing the same u-boot to boot both Linux-2.4 and Linux-2.6
> 
> I tend to reject this patch, as it will most probably lead to misuse
> by people who fail to assing correct machine ID's.
> 
> What exactly is  the  problem?  I  was  not  aware  that  there  were
> incompatible  machine id's between 2.4 and 2.6 Linux kernels? [And if
> there ware any, this should  be  fixed  on  the  Linux  kernel  side,
> shouldn't it?]

Long time since this one...
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.

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?

>> 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?

>> 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 boot process of an new AT91RM9200 board running from a serial flash looks like this:

The CPU starts executing from BootROM and since the flash is unprogrammed
it starts running X-Modem on the Debug UART.
The user should then send an In System programming application 
which is stored in the internal SRAM. The CPU then jumps into the ISP application.
The ISP application is then downloaded a second time using X-Modem and it is now stored into the serial flash.
The CPU can then be reset, and the bootROM application will find the valid ISP application image
in the serial flash and will load it and execute it.
The ISP application is then used to download U-boot using X-Modem.
If the CPU is reset, and the user does not interven, U-boot is loaded into SDRAM and executed.

As you see, you do not need any special tools like JTAG emulators to flash U-Boot
when You use the Boot ROM.

The main motivation I see behind this addition is that it is easier to use a package that
meets all the needs of the developer than a large bunch of 

The sx-at91 binary is not a part of the u-boot file, but if everyting needed to boot the AT91RM9200
is in a single package, the startup barrier for new users is 
t make life a lot easier
for users of the AT91RM9200 

The reason for including the SX-AT91 into U-boot is that 


> 
>>   Reliable download tool to be used with minicom.
> 
> Please note that we explicitely do NOT support minicom.
> 
>> Script downloading tool
>>   raw-at91
>>   allows downloading a script using minicom.
> 
> I will probably reject this.
> 
>>   A little easier to use than autoscript
>>   Tool will download the environment file one line at a time and then wait =
>> a short while.
> 
> 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?

This small utility just sends a file down the serial line.
It is not locked to minicom, it can probably be used with "expect" as well
(but I have not tried).

Anyway, I now usually handle the environement using the extra commands below.

>> Default environment
>>   This allows a fast setup/reset of the environment by running the "defenv"=
>>  command.
>>   It allows easier management of long filenames by automatically generating=
>>  filenames / scripts
>>   from "partial environment"
>>   setenv linux xxx
>>   setenv kernel-date 2006-08-12
>>   setenv kernel-version 2.6.17
>>   os
>>   printenv linux
>>   $ uImage-linux-2.6.17-2006.08-12.gz
> 
> This is probably only of very local interest. I guess I will reject this.

If you work with several files and download them from the tftpboot directory
then you want to have different names for the files.

> 
>>   "fs" will set the "rd" variable depending on the value of the "fstype", "=
>> ver" environment variables.
>>   "fstype" can be "ram" or "flash"
>>   Several default disks are provided ("rd-1","rd-2","rd-3",etc.) and
>>   the "ver" variable is be used to select between the disks =
> 
> Please don't add tons of whistles and bells that nobody needs. I feel
> most of this is just code bloat.
> 


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.

>>   Will also set "bootcmd" and "bootargs" to nice values
> 
> Maybe other people have other ideas of "nice".
> 
> Is there anything wrong with the currently used and  recommended  way
> of dealing with booatargs?
> 

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).

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

OR

setenv rd     ${rd-${ver}}

you can lose this function.


Maybe there is a way to avoid this typing, but I have not found it.

>>   The user can define his environment in the board support file.
> 
> 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.

> 
> Best regards,
> 
> Wolfgang Denk
> 


Please do not send mails or "reply" to ulfs at dof.se, 
since it will be routed to my GSM phone.
My email address is ulf at atmel.com

Best Regards
Ulf Samuelsson                ulf at atmel.com
Atmel Nordic AB
Mail:  Box 2033, 174 02 Sundbyberg, Sweden
Visit:  Kavallerivägen 24, 174 58 Sundbyberg, Sweden
Phone +46 (8) 441 54 22     Fax +46 (8) 441 54 29
GSM    +46 (706) 22 44 57

Technical support when I am not available:
AT89 C51 Applications Group: mailto:micro.hotline at nto.atmel.com
AT90 AVR Applications Group: mailto:avr at atmel.com
AT91 ARM Applications Group: mailto:at91support at atmel.com
FPSLIC Application Group: mailto:fpslic at atmel.com
Best AVR  link: www.avrfreaks.net