
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

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.

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

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

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

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.

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

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.

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
participants (4)
-
Achim Ehrlich
-
Jean-Christophe PLAGNIOL-VILLARD
-
Jens Gehrlein
-
Wolfgang Denk