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@dof.se, since it will be routed to my GSM phone. My email address is ulf@atmel.com
Best Regards Ulf Samuelsson ulf@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@nto.atmel.com AT90 AVR Applications Group: mailto:avr@atmel.com AT91 ARM Applications Group: mailto:at91support@atmel.com FPSLIC Application Group: mailto:fpslic@atmel.com Best AVR link: www.avrfreaks.net