[ECOS] ecos redboot compile problem.

Doyle, Patrick WPD@dtccom.com
Fri May 2 16:54:00 GMT 2003


>  The problem I see with the Code Composer argument is, that 
> the working image
> that you are supplying is using a different memory layout 
> than current the sram 
> ldi file. However I'm not saying that the other layout 
> shouldn't work, it just 
> didn't for me in my setup. 
The raw binary that is supplied by Delphi with their "Linux on the
Innovator" document exists solely to allow the end user to load RedBoot for
the first time on an innovator.  How that binary file was generated is
irrelevant (to the purpose of the "Linux on the Innovator" document), since,
once you run that the first time, you can load whatever version of RedBoot
(or other applications) into FLASH.  Note that there could be other features
added to RedBoot and/or eCos (such as USB support, etc...) that have no
applicability to the first application that was used to load in RedBoot.

Going forward, I would suggest that a fourth configuration be defined: CCS,
that has the minimal set of capabilities required to allow one to load
RedBoot into SRAM via Code Composer.  It would also serve as a starting
point for people, such as yourself, who need to port eCos to a new platform
and want to start by just running RedBoot in internal SRAM on the OMAP.

> 
>  Has anyone successfully built and used a sram image on CCS 
> and Innovator, using
> the released sram ldi file?
> 
I am anticipating that the answer will be "No".

--wpd

> -----Original Message-----
> From: Doyle, Patrick [mailto:WPD@dtccom.com]
> Sent: Friday, May 02, 2003 7:48 AM
> To: Beymer, Mike
> Cc: eCos Discussion
> Subject: RE: [ECOS] ecos redboot compile problem.
> 
> 
> 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.
> > 
> > 
> > 
> 
> 
> 
> 
> 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