public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
* Re: [ECOS] Help! Linker data section confusion (mine)
@ 2001-11-02  2:00 Roger Barraud
  2001-11-02  6:05 ` Gary Thomas
  0 siblings, 1 reply; 3+ messages in thread
From: Roger Barraud @ 2001-11-02  2:00 UTC (permalink / raw)
  To: ecos-discuss

Hmmm... no reply...
Help!!

Can someone please tell me whether the redboot.bin image out of the eCos config
tool is meant to be an absolute loadable image or not?

If so, why is my __ram_data_end == 0x14, when my __ram_data_start is 0x8000 ?
i.e. end < start !!?

Am I meant to relocate the image somehow? with objcopy perhaps? If so, what's
the magic incantation to get the data section located to 0x8000 correctly, with
a sensible, non-negative size???

Aaarrrgggg!!
I have too little hair left to be pulling any more out!!
~(:)

Roger Barraud
note - remove NO and SPAM from my email address to reply by email direct


> Hi All,
> 	I'm trying to build an SA11x0 redboot/eCos port. So far so good,
> using the Linux configtool version 2.03 and basing our source changes on Intel
> Assabet platform.
> 
> I have an image redboot.bin which is humongous - 1.3GB approx - which is the
> span of the addresses used in the program (rom base at 0x50000000). Is this
> normal? - or should the .bin build option strip it down to rom sections etc.?
> 
> I have stripped the first 1280MB out and managed to execute the code from boot
> ROM (FLASH (JTAGing it in))... but the part in vectors.S where the 'data'
> section is copied from rom to ram fails - probably faults actually - as
> __ram_data_end is less (at 0x14) than __ram_data_start (0x8000).
> 
> I've looked at the .ldi linker script fragments and the architecture .ld file
> (which defines things like SECTION_data)...  but I'm a little bewildered
still.
> 
> Should __ram_data_end be defined with an ABSOLUTE(.) rather than a '.' ?
> 
> The BSS section seems similarly afflicted.
> 
> What have I broken?
> 
> Any pearls of wisdom would be appreciated :)
> 
> Cheers
> Roger Barraud
> 
> 
> 


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

* Re: [ECOS] Help! Linker data section confusion (mine)
  2001-11-02  2:00 [ECOS] Help! Linker data section confusion (mine) Roger Barraud
@ 2001-11-02  6:05 ` Gary Thomas
  2001-11-02  7:59   ` Gary Thomas
  0 siblings, 1 reply; 3+ messages in thread
From: Gary Thomas @ 2001-11-02  6:05 UTC (permalink / raw)
  To: Roger Barraud; +Cc: eCos Discussion

On Tue, 2001-11-13 at 11:38, Roger Barraud wrote:
> Hmmm... no reply...
> Help!!
> 
> Can someone please tell me whether the redboot.bin image out of the eCos config
> tool is meant to be an absolute loadable image or not?
> 

Yes, absolutely.

> If so, why is my __ram_data_end == 0x14, when my __ram_data_start is 0x8000 ?
> i.e. end < start !!?
> 
> Am I meant to relocate the image somehow? with objcopy perhaps? If so, what's
> the magic incantation to get the data section located to 0x8000 correctly, with
> a sensible, non-negative size???
> 

This sounds like a familiar problem.  What version of the tools, in 
particular 'binutils' are you using?  I seem to recall seeing some 
previous messages that indicated that binutils of a certain vintage were
broken and they did not handle this properly.

> Aaarrrgggg!!
> I have too little hair left to be pulling any more out!!
> ~(:)
> 
> Roger Barraud
> note - remove NO and SPAM from my email address to reply by email direct
> 
> 
> > Hi All,
> > 	I'm trying to build an SA11x0 redboot/eCos port. So far so good,
> > using the Linux configtool version 2.03 and basing our source changes on Intel
> > Assabet platform.
> > 
> > I have an image redboot.bin which is humongous - 1.3GB approx - which is the
> > span of the addresses used in the program (rom base at 0x50000000). Is this
> > normal? - or should the .bin build option strip it down to rom sections etc.?
> > 
> > I have stripped the first 1280MB out and managed to execute the code from boot
> > ROM (FLASH (JTAGing it in))... but the part in vectors.S where the 'data'
> > section is copied from rom to ram fails - probably faults actually - as
> > __ram_data_end is less (at 0x14) than __ram_data_start (0x8000).
> > 
> > I've looked at the .ldi linker script fragments and the architecture .ld file
> > (which defines things like SECTION_data)...  but I'm a little bewildered
> still.
> > 
> > Should __ram_data_end be defined with an ABSOLUTE(.) rather than a '.' ?
> > 
> > The BSS section seems similarly afflicted.
> > 
> > What have I broken?
> > 
> > Any pearls of wisdom would be appreciated :)
> > 
> > Cheers
> > Roger Barraud
> > 
> > 
> > 


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

* Re: [ECOS] Help! Linker data section confusion (mine)
  2001-11-02  6:05 ` Gary Thomas
@ 2001-11-02  7:59   ` Gary Thomas
  0 siblings, 0 replies; 3+ messages in thread
From: Gary Thomas @ 2001-11-02  7:59 UTC (permalink / raw)
  To: Gary Thomas; +Cc: Roger Barraud, eCos Discussion

Something else to try - configure and build RedBoot for the Assabet, or
some other platform that we support "off the shelf".  If that works 
(i.e. you create an image which looks reasonable), then the problem is
somewhere in your layout.  If it fails similarly to the problem you 
describe below, then it's a tools issue.

On Tue, 2001-11-13 at 12:12, Gary Thomas wrote:
> On Tue, 2001-11-13 at 11:38, Roger Barraud wrote:
> > Hmmm... no reply...
> > Help!!
> > 
> > Can someone please tell me whether the redboot.bin image out of the eCos config
> > tool is meant to be an absolute loadable image or not?
> > 
> 
> Yes, absolutely.
> 
> > If so, why is my __ram_data_end == 0x14, when my __ram_data_start is 0x8000 ?
> > i.e. end < start !!?
> > 
> > Am I meant to relocate the image somehow? with objcopy perhaps? If so, what's
> > the magic incantation to get the data section located to 0x8000 correctly, with
> > a sensible, non-negative size???
> > 
> 
> This sounds like a familiar problem.  What version of the tools, in 
> particular 'binutils' are you using?  I seem to recall seeing some 
> previous messages that indicated that binutils of a certain vintage were
> broken and they did not handle this properly.
> 
> > Aaarrrgggg!!
> > I have too little hair left to be pulling any more out!!
> > ~(:)
> > 
> > Roger Barraud
> > note - remove NO and SPAM from my email address to reply by email direct
> > 
> > 
> > > Hi All,
> > > 	I'm trying to build an SA11x0 redboot/eCos port. So far so good,
> > > using the Linux configtool version 2.03 and basing our source changes on Intel
> > > Assabet platform.
> > > 
> > > I have an image redboot.bin which is humongous - 1.3GB approx - which is the
> > > span of the addresses used in the program (rom base at 0x50000000). Is this
> > > normal? - or should the .bin build option strip it down to rom sections etc.?
> > > 
> > > I have stripped the first 1280MB out and managed to execute the code from boot
> > > ROM (FLASH (JTAGing it in))... but the part in vectors.S where the 'data'
> > > section is copied from rom to ram fails - probably faults actually - as
> > > __ram_data_end is less (at 0x14) than __ram_data_start (0x8000).
> > > 
> > > I've looked at the .ldi linker script fragments and the architecture .ld file
> > > (which defines things like SECTION_data)...  but I'm a little bewildered
> > still.
> > > 
> > > Should __ram_data_end be defined with an ABSOLUTE(.) rather than a '.' ?
> > > 
> > > The BSS section seems similarly afflicted.
> > > 
> > > What have I broken?
> > > 
> > > Any pearls of wisdom would be appreciated :)
> > > 
> > > Cheers
> > > Roger Barraud
> > > 
> > > 
> > > 


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

end of thread, other threads:[~2001-11-13  3:19 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-11-02  2:00 [ECOS] Help! Linker data section confusion (mine) Roger Barraud
2001-11-02  6:05 ` Gary Thomas
2001-11-02  7:59   ` Gary Thomas

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