This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: [new mail]ROM start-up redboot.elf question.
>>>>> "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