arch: arm: MSP initialization during early boot

[ioannisg]

Starting a discussion [currently only concerning ARM] on whether Zephyr early boot code should initialize the Main Stack Pointer.

Currently, Zephyr relies on warm/cold reset or on the preceding executable image (e.g. boot-loader) to initialize the MSP.

To make Zephyr more independent of the preceding image (or the ARM hardware functioning) we could force MSP to take the value of VECTOR_TABLE[0] as the first thing to do in reset()

This would allow !XIP images to always have a safe MSP value (i.e. stack wouldn't overwrite code loaded in sRAM) and avoid errors that might be hard to debug.

Also, this would align with what we do for Vector Table initialization (VTOR setting), i.e. done in reset() (although not always needed, as it may either be done by hardware upon reset, or by boot-loader).

Cost:

• slight code size increase
• any side effects (??)

[ioannisg]

CC @andrewboie @pizi-nordic

[pizi-nordic]

In my opinion we should decide if basic setup of execution environment is performed by bootloader or by Zephyr itself. The latter option is safer, as it allows for reliable boot regardless of the machine state (but this might hide some bootloader errors).

[andrewboie]

I have no problem with doing this.

[ioannisg]

@pizi-nordic This issue is a step towards the direction of making Zephyr itself set up the execution environment. Because, then, Zephyr will be setting up both vector table and Main stack.

Pls, note, though, that the boot-loader would still need to know the reset_handler() of Zephyr, so it can jump to it. I don't see how that could change.

[ioannisg]

Coming back to this, after quite a while.
I think we need to decide whether to make Zephyr boot process a standalone procedure. Currently, the following assumptions are made

• image starts executing from z_arm_reset() with MSP being the value in the reset_vector[0]
• image boots with mode: thread / PRIV
• MPU is disabled, and MPU region configuration is clean

In most use cases, the above assumptions match the reality; the question is whether we should rely on the assumptions to hold, or enforce this configuration at z_arm_reset()

[SebastianBoe]

MPU is disabled, and MPU region configuration is clean

enforce this configuration at z_arm_reset()

Assuming you are asking whether Image 1 should turn off the MPU protection that Image 0 enabled then I think it should not. If Image 0 wants it's MPU protection to leak to Image 1 then it should allow it to do so, if it does not, then it should either not have enabled it in the first pace or it should clean the state before booting image 1.