Assert stack/heap/initialised RAM start and end symbols aren't placed in FLASH

[9names]

#578 changed how __sheap and _stack_end were initialised, which broke both rp2040 and rp235x linker scripts in rp-hal, and the rp235x linker script in embassy-rp.
embassy-rs/embassy#7262
Unlike the user in #578 the rpX scripts used INSERT AFTER .uninit for a section that is placed in FLASH, which updates . and means link.x now places __sheap and _stack_end in FLASH.

Regardless of whether it was the correct choice to use INSERT AFTER .uninit for the HALs, I would prefer to have received a linker error when a symbol that should have been in RAM turned up in FLASH instead.
Since we shouldn't assert that they're in RAM in case users place them in custom memory regions, I figured we could at least assert that they aren't in FLASH.

While writing those asserts I figured it would also make sense to do the same for symbols used for static RAM placement. Happy to walk back that change if anyone can think of a good reason to want DATA or BSS in FLASH.

[jonathanpallant]

Does this still work if I have a RAM based image and I've aliased the FLASH region to the RAM region?

[9names]

Probably not (I will test it)? But is that something that link.x should support?
Embassy copied the cortex-m-rt link.x and modified it to handle the machine-code in ram use-case.
https://github.com/embassy-rs/embassy/blob/890ceae4e5b353ac85d7030ea7b344c18a1d663e/tests/link_ram_cortex_m.x

Perhaps cortex-m-rt should have a link-ram.x as well as link.x if this style of usage is common?

[jonathanpallant]

I know aarch32 supports it, so maybe I just imagined it working on cortex-m too. I'll try it at the impl day tomorrow.

I think it's a reasonable use case - for rapid debugging, or with security cores that have ROM bootloaders and non-executable storage - and telling people to use different linker scripts seems messy. And, forking the linker script ties you to a specific cortex-m-rt release because much of it is internal API.