What is the booting process for ARM?

Currently, there are two exception models in the ARM architecture (reset is considered a kind of exception):

The classic model, used in pre-Cortex chip and current Cortex-A/R chips. In it, the memory at 0 contains several exception handlers:

 Offset  Handler
 ===============
 00      Reset 
 04      Undefined Instruction
 08      Supervisor Call (SVC)
 0C      Prefetch Abort
 10      Data Abort
 14      (Reserved)
 18      Interrupt (IRQ)
 1C      Fast Interrupt (FIQ)

When the exception happens, the processor just starts execution from a specific offset, so usually this table contains single-instruction branches to the complete handlers further in the code. A typical classic vector table looks like following:

00000000   LDR   PC, =Reset
00000004   LDR   PC, =Undef
00000008   LDR   PC, =SVC
0000000C   LDR   PC, =PrefAbort
00000010   LDR   PC, =DataAbort
00000014   NOP
00000018   LDR   PC, =IRQ
0000001C   LDR   PC, =FIQ

At runtime, the vector table can be relocated to 0xFFFF0000, which is often implemented as a tightly-coupled memory range for the fastest exception handling. However, the power-on reset usually begins at 0x00000000 (but in some chips can be set to 0xFFFF0000 by a processor pin).

The new microcontroller model is used in the Cortex-M line of chips. There, the vector table at 0 is actually a table of vectors (pointers), not instructions. The first entry contains the start-up value for the SP register, the second is the reset vector. This allows writing the reset handler directly in C, since the processor sets up the stack. Again, the table can be relocated at runtime. The typical vector table for Cortex-M begins like this:

__Vectors       DCD     __initial_sp              ; Top of Stack
                DCD     Reset_Handler             ; Reset Handler
                DCD     NMI_Handler               ; NMI Handler
                DCD     HardFault_Handler         ; Hard Fault Handler
                DCD     MemManage_Handler         ; MPU Fault Handler
                DCD     BusFault_Handler          ; Bus Fault Handler
                DCD     UsageFault_Handler        ; Usage Fault Handler
                [...more vectors...]

Note that in the modern complex chips such as OMAP3 or Apple's A4 the first piece of code which is executed is usually not user code but the on-chip Boot ROM. It might check various conditions to determine where to load the user code from and whether to load it at all (e.g. it could require a valid digital signature). In such cases, the user code might have to conform to different start-up conventions.

After Power is ON The cpu will start executing exception mode 1st one is reset ,As Reset must run as superviser mode since CPU doesn't know the status of the register at this time of execution it cant go into the superviser mode .To achieve this small code need to be written (See at end). after this other exceptions can be handled by loading the address into PC .

.globl _start
 _start: b       reset
    ldr     pc, _undefined_instruction
    ldr     pc, _software_interrupt
    ldr     pc, _prefetch_abort
    ldr     pc, _data_abort
    ldr     pc, _not_used
    ldr     pc, _irq
    ldr     pc, _fiq

reset:
    mrs     r0,cpsr                 /* set the cpu to SVC32 mode        */
    bic     r0,r0,#0x1f             /* (superviser mode, M=10011)       */
    orr     r0,r0,#0x13
    msr     cpsr,r0

... At the end, OS code starts to run. For ARM architecture, what is the booting process after use press the power button?

This answer is mainly in the context or modern Cortex-A CPUs; there are a great variety of ARM platforms. However, for an ARM that is PC like (tablet, cell phone, etc) ...

The ARM CPU will fetch an instruction from either 0x0 or 0xffff0000 (for a Cortex-M, it is data as opposed to an instruction). Typical ARM SOC have some boot rom which uses this mechanism. For an end user, you need to consult a manual to determine how to get your code to run. Ie, there is a BIOS built in to many ARM SOC which use the vector, but you need to use something different to get your code to run.

Typically the ARM SOC will support multiple boot devices. The device is determined by some FUSE (set by a manufacturing tool) or by sampling pins. The pins will be CPU outputs in a running system, but have been pulled up/down to configure a boot device. Each boot device will have peculiar details; ROM is simple, but NAND flash, SPI flash, MMC, etc need some configuration details. These are also often provided by a on-chip FUSE and/or sampling pins. A small portion of the device maybe read to further configure the device.

For a deeply embedded ARM chip, it may only boot from on-board flash and this process is much simpler; but I believe from the context of the question you are referring to more advanced ARM CPUs. More advanced ARM systems have a boot loader. This is because the amount of code a ROM loader will load is often limited and/or restricted. It is also often complex to set up SDRAM and the boot loader may be structured to run from internal static RAM, which configures the SDRAM.

See: Why we need a bootloader

Running the OS has its own peculiar issues. For ARM Linux, it was ATAGS and is now devicetree. People may code there own boot loader or use one of the many open-source projects with u-boot being the most common. U-boots supports vxWorks, Linux, NetBSD, Plan9, OSE, QNX, Integrity, and OpenRTOS as well a binary images.

Many original ARM Linux devices supported a direct boot of Linux without a boot loader. However, Linux does not support this in the main line except for a few very old ARM SOCs/cores.