www.linux-arm.org/pub/LinuxKernel/.../aleph-porting.pdf
up the interrupt controller. Interrupt mask and unmask functions go here too.
arch/arm/kernel/entry-armv.S
Interrupt controller base: /arch/arm/mach-omap2/omap24xx.h
Assigning irq numbers: include/asm/arch/irqs.h
__virt_to_phys() macro in include/asm-arm/arch-XXX/memory.h
(along with corresponding reverse mappings). Normally, this macro
is simply:
phys = virt - PAGE_OFFSET + PHYS_OFFSET
Initialize all memory segments as well: text addr, phys addr, virtual addr, task size, page offset, phy offset, vmalloc start/end, vmalloc offset, data addr.
arch/arm/mach-XXX/irq.c : You should provide the XXX_init_irq function here. This sets
arch/arm/mach-XXX/mm.c
include/asm/arch/dma.h : Defines for DMA channels, and DMA-able areas of memory.
For machines without DMA, you can just declare 0 DMA
channels as follows:
#define MAX_DMA_ADDRESS 0xffffffff
#define MAX_DMA_CHANNELS 0
define the memory addresses, IOaddresses, and so on: include/asm/arch/hardware.h
include/asm/arch/io.h
include/asm/arch/timex.h
Board support package initializes board specific details and keeps the OS not worried about it.
Although board initialization starts before the booting process itself.
When ARM devices are powered on the 1st software (firmware usually) is executed from ROM and written in assembly code. In many cases this firmware might not run on ARM core and may run in DSP processor, if available.
Above piece of code initializes L1 cache of the primary core (in multicore system) to load 1st bootloader, written in C.
Why L1 is required? Well this is not necessary but many vendors does it. This is to support 1st level bootloader which is written in C. As usual standard, C code program keeps segments: text, bss, data, rodata. And when this bootloader comes in execution, it requires stack segment also (as like any simplest program in C). ROM can't hold stack as it is read only (I guess L1 cache or DRAM is required to hold bss and data segment also). Main job of this 1st level of bootloader is to chainload 2nd level bootloader.
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).
http://kiranjammula.wordpress.com/
----------------------------
-Initialize CPU speed
-Initialize memory, which includes enabling memory banks, initializing memory configuration registers, and so on
-nitialize serial port (if present on the target)
-Enable instruction/data caches
-Set up stack pointer
-Set up parameter area and construct parameter structures and tags (this is an important step, as boot parameters are used by the kernel in identifying root device, page size, memory size and more)
-Perform POST (Power On Self Test) to identify the devices present and to report any problems
-Provide support for suspend/resume for power management
-Load the kernel to memory if needed
-For arm Linux kernel, before jumping to the kernel, MMU has to be turned off, D-cache should be turned off, register r0 should be set 0, r1 should contain the correct machine number and r2 should point ATAGS.
-Jump to start of kernel.
----------------------------
-Initialize CPU speed
-Initialize memory, which includes enabling memory banks, initializing memory configuration registers, and so on
-nitialize serial port (if present on the target)
-Enable instruction/data caches
-Set up stack pointer
-Set up parameter area and construct parameter structures and tags (this is an important step, as boot parameters are used by the kernel in identifying root device, page size, memory size and more)
-Perform POST (Power On Self Test) to identify the devices present and to report any problems
-Provide support for suspend/resume for power management
-Load the kernel to memory if needed
-For arm Linux kernel, before jumping to the kernel, MMU has to be turned off, D-cache should be turned off, register r0 should be set 0, r1 should contain the correct machine number and r2 should point ATAGS.
-Jump to start of kernel.
