Define region data structures exposed by linker script

[nashif]

Reported by Andrew Boie:

For memory protection we are going to need to carve up the address space into different regions with different access policies. Program text, rodata, kernel data, application data, stacks. We will need pointers and sizes of these regions at runtime to configure the hardware. Determine how we will express these areas in a data structure created by the linker.

(Imported from Jira ZEP-2198)

[nashif]

by Andrew Boie:

Note that we already expose a number of interesting regions in the linker script already, see include/linker-defs.h:

#include <zephyr/types.h>
extern char __bss_start[];
extern char __bss_end[];
#ifdef CONFIG_XIP
extern char __data_rom_start[];
extern char __data_ram_start[];
extern char __data_ram_end[];
#endif

extern char _image_rom_start[];
extern char _image_rom_end[];
extern char _image_ram_start[];
extern char _image_ram_end[];
extern char _image_text_start[];
extern char _image_text_end[];

/* end address of image. */
extern char _end[];

Additional detail on these symbols:

_bss used to zero BSS at boot, see _bss_zero() and x86 crt0.S _data used for XIP data copy, see _data_copy() and x86 crt0.S _end is used by newlib to configure the heap image* used by mem_safe (which should really be replaced with something pagefault based)

[nashif]

by Andrew Boie:

Regions I think we will need to define in the linker script:

Region with all program text (kernel & application)

Region with all rodata (kernel & application)

Region with kernel BSS

Region with kernel data

Region with kernel noinit

Region with app BSS

Region with app data

Region with app noinit

Andy Gross mentioned something about arranging these in an array instead of just a collection of discrete symbols, will discuss in the summit this week.

We also need to consider in the future supporting multiple "applications" that are isolated from each other, in which can arranging these in an array at build time would be even more beneficial.

[nashif]

by Andrew Boie:

I think we have a good set of symbols defined now in linker-defs.h I need to discuss with Andy Gross on the requirements for this to be in an array, how it will be used, right now I'm not completely seeing the use-case.

[nashif]

Blocks GH-2030