[U-Boot-Users] Submitting Patch at sourceforge fails
I have some new patches for the AT91 and the AVR32. Tried to submit them at sourceforge.net, but the submissions fails. Tried 4 times...
Is it OK to post them at this list? There are two tarballs - total size of ~360 kB.
Any comments on the patches are appreciated.
DESCRIPTION OF PATCHES ---------------------------------------------------------------------------- This patch should apply cleanly against 2006-08-12. It is a two file submission. Major additions:
AVR32 U.boot support.
The AVR32 patches were submitted before by the Design team in Trondheim but they fail against the latest source mostly due to conflicts with the blackfin. I changed the patch so that it should be OK against 2006-08-12.
Support for new AT91 boards AT91SAM9260EK AT91SAM9261EK AT91SAM9263EK (also supporta AT91SAM9262)
The AT91SAM9200DK support has been split into AT91RM9200DK AT91RM9200EK AT91RM9200DF (machine type 1119) (generic AT91RM9200 running from dataflash) There are some differences in use of I/O pins Support for the MUX selecting MMC/SD or SPI Support for AT91RM9200EK LEDs in scripts
A new "drivers/atmel" directory has ´been created to allow files common to ARM and AVR32 to reside in a single location, instead of duplicates in each board directory.
Added support for new Atmel flash memories 0,13u parallel flash (AT49BVxxxD) 0,13u dataflash (AT45DBxxxD)
Changed dataflash partitions so that partions start and end on a page boundary. Now there are 6 partitions which have names. * "Bootstrap" * "U-Boot", * "<Unused>" * "Environment" * "OS" * "FS" The start address of the FS and OS partitions are automatically set in the environment.
If there are two dataflashes in the system they can have different partitions. Second dataflash has a single partition at the moment.
Block Erase of dataflash
Support for CRC check on dataflash depending on the "crc-check" environment variable.
Support for comparing contents of dataflash with SDRAM
Ethinit command Waits until there is a valid link on network. Solves a problem when trying to tftp from slow booting PCs (Booting at the same time). "ethinit ; tftp 21000000 <myfile>" will guarantee that the tftp occurs at the right time
Dynamic Machine-Ids setenv machid <value> if "machid" exists, U-boot will pass on this value instead of the precompiled value allowing the same u-boot to boot both Linux-2.4 and Linux-2.6
Install feature: Copies the resulting binary to /tftpboot
X-Modem tool sx-at91 (pinched from from www.at91.com forum) Reliable download tool to be used with minicom.
Script downloading tool raw-at91 allows downloading a script using minicom. A little easier to use than autoscript Tool will download the environment file one line at a time and then wait a short while.
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
"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 Will also set "bootcmd" and "bootargs" to nice values
The user can define his environment in the board support file.
This is my own work, and not an "official" Atmel release.
Best Regards Ulf Samuelsson ulf@atmel.com
In message 00df01c6c5cf$b5d5aee0$ce4565d5@atmel.com you wrote:
I have some new patches for the AT91 and the AVR32. Tried to submit them at sourceforge.net, but the submissions fails. Tried 4 times...
Is it OK to post them at this list?
May I recommend to read the README? It explains in detail how to submit patches. lso, it has a section on Coding Style requirements, which is mandatory.
There are two tarballs - total size of ~360 kB.
Forget it. There is a size limit of 40 kB here on this list, and this is more than enough for any patch.
Support for new AT91 boards AT91SAM9260EK AT91SAM9261EK AT91SAM9263EK (also supporta AT91SAM9262)
The AT91SAM9200DK support has been split into AT91RM9200DK AT91RM9200EK AT91RM9200DF (machine type 1119) (generic AT91RM9200 running from dataflash) There are some differences in use of I/O pins Support for the MUX selecting MMC/SD or SPI Support for AT91RM9200EK LEDs in scripts
A new "drivers/atmel" directory has =B4been created to allow files common to ARM and AVR32 to =
reside in a single location, instead of duplicates in each board directory.
Added support for new Atmel flash memories 0,13u parallel flash (AT49BVxxxD) 0,13u dataflash (AT45DBxxxD)
Changed dataflash partitions so that partions start and end on a page boundary. Now there are 6 partitions which have names.
- "Bootstrap"
- "U-Boot",
- "<Unused>"
- "Environment"
- "OS"
- "FS"
The start address of the FS and OS partitions are = automatically set in the environment.
This is a list of MANY different topics. Please split these into individual, orthogonal patches as requested in the README.
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.
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.
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?]
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.
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.
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.
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.
"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.
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 user can define his environment in the board support file.
What does this mean? We have been supporting this for years?
Best regards,
Wolfgang Denk
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
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
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.
Here is the relevant contents of mach-type.h
#define MACH_TYPE_AT91RM9200 251 -Used by Linux 2.4 #define MACH_TYPE_AT91RM9200DK 262 #define MACH_TYPE_AT91RM9200EK 705 - Used by Linux 2.6
So the first definition defines a SoC, not a board, so in theory for an AT91RM9200EK both 251 and 705 are correct.
This was probably not a good setup from the start, but the Linux-2.4 community is using 251. Linux-2.4 does not recognize 262 and 705. Linux-2.6 (correctly) does not recognize 251. If I want to work with a customer and exchange kernels, then I will have to request them to modify their source to a non-standard and only then can I solve their problem. Not a good idea to me.
There is another, more compelling reason for having this patch though. It is becoming more common for people to design System on Modules where you have a small board with CPU, Memory and maybe an Ethernet MAC. Customers would want these boards to be as ready as possible, and thus have both U-boot and Linux running. Then they add their own baseboard, and if they desire to register the combination as a new machine type. If they recompile the kernel using the new machine Id,then they have to recompile u-boot, for the single purpose of changing the machine type. Seems better to support changing the machine type using a setenv command.
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
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
Dear Ulf,
in message 002e01c6c61d$80cc1f10$f64765d5@atmel.com you wrote:
No can do unfortunately, (this is not an official Atmel activity) and I don't run any personal servers.
I see. Maybe Atmel is helpful anyway? They should be interested in such activities...
Never used git, but I guess it is time to start.
Definitely.
Is it possible to run git on a Windows machine w Cygwin?
I have no idea. Never used Windoze, never will.
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.
...except that thjis code is already present and considered "standard" (i. e. bourne shell compatible).
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
Define a shell function or a shell script or a Makefile which runs U-Boot's "make all" as a first target.
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.
The reason I'm asking is that I don't intend to include any non-GPL code into the public U-Boot source tree.
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.
Call it command or tool or program or application or ...
I still fail to see how I can to a table lookup easily.
As I mentioned before: do it in two steps. In the first step, generate a statement with the index expanded, in the second step to the dereferencing.
I guess it would be possible with hush to do a long if statement.
Not needed.
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>
Simple:
=> sete rd-1 xxx => sete rd-2 yyy => sete rd-3 zzz u> sete foo 'sete bar sete rd $\{rd-${ver}};run bar' => sete ver 1 => run foo ; print rd rd=xxx => sete ver 2 => run foo ; print rd rd=yyy => sete ver 3 => run foo ; print rd rd=zzz =>
You see, we don't even need any hush features.
Next problem, please :-)
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}'
Yes, many things are possible. But this is probably not exactly optimal.
raw-at91 is a tool which automates console input, admittedly in a stupid way,and relies on minicom.
OK, then I will not accept it. I hate minicom, and I'm actively blackballing it ;-)
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".
Come on. Kermit does file name completion, so the typing effort is minimal.
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.
Please fix your mail setup. There are established standards, and you have little chance of redefining these.
Any important mails are better of sent to ulf@atmel.com
Then make sure this is used as From: and Return-path:
Best regards,
Wolfgang Denk
Hello!
Wolfgang Denk schrieb:
raw-at91 is a tool which automates console input, admittedly in a stupid way,and relies on minicom.
OK, then I will not accept it. I hate minicom, and I'm actively blackballing it ;-)
I also find it very important to support minicom on Linux systems because it is the default terminal program in many Linux distributions. And it is not true that the usage of sx-at91 would be restricted only to minicom; minicom itself doesn't contain transfer programs for X-, Y- and Z-MODEM; instead it uses the external programs from the rzsz package. A proper solution would be fixing the rzsz's sx program so it doesn't cause X-MODEM protocol errors for the AT91 implementation. Even M$ Hyperterminal behaves correctly.
With best regards Andreas
Andreas Schweigstill wrote:
Wolfgang Denk schrieb:
raw-at91 is a tool which automates console input, admittedly in a stupid way,and relies on minicom.
OK, then I will not accept it. I hate minicom, and I'm actively blackballing it ;-)
I also find it very important to support minicom on Linux systems because it is the default terminal program in many Linux distributions. And it is not true that the usage of sx-at91 would be restricted only to minicom; minicom itself doesn't contain transfer programs for X-, Y- and Z-MODEM; instead it uses the external programs from the rzsz package. A proper solution would be fixing the rzsz's sx program so it doesn't cause X-MODEM protocol errors for the AT91 implementation. Even M$ Hyperterminal behaves correctly.
With best regards Andreas
I've recently become a fan of serproxy. Serproxy is a daemon that acts as a telnet proxy from a TCP port to a serial port on a linux box. This abstracts the serial port on my lab linux machine to be a network device that I can connect to from anyplace. It opens up a lot of nice possibilities and I don't have to deal with the indignities of minicom.
jeff
Hi!
Jeff Mock schrieb:
I've recently become a fan of serproxy. Serproxy is a daemon that acts as a telnet proxy from a TCP port to a serial port on a linux box. This abstracts the serial port on my lab linux machine to be a network device that I can connect to from anyplace. It opens up a lot of nice possibilities and I don't have to deal with the indignities of minicom.
Oh, that's very interesting. I have been searching for such a program for quite a long time but most of these programs have some problems. Some of them cause file transfer timeouts, others need special software.
Do you know if there is also a tool available which maps a COM port on a M$ Windows PC to a TCP or TELNET port?
With best regards Andreas Schweigstill
In message 44EC85D9.9050101@schweigstill.de you wrote:
I've recently become a fan of serproxy. Serproxy is a daemon that acts as a telnet proxy from a TCP port to a serial port on a linux box. This abstracts the serial port on my lab linux machine to be a network device that I can connect to from anyplace. It opens up a lot of nice possibilities and I don't have to deal with the indignities of minicom.
Oh, that's very interesting. I have been searching for such a program for quite a long time but most of these programs have some problems. Some of them cause file transfer timeouts, others need special software.
See also tserver (= Terminalserver): ftp://ftp.denx.de/pub/tools/tserver-0.17-3.src.rpm
Do you know if there is also a tool available which maps a COM port on a M$ Windows PC to a TCP or TELNET port?
Try porting tserver...
Best regards,
Wolfgang Denk
Wolfgang Denk wrote:
In message 44EC85D9.9050101@schweigstill.de you wrote:
I've recently become a fan of serproxy. Serproxy is a daemon that acts as a telnet proxy from a TCP port to a serial port on a linux box. This abstracts the serial port on my lab linux machine to be a network device that I can connect to from anyplace. It opens up a lot of nice possibilities and I don't have to deal with the indignities of minicom.
Oh, that's very interesting. I have been searching for such a program for quite a long time but most of these programs have some problems. Some of them cause file transfer timeouts, others need special software.
See also tserver (= Terminalserver): ftp://ftp.denx.de/pub/tools/tserver-0.17-3.src.rpm
Do you know if there is also a tool available which maps a COM port on a M$ Windows PC to a TCP or TELNET port?
Try porting tserver...
Best regards,
Wolfgang Denk
Maybe I'm missing something, but there is a Windows binary on the serproxy site http://www.lspace.nildram.co.uk/freeware.html
gvb
Hello!
Wolfgang Denk schrieb:
raw-at91 is a tool which automates console input, admittedly in a stupid way,and relies on minicom.
OK, then I will not accept it. I hate minicom, and I'm actively blackballing it ;-)
I also find it very important to support minicom on Linux systems because it is the default terminal program in many Linux distributions. And it is not true that the usage of sx-at91 would be restricted only to minicom; minicom itself doesn't contain transfer programs for X-, Y- and Z-MODEM; instead it uses the external programs from the rzsz package. A proper solution would be fixing the rzsz's sx program so it doesn't cause X-MODEM protocol errors for the AT91 implementation. Even M$ Hyperterminal behaves correctly.
=> And this is exactly what Marco Cavallini's sx-at91 does I do not know if sx-at91 is a generic tool for X-Modem supporting all thinkable modes since it was built to talk to the AT91RM9200 BootROM. My experience with the minicom + sx-at91 combination is "solid as a rock"
When I said "depends on minicom", I was probably mistaken. Looked briefly into the source and I think you can run it in directly from the prompt without having to start minicom.
"sx-at91 <filename>"
should be OK (but I did not see any reason to try).
"raw-at91 <file-name>" should then work as well.
(Maybe I should change the name to "u-script")
"raw-at91" is anyway not so important as "sx-at91"
With best regards Andreas
Dear Ulf,
in message 012201c6c6f6$fab331e0$8f4765d5@atmel.com you wrote:
Wolfgang Denk schrieb:
raw-at91 is a tool which automates console input, admittedly in a stupid way,and relies on minicom.
=
OK, then I will not accept it. I hate minicom, and I'm actively blackballing it ;-)
I also find it very important to support minicom on Linux systems because it is the default terminal program in many Linux distributions. And it is not true that the usage of sx-at91 would be restricted only to minicom; minicom itself doesn't contain transfer programs for X-, Y- and Z-MODEM; instead it uses the external programs from the rzsz package. A proper solution would be fixing the rzsz's sx program so it doesn't cause X-MODEM protocol errors for the AT91 implementation. Even M$ Hyperterminal behaves correctly.
There is something seriously broken with your quoting. This was not typed by you, but is a quote of a previos posting by Andreas Schweig- still!
=> And this is exactly what Marco Cavallini's sx-at91 does I do not know if sx-at91 is a generic tool for X-Modem supporting all
No, obviously it isn't. It is NOT a fix to the rzsz but instead a specialized package duplicating functions of a well-known standard tool. This alone is reason enough not to distribute it.
Andreas' suggestion was good: instead, please fix the rzsz tool.
With best regards Andreas
--
Dipl.-Phys. Andreas Schweigstill Schweigstill IT | Embedded Systems Schauenburgerstraße 116, D-24118 Kiel, Germany Phone: (+49) 431 5606-435, Fax: (+49) 431 5606-436 Mobile: (+49) 171 6921973, Web: http://www.schweigstill.de/
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
Ulf, what you're doing here is not acceptable. This whole message looks as if it was posted by Andreas, without any indication of your changes / additions. Please stick to standard quoting rules. See http://www.netmeister.org/news/learn2quote.html
And *fix* your mail setup instead of repeating your request to ignore standard mailing list practice.
Best regards,
Wolfgang Denk
Have been thinking about how to add patches in a non-intrusive way.
The U-boot Makefile is quite large and growing. I have seen problem where a new patch breaks because another patch has been applied between the checkout of the source dir and the acceptance of the patch. ("avr32" board support breaks on "blackfin")
Even if you make sure that the patch is OK vs todays git, if another guy sends in a board patch at the same time, and they are close to each other, then the first one to get acceptance first "wins".
The main function of the proposed patch is to add: "include board/*/board.mk" to the toplevel Makefile right before the mkconfig's start
Each provider of a new board package can put his/her own ./mkconfig xxx xxx xxx xxx xxx xxx inside the board directory board.mk file.
There are no board/board.mk files in the current tree, so I do not think there is any conflict with existing boards. If there aren't any "board/*/board.mk" files present, "make" fails, so the patch also creates a dummy file : "board/template/board.mk".
The patch does not do *anything* at the moment except including empty files in the make process. It does create a platform to allow easier patch management for both developers and Wolfgang (if he thinks it is a good idea and accepts the patch)
This is the first patch I send, if I have made any glaring mistakes, I will try to improve based on feedback.
Best Regards Ulf Samuelsson
In message 008f01c6c6f2$1b58fd80$8f4765d5@atmel.com you wrote:
The U-boot Makefile is quite large and growing. I have seen problem where a new patch breaks because another patch has been applied between the checkout of the source dir and the acceptance of the patch. ("avr32" board support breaks on "blackfin")
These are normal merge conflicts, and usually trivial to resolve.
The main function of the proposed patch is to add: "include board/*/board.mk" to the toplevel Makefile right before the mkconfig's start
Rejected. I really want to be able to see everythin in one place and file. This may become a long file, but then you know exactly where to search.
Not so long ago you could run "grep foo Documentation/Configure.help" in the Linux kernel tree to find out what config option "foo" was about. Try this in a current Linux kernel tree with it's zillions of scattered Kconfig files (including all the Kconfig.char, Kconfig.debug, Kconfig.i386, Kconfig.net, Kconfig.scsi, Kconfig.x86_64 and what else variants).
Please don't worry about such merge conflicts in the Makefile - I never complaint about such merge conflicts when adding patches.
This is the first patch I send, if I have made any glaring mistakes, I will try to improve based on feedback.
I reject this patch because it tries to fix a poroblem which does not exist, and instead it makes the code much harder to maintain.
diff -purN u-boot-1.1.4-0rig/board/template/board.mk > u-boot-1.1.4/board/template/board.mk --- u-boot-1.1.4-0rig/board/template/board.mk 1970-01-01 > 01:00:00.000000000 +0100 +++ u-boot-1.1.4/board/template/board.mk 2006-08-23 21:50:30.000000000 > +0200
Why don't you use git?
+include board/*/board.mk
BTW: this approach is broken. It does not handle the case of vendor directories like board/amcc/, board/esd/, etc.
Best regards,
Wolfgang Denk
In message 008f01c6c6f2$1b58fd80$8f4765d5@atmel.com you wrote:
The U-boot Makefile is quite large and growing. I have seen problem where a new patch breaks because another patch has been applied between the checkout of the source dir and the acceptance of the patch. ("avr32" board support breaks on "blackfin")
These are normal merge conflicts, and usually trivial to resolve.
I have support responsibility for about 200 AT91RM9200/SAM9 customers of which a large percentage are totally unexperienced with U-Boot and Linux when they start.
They would not be able to fix the failing patches and the fact that the patches fail will reflect bad on us.
The alternative is to ignore the main U-boot tree (which seems to be the main strategy Atmel is using) and deliver a complete u-boot package. This has the disadvantage that new functionality in the kernel is not available to the customers.
I believe that it is a significant advantage to following the main tree, but it is a 100% requirement for me that patches does not fail.
I don't want to cause trouble for others, but I do need a resolution to the failing patch problem. Is there anyway you can guide me to how this problem can be resolved?
The main function of the proposed patch is to add: "include board/*/board.mk" to the toplevel Makefile right before the mkconfig's start
Rejected. I really want to be able to see everythin in one place and file. This may become a long file, but then you know exactly where to search.
What if I add:
++++++++++++++++ board.mk: board/*/board.mk board/*/*/board.mk echo "Automatically generated file, do not edit" > board.mk cat board/*/board.mk >> board.mk cat board/*/*/board.mk >> board.mk ---- make mrproper should remove the toplevel "board.mk" ------------------------ to the Makefile
Furthermore, the board/*/{*/}board.mk patches should only be accepted if they are simple mkconfigs. Any complex stuff needs to go into the main Makefile (Since you are controlling the patches, you can reject any complex board.mk files)
This results in two files, Makefile and (Toplevel) board.mk so the problem is significantly smaller.
Not so long ago you could run "grep foo Documentation/Configure.help" in the Linux kernel tree to find out what config option "foo" was about. Try this in a current Linux kernel tree with it's zillions of scattered Kconfig files (including all the Kconfig.char, Kconfig.debug, Kconfig.i386, Kconfig.net, Kconfig.scsi, Kconfig.x86_64 and what else variants).
Please don't worry about such merge conflicts in the Makefile - I never complaint about such merge conflicts when adding patches.
This is the first patch I send, if I have made any glaring mistakes, I will try to improve based on feedback.
I reject this patch because it tries to fix a poroblem which does not exist, and instead it makes the code much harder to maintain.
diff -purN u-boot-1.1.4-0rig/board/template/board.mk > u-boot-1.1.4/board/template/board.mk --- u-boot-1.1.4-0rig/board/template/board.mk 1970-01-01 > 01:00:00.000000000 +0100 +++ u-boot-1.1.4/board/template/board.mk 2006-08-23 21:50:30.000000000 > +0200
Why don't you use git?
+include board/*/board.mk
BTW: this approach is broken. It does not handle the case of vendor directories like board/amcc/, board/esd/, etc.
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
Dear Ulf,
in message 007b01c6c752$c068d7e0$654765d5@atmel.com you wrote:
I have support responsibility for about 200 AT91RM9200/SAM9 customers of which a large percentage are totally unexperienced with U-Boot and Linux when they start.
They would not be able to fix the failing patches and the fact that the patches fail will reflect bad on us.
Then you should not distribute poatches to these people in the first place.
I believe that it is a significant advantage to following the main tree,
Agreed.
but it is a 100% requirement for me that patches does not fail.
I guess you'd win some big prioce if you could find a method that would allow this. All the source code management systems are dealing with this problem, and no perfect solution exists yet. You can automatically merge so many patches, but no system is perfect.
I don't want to cause trouble for others, but I do need a resolution to the failing patch problem. Is there anyway you can guide me to how this problem can be resolved?
I think you will have to accept the fact that no such solution exists.
Using git will make it easier for you to deal with such problems, but you will have to have knowledge about the tools and what's going on. This is nothing that your "totally unexperienced" users will ever be able to do.
What if I add:
++++++++++++++++ board.mk: board/*/board.mk board/*/*/board.mk echo "Automatically generated file, do not edit" > board.mk cat board/*/board.mk >> board.mk cat board/*/*/board.mk >> board.mk
make mrproper should remove the toplevel "board.mk"
to the Makefile
I will reject this. Using wildcards in such a place is bad.
Furthermore, the board/*/{*/}board.mk patches should only be accepted if they are simple mkconfigs.
If this is the case, then it's easier to keep this in the Makefile.
Any complex stuff needs to go into the main Makefile (Since you are controlling the patches, you can rejectany complex board.mk files)
Actually it's the complex stuff which bloats the Makefile.
This results in two files, Makefile and (Toplevel) board.mk so the problem is significantly smaller.
Not really, I think.
Best regards,
Wolfgang Denk
Hi Ulf,
On Tuesday 22 August 2006 21:02, Ulf Samuelsson wrote:
Is it possible to run git on a Windows machine w Cygwin?
Yes, git & cygwin is supported. Never tried it myself though.
Best regards, Stefan
It is not part of the normal Cygwin distribution though. Anyone knows a valid link?
Best Regards Ulf Samuelsson
On Wednesday 23 August 2006 10:13, Ulf Samuelsson wrote:
Yes, git & cygwin is supported. Never tried it myself though.
Best regards, Stefan
It is not part of the normal Cygwin distribution though. Anyone knows a valid link?
I suspect you just have to download the git source and compile it on your Cygwin system.
Best regards, Stefan
participants (6)
-
Andreas Schweigstill -
Jeff Mock -
Jerry Van Baren -
Stefan Roese -
Ulf Samuelsson -
Wolfgang Denk