This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
RE: ecos redboot compile problem.
- From: "Doyle, Patrick" <WPD at dtccom dot com>
- To: "'Beymer, Mike'" <Mike dot Beymer at itron dot com>
- Cc: eCos Discussion <ecos-discuss at sources dot redhat dot com>
- Date: Fri, 2 May 2003 10:47:32 -0400
- 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.
>
>
>
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss