MINI2440 QEMU eCos startup analysis

1. Overview of how to start eCos

eCos currently has three default startup modes: RAM, ROM, and ROMRAM.

RAM boot means running directly in RAM. This method is generally used for debugging and does not require hardware initialization.

ROM boot mode means running directly in ROM, of course it must support XIP's NORFLASH.

The ROMRAM boot method means that it starts running in ROM and then copies all the code to RAM to continue running.

2. Mini2440 QEMU startup method selection

NOR and NAND Flash are not yet implemented in MINI2440. (Although the NAND code has been added, the naming is not working properly, so I think it cannot be used.)

Therefore, we must run eCos in RAM and complete the hardware initialization task, which leads to a series of problems.

3. Analysis of MINI2440 QEMU startup method

I add some comments to explain the following ROMRAM startup code:

// Create MMU tables

RAW_LED_MACRO 3

bl hal_mmu_init

The above statement will create the MMU page table, which will map 0x30000000 to address 0, and address 0 to 0x80000000

RAW_LED_MACRO 4

// Enable MMU

ldr r2,=10f

#ifdef CYG_HAL_STARTUP_ROMRAM

ldr r1,=__exception_handlers

ldr r9,=0x80000000

sub r1,r2,r1

add r2,r9,r1 // r9 has ROM offset

This is quite important. First, we must know that we are still running in ROM. After these two statements, we can determine that the number 10 stored in r2 is relative to

The address is 0x80000000.

#endif

ldr r1,=MMU_Control_Init|MMU_Control_M

mcr MMU_CP,0,r1,MMU_Control,c0

mov pc,r2 /* Change address spaces */

Here we can see that after the MMU is mapped, we map the address of NOR from 0 to 0x80000000, so when we jump to R2, it is in NOR after the MMU is mapped.

The operating effect.

nop

nop

nop

10:

RAW_LED_MACRO 5

#ifdef CYG_HAL_STARTUP_ROMRAM

mov r0,r9 // Relocate FLASH/ROM to RAM

ldr r1,=__exception_handlers // ram base & length

ldr r2,=__rom_data_end

20: ldr r3,[r0],#4

str r3,[r1],#4

cmp r1,r2

bne 20b

ldr r0,=30f

mov pc,r0

This part of the code is relatively simple. It copies the code in ROM to RAM and then jumps over it.

nop

nop

nop

nop

30:

#endif

4. Problems with vectors

Now let's look at our QEMU startup. One feature of ecos is that the running position is only relative to the startup position, so no matter what, the first line of our code can run in RAM.

So we let the ROMRAM code run directly in RAM to initialize the hardware.

The next question is how to ensure that the interrupt vector works properly. Let's look at two more ARM platform initialization codes (although they are quite boring)

This part is called fix_vectors

.section ".fixed_vectors"

// Interrupt/exception VSR pointers

.globl hal_vsr_table

hal_vsr_table:

.rept 8

.long 0

.endr

.globl hal_dram_size

hal_dram_size:

.long 0

// what, if anything, hal_dram_type means is up to the platform

.globl hal_dram_type

hal_dram_type:

.long 0

This part is vectors replication

//Reset software interrupt pointer

ldr r0,=CYGHWR_HAL_VECTOR_TABLE_BASE // move vectors

ldr r1,.__exception_handlers

#if defined(CYG_HAL_STARTUP_RAM) && /

!defined(CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS)

cmp r7,#CPSR_SUPERVISOR_MODE

beq 10f

#endif

ldr r2,[r1,#HAL_ARM_SWI_VECTOR_ADDR] // software interrupt

str r2,[r0,#HAL_ARM_SWI_VECTOR_ADDR]

10:

ldr r2,[r1,#HAL_ARM_IRQ_VECTOR] // IRQ

str r2,[r0,#HAL_ARM_IRQ_VECTOR]

ldr r2,[r1,#HAL_ARM_IRQ_VECTOR_ADDR]

str r2,[r0,#HAL_ARM_IRQ_VECTOR_ADDR]

ldr r2,[r1,#HAL_ARM_FIQ_VECTOR] // FIQ

str r2,[r0,#HAL_ARM_FIQ_VECTOR]

ldr r2,[r1,#HAL_ARM_FIQ_VECTOR_ADDR]

str r2,[r0,#HAL_ARM_FIQ_VECTOR_ADDR]

ldr r2,[r1,#HAL_ARM_PREFETCH_VECTOR] // abort (prefetch)

str r2,[r0,#HAL_ARM_PREFETCH_VECTOR]

ldr r2,[r1,#HAL_ARM_PREFETCH_VECTOR_ADDR]

str r2,[r0,#HAL_ARM_PREFETCH_VECTOR_ADDR]

ldr r2,[r1,#HAL_ARM_ABORT_VECTOR] // abort (data)

str r2,[r0,#HAL_ARM_ABORT_VECTOR]

ldr r2,[r1,#HAL_ARM_ABORT_VECTOR_ADDR]

str r2,[r0,#HAL_ARM_ABORT_VECTOR_ADDR]

This is the link file

#include

MEMORY

{

RAM: ORIGIN = 0, LENGTH = 0x8000000

sram: ORIGIN = 0x40000000, LENGTH = 0x1000

}

SECTIONS

{

SECTIONS_BEGIN

SECTION_fixed_vectors (ram, 0x20, LMA_EQ_VMA)

SECTION_rom_vectors (ram, 0x8000, LMA_EQ_VMA)

SECTION_RELOCS (ram, ALIGN (0x1), LMA_EQ_VMA)

SECTION_text (ram, ALIGN (0x4), LMA_EQ_VMA)

SECTION_fini (ram, ALIGN (0x4), LMA_EQ_VMA)

SECTION_rodata (ram, ALIGN (0x4), LMA_EQ_VMA)

SECTION_rodata1 (ram, ALIGN (0x4), LMA_EQ_VMA)

SECTION_got (ram, ALIGN (0x4), LMA_EQ_VMA)

SECTION_fixup (ram, ALIGN (0x4), LMA_EQ_VMA)

SECTION_gcc_except_table (ram, ALIGN (0x4), LMA_EQ_VMA)

SECTION_data (ram, ALIGN (0x4), LMA_EQ_VMA)

SECTION_bss (ram, ALIGN (0x4), LMA_EQ_VMA)

CYG_LABEL_DEFN(__heap1) = ALIGN (0x8);

SECTIONS_END

}

You see, there is a space in our RAM called fix_vector. We can copy the vector to it when we start up, and then after mmu_init

This part just meets the interrupt vector address of ARM920T. Fortunately, it can be used without modification.

5. Code duplication problem

The last question is, since we are already in RAM, we don't need to do code copying and NOR remapping, we can just define a new QEMU startup method to bypass

These two parts of the code.

Finally, as long as QEMU loads the elf format file to 0x30000000, the code can run normally.