This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: ecos redboot compile problem.


Maybe I'm confused, but when I do an arm-elf-objdump -h of
redboot-sram.out (this is the one that you built) I get the following.

/home/i386/redboot-sram.out:     file format elf32-littlearm

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .rom_vectors  00000048  20000000  20000000  00008000  2**0
                  CONTENTS, ALLOC, LOAD, CODE
  1 .text         0000fc1c  20000048  20000048  00008048  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  2 .fini         00000000  2000fc64  2000fc64  0001b800  2**0
                  CONTENTS
  3 .rodata       0000316a  2000fc64  2000fc64  00017c64  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  4 .rodata1      00000000  20012dd0  20012dd0  0001b800  2**0
                  CONTENTS
  5 .fixup        00000000  20012dd0  20012dd0  0001b800  2**0
                  CONTENTS
  6 .gcc_except_table 00000000  20012dd0  20012dd0  0001b800  2**0
                  CONTENTS
  7 .data         00000a30  20012dd0  20012dd0  0001add0  2**2
                  CONTENTS, ALLOC, LOAD, CODE
  8 .fixed_vectors 00000140  00000020  00000020  0001b800  2**5
                  CONTENTS
  9 .bss          00006238  00008000  00008000  00008000  2**4
                  ALLOC

This shows the VMA .data section at 20012dd0 which places it in sram. The current ldi 
file has the data section as:

 SECTION_data  (ram, 0x8000, FOLLOWING(.gcc_except_table))


When I would do a build with your ldi file the .data section ended up with a VMA
address of 0x8000 and a LMA after the gcc_except_table at 0x2001d86c. When I would
load this image on an innovator it would go out to lunch when it went into the 
cyg_hal_stop_constructors function, (no output at all to minicom, never reached 
initialization functions later in the code, etc. ). After moving 
the .data section to match what objdump was showing your redboot-sram.out to be, 
when loaded on the Innovator, all initializations ran and minicom showed the 
"no link" error. I'm using CCS version 2.20.00. arm-elf-gcc version 3.2.1 (eCosCentric).
I've been trying to get this build to work on the Innovator so I could start the port
to Minno, (It's always nice to know that the build process is working first :)
 -Mike
  

-----Original Message-----
From: Doyle, Patrick [mailto:WPD@dtccom.com]
Sent: Thursday, May 01, 2003 9:36 AM
To: Beymer, Mike; Jonathan Larmour
Cc: eCos Discussion
Subject: RE: [ECOS] ecos redboot compile problem.


I am confused by your change.  The version of
mlt_arm_arm9_innovator_sram.ldi that is in the repository mimics the ROM
version.  This is intentional -- the SRAM version is supposed to look, walk,
and quack like the ROM version, it's just linked at an address to which we
happen to be able to write.

Your change simply moves the initialized data section from external SDRAM
into internal SRAM.  While there is nothing intrinsicly wrong with this, it
makes the SRAM version of RedBoot look different than the ROM version, which
I am not sure I want to do.

In ROM versions of RedBoot, the initialized data (in the .data section) gets
loaded at one address (following the .gcc_except_table) in ROM, but its
runtime address is mapped to RAM.  The initialization code (in
hal/arm/arch/current/src/vectors.S) copies a chunk of memory immediately
following the .gcc_except_table to RAM at link address (0x8000 in our case).

Are you running this on an innovator or a minnow board?  If you are running
this on a minnow board, then I suggest you create a new port.

If you are running this on an innovator, then I need to investigate further
why the current tools cannot generate an SRAM version of RedBoot that can be
loaded by Code Composer -- perhaps I can even keep some notes this time,
although, with the working version at Delphi's site, it is questionable why
this would be required.

I know for a fact that the current version of the tools, with the latest
version of the repository loads and runs fine in SRAM via RedBoot.

What board are you running this on?
What version of Code Composer are you using?

--wpd


> -----Original Message-----
> From: Beymer, Mike [mailto:Mike.Beymer@itron.com] 
> Sent: Thursday, May 01, 2003 12:15 PM
> To: Beymer, Mike; Doyle, Patrick; Jonathan Larmour
> Cc: eCos Discussion
> Subject: RE: [ECOS] ecos redboot compile problem.
> 
> 
> I fat fingered vi and ended up with some extra lines at the end of
> the last ldi file. This one should be correct.
>  -Mike
> 
> -----Original Message-----
> From: Beymer, Mike 
> Sent: Thursday, May 01, 2003 8:39 AM
> To: 'Doyle, Patrick'; 'Jonathan Larmour'
> Cc: eCos Discussion
> Subject: RE: [ECOS] ecos redboot compile problem.
> 
> 
> I've attached my mlt_arm_arm9_innovator_sram.ldi with my
> changes to the .data section.
>  -Mike
> 
> -----Original Message-----
> From: Doyle, Patrick [mailto:WPD@dtccom.com]
> Sent: Thursday, May 01, 2003 6:23 AM
> To: 'Jonathan Larmour'; Beymer, Mike
> Cc: eCos Discussion
> Subject: RE: [ECOS] ecos redboot compile problem.
> 
> 
> I was confused by this as well.  I figured I would look into 
> it again after
> I finished the USB stuff I'm working on.  Perhaps by then 
> Mike will have
> solved all of the problems and I won't have to look at it :-)
> 
> --wpd
> 
> 
> > -----Original Message-----
> > From: Jonathan Larmour [mailto:jifl@eCosCentric.com] 
> > Sent: Wednesday, April 30, 2003 9:45 PM
> > To: Beymer, Mike
> > Cc: Doyle, Patrick; eCos Discussion
> > Subject: Re: [ECOS] ecos redboot compile problem.
> > 
> > 
> > Beymer, Mike wrote:
> > > Patrick,
> > >   It appears that the build problem I was experiencing was 
> > due to a change 
> > > in the memory layout file, mlt_arm_arm9_innovator_sram.ldi. 
> > The .data section
> > > was set to start at 0x8000, doing an objdump -h of 
> > redboot-sram.out the .data
> > > section is in sram at 0x20012dd0. After changing the .data 
> > section to follow 
> > > the .gcc_except_table I started seeing output from the 
> serial port. 
> > 
> > I was just wondering if there was anything we needed to do 
> to fix our 
> > master sources, but it seems that 
> > mlt_arm_arm9_innovator_sram.ldi already 
> > does this, or am I missing something?
> > 
> > -=-=-=-=-=-
> > ...
> >      SECTION_rodata1          (sram, ALIGN (0x4), LMA_EQ_VMA)
> >      SECTION_fixup            (sram, ALIGN (0x4), LMA_EQ_VMA)
> >      SECTION_gcc_except_table (sram, ALIGN (0x4), LMA_EQ_VMA)
> >      SECTION_fixed_vectors    (ram,  0x20,        LMA_EQ_VMA)
> >      SECTION_data             (ram,  0x8000, 
> > FOLLOWING(.gcc_except_table))
> >      SECTION_bss              (ram, ALIGN (0x4), LMA_EQ_VMA)
> > ...
> > -=-=-=-=-=-
> > 
> > 
> > Jifl
> > -- 
> > eCosCentric    http://www.eCosCentric.com/    The eCos and 
> > RedBoot experts
> > --[ "You can complain because roses have thorns, or you ]--
> > --[  can rejoice because thorns have roses." -Lincoln   ]-- 
> > Opinions==mine
> > 
> 
> 
> 
> 
> This message was scanned for viruses.
> 
> 
> 
> 




This message was scanned for viruses.




--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]