ARM setup: How to load from flash?

[Toralf Lund]

Grant Edwards wrote:

>>I'm also wondering how other people handle applications that will be 
>>stored on a flash, i.e. how they are linked, how data is moved to RAM 
>>etc. That's still for a standalone (no OS) arm-coff application with no 
>>and debug monitor support. Some questions:
>>
>>  1. Should I use a separate "loader" program, or have the app do the
>>     load itself?
>>    
>>
>
>Either one.  I've done both in the past. If you've got plenty
>of flash, I'd lean towards the separate loader program -- IMO
>it's easier to maintain things that way, and I think it's
>easier to disaster-recovery stuff into the loader.
>  
>
OK.

>  
>
>>  2. Do I need to move the entire program, or just the data section?
>>    
>>
>
>It depends.  I've done it both ways in the past.  Running with
>text/const in ROM is convenient, but often slow.  On some
>platforms RAM is much, much faster than flash ROM.
>  
>
Yes, of course...

>>  3. How can I override the default "start" behaviour (if that's what I
>>     want)? I tried specifying an alternative entry-point via the
>>     linker script, but the start code from crt0.S would still end up
>>     first in the output file (at least, it has the lowest address in
>>     disassembly output.)
>>    
>>
>
>Tell gcc you don't want start files linked in.  IIRC, it's
>-nostartfiles.
>  
>
I think what I *really* want is to keep the default routines in these 
files, but execute additional pieces of code *before* they are loaded 
(see below). It's probably not that much work to write a custom version 
of it all, though...

>>  4. What does "entry point" in the context of linker scripts/linker
>>     options mean anyway?
>>    
>>
>
>It set's the "entry point" field in the ojbect file.  This is
>used by things like gdb (set's the initial PC value) and
>objcopy sets the "entry-point" record in hex files.
>  
>
Fair enough.

I asked because I know that the "entry point" code is usually (always if 
you use the default startup code?) stored at the very beginning of the 
text segment, so any such field in the object file seems somewhat redundant.

>>Does the COFF format know of such a concept,
>>    
>>
>
>Yes.  So do ELF and most hex file formats.
>  
>
Yeah, I knew ELF had this.

>>or will it just execute the first instruction found in the file?
>>    
>>
>
>Depends.  To what does "it" refer to your question?
>  
>
I should have said a proper COFF loader, or something.

But now I think about this, I seem to recall reading somewhere that COFF 
in its original/most basic form does indeed treat the beginning of .text 
as the entry point, and that the entry point header is optional, or a 
later extension, or an OS-dependent feature, or something like that...

>Here's a question for you:
>
>Why are you using COFF instead of ELF?
>  
>
Well, I'm assuming that it's simpler than ELF, and we're talking about a 
very plain setup, so ELF might just introduce more complexity without 
giving me anything extra that I need.

That's not the real reason, though. Actually, it's not even true that 
I'm "using" COFF. So far, I've just loaded plain binary files and simply 
started execution from the start of the image. These files are created 
using objcopy -b binary with COFF files as input, because as I said, I 
know I'll get the right code at the beginning for COFF (I'm not saying 
that I know I won't for ELF, though.)

That's when using an older, m68k based, revision of the board.

- Toralf


------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com