Enhance .data relocation / .bss zero initialization with MEMC managed memory

[talih0]

.bss zero initialization (via z_bss_zero()) and .data relocation (via z_data_copy()) is done early in the boot up via the function z_prep_c().

In addition to initializing RAM, z_bss_zero() also internally calls
bss_zeroing_relocation();
which is the auto-generated code via CMake helper zephyr_code_relocate().

Thus when relocating data to an external RAM (via MEMC driver), the relocation happens before any driver initialization is done.

My setup is for XMC4700 (the MEMC drivers have not been upstreamed yet). But it should be the same issue of the other SoC with MEMC drivers (i.e. Atmel SAM SMC).

Impact
Invalid data in .data section. And a .bss that's not zero-initialized.

[dcpleung]

Hm... this is not a memory management issue, but rather an issue related to boot and driver initialization. z_prep_c() is an early boot process to prepare an environment for later initialization steps (including driver initialization). So there is no way for this to work as part of the early boot process if it depends on a driver initializing the needed memory. So the solution would involve initializing the external memory during the early boot process, but before the C environment has already been set up... and this will need some specially crafted code.

TBH, I don't think there can be a generic solution as each architecture has their own z_prep_c(), and it will be hard to cater to all different external memory controllers.

[talih0]

Did you have a chance to look at my PR that's in draft? It adds an extra property in the DTS that delays relocation for the MEMC Ram regions.

…

On Tue, Feb 27, 2024, 5:31 PM Daniel Leung ***@***.***> wrote: Hm... this is not a memory management issue, but rather an issue related to boot and driver initialization. z_prep_c() is an early boot process to prepare an environment for later initialization steps (including driver initialization). So there is no way for this to work as part of the early boot process if it depends on a driver initializing the needed memory. So the solution would involve initializing the external memory during the early boot process, but before the C environment has already been set up... and this will need some specially crafted code. TBH, I don't think there can be a generic solution as each architecture has their own z_prep_c(), and it will be hard to cater to all different external memory controllers. — Reply to this email directly, view it on GitHub <#68884 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEFAFWZZ4HW5PLHVYQRRSVTYVZNFDAVCNFSM6AAAAABDFAXWGCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNRXG43TINRXGY> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[dcpleung]

Part of me doubt that would work unless you are very careful on where data is placed. The reason is that continue execution of code may require some data having already relocated. So you will need to make sure any code executed between z_prep_c() and relocation being done do not access the relocated region. Relocated BSS may not be as important unless the code relies on it being zero at first.

[talih0]

Yes, you have to be careful not to reallocate some driver data. It's up to the user to
check that the data they relocate is not used before INIT_LEVEL_PRE_KERNEL_1 level.

My use case is to reallocate some application data or library that is used much later in the boot.

[ehughes]

I have a similar request. I have a board that uses the MCXN947 with external PSRAM. I need to be able to do some pin muxing and clock init such that the FlexSPI controller is intialized. This needs to happen before the c startup/copydown routines.

Even having a simple hook or weak function that can be called before C system init would be helpful.

I currently have a prototype that will do the minimal number of calls to get things setup, I just need a way to call this function right before the branch to z_prep_c

Having something like this:

`
#ifdef CONFIG_PRE_C_START_HOOK
bl z_pre_c_startup_hook
#endif

/*
 * 'bl' jumps the furthest of the branch instructions that are
 * supported on all platforms. So it is used when jumping to z_prep_c
 * (even though we do not intend to return).
 */
bl z_prep_c 

`

would be good enough for a 1st implementation. This would allow me to add some special code in my board files without needed to modify reset.S

I could prepare a PR with some guidance as to possible alternatives and have the least impact on existing implementations.

The only other option I can think of is to have some sort of dual image setup (like MCU_BOOT) that is a boot stub that will get the PSRAM setup, then jump to the Zephyr application. i.e. simulate something like the bootrom in the i.MXRT with the DCD capabilities.