public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
* [ECOS] Gnu load
@ 1998-12-04 12:03 Brenda Spaur
       [not found] ` < m0zlv1S-001vNDC@aries3.spaur.com >
  0 siblings, 1 reply; 3+ messages in thread
From: Brenda Spaur @ 1998-12-04 12:03 UTC (permalink / raw)
  To: ecos-discuss

I'm just getting started porting ECOS to a board based on the MPC850.  I
downloaded the ECOS software tools and am trying to run a test
showing that I can build S-records from a simple program and download and 
run the program on the board.  My simple test program sets a
status register and returns, and in assembly looks like:

        .text
        .globl _start
        .align 2

_start:
        li 3,10
        blr

My first attempt to link produced the following S-records:

S011000073696D706C652E61732E7372656387
S30D018000003860000A4E800020E1
S7050180000079

This produced an error and from the SBC manufacturer I received
infromation that the start address should be 10000 as opposed
to the 1800000 given in the S-records I produced.  So I created a simple
linker script to set the start address.  Now objdump shows that I
have the correct start address but the S-records look like:

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?

Many thanks in advance,
Brenda Spaur
brenda@FieldHand.com

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [ECOS] Gnu load
       [not found] ` < m0zlv1S-001vNDC@aries3.spaur.com >
@ 1998-12-04 14:09   ` Ian Lance Taylor
  0 siblings, 0 replies; 3+ messages in thread
From: Ian Lance Taylor @ 1998-12-04 14:09 UTC (permalink / raw)
  To: brenda; +Cc: ecos-discuss

   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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [ECOS] Gnu load
@ 1998-12-07  9:54 Brenda Spaur
  0 siblings, 0 replies; 3+ messages in thread
From: Brenda Spaur @ 1998-12-07  9:54 UTC (permalink / raw)
  To: Ian Lance Taylor; +Cc: ecos-discuss

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
>
>

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~1998-12-07  9:54 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1998-12-04 12:03 [ECOS] Gnu load Brenda Spaur
     [not found] ` < m0zlv1S-001vNDC@aries3.spaur.com >
1998-12-04 14:09   ` Ian Lance Taylor
1998-12-07  9:54 Brenda Spaur

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).