Re: [ECOS] RedBoot: load.c srecord input offset fix

[Grant Edwards <grante@visi.com>]

On Fri, Apr 20, 2001 at 06:40:31AM -0600, Gary Thomas wrote:

> >> The "offset" variable in load_srec_image() isn't incremented
> >> properly (assuming its purpose is to keep track of the current
> >> byte offset in the input stream).  My version of load.c has
> >> diverged enough that I can't generate a usable patch, so I'll
> >> summarize the changes:
> > [snip]
> > 
> > I'm probably being dumb but this doesn't seem right to me either. If it's
> > purely the offset within the I/O stream, then there should be one per getc.
> > If it's the offset of the decoded data bytes, there should be one for every
> > two chars of actual encoded srec data, and the offset shouldn't be
> > incremented for any of the header or checksum.
> > 
> > What is the "offset" actually meant to _be_ if neither of those two
> > options?
> 
> It's only purpose is to try and provide more information when there is
> damage in the input [stream].  In this case, it _should_ be just a count
> of the calls to getc().
> 
> I'll look at Grant's suggestions and make sure that it really does so.

I added a debugging line to print out the offset value when the
load is finished, and (with my changes) the value printed now
matches the size of the s-record file.  Previously it was
somewhere between the size of the binary and the size of the
s-record file.

I also noticed that the checksum of the entry-address record
(S[789]...) wasn't being verified.

One other change I made that I've found quite useful is to save
the lowest/highest/entry addresses in a globally visible spot
and have the "fis create" command use those values as defaults
if none are provided on the command line.  Loading a file from
a tftp server into flash is now something that can be scripted 
a bit easier using Kermit or some other programmatic interface.

RedBoot> load -h 10.0.0.1 filename.srec
RedBoot> fis create filename


-- 
Grant Edwards
grante@visi.com