Low power fixups

[will-v-pi]

Fixups to low power, for better compatibility and maintainability

Move persistent data reset into C runtime init code, as it doesn't need to be in crt0 - this will make it easier to maintain. Also adds resetting persistent data on all non-powman boots, rather than resetting just based off the contents of scratch[6], as that could be leftover when loading with a debugger.

Fix low power compilation issue with clang

• clang sometimes tries to place persistent_data in a differet region
  , the fix is to add > XXX to the end, to explicitly put it in RAM/XIP_RAM. I noticed this as part of pico-psram (where Clang would try to put it in PSRAM at the address in SRAM, and therefore it wouldn't fit), but this could also occur when using section_extra_post_data.incl. This requires adding memory_xip_ram.incl to the linker scripts by default, which was coming anyway as part of the xip_ram PR.

[kilograham]

looks good - quick question - does the linker complain if you initialize variables in __persistent_data (since it is NOLOAD)?

[will-v-pi]

looks good - quick question - does the linker complain if you initialize variables in __persistent_data (since it is NOLOAD)?

I thought it would complain, but it seems the linker only complains on RP2040, where the persistent data is placed in .bss, with the error:

error: only zero initializers are allowed in section '.bss.num_runs'

It looks like the fix is to change the .persistent_data section to be .bss.persistent_data - I will see if I can get that working

[will-v-pi]

looks good - quick question - does the linker complain if you initialize variables in __persistent_data (since it is NOLOAD)?

I thought it would complain, but it seems the linker only complains on RP2040, where the persistent data is placed in .bss, with the error:

error: only zero initializers are allowed in section '.bss.num_runs'

It looks like the fix is to change the .persistent_data section to be .bss.persistent_data - I will see if I can get that working

I don't think this is possible for the following reasons:

1. To get the error, the section has to start with .bss.
2. If this comes after .bss, then it will get included in *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.bss*))), so won't get put in .persistent_data
3. This cannot come before .bss, because if placed in RAM it will move the location counter (.) forwards to the PERSISTENT_DATA_LOC, and the location counter cannot then be moved backwards

A way to raise a different error if you try to initialise __persistent_data is to put a semicolon a the end of the macro - I'll raise a PR to discuss this approach

[will-v-pi]

Actually that doesn't work either, it breaks

char __persistent_data(large_thing)[0x1000]