About linker file

Hi everyone,
After the .LD file(linker file) of an embedded bare metal specifies that FLASH is not writable,
for example:

MEMORY { 
{
  FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 64K
  RAM (rwx) : ORIGIN = 0x20000000, LENGTH = 16K
}

how do the bare metal ensure that this access permission(or attribute) is not violated?Could it be that GCC statically checks the program code to make sure the program doesn't write FLASH? But what about runtime?

The flash is physically not writable (as memory), and the compiler/linker will not put writable data in that section.

So all that declaration does is advise the linker on how to lay out the executable. It has absolutely zero access restrictions impact at runtime and compile-time, right?

Right. The C compiled does not generate any actual access-checking code, nor does it manipulate any memory protection features that may be present in the processor.

I'm pretty sure that ARM CPUs will "fault" if you try to write to a flash memory address. Actually writing to flash will involve using something like a "NVM peripheral."

But what if I don't configure the NVM peripheral controller? Will the ARM CPU still generate a "fault"? Did you mean that the linker will help me configure the NVM peripheral controller?

Yes. For flash memory.
Note that writing to flash is a lot more than just "configuring" the NVM controller. Each page of flash needs to be erase before any of its words can be written, so it's a whole PROCESS to write to flash.

[quote] Did you mean that the linker will help me configure the NVM peripheral controller?
[/quote]
No, it won't. Aside from perhaps providing symbols that match up with the memory areas.

I'm not sure what you're trying to really ask, or what you're trying to accomplish, or what processor you're using.