Patch for zsrec.c

Hello!

File ftp://linuxppc.cs.nmt.edu/pub/linuxppc/embedded/zsrec.c has a bug.
It uses an S9 closing record, but specifies 3 address bytes instead of 2
required by the standard.

RPX/Lite boards report checksum error on such records, which is not good
either, but the real bug is zsrec.c

Since data are represented by S3 records with 4-byte addresses, the safest
way to fix it would be to use S7 records that also use 4-byte addresses.
It is also possible to use 0x200000 as the starting address, so that the
"t" command in the boot prompt works!

The sentence about buggy RPX boards should be removed from
getting_started.rpx

This is my patch

=== cut here ===

--- zsrec.c	Mon Jan 31 10:57:19 2000
+++ zsrec.c	Mon Jan 31 18:41:55 2000

@@ -69,7 +69,7 @@
 		lev1();
 	if (l1total)
 		lev1();
-	printf("S904000000FB\n");
+	printf("S70500200000DA\n");
 }

 lev1()

=== cut here ===

Pavel Roskin


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Pavel Roskin writes:

The sentence about buggy RPX boards should be removed from
getting_started.rpx

Your patch might fix the error on the last record, but I'm having no end of
trouble with the download timeouts (which Dan also mentions in that paragraph
of getting_started.rpx) on our CLLF boards. I don't seem to be making any
progress with Embedded Planet technical support on this either -- they say
they haven't reproduced the problem.

Are other people also having problems with download timeouts on Embedded Planet
boards? (or even if you're not, I'd love to hear what you're doing different).

Thanks,
Graham

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

I had this problem on a busy 10Mb shared wire.  My guess is they are handling
collisions wrong in their low level driver?  It works FINE at home on my three
machine network, which although also 10Mb is pretty well idle when I'm
downloading most of the time.

a

On Mon, 31 Jan 2000, Graham Stoney
wrote: > Pavel Roskin writes:

quoted

The sentence about buggy RPX boards should be removed from
getting_started.rpx

Your patch might fix the error on the last record, but I'm having no end of
trouble with the download timeouts (which Dan also mentions in that paragraph
of getting_started.rpx) on our CLLF boards. I don't seem to be making any
progress with Embedded Planet technical support on this either -- they say
they haven't reproduced the problem.

Are other people also having problems with download timeouts on Embedded Planet
boards? (or even if you're not, I'd love to hear what you're doing different).

Thanks,
Graham

--
Alan Mimms     Packet Engines, Inc.     Spokane, Washington [99214-0497]
  USA, Earth, Sol, Milky Way, The Local Group, Virgo Supercluster, U0
Despite the cost of living, have you noticed how popular it remains?
  -- Steven Wright?

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Are other people also having problems with download timeouts on
Embedded Planet
boards? (or even if you're not, I'd love to hear what you're
doing different).

I assume you mean using tftp.  If so ...
I have had the download timeout problems.  It is not related (directly) to
the EP boards.  It is more of a tftp issue.  If there is alot of network
traffic, tftp might not receive its packets in time.  If you have a large
file with alot of network traffic, it defintely will timeout.  I worked
around these issues by isolating the EP and host from the other network
traffic and/or splitting the srec file into smaller parts.

PS: we are working on a ELF binary dnload capabiltiy, watch EPs website next
month.  That will speed up the dnload.


Matthew Locke
Senior Software Engineer
Embedded Planet


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Hi Matt,

Thanks for chiming in here; I was beginning to think I was just going crazy...

Matthew Locke writes:

I assume you mean using tftp.  If so ...
I have had the download timeout problems.  It is not related (directly) to
the EP boards.  It is more of a tftp issue. If there is alot of network
traffic, tftp might not receive its packets in time.  If you have a large
file with alot of network traffic, it defintely will timeout.

I think you mean it's an issue with the EP implementation of tftp.

RFC1350 requires that the sender and receiver use retransmission after
timeouts to deal with lost UDP packets, as follows:

					If a packet gets lost in the
    network, the intended recipient will timeout and may retransmit his
    last packet (which may be data or an acknowledgment), thus causing
    the sender of the lost packet to retransmit that lost packet.

It seems as though the EP implementation simply aborts the transfer instead.

                                                               I worked
around these issues by isolating the EP and host from the other network
traffic and/or splitting the srec file into smaller parts.

Both these options are painful. It's hard to isolate a network device and its
server from the network, and splitting the file prevents me using the autoload
feature in the ROM monitor.

PS: we are working on a ELF binary dnload capabiltiy, watch EPs website next
month.  That will speed up the dnload.

Sounds great! If it's still using tftp, can you make sure they get the timeout
handling right this time? :-)

Thanks,
Graham

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

I think you mean it's an issue with the EP implementation of tftp.

Well... you didn't hear that from me:-)

Sounds great! If it's still using tftp, can you make sure they
get the timeout
handling right this time? :-)

Definitely.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Graham Stoney wrote:

....... but I'm having no end of
trouble with the download timeouts

There is some trouble with large downloads and high network
traffic.  I don't know exactly the trouble, but Embedded Planet
is working to correct this.  I have discussed it with them, and
probably bypassed their normal technical support channel so the
person that answered the phone or replied to your e-mail may not
see any problem report.......

I get around this two ways.  First, split the download into
smaller pieces.  Second, modify a Linux/PPC kernel to only
use the first 4 Mbytes of memory, put it into the flash rom,
write a program to copy a file from the (NFS) file system into
mmap()'ed physical memory, and modify the kernel restart
function so a reboot with the appropriate parameters jumps to
this new code.



	-- Dan

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/