How does VFP model omit startup code?

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!

Parents
  • 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.

Reply
  • 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.

Children
More questions in this forum