[ECOS] [new mail]ROM start-up redboot.elf question.

[ECOS] [new mail]ROM start-up redboot.elf question.

[Miguel Josue Vega]

Hi everyone,

I produced a ROM start-up redboot.elf for the CME555 board using
ecosconfig.

By doing the following:
1. > ecosconfig new cme555 redboot
2. > ecosconfig import <file directory...>/redboot_ROM.ecm
3. > ecosconfig tree
4. > make

We have been programming this file into internal FLASH using the flash
programmer in CodeWarrior. Unfortunately I do not get redboot to respond
(no banner prints, etc.). We have been able to get hello world programs to
run from internal flash, so I'm pretty sure we are burning to flash correctly
and setting up the jumpers correctly for internal flash start-up also.

I used powerpc-eabi-objdump to look at the redboot.elf in assembly and I
noticed that a part of the assembly code contains code at internal RAM
addresses. Why is this? I thought that the redboot.elf file was supposed
to go only into internal FLASH.

Thank you for your time,
Miguel Vega
FEGI Team
University of Michigan

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

Re: [ECOS] [new mail]ROM start-up redboot.elf question.

[Gary Thomas]

On Wed, 2004-05-26 at 16:30, Miguel Josue Vega wrote:
> Hi everyone,
> 
> I produced a ROM start-up redboot.elf for the CME555 board using
> ecosconfig.
> 
> By doing the following:
> 1. > ecosconfig new cme555 redboot
> 2. > ecosconfig import <file directory...>/redboot_ROM.ecm
> 3. > ecosconfig tree
> 4. > make
> 
> We have been programming this file into internal FLASH using the flash
> programmer in CodeWarrior. Unfortunately I do not get redboot to respond
> (no banner prints, etc.). We have been able to get hello world programs to
> run from internal flash, so I'm pretty sure we are burning to flash correctly
> and setting up the jumpers correctly for internal flash start-up also.
> 
> I used powerpc-eabi-objdump to look at the redboot.elf in assembly and I
> noticed that a part of the assembly code contains code at internal RAM
> addresses. Why is this? I thought that the redboot.elf file was supposed
> to go only into internal FLASH.

Have you tried running the RAM version of RedBoot?  Seeing that work 
could be useful to understanding what's going on.

Note: the cme555 is a contributed port.  Help from the list, while 
offered freely, may be a little thin.  Try contacting Bob Koninckx
(CC'd) for better help.

-- 
Gary Thomas <gary@mlbassoc.com>
MLB Associates


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

Re: [ECOS] [new mail]ROM start-up redboot.elf question.

[Miguel Josue Vega]

Hi Gary,

We have actually gotten a RAM version of redboot to build and run on the
board. We have noticed some differences when we dump both types (RAM and
ROM) of redboot.elf files into assembly we are currently looking into
this.

In general, do you happen to know why there would be code in an assembly
dumped version of a ROM start-up type redboot.elf that has code at
internal FLASH addresses as well as internal RAM addresses?

Thanks for your prompt reply,
Miguel Vega
FEGI Team
University of Michigan

On Wed, 26 May 2004, Gary Thomas wrote:

> On Wed, 2004-05-26 at 16:30, Miguel Josue Vega wrote:
> > Hi everyone,
> >
> > I produced a ROM start-up redboot.elf for the CME555 board using
> > ecosconfig.
> >
> > By doing the following:
> > 1. > ecosconfig new cme555 redboot
> > 2. > ecosconfig import <file directory...>/redboot_ROM.ecm
> > 3. > ecosconfig tree
> > 4. > make
> >
> > We have been programming this file into internal FLASH using the flash
> > programmer in CodeWarrior. Unfortunately I do not get redboot to respond
> > (no banner prints, etc.). We have been able to get hello world programs to
> > run from internal flash, so I'm pretty sure we are burning to flash correctly
> > and setting up the jumpers correctly for internal flash start-up also.
> >
> > I used powerpc-eabi-objdump to look at the redboot.elf in assembly and I
> > noticed that a part of the assembly code contains code at internal RAM
> > addresses. Why is this? I thought that the redboot.elf file was supposed
> > to go only into internal FLASH.
>
> Have you tried running the RAM version of RedBoot?  Seeing that work
> could be useful to understanding what's going on.
>
> Note: the cme555 is a contributed port.  Help from the list, while
> offered freely, may be a little thin.  Try contacting Bob Koninckx
> (CC'd) for better help.
>
> --
> Gary Thomas <gary@mlbassoc.com>
> MLB Associates
>
>

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

Re: [ECOS] [new mail]ROM start-up redboot.elf question.

[Gary Thomas]

On Wed, 2004-05-26 at 16:49, Miguel Josue Vega wrote:
> Hi Gary,
> 
> We have actually gotten a RAM version of redboot to build and run on the
> board. We have noticed some differences when we dump both types (RAM and
> ROM) of redboot.elf files into assembly we are currently looking into
> this.
> 
> In general, do you happen to know why there would be code in an assembly
> dumped version of a ROM start-up type redboot.elf that has code at
> internal FLASH addresses as well as internal RAM addresses?

I really don't know anything about this port, but in general, ROM code
has two parts - the TEXT and static DATA portions and dynamic 
initialized DATA.  The ROM startup code expects those DATA portions to
exist in the ROM image as well.  The startup code then copies the
DATA portions from the ROM copy into the appropriate RAM locations
before starting up.  You need to make sure that what you put into the
ROM has all of these components - otherwise it won't run.

> 
> Thanks for your prompt reply,
> Miguel Vega
> FEGI Team
> University of Michigan
> 
> On Wed, 26 May 2004, Gary Thomas wrote:
> 
> > On Wed, 2004-05-26 at 16:30, Miguel Josue Vega wrote:
> > > Hi everyone,
> > >
> > > I produced a ROM start-up redboot.elf for the CME555 board using
> > > ecosconfig.
> > >
> > > By doing the following:
> > > 1. > ecosconfig new cme555 redboot
> > > 2. > ecosconfig import <file directory...>/redboot_ROM.ecm
> > > 3. > ecosconfig tree
> > > 4. > make
> > >
> > > We have been programming this file into internal FLASH using the flash
> > > programmer in CodeWarrior. Unfortunately I do not get redboot to respond
> > > (no banner prints, etc.). We have been able to get hello world programs to
> > > run from internal flash, so I'm pretty sure we are burning to flash correctly
> > > and setting up the jumpers correctly for internal flash start-up also.
> > >
> > > I used powerpc-eabi-objdump to look at the redboot.elf in assembly and I
> > > noticed that a part of the assembly code contains code at internal RAM
> > > addresses. Why is this? I thought that the redboot.elf file was supposed
> > > to go only into internal FLASH.
> >
> > Have you tried running the RAM version of RedBoot?  Seeing that work
> > could be useful to understanding what's going on.
> >
> > Note: the cme555 is a contributed port.  Help from the list, while
> > offered freely, may be a little thin.  Try contacting Bob Koninckx
> > (CC'd) for better help.
> >
> > --
> > Gary Thomas <gary@mlbassoc.com>
> > MLB Associates
> >
> >
-- 
Gary Thomas <gary@mlbassoc.com>
MLB Associates


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

Re: [ECOS] [new mail]ROM start-up redboot.elf question.

[Bart Veer]

>>>>> "Miguel" == Miguel Josue Vega <mserrano@engin.umich.edu> writes:

    Miguel> In general, do you happen to know why there would be code
    Miguel> in an assembly dumped version of a ROM start-up type
    Miguel> redboot.elf that has code at internal FLASH addresses as
    Miguel> well as internal RAM addresses?

With some flash drivers the low-level code that actually modifies the
flash, i.e. the write and erase routines, cannot itself run in flash.
The hardware fails to distinguish between instruction fetches and the
memory write sequences that perform the flash update, so these
sequences get aborted. In such cases the low-level code gets placed in
a .2ram section which ends up in the .data region, alongside
statically initialized data. All of .data gets copied from ROM to RAM
during system initialization, and hence this code will end up
executing from RAM rather than flash.

I don't know if that is what is happening here, but it is one case of
code that ends up in RAM even for a ROM start-up.

Bart

-- 
Bart Veer                       eCos Configuration Architect
http://www.ecoscentric.com/     The eCos and RedBoot experts

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