* [ECOS] ecos redboot compile problem.
@ 2003-04-17 20:21 Beymer, Mike
2003-04-17 21:18 ` Gary D. Thomas
0 siblings, 1 reply; 25+ messages in thread
From: Beymer, Mike @ 2003-04-17 20:21 UTC (permalink / raw)
To: ecos-discuss
I'm working on a port of redboot to the PSI Minno OMAP5910 PCA. Which is very similar
to the PSI Innovator. In trying to verify my build process, I am attempting to rebuild Patrick Doyle's SRAM image for the innovator. ( his works mine doesn't). In looking at an objdump -d
of Patrick's object file compared to mine, it appears to have a problem with endian'ism
Patrick's looks as follows:
redboot-sram.out: file format elf32-littlearm
Disassembly of section .rom_vectors:
20000000 <__rom_vectors_lma>:
20000000: 78 56 34 12 21 43 65 87 xV4.!Ce.
20000008 <__exception_handlers>:
Mine comes out as:
redboot.img: file format elf32-littlearm
Disassembly of section .rom_vectors:
20000000 <__rom_vectors_lma>:
20000000: 12345678 eornes r5, r4, #125829120 ; 0x7800000
20000004: 87654321 strhib r4, [r5, -r1, lsr #6]!
20000008 <__exception_handlers>:
The same numbers but a different order. I've tried playing with the endian switches in the
compiler with no change in the results. I stumped, Patrick sent me what he remembers doing to build the file, but that didn't work. Any ideas??
-Mike Beymer
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [ECOS] ecos redboot compile problem.
2003-04-17 20:21 [ECOS] ecos redboot compile problem Beymer, Mike
@ 2003-04-17 21:18 ` Gary D. Thomas
0 siblings, 0 replies; 25+ messages in thread
From: Gary D. Thomas @ 2003-04-17 21:18 UTC (permalink / raw)
To: Beymer, Mike; +Cc: eCos Discussion
On Thu, 2003-04-17 at 14:21, Beymer, Mike wrote:
> I'm working on a port of redboot to the PSI Minno OMAP5910 PCA. Which is very similar
> to the PSI Innovator. In trying to verify my build process, I am attempting to rebuild Patrick Doyle's SRAM image for the innovator. ( his works mine doesn't). In looking at an objdump -d
> of Patrick's object file compared to mine, it appears to have a problem with endian'ism
> Patrick's looks as follows:
>
> redboot-sram.out: file format elf32-littlearm
>
> Disassembly of section .rom_vectors:
>
> 20000000 <__rom_vectors_lma>:
> 20000000: 78 56 34 12 21 43 65 87 xV4.!Ce.
>
> 20000008 <__exception_handlers>:
>
>
> Mine comes out as:
>
> redboot.img: file format elf32-littlearm
>
> Disassembly of section .rom_vectors:
>
> 20000000 <__rom_vectors_lma>:
> 20000000: 12345678 eornes r5, r4, #125829120 ; 0x7800000
> 20000004: 87654321 strhib r4, [r5, -r1, lsr #6]!
>
> 20000008 <__exception_handlers>:
>
> The same numbers but a different order. I've tried playing with the endian switches in the
> compiler with no change in the results. I stumped, Patrick sent me what he remembers doing to build the file, but that didn't work. Any ideas??
> -Mike Beymer
Must be something with your tools. I just built this and I
got identical results to Patrick's.
What host are you using?
Where did you get your toolchain from?
--
.--------------------------------------------------------.
| Mind: Embedded Linux and eCos Development |
|--------------------------------------------------------|
| Gary Thomas email: gary.thomas@mind.be |
| Mind ( http://mind.be ) tel: +1 (970) 229-1963 |
| gpg: http://www.chez-thomas.org/gary/gpg_key.asc |
'--------------------------------------------------------'
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss
^ permalink raw reply [flat|nested] 25+ messages in thread
* RE: [ECOS] ecos redboot compile problem.
@ 2003-05-02 16:54 Doyle, Patrick
0 siblings, 0 replies; 25+ messages in thread
From: Doyle, Patrick @ 2003-05-02 16:54 UTC (permalink / raw)
To: 'Beymer, Mike'; +Cc: eCos Discussion
> 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
^ permalink raw reply [flat|nested] 25+ messages in thread
* RE: [ECOS] ecos redboot compile problem.
@ 2003-05-02 16:42 Beymer, Mike
0 siblings, 0 replies; 25+ messages in thread
From: Beymer, Mike @ 2003-05-02 16:42 UTC (permalink / raw)
To: Doyle, Patrick; +Cc: eCos Discussion
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.
Has anyone successfully built and used a sram image on CCS and Innovator, using
the released sram ldi file?
-----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
^ permalink raw reply [flat|nested] 25+ messages in thread
* RE: [ECOS] ecos redboot compile problem.
@ 2003-05-02 14:51 Doyle, Patrick
0 siblings, 0 replies; 25+ messages in thread
From: Doyle, Patrick @ 2003-05-02 14:51 UTC (permalink / raw)
To: 'Beymer, Mike'; +Cc: eCos Discussion
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* RE: [ECOS] ecos redboot compile problem.
@ 2003-05-01 17:57 Beymer, Mike
0 siblings, 0 replies; 25+ messages in thread
From: Beymer, Mike @ 2003-05-01 17:57 UTC (permalink / raw)
To: Doyle, Patrick, Jonathan Larmour; +Cc: eCos Discussion
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* RE: [ECOS] ecos redboot compile problem.
@ 2003-05-01 16:40 Doyle, Patrick
0 siblings, 0 replies; 25+ messages in thread
From: Doyle, Patrick @ 2003-05-01 16:40 UTC (permalink / raw)
To: 'Beymer, Mike', Jonathan Larmour; +Cc: eCos Discussion
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.
>
>
>
>
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss
^ permalink raw reply [flat|nested] 25+ messages in thread
* RE: [ECOS] ecos redboot compile problem.
@ 2003-05-01 16:15 Beymer, Mike
0 siblings, 0 replies; 25+ messages in thread
From: Beymer, Mike @ 2003-05-01 16:15 UTC (permalink / raw)
To: Beymer, Mike, Doyle, Patrick, Jonathan Larmour; +Cc: eCos Discussion
[-- Attachment #1: Type: text/plain, Size: 2552 bytes --]
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.
[-- Attachment #2: mlt_arm_arm9_innovator_sram.ldi --]
[-- Type: application/octet-stream, Size: 985 bytes --]
// eCos memory layout - Tue Aug 07 11:15:51 2001
// This is a generated file - do not edit
#include <cyg/infra/cyg_type.inc>
MEMORY
{
ram : ORIGIN = 0x00000000, LENGTH = 0x02000000
sram : ORIGIN = 0x20000000, LENGTH = 0x00030000
}
SECTIONS
{
SECTIONS_BEGIN
SECTION_rom_vectors (sram, 0x20000000, LMA_EQ_VMA)
SECTION_text (sram, ALIGN (0x4), LMA_EQ_VMA)
SECTION_fini (sram, ALIGN (0x4), LMA_EQ_VMA)
SECTION_rodata (sram, ALIGN (0x4), LMA_EQ_VMA)
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_data (sram, ALIGN (0x4), FOLLOWING(.gcc_except_table))
SECTION_fixed_vectors (ram, 0x20, LMA_EQ_VMA)
SECTION_bss (ram, 0x8000 , LMA_EQ_VMA)
CYG_LABEL_DEFN(__heap1) = ALIGN (0x8);
SECTIONS_END
}
[-- Attachment #3: Type: text/plain, Size: 146 bytes --]
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss
^ permalink raw reply [flat|nested] 25+ messages in thread
* RE: [ECOS] ecos redboot compile problem.
@ 2003-05-01 15:38 Beymer, Mike
0 siblings, 0 replies; 25+ messages in thread
From: Beymer, Mike @ 2003-05-01 15:38 UTC (permalink / raw)
To: Doyle, Patrick, Jonathan Larmour; +Cc: eCos Discussion
[-- Attachment #1: Type: text/plain, Size: 2221 bytes --]
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.
[-- Attachment #2: mlt_arm_arm9_innovator_sram.ldi --]
[-- Type: application/octet-stream, Size: 1104 bytes --]
// eCos memory layout - Tue Aug 07 11:15:51 2001
// This is a generated file - do not edit
#include <cyg/infra/cyg_type.inc>
MEMORY
{
ram : ORIGIN = 0x00000000, LENGTH = 0x02000000
sram : ORIGIN = 0x20000000, LENGTH = 0x00030000
}
SECTIONS
{
SECTIONS_BEGIN
SECTION_rom_vectors (sram, 0x20000000, LMA_EQ_VMA)
SECTION_text (sram, ALIGN (0x4), LMA_EQ_VMA)
SECTION_fini (sram, ALIGN (0x4), LMA_EQ_VMA)
SECTION_rodata (sram, ALIGN (0x4), LMA_EQ_VMA)
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_data (sram, ALIGN (0x4), FOLLOWING(.gcc_except_table))
SECTION_fixed_vectors (ram, 0x20, LMA_EQ_VMA)
SECTION_bss (ram, 0x8000 , LMA_EQ_VMA)
CYG_LABEL_DEFN(__heap1) = ALIGN (0x8);
SECTION_fixed_vectors (ram, 0x20, LMA_EQ_VMA)
SECTION_bss (ram, 0xf000 , LMA_EQ_VMA)
SECTIONS_END
}
[-- Attachment #3: Type: text/plain, Size: 146 bytes --]
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss
^ permalink raw reply [flat|nested] 25+ messages in thread
* RE: [ECOS] ecos redboot compile problem.
@ 2003-05-01 13:25 Doyle, Patrick
0 siblings, 0 replies; 25+ messages in thread
From: Doyle, Patrick @ 2003-05-01 13:25 UTC (permalink / raw)
To: 'Jonathan Larmour', Beymer, Mike; +Cc: eCos Discussion
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
>
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [ECOS] ecos redboot compile problem.
2003-04-29 23:49 Beymer, Mike
@ 2003-05-01 1:45 ` Jonathan Larmour
0 siblings, 0 replies; 25+ messages in thread
From: Jonathan Larmour @ 2003-05-01 1:45 UTC (permalink / raw)
To: Beymer, Mike; +Cc: Doyle, Patrick, eCos Discussion
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
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss
^ permalink raw reply [flat|nested] 25+ messages in thread
* RE: [ECOS] ecos redboot compile problem.
@ 2003-04-30 12:20 Doyle, Patrick
0 siblings, 0 replies; 25+ messages in thread
From: Doyle, Patrick @ 2003-04-30 12:20 UTC (permalink / raw)
To: 'Beymer, Mike'; +Cc: eCos Discussion
The "no link" message is from the ethernet driver. If you don't have an
ethernet MAC/PHY, then you should remove the CYGPKG_DEVS_ETH_ARM_INNOVATOR
package. If you do have one, but it is different than the innovator, then
you should remove it until you have the time to adapt the innovator package
for your target.
--wpd
> -----Original Message-----
> From: Beymer, Mike [mailto:Mike.Beymer@itron.com]
> Sent: Tuesday, April 29, 2003 7:43 PM
> To: Doyle, Patrick
> Cc: eCos Discussion
> Subject: RE: [ECOS] ecos redboot compile problem.
>
>
> 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'm now seeing "no link" on the serial port which appears
> to be coming from
> the network driver. I'm assuming at this point that these are
> some of the problems
> you dealt with getting the network driver to work properly.
> -Mike Beymer
>
> -----Original Message-----
> From: Doyle, Patrick [mailto:WPD@dtccom.com]
> Sent: Friday, April 25, 2003 1:35 PM
> To: Doyle, Patrick; Beymer, Mike
> Cc: eCos Discussion
> Subject: RE: [ECOS] ecos redboot compile problem.
>
>
> Item 2 probably would make more sense if I included all of
> the words I meant
> to include.
>
> Sigh... It's Friday... I'm going home soon.
>
> --wpd
>
>
> > 2) Even if eCos did flag certain regions of memory as
> > "readonly" (which it would do for the internal SRAM of
> ^
> ^^^
> NOT
> > the OMAP), the only time that those first two locations
> > of SRAM are written are immediately following a reset --
> > before any such protections would be enabled (which they are not).
>
>
>
>
> 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
^ permalink raw reply [flat|nested] 25+ messages in thread
* RE: [ECOS] ecos redboot compile problem.
@ 2003-04-29 23:49 Beymer, Mike
2003-05-01 1:45 ` Jonathan Larmour
0 siblings, 1 reply; 25+ messages in thread
From: Beymer, Mike @ 2003-04-29 23:49 UTC (permalink / raw)
To: Doyle, Patrick; +Cc: eCos Discussion
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'm now seeing "no link" on the serial port which appears to be coming from
the network driver. I'm assuming at this point that these are some of the problems
you dealt with getting the network driver to work properly.
-Mike Beymer
-----Original Message-----
From: Doyle, Patrick [mailto:WPD@dtccom.com]
Sent: Friday, April 25, 2003 1:35 PM
To: Doyle, Patrick; Beymer, Mike
Cc: eCos Discussion
Subject: RE: [ECOS] ecos redboot compile problem.
Item 2 probably would make more sense if I included all of the words I meant
to include.
Sigh... It's Friday... I'm going home soon.
--wpd
> 2) Even if eCos did flag certain regions of memory as
> "readonly" (which it would do for the internal SRAM of
^
^^^
NOT
> the OMAP), the only time that those first two locations
> of SRAM are written are immediately following a reset --
> before any such protections would be enabled (which they are not).
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* RE: [ECOS] ecos redboot compile problem.
@ 2003-04-25 21:32 Beymer, Mike
0 siblings, 0 replies; 25+ messages in thread
From: Beymer, Mike @ 2003-04-25 21:32 UTC (permalink / raw)
To: Doyle, Patrick; +Cc: eCos Discussion
One other think I noticed was, that when I load my image with
code composer I don't get the load error at 0x20. I notice that in
the fixed vectors section is set to this address in the sram .ldi file.
I don't understand what's getting loaded here.
-Mike
-----Original Message-----
From: Doyle, Patrick [mailto:WPD@dtccom.com]
Sent: Friday, April 25, 2003 1:35 PM
To: Doyle, Patrick; Beymer, Mike
Cc: eCos Discussion
Subject: RE: [ECOS] ecos redboot compile problem.
Item 2 probably would make more sense if I included all of the words I meant
to include.
Sigh... It's Friday... I'm going home soon.
--wpd
> 2) Even if eCos did flag certain regions of memory as
> "readonly" (which it would do for the internal SRAM of
^
^^^
NOT
> the OMAP), the only time that those first two locations
> of SRAM are written are immediately following a reset --
> before any such protections would be enabled (which they are not).
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* RE: [ECOS] ecos redboot compile problem.
@ 2003-04-25 20:53 Doyle, Patrick
0 siblings, 0 replies; 25+ messages in thread
From: Doyle, Patrick @ 2003-04-25 20:53 UTC (permalink / raw)
To: Doyle, Patrick, 'Beymer, Mike'; +Cc: eCos Discussion
Item 2 probably would make more sense if I included all of the words I meant
to include.
Sigh... It's Friday... I'm going home soon.
--wpd
> 2) Even if eCos did flag certain regions of memory as
> "readonly" (which it would do for the internal SRAM of
^
^^^
NOT
> the OMAP), the only time that those first two locations
> of SRAM are written are immediately following a reset --
> before any such protections would be enabled (which they are not).
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss
^ permalink raw reply [flat|nested] 25+ messages in thread
* RE: [ECOS] ecos redboot compile problem.
@ 2003-04-25 20:37 Doyle, Patrick
0 siblings, 0 replies; 25+ messages in thread
From: Doyle, Patrick @ 2003-04-25 20:37 UTC (permalink / raw)
To: 'Beymer, Mike'; +Cc: eCos Discussion
It's a good concern, but misplaced in this case for a couple of reasons:
1) In general eCos does not enable MMU-style memory protection. Having said
that, it is possible/likely that certain regions of non-existent memory may
be flagged as "inaccessible" using whatever hardware is available (the MMU
on the ARMs, the BAT registers on the PowerPC's etc...), but eCos does not
implement general memory protection such as is found in Linux, or
occasionally, Windows.
2) Even if eCos did flag certain regions of memory as "readonly" (which it
would do for the internal SRAM of the OMAP), the only time that those first
two locations of SRAM are written are immediately following a reset --
before any such protections would be enabled (which they are not).
So, in this case, you may rest easily :-)
--wpd
> -----Original Message-----
> From: Beymer, Mike [mailto:Mike.Beymer@itron.com]
> Sent: Friday, April 25, 2003 4:27 PM
> To: Doyle, Patrick
> Cc: eCos Discussion
> Subject: RE: [ECOS] ecos redboot compile problem.
>
>
> So I take it ecos isn't invoking memory protection based on this?
> My thought for a infinite loop was if this code was in
> protected memory
> when we attempt to access that area with a write it will generate a
> data abort exception and the value would not be changed. When we
> return from the exception an run again we would again find
> the same values.
> but I may be just blowing wind.
> -Mike
>
> -----Original Message-----
> From: Doyle, Patrick [mailto:WPD@dtccom.com]
> Sent: Friday, April 25, 2003 11:45 AM
> To: Beymer, Mike
> Cc: eCos Discussion
> Subject: RE: [ECOS] ecos redboot compile problem.
>
>
> > Another point just discovered,
> > An arm-elf-objdump -h of redboot.img reveals .rom_vectors as
> > CONTENTS, ALLOC, LOAD, READONLY, CODE
> > arm-elf-objdump -h of redboot-SRAM.out show .rom_vectors as
> > CONTENTS, ALLOC, LOAD, CODE
> >
> I don't know why it changed from when I created
> redboot-SRAM.out to now, but
> it doesn't matter. The READONLY attribute is just a flag to loader.
> RedBoot, at startup just scribbles to locations in SRAM
> (which is writable,
> despite what hints might be in some files somewhere on the
> host computer),
> so why do you think that is putting you in an infinite loop?
>
> > if the READONLY means that code is not allowed to be
> > changed i.e. protected
> > space. Then trying to rewrite the 0x12345678 and 0x87654321
> > would fail and
> > put me into an infinite loop. How do I get this READONLY
> > turned off??
>
> --wpd
>
>
>
>
> 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
^ permalink raw reply [flat|nested] 25+ messages in thread
* RE: [ECOS] ecos redboot compile problem.
@ 2003-04-25 20:33 Beymer, Mike
0 siblings, 0 replies; 25+ messages in thread
From: Beymer, Mike @ 2003-04-25 20:33 UTC (permalink / raw)
To: Doyle, Patrick; +Cc: eCos Discussion
So I take it ecos isn't invoking memory protection based on this?
My thought for a infinite loop was if this code was in protected memory
when we attempt to access that area with a write it will generate a
data abort exception and the value would not be changed. When we
return from the exception an run again we would again find the same values.
but I may be just blowing wind.
-Mike
-----Original Message-----
From: Doyle, Patrick [mailto:WPD@dtccom.com]
Sent: Friday, April 25, 2003 11:45 AM
To: Beymer, Mike
Cc: eCos Discussion
Subject: RE: [ECOS] ecos redboot compile problem.
> Another point just discovered,
> An arm-elf-objdump -h of redboot.img reveals .rom_vectors as
> CONTENTS, ALLOC, LOAD, READONLY, CODE
> arm-elf-objdump -h of redboot-SRAM.out show .rom_vectors as
> CONTENTS, ALLOC, LOAD, CODE
>
I don't know why it changed from when I created redboot-SRAM.out to now, but
it doesn't matter. The READONLY attribute is just a flag to loader.
RedBoot, at startup just scribbles to locations in SRAM (which is writable,
despite what hints might be in some files somewhere on the host computer),
so why do you think that is putting you in an infinite loop?
> if the READONLY means that code is not allowed to be
> changed i.e. protected
> space. Then trying to rewrite the 0x12345678 and 0x87654321
> would fail and
> put me into an infinite loop. How do I get this READONLY
> turned off??
--wpd
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* RE: [ECOS] ecos redboot compile problem.
@ 2003-04-25 18:54 Doyle, Patrick
0 siblings, 0 replies; 25+ messages in thread
From: Doyle, Patrick @ 2003-04-25 18:54 UTC (permalink / raw)
To: 'Beymer, Mike'; +Cc: eCos Discussion
> Another point just discovered,
> An arm-elf-objdump -h of redboot.img reveals .rom_vectors as
> CONTENTS, ALLOC, LOAD, READONLY, CODE
> arm-elf-objdump -h of redboot-SRAM.out show .rom_vectors as
> CONTENTS, ALLOC, LOAD, CODE
>
I don't know why it changed from when I created redboot-SRAM.out to now, but
it doesn't matter. The READONLY attribute is just a flag to loader.
RedBoot, at startup just scribbles to locations in SRAM (which is writable,
despite what hints might be in some files somewhere on the host computer),
so why do you think that is putting you in an infinite loop?
> if the READONLY means that code is not allowed to be
> changed i.e. protected
> space. Then trying to rewrite the 0x12345678 and 0x87654321
> would fail and
> put me into an infinite loop. How do I get this READONLY
> turned off??
--wpd
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss
^ permalink raw reply [flat|nested] 25+ messages in thread
* RE: [ECOS] ecos redboot compile problem.
@ 2003-04-25 18:19 Beymer, Mike
0 siblings, 0 replies; 25+ messages in thread
From: Beymer, Mike @ 2003-04-25 18:19 UTC (permalink / raw)
To: Doyle, Patrick; +Cc: eCos Discussion
Another point just discovered,
An arm-elf-objdump -h of redboot.img reveals .rom_vectors as
CONTENTS, ALLOC, LOAD, READONLY, CODE
arm-elf-objdump -h of redboot-SRAM.out show .rom_vectors as
CONTENTS, ALLOC, LOAD, CODE
if the READONLY means that code is not allowed to be changed i.e. protected
space. Then trying to rewrite the 0x12345678 and 0x87654321 would fail and
put me into an infinite loop. How do I get this READONLY turned off??
-Thanks Mike Beymer
-----Original Message-----
From: Doyle, Patrick [mailto:WPD@dtccom.com]
Sent: Friday, April 25, 2003 6:13 AM
To: Beymer, Mike
Cc: eCos Discussion
Subject: RE: [ECOS] ecos redboot compile problem.
Just so we're on the same page here, what system are you using to compile
your eCos? Is it, perhaps, a Sparc or other big-endian machine? That might
explain the byte swapping problem you are observing.
As far as the 12345678 87654321 "trick"...
This is a trick that I implemented solely to minimize the number of times I
have to switch to running Code Composer (on a Windows machine) so I can stay
in my nice, warm, cozy, Linux world.
Basically, RedBoot (and the stupid serial port bootloader I wrote before I
ported RedBoot) checks the first two locations in internal SRAM at startup.
If they are 0x12345678 and 0x87654321 respectively, then RedBoot branches to
the third location in SRAM. (It also zeros those two locations if they
match -- that way it only works the first time I press reset after loading
code into SRAM). Since SRAM contents are preserved across hard resets (also
known as "power on" resets, but don't expect SRAM to be preserved across a
power cycle :-)), I can download a new version of RedBoot to internal SRAM,
hold down the reset button for longer than two seconds (so that the FPGA
generates a poweron reset), and see if my new version of RedBoot works
before I commit it to flash. Without that feature, if I committed a new
version of RedBoot to flash, pressed the reset button, and something didn't
work, I would have to go find my Windows box with Code Composer on it,
attach the JTAG, and use Code Composer to reload a known good RedBoot.
There is nothing special about the 0x12345678 and 0x87654321 constants.
They were not selected because of any resemblance to known opcodes. They
were just the first two constants that I thought of that I thought had a
reasonable chance of not showing up by chance in SRAM.
Now, having said all of that, it turns out that the SRAM version of RedBoot
is also suitable for loading in via Code Composer. Sometime in the recent
past, TI added support for ELF files (traditionally, TI tools only support
COFF files). However, with the version 2.00 tools I was using, I found that
some versions of the RedBoot for SRAM caused CCS to die. So I fiddled
around, removing the networking packages, etc... until I generated an ELF
file which didn't choke CCS. I haven't tried with the 2.20 tools that are
available now.
Regardless, you should be able to generate the SRAM version of RedBoot with
something similar to:
prompt$ ecosconfig new innovator redboot
prompt$ ecosconfig import
$ECOS_REPOSITORY/hal/arm/arm9/innovator/current/misc/redboot_SRAM.ecm
prompt$ ecosconfig tree
prompt$ make
prompt$ arm-elf-objdump -D install/bin/redboot.elf | grep "2000000[04]:"
produces the following output:
20000000: 12345678 eornes r5, r4, #125829120 ; 0x7800000
20000004: 87654321 strhib r4, [r5, -r1, lsr #6]!
FWIW...
prompt$ arm-elf-gcc -v
Reading specs from
/usr/local/xtools/arm-elf-3.2.1/lib/gcc-lib/arm-elf/3.2.1/specs
Configured with: ../../src/gcc-3.2.1/configure --target=arm-elf
--prefix=/usr/local/xtools/arm-elf-3.2.1 --enable-languages=c,c++
--with-gnu-as --with-gnu-ld --with-newlib
--with-gxx-include-dir=/usr/local/xtools/arm-elf-3.2.1/arm-elf/include -v
Thread model: single
gcc version 3.2.1
HTH
--wpd
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss
^ permalink raw reply [flat|nested] 25+ messages in thread
* RE: [ECOS] ecos redboot compile problem.
@ 2003-04-25 17:02 Doyle, Patrick
0 siblings, 0 replies; 25+ messages in thread
From: Doyle, Patrick @ 2003-04-25 17:02 UTC (permalink / raw)
To: 'Beymer, Mike'; +Cc: eCos Discussion
> Thanks for the reply Patrick,
> I found the branch at the third location in SRAM. However,
> what I don't understand is how
> the PC is getting to address 0x20000008 (Third position in
> SRAM) on a reset. From the comments
> in the source I assume that there is a branch in Flash at
> 0x00 that goes to SRAM. If it's
> going to 0x20000000 then why don't the codes at 0x20000000
> and 0x20000004 get executed since
> they are valid opcodes?
At reset, the processor starts executing at address 0. Assuming the DIP
switches are in their default positions, address 0 maps to the AMD boot
flash on the innovator.
The code at address 0 contains a branch instruction to the initialization
code in RedBoot.
The initialization code examines addresses 0x20000000 and 0x20000004 to see
if they contain 0x12345678 and 0x87654321 respectively. If they do, the
code zeros those locations and branches to address 0x20000008 (the third
word in SRAM). So, the opcodes at addresses 0x20000000 and 0x20000004 are
never executed.
>
> BTW. I'm running on a X86 Linux Red Hat 9.0. I've tried
> both the caned and home built
> cross-compiler. For some reason arm-elf-objdump thinks that
> the data at 0x20000000 is
> data in redboot-SRAM.out from you; and my redboot.img it
> shows as instructions.
>
Now I am confused as to what was your original problem...
When I run arm-elf-objdump -D as I described in my previous email, I get the
same results for redboot-SRAM.out as I do for install/bin/redboot.elf.
(Well, they are the same for the 0x20000000 addresses of which we are
speaking -- I've changed other things since then).
So I am confused... what problem are you trying to solve?
--wpd
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss
^ permalink raw reply [flat|nested] 25+ messages in thread
* RE: [ECOS] ecos redboot compile problem.
@ 2003-04-25 15:53 Beymer, Mike
0 siblings, 0 replies; 25+ messages in thread
From: Beymer, Mike @ 2003-04-25 15:53 UTC (permalink / raw)
To: Doyle, Patrick; +Cc: eCos Discussion
Thanks for the reply Patrick,
I found the branch at the third location in SRAM. However, what I don't understand is how
the PC is getting to address 0x20000008 (Third position in SRAM) on a reset. From the comments
in the source I assume that there is a branch in Flash at 0x00 that goes to SRAM. If it's
going to 0x20000000 then why don't the codes at 0x20000000 and 0x20000004 get executed since
they are valid opcodes?
BTW. I'm running on a X86 Linux Red Hat 9.0. I've tried both the caned and home built
cross-compiler. For some reason arm-elf-objdump thinks that the data at 0x20000000 is
data in redboot-SRAM.out from you; and my redboot.img it shows as instructions.
-Thanks
Mike Beymer
-----Original Message-----
From: Doyle, Patrick [mailto:WPD@dtccom.com]
Sent: Friday, April 25, 2003 6:13 AM
To: Beymer, Mike
Cc: eCos Discussion
Subject: RE: [ECOS] ecos redboot compile problem.
Just so we're on the same page here, what system are you using to compile
your eCos? Is it, perhaps, a Sparc or other big-endian machine? That might
explain the byte swapping problem you are observing.
As far as the 12345678 87654321 "trick"...
This is a trick that I implemented solely to minimize the number of times I
have to switch to running Code Composer (on a Windows machine) so I can stay
in my nice, warm, cozy, Linux world.
Basically, RedBoot (and the stupid serial port bootloader I wrote before I
ported RedBoot) checks the first two locations in internal SRAM at startup.
If they are 0x12345678 and 0x87654321 respectively, then RedBoot branches to
the third location in SRAM. (It also zeros those two locations if they
match -- that way it only works the first time I press reset after loading
code into SRAM). Since SRAM contents are preserved across hard resets (also
known as "power on" resets, but don't expect SRAM to be preserved across a
power cycle :-)), I can download a new version of RedBoot to internal SRAM,
hold down the reset button for longer than two seconds (so that the FPGA
generates a poweron reset), and see if my new version of RedBoot works
before I commit it to flash. Without that feature, if I committed a new
version of RedBoot to flash, pressed the reset button, and something didn't
work, I would have to go find my Windows box with Code Composer on it,
attach the JTAG, and use Code Composer to reload a known good RedBoot.
There is nothing special about the 0x12345678 and 0x87654321 constants.
They were not selected because of any resemblance to known opcodes. They
were just the first two constants that I thought of that I thought had a
reasonable chance of not showing up by chance in SRAM.
Now, having said all of that, it turns out that the SRAM version of RedBoot
is also suitable for loading in via Code Composer. Sometime in the recent
past, TI added support for ELF files (traditionally, TI tools only support
COFF files). However, with the version 2.00 tools I was using, I found that
some versions of the RedBoot for SRAM caused CCS to die. So I fiddled
around, removing the networking packages, etc... until I generated an ELF
file which didn't choke CCS. I haven't tried with the 2.20 tools that are
available now.
Regardless, you should be able to generate the SRAM version of RedBoot with
something similar to:
prompt$ ecosconfig new innovator redboot
prompt$ ecosconfig import
$ECOS_REPOSITORY/hal/arm/arm9/innovator/current/misc/redboot_SRAM.ecm
prompt$ ecosconfig tree
prompt$ make
prompt$ arm-elf-objdump -D install/bin/redboot.elf | grep "2000000[04]:"
produces the following output:
20000000: 12345678 eornes r5, r4, #125829120 ; 0x7800000
20000004: 87654321 strhib r4, [r5, -r1, lsr #6]!
FWIW...
prompt$ arm-elf-gcc -v
Reading specs from
/usr/local/xtools/arm-elf-3.2.1/lib/gcc-lib/arm-elf/3.2.1/specs
Configured with: ../../src/gcc-3.2.1/configure --target=arm-elf
--prefix=/usr/local/xtools/arm-elf-3.2.1 --enable-languages=c,c++
--with-gnu-as --with-gnu-ld --with-newlib
--with-gxx-include-dir=/usr/local/xtools/arm-elf-3.2.1/arm-elf/include -v
Thread model: single
gcc version 3.2.1
HTH
--wpd
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss
^ permalink raw reply [flat|nested] 25+ messages in thread
* RE: [ECOS] ecos redboot compile problem.
@ 2003-04-25 13:32 Doyle, Patrick
0 siblings, 0 replies; 25+ messages in thread
From: Doyle, Patrick @ 2003-04-25 13:32 UTC (permalink / raw)
To: 'Beymer, Mike'; +Cc: eCos Discussion
Just so we're on the same page here, what system are you using to compile
your eCos? Is it, perhaps, a Sparc or other big-endian machine? That might
explain the byte swapping problem you are observing.
As far as the 12345678 87654321 "trick"...
This is a trick that I implemented solely to minimize the number of times I
have to switch to running Code Composer (on a Windows machine) so I can stay
in my nice, warm, cozy, Linux world.
Basically, RedBoot (and the stupid serial port bootloader I wrote before I
ported RedBoot) checks the first two locations in internal SRAM at startup.
If they are 0x12345678 and 0x87654321 respectively, then RedBoot branches to
the third location in SRAM. (It also zeros those two locations if they
match -- that way it only works the first time I press reset after loading
code into SRAM). Since SRAM contents are preserved across hard resets (also
known as "power on" resets, but don't expect SRAM to be preserved across a
power cycle :-)), I can download a new version of RedBoot to internal SRAM,
hold down the reset button for longer than two seconds (so that the FPGA
generates a poweron reset), and see if my new version of RedBoot works
before I commit it to flash. Without that feature, if I committed a new
version of RedBoot to flash, pressed the reset button, and something didn't
work, I would have to go find my Windows box with Code Composer on it,
attach the JTAG, and use Code Composer to reload a known good RedBoot.
There is nothing special about the 0x12345678 and 0x87654321 constants.
They were not selected because of any resemblance to known opcodes. They
were just the first two constants that I thought of that I thought had a
reasonable chance of not showing up by chance in SRAM.
Now, having said all of that, it turns out that the SRAM version of RedBoot
is also suitable for loading in via Code Composer. Sometime in the recent
past, TI added support for ELF files (traditionally, TI tools only support
COFF files). However, with the version 2.00 tools I was using, I found that
some versions of the RedBoot for SRAM caused CCS to die. So I fiddled
around, removing the networking packages, etc... until I generated an ELF
file which didn't choke CCS. I haven't tried with the 2.20 tools that are
available now.
Regardless, you should be able to generate the SRAM version of RedBoot with
something similar to:
prompt$ ecosconfig new innovator redboot
prompt$ ecosconfig import
$ECOS_REPOSITORY/hal/arm/arm9/innovator/current/misc/redboot_SRAM.ecm
prompt$ ecosconfig tree
prompt$ make
prompt$ arm-elf-objdump -D install/bin/redboot.elf | grep "2000000[04]:"
produces the following output:
20000000: 12345678 eornes r5, r4, #125829120 ; 0x7800000
20000004: 87654321 strhib r4, [r5, -r1, lsr #6]!
FWIW...
prompt$ arm-elf-gcc -v
Reading specs from
/usr/local/xtools/arm-elf-3.2.1/lib/gcc-lib/arm-elf/3.2.1/specs
Configured with: ../../src/gcc-3.2.1/configure --target=arm-elf
--prefix=/usr/local/xtools/arm-elf-3.2.1 --enable-languages=c,c++
--with-gnu-as --with-gnu-ld --with-newlib
--with-gxx-include-dir=/usr/local/xtools/arm-elf-3.2.1/arm-elf/include -v
Thread model: single
gcc version 3.2.1
HTH
--wpd
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss
^ permalink raw reply [flat|nested] 25+ messages in thread
* RE: [ECOS] ecos redboot compile problem.
@ 2003-04-24 22:04 Beymer, Mike
0 siblings, 0 replies; 25+ messages in thread
From: Beymer, Mike @ 2003-04-24 22:04 UTC (permalink / raw)
To: Gary D. Thomas; +Cc: eCos Discussion
I'm still unable to get the same results as Patrick and Gary. Here's a list of things tried.
- reinstall ecos and tool chains.
- build tool chain from scratch.
- looked at hex dumps of img file and found same byte order at same offset for the
12345678 87654321 pattern.
- looked at the source for this pattern. According to a comment in source the 12345678 and
87654321 when loaded into the first 2 words of sram is a trick to get the reset to branch
to the 3rd location in sram.
- 12345678 decodes into a valid arm instruction. "eornes r5, r4, #125829120" 87654321
decodes into a valid instruction as well. Maybe the better question to ask is why
isn't this code being looked at by obj-dump -d as an instruction in Patrick and Gary's'
generated code. Is there somewhere that this "trick" is documented outside of ECOS?
Any ideas?
-Thanks Mike Beymer
-----Original Message-----
From: Gary D. Thomas [mailto:gary.thomas@mind.be]
Sent: Friday, April 18, 2003 1:54 AM
To: Beymer, Mike
Cc: eCos Discussion
Subject: RE: [ECOS] ecos redboot compile problem.
On Thu, 2003-04-17 at 16:01, Beymer, Mike wrote:
> I'm building on Linux RH 8.0. I went on vacation and can't remember exactly where the toolchains came from. The version information from arm-elf-gcc returns
>
> arm-elf-gcc (GCC) 3.2.1 (eCosCentric)
Then you got these from the eCos 2.0 Beta distribution.
>
> Do you know which tool chain you are using? Maybe I need to replace mine.
I build my own toolchains, but the ones that you've downloaded
are known to work fine.
What commands did you use to build? Here's what I did that worked:
% ecosconfig new innovator redboot
% ecosconfig import /work2/ecos/packages/hal/arm/arm9/innovator/current/misc/redboot_SRAM.ecm
% ecosconfig tree
% make
(my eCos repository is stored at "/work2/ecos/packages")
> -Thanks
> -Mike Beymer
>
> -----Original Message-----
> From: Gary D. Thomas [mailto:gary.thomas@mind.be]
> Sent: Thursday, April 17, 2003 2:18 PM
> To: Beymer, Mike
> Cc: eCos Discussion
> Subject: Re: [ECOS] ecos redboot compile problem.
>
>
> On Thu, 2003-04-17 at 14:21, Beymer, Mike wrote:
> > I'm working on a port of redboot to the PSI Minno OMAP5910 PCA. Which is very similar
> > to the PSI Innovator. In trying to verify my build process, I am attempting to rebuild Patrick Doyle's SRAM image for the innovator. ( his works mine doesn't). In looking at an objdump -d
> > of Patrick's object file compared to mine, it appears to have a problem with endian'ism
> > Patrick's looks as follows:
> >
> > redboot-sram.out: file format elf32-littlearm
> >
> > Disassembly of section .rom_vectors:
> >
> > 20000000 <__rom_vectors_lma>:
> > 20000000: 78 56 34 12 21 43 65 87 xV4.!Ce.
> >
> > 20000008 <__exception_handlers>:
> >
> >
> > Mine comes out as:
> >
> > redboot.img: file format elf32-littlearm
> >
> > Disassembly of section .rom_vectors:
> >
> > 20000000 <__rom_vectors_lma>:
> > 20000000: 12345678 eornes r5, r4, #125829120 ; 0x7800000
> > 20000004: 87654321 strhib r4, [r5, -r1, lsr #6]!
> >
> > 20000008 <__exception_handlers>:
> >
> > The same numbers but a different order. I've tried playing with the endian switches in the
> > compiler with no change in the results. I stumped, Patrick sent me what he remembers doing to build the file, but that didn't work. Any ideas??
> > -Mike Beymer
>
> Must be something with your tools. I just built this and I
> got identical results to Patrick's.
>
> What host are you using?
> Where did you get your toolchain from?
>
> --
> .--------------------------------------------------------.
> | Mind: Embedded Linux and eCos Development |
> |--------------------------------------------------------|
> | Gary Thomas email: gary.thomas@mind.be |
> | Mind ( http://mind.be ) tel: +1 (970) 229-1963 |
> | gpg: http://www.chez-thomas.org/gary/gpg_key.asc |
> '--------------------------------------------------------'
>
>
>
>
>
> This message was scanned for viruses.
>
>
--
.--------------------------------------------------------.
| Mind: Embedded Linux and eCos Development |
|--------------------------------------------------------|
| Gary Thomas email: gary.thomas@mind.be |
| Mind ( http://mind.be ) tel: +1 (970) 229-1963 |
| gpg: http://www.chez-thomas.org/gary/gpg_key.asc |
'--------------------------------------------------------'
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* RE: [ECOS] ecos redboot compile problem.
@ 2003-04-18 19:29 Beymer, Mike
0 siblings, 0 replies; 25+ messages in thread
From: Beymer, Mike @ 2003-04-18 19:29 UTC (permalink / raw)
To: Gary D. Thomas; +Cc: eCos Discussion
Those are the same commands I used exactly (except the directory of course). Today I tried
redownloading ecos from cvs and rebuilt redboot with exactly the same results. I guess the
toolchain is next suspect.
-Mike
-----Original Message-----
From: Gary D. Thomas [mailto:gary.thomas@mind.be]
Sent: Friday, April 18, 2003 1:54 AM
To: Beymer, Mike
Cc: eCos Discussion
Subject: RE: [ECOS] ecos redboot compile problem.
Please CC your replies to the eCos mailing list so that all
can benefit from the information. That list provides free
support - private support is available under contract only.
On Thu, 2003-04-17 at 16:01, Beymer, Mike wrote:
> I'm building on Linux RH 8.0. I went on vacation and can't remember exactly where the toolchains came from. The version information from arm-elf-gcc returns
>
> arm-elf-gcc (GCC) 3.2.1 (eCosCentric)
Then you got these from the eCos 2.0 Beta distribution.
>
> Do you know which tool chain you are using? Maybe I need to replace mine.
I build my own toolchains, but the ones that you've downloaded
are known to work fine.
What commands did you use to build? Here's what I did that worked:
% ecosconfig new innovator redboot
% ecosconfig import /work2/ecos/packages/hal/arm/arm9/innovator/current/misc/redboot_SRAM.ecm
% ecosconfig tree
% make
(my eCos repository is stored at "/work2/ecos/packages")
> -Thanks
> -Mike Beymer
>
> -----Original Message-----
> From: Gary D. Thomas [mailto:gary.thomas@mind.be]
> Sent: Thursday, April 17, 2003 2:18 PM
> To: Beymer, Mike
> Cc: eCos Discussion
> Subject: Re: [ECOS] ecos redboot compile problem.
>
>
> On Thu, 2003-04-17 at 14:21, Beymer, Mike wrote:
> > I'm working on a port of redboot to the PSI Minno OMAP5910 PCA. Which is very similar
> > to the PSI Innovator. In trying to verify my build process, I am attempting to rebuild Patrick Doyle's SRAM image for the innovator. ( his works mine doesn't). In looking at an objdump -d
> > of Patrick's object file compared to mine, it appears to have a problem with endian'ism
> > Patrick's looks as follows:
> >
> > redboot-sram.out: file format elf32-littlearm
> >
> > Disassembly of section .rom_vectors:
> >
> > 20000000 <__rom_vectors_lma>:
> > 20000000: 78 56 34 12 21 43 65 87 xV4.!Ce.
> >
> > 20000008 <__exception_handlers>:
> >
> >
> > Mine comes out as:
> >
> > redboot.img: file format elf32-littlearm
> >
> > Disassembly of section .rom_vectors:
> >
> > 20000000 <__rom_vectors_lma>:
> > 20000000: 12345678 eornes r5, r4, #125829120 ; 0x7800000
> > 20000004: 87654321 strhib r4, [r5, -r1, lsr #6]!
> >
> > 20000008 <__exception_handlers>:
> >
> > The same numbers but a different order. I've tried playing with the endian switches in the
> > compiler with no change in the results. I stumped, Patrick sent me what he remembers doing to build the file, but that didn't work. Any ideas??
> > -Mike Beymer
>
> Must be something with your tools. I just built this and I
> got identical results to Patrick's.
>
> What host are you using?
> Where did you get your toolchain from?
>
> --
> .--------------------------------------------------------.
> | Mind: Embedded Linux and eCos Development |
> |--------------------------------------------------------|
> | Gary Thomas email: gary.thomas@mind.be |
> | Mind ( http://mind.be ) tel: +1 (970) 229-1963 |
> | gpg: http://www.chez-thomas.org/gary/gpg_key.asc |
> '--------------------------------------------------------'
>
>
>
>
>
> This message was scanned for viruses.
>
>
--
.--------------------------------------------------------.
| Mind: Embedded Linux and eCos Development |
|--------------------------------------------------------|
| Gary Thomas email: gary.thomas@mind.be |
| Mind ( http://mind.be ) tel: +1 (970) 229-1963 |
| gpg: http://www.chez-thomas.org/gary/gpg_key.asc |
'--------------------------------------------------------'
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* RE: [ECOS] ecos redboot compile problem.
[not found] <218C6B103596E746932D287EB519B5DD096695@spokane-mx1.itron.com>
@ 2003-04-18 11:28 ` Gary D. Thomas
0 siblings, 0 replies; 25+ messages in thread
From: Gary D. Thomas @ 2003-04-18 11:28 UTC (permalink / raw)
To: Beymer, Mike; +Cc: eCos Discussion
Please CC your replies to the eCos mailing list so that all
can benefit from the information. That list provides free
support - private support is available under contract only.
On Thu, 2003-04-17 at 16:01, Beymer, Mike wrote:
> I'm building on Linux RH 8.0. I went on vacation and can't remember exactly where the toolchains came from. The version information from arm-elf-gcc returns
>
> arm-elf-gcc (GCC) 3.2.1 (eCosCentric)
Then you got these from the eCos 2.0 Beta distribution.
>
> Do you know which tool chain you are using? Maybe I need to replace mine.
I build my own toolchains, but the ones that you've downloaded
are known to work fine.
What commands did you use to build? Here's what I did that worked:
% ecosconfig new innovator redboot
% ecosconfig import /work2/ecos/packages/hal/arm/arm9/innovator/current/misc/redboot_SRAM.ecm
% ecosconfig tree
% make
(my eCos repository is stored at "/work2/ecos/packages")
> -Thanks
> -Mike Beymer
>
> -----Original Message-----
> From: Gary D. Thomas [mailto:gary.thomas@mind.be]
> Sent: Thursday, April 17, 2003 2:18 PM
> To: Beymer, Mike
> Cc: eCos Discussion
> Subject: Re: [ECOS] ecos redboot compile problem.
>
>
> On Thu, 2003-04-17 at 14:21, Beymer, Mike wrote:
> > I'm working on a port of redboot to the PSI Minno OMAP5910 PCA. Which is very similar
> > to the PSI Innovator. In trying to verify my build process, I am attempting to rebuild Patrick Doyle's SRAM image for the innovator. ( his works mine doesn't). In looking at an objdump -d
> > of Patrick's object file compared to mine, it appears to have a problem with endian'ism
> > Patrick's looks as follows:
> >
> > redboot-sram.out: file format elf32-littlearm
> >
> > Disassembly of section .rom_vectors:
> >
> > 20000000 <__rom_vectors_lma>:
> > 20000000: 78 56 34 12 21 43 65 87 xV4.!Ce.
> >
> > 20000008 <__exception_handlers>:
> >
> >
> > Mine comes out as:
> >
> > redboot.img: file format elf32-littlearm
> >
> > Disassembly of section .rom_vectors:
> >
> > 20000000 <__rom_vectors_lma>:
> > 20000000: 12345678 eornes r5, r4, #125829120 ; 0x7800000
> > 20000004: 87654321 strhib r4, [r5, -r1, lsr #6]!
> >
> > 20000008 <__exception_handlers>:
> >
> > The same numbers but a different order. I've tried playing with the endian switches in the
> > compiler with no change in the results. I stumped, Patrick sent me what he remembers doing to build the file, but that didn't work. Any ideas??
> > -Mike Beymer
>
> Must be something with your tools. I just built this and I
> got identical results to Patrick's.
>
> What host are you using?
> Where did you get your toolchain from?
>
> --
> .--------------------------------------------------------.
> | Mind: Embedded Linux and eCos Development |
> |--------------------------------------------------------|
> | Gary Thomas email: gary.thomas@mind.be |
> | Mind ( http://mind.be ) tel: +1 (970) 229-1963 |
> | gpg: http://www.chez-thomas.org/gary/gpg_key.asc |
> '--------------------------------------------------------'
>
>
>
>
>
> This message was scanned for viruses.
>
>
--
.--------------------------------------------------------.
| Mind: Embedded Linux and eCos Development |
|--------------------------------------------------------|
| Gary Thomas email: gary.thomas@mind.be |
| Mind ( http://mind.be ) tel: +1 (970) 229-1963 |
| gpg: http://www.chez-thomas.org/gary/gpg_key.asc |
'--------------------------------------------------------'
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss
^ permalink raw reply [flat|nested] 25+ messages in thread
end of thread, other threads:[~2003-05-02 16:54 UTC | newest]
Thread overview: 25+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-04-17 20:21 [ECOS] ecos redboot compile problem Beymer, Mike
2003-04-17 21:18 ` Gary D. Thomas
[not found] <218C6B103596E746932D287EB519B5DD096695@spokane-mx1.itron.com>
2003-04-18 11:28 ` Gary D. Thomas
2003-04-18 19:29 Beymer, Mike
2003-04-24 22:04 Beymer, Mike
2003-04-25 13:32 Doyle, Patrick
2003-04-25 15:53 Beymer, Mike
2003-04-25 17:02 Doyle, Patrick
2003-04-25 18:19 Beymer, Mike
2003-04-25 18:54 Doyle, Patrick
2003-04-25 20:33 Beymer, Mike
2003-04-25 20:37 Doyle, Patrick
2003-04-25 20:53 Doyle, Patrick
2003-04-25 21:32 Beymer, Mike
2003-04-29 23:49 Beymer, Mike
2003-05-01 1:45 ` Jonathan Larmour
2003-04-30 12:20 Doyle, Patrick
2003-05-01 13:25 Doyle, Patrick
2003-05-01 15:38 Beymer, Mike
2003-05-01 16:15 Beymer, Mike
2003-05-01 16:40 Doyle, Patrick
2003-05-01 17:57 Beymer, Mike
2003-05-02 14:51 Doyle, Patrick
2003-05-02 16:42 Beymer, Mike
2003-05-02 16:54 Doyle, Patrick
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).