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

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

[Ulf Samuelsson]

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 at atmel.com

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

[Wolfgang Denk]

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

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
We have found all life forms in the galaxy are  capable  of  superior
development.
	-- Kirk, "The Gamesters of Triskelion", stardate 3211.7

[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

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

[Wolfgang Denk]

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 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@dof.se>
	Return-path: <ulfs@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.

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

[Ulf Samuelsson]

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

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

[Ulf Samuelsson]

> 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 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@dof.se>
> Return-path: <ulfs@dof.se>
> 
> This leaves no doubt...


Sorrry about that:
My setup is ulf at atmel.com goes to a POP3 server, which forwards to an IMAP server with the account ulfs at dof.se.
The mobile phone does not support "Return Path".
Atmels firewall does not accept that incoming mail are xxx at 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 at 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

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

[Wolfgang Denk]

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 at atmel.com

Then make sure this is used as From: and Return-path:

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
A stone was placed at a ford in a river with the inscription:
"When this stone is covered it is dangerous to ford here."

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

[Andreas Schweigstill]

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

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

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

[Jeff Mock]

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

[U-Boot-Users] Off-topic: Serial port redirection

[Andreas Schweigstill]

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

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

[U-Boot-Users] Off-topic: Serial port redirection

[Wolfgang Denk]

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

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Is not that the nature of men and women -- that the  pleasure  is  in
the learning of each other?
	-- Natira, the High Priestess of Yonada, "For the World is
	   Hollow and I Have Touched the Sky", stardate 5476.3.

[U-Boot-Users] Off-topic: Serial port redirection

[Jerry Van Baren]

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

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

[Ulf Samuelsson]

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

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

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

[Wolfgang Denk]

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 at dof.se,
> 
> since it will be routed to my GSM phone.
> My email address is ulf at 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

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
One does not thank logic.
	-- Sarek, "Journey to Babel", stardate 3842.4

[U-Boot-Users] Makefile suggestion

[Ulf Samuelsson]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0.Makefile.patch
Type: application/octet-stream
Size: 821 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20060823/74a25a64/attachment.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0.Makefile.CHANGELOG
Type: application/octet-stream
Size: 272 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20060823/74a25a64/attachment-0001.obj 

[U-Boot-Users] Makefile suggestion

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

> 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

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"The more data I punch in this card,  the lighter it becomes, and the
lower the mailing cost."
                     - Stan Kelly-Bootle, "The Devil's DP Dictionary"

[U-Boot-Users] Makefile suggestion

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

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

[U-Boot-Users] Makefile suggestion

[Wolfgang Denk]

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 reject
> any 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

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
I think that all right-thinking people in this country are  sick  and
tired  of  being  told that ordinary decent people are fed up in this
country with being sick and tired. I'm certainly not.  But  I'm  sick
and tired of being told that I am.                     - Monty Python

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

[Stefan Roese]

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

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

[Ulf Samuelsson]

> 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

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

[Stefan Roese]

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