Change TKey RAM and APP mem size for QEMU build

[jthornblad]

Description

Increase the size of the emulated RAM for TKey in QEMU. This is to be able to build large TKey apps without optimization and do debugging with gdb through QEMU.

Type of change

Please tick any that are relevant to this PR and remove any that aren't.

• Bugfix (non breaking change which resolve an issue)
• Feature (non breaking change which adds functionality)
• Breaking Change (a change which would cause existing functionality to not work as expected)
• Documentation (a change to documentation)

Submission checklist

• My code follows the style guidelines of this project
• I have performed a self-review of my changes
• I have tested and verified my changes on target
• My changes are well written and CI is passing
• I have squashed my work to relevant commits and rebased on main for linear history
• I have added a "Co-authored-by: x" if several people contributed, either pair programming or by squashing commits from different authors.
• I have updated the documentation where relevant (readme, dev.tillitis.se etc.)
• QEMU is updated to reflect changes

[mchack-work]

Just a glance at the diff right now, but this also moves the stack to almost beginning of RAM, right? Perhaps update the commit message to make that clear?

Moving the stack to the beginning of memory is really good and something we've been talking about for a long time. It would enable the hardware Security Monitor to check for stack overflows.

However, this change also limits the stack to something predefined in the linker script (16 kByte), which is a huge change compared to what we had earlier. This needs to be both documented and communicated.

Also relates to #37

I'll have a closer look soon.

[agren]

We also need to take the TK1_MMIO_TK1_CPU_MON_* registers into consideration. If we only move the stack but not .data and .bss an app can no longer protect all of them from execution. If an app wants to protect stack, .bss and .data they need to be located next to each other since we can only register one contiguous area in the CPU monitor.

[mchack-work]

In discussion with @jthornblad he came up with the idea to move both .data and .bss together with the stack, so it would be a continous area of memory. This would probably fix the problems with what CPU_MON can watch over.

[mchack-work]

Jonas changed this PR to be just about the RAM size. Stack move PR is now in #73

[mchack-work]

We would need to change RAM size in linker script app.lds, too, so the linker knows how large the memory is when linking device apps.