feat(riscv): relocate .trap machinery to RAM

[sethp]

This change follows through on relocating the _vector_table, _start_trap, and _start_trap_rust functions for all present build/link modes for the 'c2, 'c3, 'c6, and 'h2.

It has been tested by running the software_interrupts example for the 'c3 in direct-boot and esp-bootloader contexts, but I wasn't able to identify how to run the mcu-boot mode for the 'c3, nor do I have present access to any of the other devices for testing.

Must

• The code compiles without errors or warnings.
  • at least, it introduces no new ones: I do see something about Timer0::steal for all devices and RtcFastClockXtalD2 for the 'h2
• All examples work.
  • that I was able to test, anyway (see above)
• cargo fmt was run.
• Your changes were added to the CHANGELOG.md in the proper section.
• You updated existing examples or added examples (if applicable).
• Added examples are checked in CI

Nice to have

• You add a description of your work to this PR.
• You added proper docs for your newly added features and code.

[sethp]

Hmm, I'm not sure whether to add a CHANGELOG entry. I see at the top that it says:

Please note that only changes to the esp-hal-common package are tracked in this CHANGELOG.

Seems like we ought to either remove that caveat or update the changelog CI action to reflect it. What do you think?

[bjoernQ]

The skip-changelog label should disable the check (in rare cases where a PR doesn't add something that should get mentioned in the CHANGELOG)

[MabezDev]

So it looks like this change moves about 2775 bytes into RAM. I don't think that will a be a huge deal, especially since the hal trap function is actually taking up most of that:

riscv32-esp-elf-objdump -t target/riscv32imc-unknown-none-elf/release/examples/software_interrupts| grep start_trap_rust_hal
40380880 g     F .trap  0000095a _start_trap_rust_hal

I imagine improvements in other PRs will reduce this usage quite a bit.

In my opinion this LGTM. Will let @bjoernQ voice any concerns about the memory usage if he wants.

[bjoernQ]

I guess 2775 bytes should be okay. If this becomes a problem in future, we can still make it an opt-out feature

But I have no idea why the changelog-check still fails with the label 🤔 On the other hand probably this is really a change that deserves a changelog-entry in the "changed" section

[MabezDev]

On the other hand probably this is really a change that deserves a changelog-entry in the "changed" section

I agree, @sethp would you mind adding a quick changelog entry under the "changed" section?

[sethp]

Yeah for sure: sorry for the confusion, I was just thrown by the "only changes to esp-hal-common" bit when this doesn't actually touch that directory at all.

[sethp]

Also, I'm totally on board for gating this somehow, I'm just not sure what that looks like with linker scripts. A change to the build.rs that generates/copies different files depending on feature flags was the least-bad idea I had, and that seemed like it'd fall down ~immediately once there was a second feature to wrangle that way.

But if y'all want that, I'm happy to take it on: just let me know!

[bjoernQ]

Also, I'm totally on board for gating this somehow, I'm just not sure what that looks like with linker scripts. A change to the build.rs that generates/copies different files depending on feature flags was the least-bad idea I had, and that seemed like it'd fall down ~immediately once there was a second feature to wrangle that way.

But if y'all want that, I'm happy to take it on: just let me know!

The build.rs way is already used for ESP32 to reserve more of the RAM for bluetooth - t.b.h. I haven't had any better (or any other) idea