[ECOS] Gnu load

[Brenda Spaur]

Thanks for your reply.  It really cleared up what was going on with
the S-records for me.  The documentation for the utility that handles
downloading S-records on my board explicitly states that it only
interprets S-records that correspond to the 32-bit addressing mode;
hence the reason it doesn't handle the S2 and S8 types.  I tried
your second suggestion of editing the bfd/srec.c file to force
it to generate S-records with 32 bit addresses and that did the
trick.

Thanks again,
Brenda Spaur
brenda@FieldHand.com

At 05:09 PM 12/4/98 -0500, Ian Lance Taylor wrote:
>   Date: Fri, 4 Dec 1998 06:11:50 -0700 (MST)
>   From: Brenda Spaur <brenda@fieldhand.com>
>
>   S011000073696D706C652E61732E7372656387
>   S20C0100003860000A4E80002062
>   S804010000FA
>
>   The S2 and S804 records are not recognized by my ROM download which
>   is looking for the S3 and S705 records.  I'd bet that there are still
>   some linker options that I need to provide but so far I haven't determined
>   what the problem is.  Any idea what is causing this problem?
>
>Both S2 and S8 are standard S-record types.  S2 is a data record with
>a three byte address.  In this case, the address is 0x10000.  S8 is a
>termination record with a three byte address (the 04 you mention is
>simply the length of the record, as with all S-record types).  In this
>case, the address, which for all termination records (S7/S8/S9) is the
>start address of the program, is again 0x10000.
>
>I would recommend fixing your downloader to recognize S1/S2/S8/S9
>records, which are perfectly standard.
>
>Otherwise, the linker will generate the smallest type of S-records
>that it can get away with.  So, you can force it to generate S3/S7
>records by having some section loaded at an address larger than
>0xffffff.  Of course, if your board does not have any memory at such
>an address, you will probably have other problems during the download.
>
>You can also change the linker behaviour by editing bfd/srec.c.
>Search for tdata->type.
>
>Ian
>
>