All of lore.kernel.org
 help / color / mirror / Atom feed
* [U-Boot] Timeout in tftp.c
@ 2009-05-12 12:22 Achim Ehrlich
  2009-05-12 18:40 ` Jean-Christophe PLAGNIOL-VILLARD
  2009-05-12 18:48 ` Wolfgang Denk
  0 siblings, 2 replies; 9+ messages in thread
From: Achim Ehrlich @ 2009-05-12 12:22 UTC (permalink / raw)
  To: u-boot

Hello,

The timeout for lost packages in tftp.c is defined to 5000 msecs. But 
when setting the timeout get_timer(0) is called in NetSetTimeout in net.c.
But on AT91 the timer code returns usecs and not msecs resulting in a 
timeout of 5 ms instead of 5 secs, which is kind of short. I looked in 
the timer code of other ARM-based platforms and they seem to use 
usec-based timers as well.
Of course I can change the defined timeout in tftp.c to one second or 
so, but that doesn't seem to be the right way to solve this issue.

Any suggestions or ideas or do I miss something here?

Kind regards

Achim

-- 
product manager

email:aehrlich at taskit.de
Tel.: ++49 30 611295-25
Fax: ++49 30 611295-11

--
taskit GmbH
Seelenbinderstr. 33 | D-12555 Berlin
web:http://www.taskit.de
Amtsgericht Charlottenburg: 93HRB39014
Managing director: Thorsten Raulfs
--

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [U-Boot] Timeout in tftp.c
  2009-05-12 12:22 [U-Boot] Timeout in tftp.c Achim Ehrlich
@ 2009-05-12 18:40 ` Jean-Christophe PLAGNIOL-VILLARD
  2009-05-12 18:48 ` Wolfgang Denk
  1 sibling, 0 replies; 9+ messages in thread
From: Jean-Christophe PLAGNIOL-VILLARD @ 2009-05-12 18:40 UTC (permalink / raw)
  To: u-boot

On 14:22 Tue 12 May     , Achim Ehrlich wrote:
> Hello,
> 
> The timeout for lost packages in tftp.c is defined to 5000 msecs. But 
> when setting the timeout get_timer(0) is called in NetSetTimeout in net.c.
> But on AT91 the timer code returns usecs and not msecs resulting in a 
> timeout of 5 ms instead of 5 secs, which is kind of short. I looked in 
> the timer code of other ARM-based platforms and they seem to use 
> usec-based timers as well.
> Of course I can change the defined timeout in tftp.c to one second or 
> so, but that doesn't seem to be the right way to solve this issue.
> 
> Any suggestions or ideas or do I miss something here?
could you be more precise against which version your test was done?

Best Regards,
J.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [U-Boot] Timeout in tftp.c
  2009-05-12 12:22 [U-Boot] Timeout in tftp.c Achim Ehrlich
  2009-05-12 18:40 ` Jean-Christophe PLAGNIOL-VILLARD
@ 2009-05-12 18:48 ` Wolfgang Denk
  2009-05-13  4:59   ` Jens Gehrlein
  1 sibling, 1 reply; 9+ messages in thread
From: Wolfgang Denk @ 2009-05-12 18:48 UTC (permalink / raw)
  To: u-boot

Dear Achim Ehrlich,

In message <4A0969FC.2060504@taskit.de> you wrote:
> 
> The timeout for lost packages in tftp.c is defined to 5000 msecs. But 
> when setting the timeout get_timer(0) is called in NetSetTimeout in net.c.
> But on AT91 the timer code returns usecs and not msecs resulting in a 
> timeout of 5 ms instead of 5 secs, which is kind of short. I looked in 
> the timer code of other ARM-based platforms and they seem to use 
> usec-based timers as well.
> Of course I can change the defined timeout in tftp.c to one second or 
> so, but that doesn't seem to be the right way to solve this issue.
> 
> Any suggestions or ideas or do I miss something here?

Any chance that you are using an old version of U-Boot?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Comparing information  and  knowledge  is  like  asking  whether  the
fatness  of  a  pig  is more or less green than the designated hitter
rule."                                               - David Guaspari

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [U-Boot] Timeout in tftp.c
  2009-05-12 18:48 ` Wolfgang Denk
@ 2009-05-13  4:59   ` Jens Gehrlein
  2009-05-13 11:37     ` Achim Ehrlich
  0 siblings, 1 reply; 9+ messages in thread
From: Jens Gehrlein @ 2009-05-13  4:59 UTC (permalink / raw)
  To: u-boot

Wolfgang Denk schrieb:
> Dear Achim Ehrlich,
> 
> In message <4A0969FC.2060504@taskit.de> you wrote:
>> The timeout for lost packages in tftp.c is defined to 5000 msecs. But 
>> when setting the timeout get_timer(0) is called in NetSetTimeout in net.c.
>> But on AT91 the timer code returns usecs and not msecs resulting in a 
>> timeout of 5 ms instead of 5 secs, which is kind of short. I looked in 
>> the timer code of other ARM-based platforms and they seem to use 
>> usec-based timers as well.
>> Of course I can change the defined timeout in tftp.c to one second or 
>> so, but that doesn't seem to be the right way to solve this issue.
>>
>> Any suggestions or ideas or do I miss something here?
> 
> Any chance that you are using an old version of U-Boot?

Hi Achim,

I'm interested in this, too. I observed timeouts on ARM11 (MX31),
but couldn't do any investigation due to other projects.

Kind regards,
Jens

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [U-Boot] Timeout in tftp.c
  2009-05-13  4:59   ` Jens Gehrlein
@ 2009-05-13 11:37     ` Achim Ehrlich
  2009-05-13 11:39       ` Jean-Christophe PLAGNIOL-VILLARD
  0 siblings, 1 reply; 9+ messages in thread
From: Achim Ehrlich @ 2009-05-13 11:37 UTC (permalink / raw)
  To: u-boot

Jens Gehrlein schrieb:
> Wolfgang Denk schrieb:
>> Dear Achim Ehrlich,
>>
>> In message <4A0969FC.2060504@taskit.de> you wrote:
>>> The timeout for lost packages in tftp.c is defined to 5000 msecs. But 
>>> when setting the timeout get_timer(0) is called in NetSetTimeout in 
>>> net.c.
>>> But on AT91 the timer code returns usecs and not msecs resulting in a 
>>> timeout of 5 ms instead of 5 secs, which is kind of short. I looked 
>>> in the timer code of other ARM-based platforms and they seem to use 
>>> usec-based timers as well.
>>> Of course I can change the defined timeout in tftp.c to one second or 
>>> so, but that doesn't seem to be the right way to solve this issue.
>>>
>>> Any suggestions or ideas or do I miss something here?
>>
>> Any chance that you are using an old version of U-Boot?
> 
> Hi Achim,
> 
> I'm interested in this, too. I observed timeouts on ARM11 (MX31),
> but couldn't do any investigation due to other projects.
> 

I'm working on a custom developed board with AT91Sam9G20 and on the 
current at91-tree of u-boot, so all new. I will do further work this 
afternoon on this issue.

Kind regards

Achim

-- 
product manager

email:aehrlich at taskit.de
Tel.: ++49 30 611295-25
Fax: ++49 30 611295-11

--
taskit GmbH
Seelenbinderstr. 33 | D-12555 Berlin
web:http://www.taskit.de
Amtsgericht Charlottenburg: 93HRB39014
Managing director: Thorsten Raulfs
--

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [U-Boot] Timeout in tftp.c
  2009-05-13 11:37     ` Achim Ehrlich
@ 2009-05-13 11:39       ` Jean-Christophe PLAGNIOL-VILLARD
  2009-05-14 15:17         ` Achim Ehrlich
  0 siblings, 1 reply; 9+ messages in thread
From: Jean-Christophe PLAGNIOL-VILLARD @ 2009-05-13 11:39 UTC (permalink / raw)
  To: u-boot

On 13:37 Wed 13 May     , Achim Ehrlich wrote:
> Jens Gehrlein schrieb:
> > Wolfgang Denk schrieb:
> >> Dear Achim Ehrlich,
> >>
> >> In message <4A0969FC.2060504@taskit.de> you wrote:
> >>> The timeout for lost packages in tftp.c is defined to 5000 msecs. But 
> >>> when setting the timeout get_timer(0) is called in NetSetTimeout in 
> >>> net.c.
> >>> But on AT91 the timer code returns usecs and not msecs resulting in a 
> >>> timeout of 5 ms instead of 5 secs, which is kind of short. I looked 
> >>> in the timer code of other ARM-based platforms and they seem to use 
> >>> usec-based timers as well.
> >>> Of course I can change the defined timeout in tftp.c to one second or 
> >>> so, but that doesn't seem to be the right way to solve this issue.
> >>>
> >>> Any suggestions or ideas or do I miss something here?
> >>
> >> Any chance that you are using an old version of U-Boot?
> > 
> > Hi Achim,
> > 
> > I'm interested in this, too. I observed timeouts on ARM11 (MX31),
> > but couldn't do any investigation due to other projects.
> > 
> 
> I'm working on a custom developed board with AT91Sam9G20 and on the 
> current at91-tree of u-boot, so all new. I will do further work this 
> afternoon on this issue.
which value do you put in the CONFIG_SYS_HZ?

if you can send patch we could take a look on this

Best Regards,
J.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [U-Boot] Timeout in tftp.c
  2009-05-13 11:39       ` Jean-Christophe PLAGNIOL-VILLARD
@ 2009-05-14 15:17         ` Achim Ehrlich
  2009-05-14 15:48           ` Jean-Christophe PLAGNIOL-VILLARD
  0 siblings, 1 reply; 9+ messages in thread
From: Achim Ehrlich @ 2009-05-14 15:17 UTC (permalink / raw)
  To: u-boot

Jean-Christophe PLAGNIOL-VILLARD schrieb:
> On 13:37 Wed 13 May     , Achim Ehrlich wrote:
>> Jens Gehrlein schrieb:
>>> Wolfgang Denk schrieb:
>>>> Dear Achim Ehrlich,
>>>>
>>>> In message <4A0969FC.2060504@taskit.de> you wrote:
>>>>> The timeout for lost packages in tftp.c is defined to 5000 msecs. But 
>>>>> when setting the timeout get_timer(0) is called in NetSetTimeout in 
>>>>> net.c.
>>>>> But on AT91 the timer code returns usecs and not msecs resulting in a 
>>>>> timeout of 5 ms instead of 5 secs, which is kind of short. I looked 
>>>>> in the timer code of other ARM-based platforms and they seem to use 
>>>>> usec-based timers as well.
>>>>> Of course I can change the defined timeout in tftp.c to one second or 
>>>>> so, but that doesn't seem to be the right way to solve this issue.
>>>>>
>>>>> Any suggestions or ideas or do I miss something here?
>>>> Any chance that you are using an old version of U-Boot?
>>> Hi Achim,
>>>
>>> I'm interested in this, too. I observed timeouts on ARM11 (MX31),
>>> but couldn't do any investigation due to other projects.
>>>
>> I'm working on a custom developed board with AT91Sam9G20 and on the 
>> current at91-tree of u-boot, so all new. I will do further work this 
>> afternoon on this issue.
> which value do you put in the CONFIG_SYS_HZ?
> 
> if you can send patch we could take a look on this
> 
> Best Regards,
> J.

My value was at 1000000. Switching back to 1000 didn't solve my problem, 
but instead causes erase and write operations on nand flash to timeout 
as well. My u-boot was built on commit 
03bab0091948196b9558248684c04f60943ca4b5 of the at-91 tree. Rebasing it 
to the current version with the changed timer code caused u-boot to not 
boot at all on my hardware. I just made a simple board port and didn't 
change much, but I add my diff against u-boot-at91 anyway. It should 
work on the Atmel Board as well, but I don't own any.
Thank you for your help

Achim

-- 
product manager

email:aehrlich at taskit.de
Tel.: ++49 30 611295-25
Fax: ++49 30 611295-11

--
taskit GmbH
Seelenbinderstr. 33 | D-12555 Berlin
web:http://www.taskit.de
Amtsgericht Charlottenburg: 93HRB39014
Managing director: Thorsten Raulfs
--
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: stamp9g20.diff
Url: http://lists.denx.de/pipermail/u-boot/attachments/20090514/c1285c00/attachment.txt 

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [U-Boot] Timeout in tftp.c
  2009-05-14 15:17         ` Achim Ehrlich
@ 2009-05-14 15:48           ` Jean-Christophe PLAGNIOL-VILLARD
  2009-05-18  9:46             ` Achim Ehrlich
  0 siblings, 1 reply; 9+ messages in thread
From: Jean-Christophe PLAGNIOL-VILLARD @ 2009-05-14 15:48 UTC (permalink / raw)
  To: u-boot


> My value was at 1000000. Switching back to 1000 didn't solve my problem,  
> but instead causes erase and write operations on nand flash to timeout  
> as well. My u-boot was built on commit  
> 03bab0091948196b9558248684c04f60943ca4b5 of the at-91 tree.
this revision does not integrate the timer fix
> Rebasing it  
> to the current version with the changed timer code caused u-boot to not  
> boot at all on my hardware. I just made a simple board port and didn't  
> change much, but I add my diff against u-boot-at91 anyway. It should  
> work on the Atmel Board as well, but I don't own any.
normaly yes but you need to update a few your config to have it working
see comment on your patch
> Thank you for your help
>
> Achim
>
 +
> +#ifdef CONFIG_AT91SAM9G20EK
> +	/* arch number of AT91SAM9260EK-Board */
> +	gd->bd->bi_arch_number = MACH_TYPE_AT91SAM9G20EK;
> +#else
> +	/* arch number of AT91SAM9260EK-Board */
> +	gd->bd->bi_arch_number = MACH_TYPE_AT91SAM9260EK;
> +#endif
sure?
> +	/* adress of boot parameters */
> +	gd->bd->bi_boot_params = PHYS_SDRAM + 0x100;
> +
> +	at91_serial_hw_init();
> +#ifdef CONFIG_CMD_NAND
> +	stamp9G20_nand_hw_init();
> +#endif

> diff --git a/include/asm-arm/mach-types.h b/include/asm-arm/mach-types.h
> index 2c1e69b..91fc62f 100644
> --- a/include/asm-arm/mach-types.h
> +++ b/include/asm-arm/mach-types.h
when you will send your final please send a sync request

> diff --git a/include/configs/stamp9G20.h b/include/configs/stamp9G20.h
> new file mode 100644
> index 0000000..6c4a1b5
> --- /dev/null
> +++ b/include/configs/stamp9G20.h
> @@ -0,0 +1,183 @@
> +/*
> + * (C) Copyright 2007-2008
> + * Stelian Pop <stelian.pop@leadtechdesign.com>
> + * Lead Tech Design <www.leadtechdesign.com>
> + * (C) Achim Ehrlich <aehrlich@taskit.de>
> + * taskit GmbH <www.taskit.de>
> + *
> + * Configuation settings for the Stamp9G20 CPU module.
> + *
> + * See file CREDITS for list of people who contributed to this
> + * project.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of
> + * the License, or (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
> + * MA 02111-1307 USA
> + */
> +
> +#ifndef __CONFIG_H
> +#define __CONFIG_H
> +
> +/* ARM asynchronous clock */
> +#define AT91_MAIN_CLOCK		18432000	/* 18.432 MHz crystal */
> +#define CONFIG_SYS_AT91_PLLB	0x10193f05	/* PLLB settings for USB */
please remove
> +#define CONFIG_SYS_HZ		1000		/* 1ms resolution */
> +
> +#define AT91_SLOW_CLOCK		32768	/* slow clock */
please remove
> +
> +#define CONFIG_ARM926EJS	1	/* This is an ARM926EJS Core	*/
> +#define AT91_CPU_NAME		"AT91SAM9G20"
> +//#define AT91_MASTER_CLOCK	132000000	/* peripheral */
> +//#define AT91_CPU_CLOCK		396000000	/* cpu */
> +#define CONFIG_AT91SAM9G20	1	/* It's an Atmel AT91SAM9G20 SoC*/
please add
#define CONFIG_ARCH_CPU_INIT
> +

please note I've sync the at91 with u-boot general tree they are the same now
but for dev please base your code against u-boot-arm/next

Best Regards,
J.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [U-Boot] Timeout in tftp.c
  2009-05-14 15:48           ` Jean-Christophe PLAGNIOL-VILLARD
@ 2009-05-18  9:46             ` Achim Ehrlich
  0 siblings, 0 replies; 9+ messages in thread
From: Achim Ehrlich @ 2009-05-18  9:46 UTC (permalink / raw)
  To: u-boot

Jean-Christophe PLAGNIOL-VILLARD schrieb:
>> My value was at 1000000. Switching back to 1000 didn't solve my problem,  
>> but instead causes erase and write operations on nand flash to timeout  
>> as well. My u-boot was built on commit  
>> 03bab0091948196b9558248684c04f60943ca4b5 of the at-91 tree.
> this revision does not integrate the timer fix
>> Rebasing it  
>> to the current version with the changed timer code caused u-boot to not  
>> boot at all on my hardware. I just made a simple board port and didn't  
>> change much, but I add my diff against u-boot-at91 anyway. It should  
>> work on the Atmel Board as well, but I don't own any.
> normaly yes but you need to update a few your config to have it working
> see comment on your patch
>> Thank you for your help
>>
>> Achim
>>
>  +
>> +#ifdef CONFIG_AT91SAM9G20EK
>> +	/* arch number of AT91SAM9260EK-Board */
>> +	gd->bd->bi_arch_number = MACH_TYPE_AT91SAM9G20EK;
>> +#else
>> +	/* arch number of AT91SAM9260EK-Board */
>> +	gd->bd->bi_arch_number = MACH_TYPE_AT91SAM9260EK;
>> +#endif
> sure?
>> +	/* adress of boot parameters */
>> +	gd->bd->bi_boot_params = PHYS_SDRAM + 0x100;
>> +
>> +	at91_serial_hw_init();
>> +#ifdef CONFIG_CMD_NAND
>> +	stamp9G20_nand_hw_init();
>> +#endif
> 
>> diff --git a/include/asm-arm/mach-types.h b/include/asm-arm/mach-types.h
>> index 2c1e69b..91fc62f 100644
>> --- a/include/asm-arm/mach-types.h
>> +++ b/include/asm-arm/mach-types.h
> when you will send your final please send a sync request
> 
>> diff --git a/include/configs/stamp9G20.h b/include/configs/stamp9G20.h
>> new file mode 100644
>> index 0000000..6c4a1b5
>> --- /dev/null
>> +++ b/include/configs/stamp9G20.h
>> @@ -0,0 +1,183 @@
>> +/*
>> + * (C) Copyright 2007-2008
>> + * Stelian Pop <stelian.pop@leadtechdesign.com>
>> + * Lead Tech Design <www.leadtechdesign.com>
>> + * (C) Achim Ehrlich <aehrlich@taskit.de>
>> + * taskit GmbH <www.taskit.de>
>> + *
>> + * Configuation settings for the Stamp9G20 CPU module.
>> + *
>> + * See file CREDITS for list of people who contributed to this
>> + * project.
>> + *
>> + * This program is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU General Public License as
>> + * published by the Free Software Foundation; either version 2 of
>> + * the License, or (at your option) any later version.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program; if not, write to the Free Software
>> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
>> + * MA 02111-1307 USA
>> + */
>> +
>> +#ifndef __CONFIG_H
>> +#define __CONFIG_H
>> +
>> +/* ARM asynchronous clock */
>> +#define AT91_MAIN_CLOCK		18432000	/* 18.432 MHz crystal */
>> +#define CONFIG_SYS_AT91_PLLB	0x10193f05	/* PLLB settings for USB */
> please remove
>> +#define CONFIG_SYS_HZ		1000		/* 1ms resolution */
>> +
>> +#define AT91_SLOW_CLOCK		32768	/* slow clock */
> please remove
>> +
>> +#define CONFIG_ARM926EJS	1	/* This is an ARM926EJS Core	*/
>> +#define AT91_CPU_NAME		"AT91SAM9G20"
>> +//#define AT91_MASTER_CLOCK	132000000	/* peripheral */
>> +//#define AT91_CPU_CLOCK		396000000	/* cpu */
>> +#define CONFIG_AT91SAM9G20	1	/* It's an Atmel AT91SAM9G20 SoC*/
> please add
> #define CONFIG_ARCH_CPU_INIT
>> +
> 
> please note I've sync the at91 with u-boot general tree they are the same now
> but for dev please base your code against u-boot-arm/next
> 
> Best Regards,
> J.

Thank you, these changes made it work fine. The tftpboot timeout is now 
correct as well.

Kind regards

Achim

-- 
product manager

email:aehrlich at taskit.de
Tel.: ++49 30 611295-25
Fax: ++49 30 611295-11

--
taskit GmbH
Seelenbinderstr. 33 | D-12555 Berlin
web:http://www.taskit.de
Amtsgericht Charlottenburg: 93HRB39014
Managing director: Thorsten Raulfs
--

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2009-05-18  9:46 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-05-12 12:22 [U-Boot] Timeout in tftp.c Achim Ehrlich
2009-05-12 18:40 ` Jean-Christophe PLAGNIOL-VILLARD
2009-05-12 18:48 ` Wolfgang Denk
2009-05-13  4:59   ` Jens Gehrlein
2009-05-13 11:37     ` Achim Ehrlich
2009-05-13 11:39       ` Jean-Christophe PLAGNIOL-VILLARD
2009-05-14 15:17         ` Achim Ehrlich
2009-05-14 15:48           ` Jean-Christophe PLAGNIOL-VILLARD
2009-05-18  9:46             ` Achim Ehrlich

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.