Niren Raju wrote:
> 1) What are the minimum files requried for successful compilation of
> project in WinARM ?
Not sure what you mean or why you ask, and teh answer is not simple.
WinARM is a collection of tools, documentation and examples. Determining
just what your application needs is not straightforward. Even if I could
give you a file list, it would be long. Just take it all - why wouldn't
you? Storage is cheaper than toilet paper. Another problem is that
different releases of WinARM have included different tools in different
folders. Some parts of the tool chain provide support for different
variants of teh ARM architecture, so what you need also depends on your
target. If you do wish to cut down its footprint, do it on a folder
basis rather than a file basis.

>
> 2)Whether low level startup code is same for all processors ?
>
No. An ARM9 for example has different startup requiremts than an ARM7
since it is likely to have external SDRAM, and cache memory for example.
Even within a single ARM architecture, parts from different vendors (or
even parts from teh same vendor) have different memory organisation,
different interrupt controllers, and different clock initialisation
requirements for example. There is much in a typical ARM microcontroller
that is vendor specific and not part of the ARM core. This includes
clock hardware and interrupt controllers which are typically configured
at in the runtime startup code. Then there is teh fact that there are
multipla ARM architecture variants - ARM7, ARM9, ARM11, Cortex M3 and
M8, XScale etc. And each of these can execute alternative instruction
sets (ARM and Thumb, and recently Thumb-2 for example). You even have a
choice of big or little endian byte ordering!

> 3)Whether same low level startup code can be used for two different
> programes but both using same processor ?

Yes of course, for a particular target, start-up code is normally
designed to be application independent. If you start putting application
dependencies in your start up code you loose that benefit. On some
targets you may have teh choice to execute code form Flash or RAM, the
start-up code for each would be different.

Hardware initialisation may vary, between targets, but the C runtime
environment initialisation follows this basic sequence.

   - zero uninitialised static data,
   - copy static initilaizers to RAM (to initialise it),
   - set the stack pointer to the top of the RAM area allocated to the
stack
   - For C++ call constructors of static objects
   - Jump to main()


Clifford

Clifford Slocombe wrote:
> Hardware initialisation may vary, between targets, but the C runtime
> environment initialisation follows this basic sequence.
>
>    - zero uninitialised static data,

Is this what in WinARM startup examples is commented as "Clear .bss
section (Zero init)"?

# Clear .bss section (Zero init)
                MOV     R0, #0
                LDR     R1, =__bss_start__
                LDR     R2, =__bss_end__
LoopZI:         CMP     R1, R2
                STRLO   R0, [R1], #4
                BLO     LoopZI

>    - copy static initilaizers to RAM (to initialise it),
And for static initializers:

# Relocate .data section (Copy from ROM to RAM)
                LDR     R1, =_etext
                LDR     R2, =_data
                LDR     R3, =_edata
LoopRel:        CMP     R2, R3
                LDRLO   R0, [R1], #4
                STRLO   R0, [R2], #4
                BLO     LoopRel

Does it matter the sequence of operations: first handle .bss and then
.data section or vise versa?

Roman Mashak wrote:
> Is this what in WinARM startup examples is commented as "Clear .bss
> section (Zero init)"?
>

Yes

Roman Mashak wrote:
> And for static initializers:
>

Yes

Roman Mashak wrote:
> Does it matter the sequence of operations: first handle .bss and then
> .data section or vise versa?

No, it does not matter.

C++ static object initialisation must occur after both stack and static
data initialisation since constructors must be called and these being
functions require a runtime environment. Note that the order of static
constructor calls is not deterministic, so one static constructor should
not reference another static object.

Regarding the various memory segments, this may clarify things for you:
http://www.cs.rochester.edu/~scott/252/notes/07_linking. They are also
discussed here:
http://csg.lbl.gov/pipermail/vxwexplo/2004-January/004166.html



Clifford