RE: [ECOS] FLASH configuration checksum error

RE: [ECOS] FLASH configuration checksum error

[Warren Jasper]

When you say near the end of flash, is that the end that it thinks it is
(ie 0x9000000) or where I told it it was (0x08800000).
When I do a fis list, I don't see the configuration block only
the FIS directory at 0x087C0000 of length 0x00040000.

-----Original Message-----
From: Jonathan Larmour [ mailto:jlarmour@redhat.com ]
Sent: Friday, September 21, 2001 3:38 PM
To: Warren Jasper
Cc: 'eCos Discussion'
Subject: Re: [ECOS] FLASH configuration checksum error


Warren Jasper wrote:
> 
> I am using a StrongARM SA1110 CPU with tow (2) 28F640J3A Flash
> chips. I think the hardware for our development board is
> not addressing the chip correctly, since I can only see
> half of the FLASH.  To fix this problem, I set CYGNUM_FLASH_BASE_MASK =
> 0xFF800000
> instead of 0xFE000000.  This works great.  I get the following messages:
> 
> FLASH: Oversized device! End addr 0x09000000 changed to 0x08800000
> FLASH configuration checksum error or invalid key
> 
> RAM: 0x00000000-0x01000000, 0x0000dc88-00fbf000 available
> FLASH: 0x08000000 - 0x08800000, 32 blocks of 0x00040000 bytes each.
> 
> Which is correct since I can only see half of the flash.  My question is
> how to get rid of the line
> 
> FLASH configuration checksum error or invalid key
> 
> I tried to run flconfig -i but that does not get rid of the problem.
> 
> Any suggestions?  I could ignore it, but I wanted to know how to set the
> checksum correctly.

The flash configuration block is set near the end of flash. There's
probably something in the code which is still trying to write to the half
of the flash you don't have.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine

Re: [ECOS] FLASH configuration checksum error

[Jonathan Larmour]

Warren Jasper wrote:
> 
> When you say near the end of flash, is that the end that it thinks it is
> (ie 0x9000000) or where I told it it was (0x08800000).

I'm saying that it may have gotten confused and want to put it at
0x9000000-2*blocksize rather than 0x8800000-2*blocksize. It would be a bug
yes, but that's my theory.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine

[ECOS] RedBoot serial or network ?

[Pushparaj]

Hi,
Just wanted to know how does RedBoot respond to multiple connections
either
through serial or network.
Lets say the serial console is being used for configuration and now we
receive
a telnet packet over the network. Now my question is does the RedBoot
drop the
incoming network connection or gets connected to the telnet client ?

Thanks and Regards,
Pushparaj

Re: [ECOS] RedBoot serial or network ?

[Gary Thomas]

On Mon, 2001-09-24 at 03:06, Pushparaj wrote:
> Hi,
> Just wanted to know how does RedBoot respond to multiple connections
> either
> through serial or network.
> Lets say the serial console is being used for configuration and now we
> receive
> a telnet packet over the network. Now my question is does the RedBoot
> drop the
> incoming network connection or gets connected to the telnet client ?
> 
> Thanks and Regards,
> Pushparaj

RedBoot will check for incoming connections when the serial port is
"idle".  The default configuration for this is to check only at the
start of a command line.

Don't forget that the default is also to listen on port 9000, not the
standard TELNET port of 23.

[ECOS] TFTP bug

[Pushparaj]

Hi,
I had downloaded redboot sources some 2 months back
Now I am implementing the tftp file download.
The problem I am facing is this:
I try to download a file ( a S19 file or a s record file ) from a tftp
server. After say 10 packets received and sent the redboot sends a packet
( ie. ACK) with destination port zero. And this prompts the tftp server to
send a icmp destination unreachable message.

Has this bug been fixed ?
Do I need to download the latest from the cvs server ?

I ask this because in the udp.c file I can see FIXME messages for some of
the functions.

Regards,
Pushparaj

[ECOS] STL?

[Mathieu Routhier]

I've searched the archives for this but only found an unanswered
question.

Anyone successfully used STL in eCOS?  I've hit inclusion problems
(iostream.h) and I was wondering if it was ever possible.

Mathieu Routhier

RE: [ECOS] STL?

[Mathieu Routhier]

Oups.  For everyone interested, here is something noteful about STL.

http://sources.redhat.com/ml/ecos-discuss/2000-04/msg00198.html

Mat

-----Original Message-----
From: ecos-discuss-owner@sources.redhat.com
[ mailto:ecos-discuss-owner@sources.redhat.com ] On Behalf Of Mathieu
Routhier
Sent: Thursday, September 27, 2001 2:58 PM
To: ecos-discuss@sources.redhat.com
Subject: [ECOS] STL?

I've searched the archives for this but only found an unanswered
question.

Anyone successfully used STL in eCOS?  I've hit inclusion problems
(iostream.h) and I was wondering if it was ever possible.

Mathieu Routhier

Re: [ECOS] TFTP bug

[Gary Thomas]

On Fri, 2001-09-28 at 02:37, Pushparaj wrote:
> Hi,
> I had downloaded redboot sources some 2 months back
> Now I am implementing the tftp file download.
> The problem I am facing is this:
> I try to download a file ( a S19 file or a s record file ) from a tftp
> server. After say 10 packets received and sent the redboot sends a packet
> ( ie. ACK) with destination port zero. And this prompts the tftp server to
> send a icmp destination unreachable message.
> 
> Has this bug been fixed ?
> Do I need to download the latest from the cvs server ?
> 

This has never been observed before.  The TFTP code in RedBoot works 
quite well as far as I know.

Perhaps it has something to do with the file you are downloading?
The port used is kept in a structure in static memory.  If somehow
you convinced RedBoot to write over that memory, it would get very
confused.

> I ask this because in the udp.c file I can see FIXME messages for some of
> the functions.

I'm not sure where you see this.  The only FIXME is in the tftp_client
code and it's just a comment that a number is being used where a 
symbolic constant should be.

You've not said what your target platform is.  Maybe that has some 
bearing on the problem.

Re: [ECOS] TFTP bug

[Pushparaj]

Hi Gary,
Ok, let me tell you what I am trying to do exactly.
I am trying to download a " .out" file built at 2MB in the RAM with the -r
option, for raw file download in the load command. It gets aborted  after
0x13800 bytes of download after which it stops. As I said the redboot sends the
packet of destination port as zero and the tftp server gets confused and sends a
destination unreachable message. I know downloading a ".out" file is of no use
in RAM but I am just trying.Will it create problems ?

Also I am able to  download small files of size 6k Also when I try downloading a
S record of size 819 k built at 2MB in the RAM, it gives a message
"*** Warning! Checksum failure -- Addr: 2000a0, D4 <> 00 "
Now why should this happen. Here too after downloading certain percentage of the
file, redboot makes destination port as zero and the tftp server gets confused
and sends a destination unreachable message.

Regards,
Pushparaj



Gary Thomas wrote:

> On Fri, 2001-09-28 at 02:37, Pushparaj wrote:
> > Hi,
> > I had downloaded redboot sources some 2 months back
> > Now I am implementing the tftp file download.
> > The problem I am facing is this:
> > I try to download a file ( a S19 file or a s record file ) from a tftp
> > server. After say 10 packets received and sent the redboot sends a packet
> > ( ie. ACK) with destination port zero. And this prompts the tftp server to
> > send a icmp destination unreachable message.
> >
> > Has this bug been fixed ?
> > Do I need to download the latest from the cvs server ?
> >
>
> This has never been observed before.  The TFTP code in RedBoot works
> quite well as far as I know.
>
> Perhaps it has something to do with the file you are downloading?
> The port used is kept in a structure in static memory.  If somehow
> you convinced RedBoot to write over that memory, it would get very
> confused.
>
> > I ask this because in the udp.c file I can see FIXME messages for some of
> > the functions.
>
> I'm not sure where you see this.  The only FIXME is in the tftp_client
> code and it's just a comment that a number is being used where a
> symbolic constant should be.
>
> You've not said what your target platform is.  Maybe that has some
> bearing on the problem.

Re: [ECOS] TFTP bug

[Jonathan Larmour]

Pushparaj wrote:
> 
> Hi Gary,
> Ok, let me tell you what I am trying to do exactly.
> I am trying to download a " .out" file built at 2MB in the RAM with the -r
> option, for raw file download in the load command.

Which platform? And _exactly_ which command are you using to load it? The
memory address you are loading to is the most interesting thing. Are you
sure it isn't overwriting RedBoot's RAM area (generally the bottom 64K/128K
or so of RAM)

> It gets aborted  after
> 0x13800 bytes of download after which it stops. As I said the redboot sends the
> packet of destination port as zero and the tftp server gets confused and sends a
> destination unreachable message. I know downloading a ".out" file is of no use
> in RAM but I am just trying.Will it create problems ?

A .out file is at a guess ELF format (as in a.out?), in which case no that
wouldn't work, but you can use the objcopy utility to convert to a better
format like srec.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine

Re: [ECOS] TFTP bug

[Pushparaj]

Hi Jonathan,
I am working on motorola powerpc 860 platform and trying to download a 890,338 size
s19 file.
It is a s-record. It is built at 2MB in RAM. I am using the load command and I give it
in this format.
load c:\image.s19.
The server ip address is set and the redboot is also able to understand that the
image.s19 file is built at 2MB. Redboot is not using this address in RAM.
Now when I try to download I print the server port numbers in functions,
tftp_stream_read and udp_sendto and udp_recvfrom. I find that the server udp port
number ie., sin_port is changing to zero sometimes. Why does this happen ?
When this happens and the redboot sends a ack with destination port number zero , the
tftpserver is confused and the session aborts abruptly. I am using Walusoft tftp
server 2000. Has it got anything to do with tftp server ?
What are the files that can be downloaded using the redboot ?

Please help
REgards,
Pushparaj


Jonathan Larmour wrote:

> Pushparaj wrote:
> >
> > Hi Gary,
> > Ok, let me tell you what I am trying to do exactly.
> > I am trying to download a " .out" file built at 2MB in the RAM with the -r
> > option, for raw file download in the load command.
>
> Which platform? And _exactly_ which command are you using to load it? The
> memory address you are loading to is the most interesting thing. Are you
> sure it isn't overwriting RedBoot's RAM area (generally the bottom 64K/128K
> or so of RAM)
>
> > It gets aborted  after
> > 0x13800 bytes of download after which it stops. As I said the redboot sends the
> > packet of destination port as zero and the tftp server gets confused and sends a
> > destination unreachable message. I know downloading a ".out" file is of no use
> > in RAM but I am just trying.Will it create problems ?
>
> A .out file is at a guess ELF format (as in a.out?), in which case no that
> wouldn't work, but you can use the objcopy utility to convert to a better
> format like srec.
>
> Jifl
> --
> Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
> Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine

Re: [ECOS] TFTP bug

[Jonathan Larmour]

Pushparaj wrote:
> 
> Hi Jonathan,
> I am working on motorola powerpc 860 platform and trying to download a 890,338 size
> s19 file.
> It is a s-record. It is built at 2MB in RAM. I am using the load command and I give it
> in this format.
> load c:\image.s19.

You said before you were loading it in "raw" format using -r. Make your
mind up!

> The server ip address is set and the redboot is also able to understand that the
> image.s19 file is built at 2MB. Redboot is not using this address in RAM.
> Now when I try to download I print the server port numbers in functions,
> tftp_stream_read and udp_sendto and udp_recvfrom. I find that the server udp port
> number ie., sin_port is changing to zero sometimes. Why does this happen ?

Curiously, looking at the code in redboot's tftp_client.c, I can't see how
tftp_stream.from_addr gets set at all. I can only assume it has worked
before because all the data has already been sent from the server fast
enough.

I think you'll find it works if near the end of tftp_stream_open (after the
assignment to total_timeouts) you add a:

memcpy(&tftp_stream.local_addr, server, sizeof(*server));

Let us know if that's sufficient to fix the problem for you and I'll apply
it in the main sources.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine

Re: [ECOS] TFTP bug

[Gary Thomas]

On Sun, 2001-09-30 at 07:23, Jonathan Larmour wrote:
> Pushparaj wrote:
> > 
> > Hi Jonathan,
> > I am working on motorola powerpc 860 platform and trying to download a 890,338 size
> > s19 file.
> > It is a s-record. It is built at 2MB in RAM. I am using the load command and I give it
> > in this format.
> > load c:\image.s19.
> 
> You said before you were loading it in "raw" format using -r. Make your
> mind up!
> 
> > The server ip address is set and the redboot is also able to understand that the
> > image.s19 file is built at 2MB. Redboot is not using this address in RAM.
> > Now when I try to download I print the server port numbers in functions,
> > tftp_stream_read and udp_sendto and udp_recvfrom. I find that the server udp port
> > number ie., sin_port is changing to zero sometimes. Why does this happen ?
> 
> Curiously, looking at the code in redboot's tftp_client.c, I can't see how
> tftp_stream.from_addr gets set at all. I can only assume it has worked
> before because all the data has already been sent from the server fast
> enough.
> 

It gets set on line 308:
     if ((data_len = __udp_recvfrom(&tftp_stream.data[0], recv_len, &tftp_stream.from_addr, 
                                    &tftp_stream.local_addr,  &timeout)) < 0) {
One result of this call will be to set 'from_addr' to the information
about the host (sender).

That address will only be used to send back the ACK.  I don't see how 
it's possible for it to ever get a port of zero, since that's filled in 
when a data packet arrives and had to match to be accepted.

> I think you'll find it works if near the end of tftp_stream_open (after the
> assignment to total_timeouts) you add a:
> 
> memcpy(&tftp_stream.local_addr, server, sizeof(*server));
> 

This is not necessary and will be overwritten by the first packet 
received.

> Let us know if that's sufficient to fix the problem for you and I'll apply
> it in the main sources.

There is obviously something else wrong with Pushparaha's system.  I'd 
suggest adding some diag_printf() calls with the body of 
tftp_stream_read() to try and get a feel for what's up.

This code works on other platforms.  We routinely use it to load images
of many megabytes (JFFS2 images on the iPAQ are 14MB, for example).

Re: [ECOS] TFTP bug

[Pushparaj]

Hi,
Today, I looked into the tftp download problem in a more detail. This is what I inferred from
the packed view that I captured between the tftp server and the client.
I use the following command to load a s record.
load c:\image.s19.
The target hardware which is running on motorola powerpc 860, sends the first packet over UDP
on the port 69. The server is listening on this port and it replies back saying that its port
is 1750 and sends the first 512 chunk.
After this the board sends the ack for this packet with destination port 1750.
This continues for few more 512 chunks of memory. And the transaction is fine with the server
sending the packet 'n' and the redboot sending the ack for packet 'n'.
Now the server transmits the (n+1) packet and suddenly the board sends the ack for nth packet
again with destination port 0.

I have used the latest tftp client code from the CVS server and tried. This happens
consistently and once this happens the tftp server sends an ICMP "destination unreachable'
reply. The board still tries sending the ack for nth packet ( with destination port 0 ofcourse
! ) and the server sends again the icmp packet . This happens till the redboot times out.

I am using this Walusoft tftp server. I have downloaded it recently for test purpose and I dont
know how efficient this server is  ;-)
I shall try with the linux tftp server tomorrow and get back to u with the latest.
Meantime if you have faced the problem where in the redboot sends the ack for nth packet twice,
please get back to me.

Best Regards,
Pushparaj



Gary Thomas wrote:

> On Sun, 2001-09-30 at 07:23, Jonathan Larmour wrote:
> > Pushparaj wrote:
> > >
> > > Hi Jonathan,
> > > I am working on motorola powerpc 860 platform and trying to download a 890,338 size
> > > s19 file.
> > > It is a s-record. It is built at 2MB in RAM. I am using the load command and I give it
> > > in this format.
> > > load c:\image.s19.
> >
> > You said before you were loading it in "raw" format using -r. Make your
> > mind up!
> >
> > > The server ip address is set and the redboot is also able to understand that the
> > > image.s19 file is built at 2MB. Redboot is not using this address in RAM.
> > > Now when I try to download I print the server port numbers in functions,
> > > tftp_stream_read and udp_sendto and udp_recvfrom. I find that the server udp port
> > > number ie., sin_port is changing to zero sometimes. Why does this happen ?
> >
> > Curiously, looking at the code in redboot's tftp_client.c, I can't see how
> > tftp_stream.from_addr gets set at all. I can only assume it has worked
> > before because all the data has already been sent from the server fast
> > enough.
> >
>
> It gets set on line 308:
>      if ((data_len = __udp_recvfrom(&tftp_stream.data[0], recv_len, &tftp_stream.from_addr,
>                                     &tftp_stream.local_addr,  &timeout)) < 0) {
> One result of this call will be to set 'from_addr' to the information
> about the host (sender).
>
> That address will only be used to send back the ACK.  I don't see how
> it's possible for it to ever get a port of zero, since that's filled in
> when a data packet arrives and had to match to be accepted.
>
> > I think you'll find it works if near the end of tftp_stream_open (after the
> > assignment to total_timeouts) you add a:
> >
> > memcpy(&tftp_stream.local_addr, server, sizeof(*server));
> >
>
> This is not necessary and will be overwritten by the first packet
> received.
>
> > Let us know if that's sufficient to fix the problem for you and I'll apply
> > it in the main sources.
>
> There is obviously something else wrong with Pushparaha's system.  I'd
> suggest adding some diag_printf() calls with the body of
> tftp_stream_read() to try and get a feel for what's up.
>
> This code works on other platforms.  We routinely use it to load images
> of many megabytes (JFFS2 images on the iPAQ are 14MB, for example).

Re: [ECOS] TFTP bug

[Mark Salter]

>>>>> Pushparaj  writes:

> Hi,
> Today, I looked into the tftp download problem in a more detail. This is what I inferred from
> the packed view that I captured between the tftp server and the client.
> I use the following command to load a s record.
> load c:\image.s19.
> The target hardware which is running on motorola powerpc 860, sends the first packet over UDP
> on the port 69. The server is listening on this port and it replies back saying that its port
> is 1750 and sends the first 512 chunk.
> After this the board sends the ack for this packet with destination port 1750.
> This continues for few more 512 chunks of memory. And the transaction is fine with the server
> sending the packet 'n' and the redboot sending the ack for packet 'n'.
> Now the server transmits the (n+1) packet and suddenly the board sends the ack for nth packet
> again with destination port 0.

I think I see the problem. My guess is that the (n+1) packet is delayed
from the (n) ACK such that the __udp_recvfrom() times out. __udp_recvfrom
starts out by zeroing the port number and will fill it in with the server
port when a packet is received. If no packet is received, the port number
is left at zero. The tftp client code passes in a pointer to its global
server sockaddr structure, so it gets trampled by a recvfrom timeout.

I think this will fix the problem:

Index: tftp_client.c
===================================================================
RCS file: /home/cvs/ecc/ecc/redboot/current/src/net/tftp_client.c,v
retrieving revision 1.11
diff -u -p -5 -c -r1.11 tftp_client.c
cvs server: conflicting specifications of output style
*** tftp_client.c	2001/07/27 16:41:38	1.11
--- tftp_client.c	2001/09/30 20:05:37
*************** tftp_stream_read(char *buf,
*** 273,282 ****
--- 273,283 ----
  {
      int total_bytes = 0;
      int size, recv_len, data_len;
      struct timeval timeout;
      struct tftphdr *hdr = (struct tftphdr *)tftp_stream.data;
+     struct sockaddr_in tmp_addr;
  
      while (total_bytes < len) {
          // Move any bytes which we've already read/buffered
          if (tftp_stream.avail > 0) {
              size = tftp_stream.avail;
*************** tftp_stream_read(char *buf,
*** 303,322 ****
                  break;
              }
              timeout.tv_sec = TFTP_TIMEOUT_PERIOD;
              timeout.tv_usec = 0;
              recv_len = sizeof(tftp_stream.data);
!             if ((data_len = __udp_recvfrom(&tftp_stream.data[0], recv_len, &tftp_stream.from_addr, 
                                             &tftp_stream.local_addr,  &timeout)) < 0) {
                  // No data, try again
                  if ((++tftp_stream.total_timeouts > TFTP_TIMEOUT_MAX) || 
                      (tftp_stream.last_good_block == 0)) {
                      // Timeout - no data received
                      *err = TFTP_TIMEOUT;
                      return -1;
                  }
              } else {
                  if (ntohs(hdr->th_opcode) == DATA) {
                      if (ntohs(hdr->th_block) == (tftp_stream.last_good_block+1)) {
                          // Consume this data
                          data_len -= 4;  /* Sizeof TFTP header */
                          tftp_stream.avail = tftp_stream.actual_len = data_len;
--- 304,325 ----
                  break;
              }
              timeout.tv_sec = TFTP_TIMEOUT_PERIOD;
              timeout.tv_usec = 0;
              recv_len = sizeof(tftp_stream.data);
!             tmp_addr = tftp_stream.from_addr;
!             if ((data_len = __udp_recvfrom(&tftp_stream.data[0], recv_len, &tmp_addr, 
                                             &tftp_stream.local_addr,  &timeout)) < 0) {
                  // No data, try again
                  if ((++tftp_stream.total_timeouts > TFTP_TIMEOUT_MAX) || 
                      (tftp_stream.last_good_block == 0)) {
                      // Timeout - no data received
                      *err = TFTP_TIMEOUT;
                      return -1;
                  }
              } else {
+                 tftp_stream.from_addr = tmp_addr;
                  if (ntohs(hdr->th_opcode) == DATA) {
                      if (ntohs(hdr->th_block) == (tftp_stream.last_good_block+1)) {
                          // Consume this data
                          data_len -= 4;  /* Sizeof TFTP header */
                          tftp_stream.avail = tftp_stream.actual_len = data_len;


--Mark

Re: [ECOS] TFTP bug

[Gary Thomas]

On Mon, 2001-10-01 at 05:07, Mark Salter wrote:
> >>>>> Pushparaj  writes:
> 
> > Hi,
> > Today, I looked into the tftp download problem in a more detail. This is what I inferred from
> > the packed view that I captured between the tftp server and the client.
> > I use the following command to load a s record.
> > load c:\image.s19.
> > The target hardware which is running on motorola powerpc 860, sends the first packet over UDP
> > on the port 69. The server is listening on this port and it replies back saying that its port
> > is 1750 and sends the first 512 chunk.
> > After this the board sends the ack for this packet with destination port 1750.
> > This continues for few more 512 chunks of memory. And the transaction is fine with the server
> > sending the packet 'n' and the redboot sending the ack for packet 'n'.
> > Now the server transmits the (n+1) packet and suddenly the board sends the ack for nth packet
> > again with destination port 0.
> 
> I think I see the problem. My guess is that the (n+1) packet is delayed
> from the (n) ACK such that the __udp_recvfrom() times out. __udp_recvfrom
> starts out by zeroing the port number and will fill it in with the server
> port when a packet is received. If no packet is received, the port number
> is left at zero. The tftp client code passes in a pointer to its global
> server sockaddr structure, so it gets trampled by a recvfrom timeout.
> 
> I think this will fix the problem:
> 
> Index: tftp_client.c
> ===================================================================
> RCS file: /home/cvs/ecc/ecc/redboot/current/src/net/tftp_client.c,v
> retrieving revision 1.11
> diff -u -p -5 -c -r1.11 tftp_client.c
> cvs server: conflicting specifications of output style
> *** tftp_client.c	2001/07/27 16:41:38	1.11
> --- tftp_client.c	2001/09/30 20:05:37
> *************** tftp_stream_read(char *buf,
> *** 273,282 ****
> --- 273,283 ----
>   {
>       int total_bytes = 0;
>       int size, recv_len, data_len;
>       struct timeval timeout;
>       struct tftphdr *hdr = (struct tftphdr *)tftp_stream.data;
> +     struct sockaddr_in tmp_addr;
>   
>       while (total_bytes < len) {
>           // Move any bytes which we've already read/buffered
>           if (tftp_stream.avail > 0) {
>               size = tftp_stream.avail;
> *************** tftp_stream_read(char *buf,
> *** 303,322 ****
>                   break;
>               }
>               timeout.tv_sec = TFTP_TIMEOUT_PERIOD;
>               timeout.tv_usec = 0;
>               recv_len = sizeof(tftp_stream.data);
> !             if ((data_len = __udp_recvfrom(&tftp_stream.data[0], recv_len, &tftp_stream.from_addr, 
>                                              &tftp_stream.local_addr,  &timeout)) < 0) {
>                   // No data, try again
>                   if ((++tftp_stream.total_timeouts > TFTP_TIMEOUT_MAX) || 
>                       (tftp_stream.last_good_block == 0)) {
>                       // Timeout - no data received
>                       *err = TFTP_TIMEOUT;
>                       return -1;
>                   }
>               } else {
>                   if (ntohs(hdr->th_opcode) == DATA) {
>                       if (ntohs(hdr->th_block) == (tftp_stream.last_good_block+1)) {
>                           // Consume this data
>                           data_len -= 4;  /* Sizeof TFTP header */
>                           tftp_stream.avail = tftp_stream.actual_len = data_len;
> --- 304,325 ----
>                   break;
>               }
>               timeout.tv_sec = TFTP_TIMEOUT_PERIOD;
>               timeout.tv_usec = 0;
>               recv_len = sizeof(tftp_stream.data);
> !             tmp_addr = tftp_stream.from_addr;
> !             if ((data_len = __udp_recvfrom(&tftp_stream.data[0], recv_len, &tmp_addr, 
>                                              &tftp_stream.local_addr,  &timeout)) < 0) {
>                   // No data, try again
>                   if ((++tftp_stream.total_timeouts > TFTP_TIMEOUT_MAX) || 
>                       (tftp_stream.last_good_block == 0)) {
>                       // Timeout - no data received
>                       *err = TFTP_TIMEOUT;
>                       return -1;
>                   }
>               } else {
> +                 tftp_stream.from_addr = tmp_addr;
>                   if (ntohs(hdr->th_opcode) == DATA) {
>                       if (ntohs(hdr->th_block) == (tftp_stream.last_good_block+1)) {
>                           // Consume this data
>                           data_len -= 4;  /* Sizeof TFTP header */
>                           tftp_stream.avail = tftp_stream.actual_len = data_len;
> 
> 
> --Mark

Or, alternatively since the "from" address is only valid IFF UDP 
receives a packet within the time limit, don't change it until the
packet is received.  This patch would have the same effect, but would
fix it at the source (as it were).

Index: redboot/current/src/net/udp.c
===================================================================
RCS file: /home/cvs/ecc/ecc/redboot/current/src/net/udp.c,v
retrieving revision 1.7
diff -u -5 -p -r1.7 udp.c
--- redboot/current/src/net/udp.c	23 Aug 2001 21:27:13 -0000	1.7
+++ redboot/current/src/net/udp.c	30 Sep 2001 22:47:37 -0000
@@ -233,11 +233,10 @@ __udp_recvfrom(char *data, int len, stru
 {
     int res, my_port, total_ms;
     udp_socket_t skt;
     unsigned long start;
 
-    server->sin_port = 0;
     my_port = ntohs(local->sin_port);
     if (__udp_install_listener(&skt, my_port, __udp_recvfrom_handler) < 0) {
         return -1;
     }
     recvfrom_buf = data;

Re: [ECOS] TFTP bug

[Pushparaj]

Hi,
I did not try the fix suggested by Mark Salter. But I did try the suggestion by Gary Thomas. And it did
really pretty well help me in downloading 30% of image into the target hardware. All I did was I commented
the
server->sin_port = 0
line in the code. But I still face the same problem ( now the destination port is never zero !! ). I am
now sure that it is a timeout problem.
This is what I observed in my todays download process.
The redboot is able to send the ack for most of the packets that is sent by tftp server.But for some it
sends wrong acks, ie., the acknowledgement for previous packets ( obviously it times out but now sends
correct destination port ! ) but tftp server is faithful enough to transmit the next sequence of packet
again. For which the redboot sends the correct ack. This goes on until suddenly the redboot aborts the
download by sending the ack for previous packet. Once again the tftp server sends the next packet but I
guess the redboot timesout and is not able to receive the packet and thinks it is the last packet and then
it calculates the checksum for the downloaded chunk and displays the checksum failure message.
I am sure now it is a timeout problem. What is the timeout value in ms I need to provide in the while loop
inside the function  _udp_recvfrom ? ie., what is the value to be fixed for total_ms variable ?
A correct timeout I guess should solve the problem which I am facing.

Regards,
Pushparaj





Gary Thomas wrote:

> On Mon, 2001-10-01 at 05:07, Mark Salter wrote:
> > >>>>> Pushparaj  writes:
> >
> > > Hi,
> > > Today, I looked into the tftp download problem in a more detail. This is what I inferred from
> > > the packed view that I captured between the tftp server and the client.
> > > I use the following command to load a s record.
> > > load c:\image.s19.
> > > The target hardware which is running on motorola powerpc 860, sends the first packet over UDP
> > > on the port 69. The server is listening on this port and it replies back saying that its port
> > > is 1750 and sends the first 512 chunk.
> > > After this the board sends the ack for this packet with destination port 1750.
> > > This continues for few more 512 chunks of memory. And the transaction is fine with the server
> > > sending the packet 'n' and the redboot sending the ack for packet 'n'.
> > > Now the server transmits the (n+1) packet and suddenly the board sends the ack for nth packet
> > > again with destination port 0.
> >
> > I think I see the problem. My guess is that the (n+1) packet is delayed
> > from the (n) ACK such that the __udp_recvfrom() times out. __udp_recvfrom
> > starts out by zeroing the port number and will fill it in with the server
> > port when a packet is received. If no packet is received, the port number
> > is left at zero. The tftp client code passes in a pointer to its global
> > server sockaddr structure, so it gets trampled by a recvfrom timeout.
> >
> > I think this will fix the problem:
> >
> > Index: tftp_client.c
> > ===================================================================
> > RCS file: /home/cvs/ecc/ecc/redboot/current/src/net/tftp_client.c,v
> > retrieving revision 1.11
> > diff -u -p -5 -c -r1.11 tftp_client.c
> > cvs server: conflicting specifications of output style
> > *** tftp_client.c     2001/07/27 16:41:38     1.11
> > --- tftp_client.c     2001/09/30 20:05:37
> > *************** tftp_stream_read(char *buf,
> > *** 273,282 ****
> > --- 273,283 ----
> >   {
> >       int total_bytes = 0;
> >       int size, recv_len, data_len;
> >       struct timeval timeout;
> >       struct tftphdr *hdr = (struct tftphdr *)tftp_stream.data;
> > +     struct sockaddr_in tmp_addr;
> >
> >       while (total_bytes < len) {
> >           // Move any bytes which we've already read/buffered
> >           if (tftp_stream.avail > 0) {
> >               size = tftp_stream.avail;
> > *************** tftp_stream_read(char *buf,
> > *** 303,322 ****
> >                   break;
> >               }
> >               timeout.tv_sec = TFTP_TIMEOUT_PERIOD;
> >               timeout.tv_usec = 0;
> >               recv_len = sizeof(tftp_stream.data);
> > !             if ((data_len = __udp_recvfrom(&tftp_stream.data[0], recv_len, &tftp_stream.from_addr,
> >                                              &tftp_stream.local_addr,  &timeout)) < 0) {
> >                   // No data, try again
> >                   if ((++tftp_stream.total_timeouts > TFTP_TIMEOUT_MAX) ||
> >                       (tftp_stream.last_good_block == 0)) {
> >                       // Timeout - no data received
> >                       *err = TFTP_TIMEOUT;
> >                       return -1;
> >                   }
> >               } else {
> >                   if (ntohs(hdr->th_opcode) == DATA) {
> >                       if (ntohs(hdr->th_block) == (tftp_stream.last_good_block+1)) {
> >                           // Consume this data
> >                           data_len -= 4;  /* Sizeof TFTP header */
> >                           tftp_stream.avail = tftp_stream.actual_len = data_len;
> > --- 304,325 ----
> >                   break;
> >               }
> >               timeout.tv_sec = TFTP_TIMEOUT_PERIOD;
> >               timeout.tv_usec = 0;
> >               recv_len = sizeof(tftp_stream.data);
> > !             tmp_addr = tftp_stream.from_addr;
> > !             if ((data_len = __udp_recvfrom(&tftp_stream.data[0], recv_len, &tmp_addr,
> >                                              &tftp_stream.local_addr,  &timeout)) < 0) {
> >                   // No data, try again
> >                   if ((++tftp_stream.total_timeouts > TFTP_TIMEOUT_MAX) ||
> >                       (tftp_stream.last_good_block == 0)) {
> >                       // Timeout - no data received
> >                       *err = TFTP_TIMEOUT;
> >                       return -1;
> >                   }
> >               } else {
> > +                 tftp_stream.from_addr = tmp_addr;
> >                   if (ntohs(hdr->th_opcode) == DATA) {
> >                       if (ntohs(hdr->th_block) == (tftp_stream.last_good_block+1)) {
> >                           // Consume this data
> >                           data_len -= 4;  /* Sizeof TFTP header */
> >                           tftp_stream.avail = tftp_stream.actual_len = data_len;
> >
> >
> > --Mark
>
> Or, alternatively since the "from" address is only valid IFF UDP
> receives a packet within the time limit, don't change it until the
> packet is received.  This patch would have the same effect, but would
> fix it at the source (as it were).
>
> Index: redboot/current/src/net/udp.c
> ===================================================================
> RCS file: /home/cvs/ecc/ecc/redboot/current/src/net/udp.c,v
> retrieving revision 1.7
> diff -u -5 -p -r1.7 udp.c
> --- redboot/current/src/net/udp.c       23 Aug 2001 21:27:13 -0000      1.7
> +++ redboot/current/src/net/udp.c       30 Sep 2001 22:47:37 -0000
> @@ -233,11 +233,10 @@ __udp_recvfrom(char *data, int len, stru
>  {
>      int res, my_port, total_ms;
>      udp_socket_t skt;
>      unsigned long start;
>
> -    server->sin_port = 0;
>      my_port = ntohs(local->sin_port);
>      if (__udp_install_listener(&skt, my_port, __udp_recvfrom_handler) < 0) {
>          return -1;
>      }
>      recvfrom_buf = data;

Re: [ECOS] TFTP bug

[Mark Salter]

>>>>> Pushparaj  writes:

> I am now sure that it is a timeout problem.

The timeout is pretty long (5 seconds). I'd be surprising if the server
really delayed that much. Perhaps there is a problem with the platform
HAL_DELAY_US() macro.

--Mark