>>109078983
what do you want to do? is this the risc-v or xtensa chip?
anyway, you can start by identifying how the chip knows where to start from.. fixed location, or some boot identifier word and then write the startup assembly code
below is startup code i wrote for the cortex m4 on my stm32f411
.set VTOR_REG, 0xE000ED08
.text
.thumb
.globl _start
.globl reset_handler
_start:
reset_handler:
cpsid i # Disable interrupts out of reset, RTOS enables them later
# Clear GPRs
mov r0, #0
mov r1, #0
mov r2, #0
mov r3, #0
mov r4, #0
mov r5, #0
mov r6, #0
mov r7, #0
# Set VTOR to default vector table location
SetVTOR:
ldr r0, =VTOR_REG
ldr r1, =__VECTOR_START
str r1, [r0]
# Initialize SRAM to zero
InitSRAM:
ldr r2, =0x20000000
ldr r3, =0x20020000
movs r0, #0
movs r1, #0
SRAMLoop:
stm r2!, {r0, r1}
cmp r2, r3
blt SRAMLoop
# Set the stack pointer only after SRAM is zeroed
SetStack:
ldr r0, =__stack_end__
msr msp, r0
__MAIN:
bl main
on ARM the first word in the exception vector is the initial stack pointer location. i don't use this mechanism since it lends itself to issues if you have uninitialized ECC on the TCM or RAM where the stack is located.
i've stopped doing a lot of initialization in assembly, just keeping to the bare minimum to minimize the amount of manually written assembly code.
so the first thing that the main entry does is to zero-init the BSS and copy ROM data to RAM, followed by explicit calls to preinit_array and init_array from my custom C++ runtime library to make sure that global constructors and such are run
after this its device initialization.
clocks, gpio, modes, flash, etc.
on some platforms you will have a very slow clock out of reset and you will want to make sure to lock the pll before running all the initialization.
final thing depends on whether you want to use an OS or not, but initializing the OS interrupt source, and then start the OS.
