add some unsafe method to run code before RAM is initialized

[japaric]

Some people have expressed that they would like to configure the CPU clock before RAM initialization to speed up the initialization process (specially when lots of RAM need to be initialized).

This has to be unsafe because all the static variables stored in .bss / .data would be uninitialized during the execution of this pre-init routine.

Possible user facing interface:

#[macro_use]
extern crate cortex_m_rt;

pre_init!(unsafe {
    // something
});

where pre_init! can only be used once.

[djmcgill]

How do you recommend doing this? I was thinking of either something like rust-lang/rfcs#1971 i.e. a default trait implementation and have the macro override it, or adding a new (weakly linked) function and then overriding that a la the r0 crate's init_array.

[japaric]

The latter, like we do for interrupt / exception handlers.

[jcsoo]

Another use case is disabling watchdogs before main() on some devices such as the K64 that have them enabled on reset. Unfortunately, leaving the watchdog enabled can leave the device in a reset loop that is difficult to recover from.

I would also like to enable instruction cache on devices that support it, and enter main() with interrupts disabled by default.

It sounds like the right way to do this is to add a weakly linked pre_init function that
is NOP by default but that can be overridden, and then call that within reset_handler().

Or would it be better to have a way to replace reset_handler?

[thejpster]

I needed this on the AM5728 IPU1 as both Cortex-M4 cores (there are two) are released out of reset at the same time with the same reset vector. You write a little bit of code (making sure not to use the stack pointer) to put Core 1 to sleep and let Core 0 carry on. You can then take Core 1 out of sleep at a later time if you're running an SMP-capable RTOS.

Currently I fixed this by forking the crate.