I noticed most bare-metal examples included with DS-5 that rely on a FVP also include startup code (e.g. startup.s). However, there's one bare-metal example (Calendar program for Cortex-A8-FVP) that only includes code for the main program. How is model startup handled in this case? Can all FVP models be run in this manner or is it something specific to the Cortex-A8-FVP?
In the debug configuration settings I don't see any noticeable differences between the examples outside of a different FVP model being used. I was half expecting some sort of "use default startup sequence" check-box, but didn't find it.
Thanks for any help!
The Calendar example is a simple semihosted console-based application written in C code. The C run-time environment (e.g. setting up user stack, heap, library initialization, etc), is established by executing some library code (called "__main" in the ARM Compilation tools). This is automatically linked-into the application executable at link time by the ARM Linker (armlink) and is marked as being the entry point, so is run first before your user main() function is reached. The Calendar example is so simple that it does not need an exception vector table, cache/MMU set up, or VFP enabled, so does not need any assembler start-up code.
By contrast, the other bare-metal examples are full reference 'real world' examples, that show all the code that would typically be necessary to run an application on real target hardware. This includes an exception vector table (e.g. to handle reset and interrupts), setting up the stack pointers for the other modes, cache/MMU initialization and VFP setup for better performance, multi-core startup, etc. This code has to be written in assembler, hence the need for startup.s. The C run-time environment is still established by "__main", but in this case __main is executed after the startup.s assembler has run.
This is not specific to the Cortex-A8 FVP model - all FVP models can be used in this way.
Thanks Stephen.
Very well answered! I went back to the examples and I see now how "__main" plays it's role. In particular (coming from a more GNU background) I overlooked the scatter file which I realize now is like the linker script.
In the full reference examples, I assume this scatter file helps defines what happens after __main calls __scatterload. In the simple calendar example, __scatterload must setup a default C run-time environment defined by the compiler.
Yes, that's right. The scatter file tells the linker how/where the code/data should be placed in the memory map by __scatterload. The simple calendar example has no scatter file so a default layout is used. The default layout is program code (.text) first starting at --ro-base, followed by RW data (.data), followed by ZI data (.bss). The armlink User Guide gives more information - see section 3.6.