[ECOS] ecos redboot compile problem.

Doyle, Patrick WPD@dtccom.com
Fri May 2 14:51:00 GMT 2003


Hmmm... Now I see what you are getting at.  I still think that it is a Code
Composer problem, but I'm not in a position to test with Code Composer right
now.

It is possible that Code Composer's ELF support attempts to write the .data
section to the VMA instead of the LMA.  Actually, now that I think about it,
that sounds likely.

I'll have to think about this some more.  My first inclination is that the
SRAM version of RedBoot should be identical to the ROM version, with just an
address change.  Remember, the whole purpose of the SRAM version was to
enable me to check out initialization code while minimizing the chance that
I corrupt the FLASH to the point that I need to break out Code Composer.
The nice coincidence that I can (almost) use Code Composer to load that
version of the code is just an added benefit.

Of course, there is nothing stopping anybody from creating a CCS version of
RedBoot, that has the memory map that you (and Code Composer) desire.

Question for the maintainers (if any are still paying attention to this
thread :-):

What is you opinion on the proliferation of RedBoot configurations?  Right
now, the innovator has ROM, RAM, and SRAM RedBoot configurations.  I may add
a ROMRAM configuration later although, I'm not sure it buys us anything
since the part has a cache.  Will adding a fourth (or possibly fifth)
configuration, just for use with TI's proprietary JTAG debugger go against
the spirit of eCos?

--wpd


> -----Original Message-----
> From: Beymer, Mike [mailto:Mike.Beymer@itron.com] 
> Sent: Thursday, May 01, 2003 1:57 PM
> To: Doyle, Patrick; Jonathan Larmour
> Cc: eCos Discussion
> Subject: RE: [ECOS] 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



More information about the Ecos-discuss mailing list