arch: arm: cortex_m: maintainability improvement by reducing assembly surface

[ithinuel]

This PR simplifies maintenance and improves portability by relying on C where asm is not strictly required.

This requires:

• arch: arm: cortex_m: Move default configs to a file and add consistency checks  #64978

[carlescufi]

Merging since the maintainer is the author.

[Thalley]

@ithinuel this PR seems to break some ARM targets like the nRF5340. I haven't tested other platforms just yet, but at least the Bluetooth IPC driver seems to not work after this.

[ithinuel]

Hello @Thalley, I am aware of some breakage on some NXP platforms (see #64784) but I’m not aware of anything else.

Can you please create an issue & provide a method to reproduce?

[gchwier]

It causes also a rolling reboot in tests of MCUboot.
To reproduce:
west build --sysbuild -p -b nrf5340dk/nrf5340/cpuapp zephyr/tests/boot/with_mcumgr
west flash

[gchwier]

when added

	while (1) {
		k_sleep(K_MSEC(1000));
	}

instead of just returning main, it works (no rolling reboot)

[carlescufi]

@gchwier can you please open an issue as well?

[ithinuel]

@gchwier I think I identified an issue in cpu_idle.c.

Would you mind checking if #71593 solves it?
This is the only significant difference I could notice between the two generated binaries.

[Thalley]

@gchwier I think I identified an issue in cpu_idle.c.

Would you mind checking if #71593 solves it? This is the only significant difference I could notice between the two generated binaries.

It does not fix the issue I'm seeing - I'll create a bug report soon

[Thalley]

@gchwier I think I identified an issue in cpu_idle.c.
Would you mind checking if #71593 solves it? This is the only significant difference I could notice between the two generated binaries.

It does not fix the issue I'm seeing - I'll create a bug report soon

@ithinuel #71596

Interestingly there are no issues for non-Bluetooth applications, so may be related to the HCI driver or something else.

[nordic-piks]

@gchwier I think I identified an issue in cpu_idle.c.
Would you mind checking if #71593 solves it? This is the only significant difference I could notice between the two generated binaries.

It does not fix the issue I'm seeing - I'll create a bug report soon

@ithinuel #71596

Interestingly there are no issues for non-Bluetooth applications, so may be related to the HCI driver or something else.

There are issues for multiple tests (not only Bluetooth), eg.
nrf9160dk_nrf9160: tests/kernel/workq/work_queue/kernel.workqueue

10:12:56  Running TESTSUITE workqueue_delayed
10:12:56  ===================================================================
10:12:56  ASSERTION FAIL [!z_is_thread_state_set(_kernel.cpus[0].current, ((1UL << (4))))] @ ../../../../../../../zephyr/kernel/sched.c:1170
10:12:56  E: ***** HARD FAULT *****
10:12:56  E:   Fault escalation (see below)
10:12:56  E: ARCH_EXCEPT with reason 4
10:12:56  E: r0/a1:  0x00000004  r1/a2:  0x00000492  r2/a3:  0x00000001
10:12:56  E: r3/a4:  0x00000004 r12/ip:  0x00000000 r14/lr:  0x00006c09
10:12:56  E:  xpsr:  0x29000000
10:12:56  E: Faulting instruction address (r15/pc): 0x000086d0
10:12:56  E: >>> ZEPHYR FATAL ERROR 4: Kernel panic on CPU 0
10:12:56  E: Current thread: 0x200008f0 (main)
10:12:56  E: Halting system```

[gchwier]

@gchwier I think I identified an issue in cpu_idle.c.

Would you mind checking if #71593 solves it? This is the only significant difference I could notice between the two generated binaries.

With that fix there is no rolling-boot, but there is also no printed messages on the console, and shell is not available

[stephanosio]

I am a bit late to the party here ... but is converting the core arch implementations written in ASM to C really something we want/should be doing?

The _isr_wrapper function in isr_wrapper.S, for instance, is called for every interrupt and just a few instructions added to it can lead to a significant performance degradation. Same goes for z_arm_pendsv, which is called for every context switch.

Places like these are where we want complete control over the exact instructions used and hence why they were written in ASM.

Also, it is more difficult to control data and instruction barriers by switching to the C implementation (especially using the CMSIS functions), and this can lead to unnecessary and redundant pipeline flushes and hence performance degradation.

Moreover, the existing ASM implementation was fairly clean, well commented, and easy enough to read.

Given that this has already caused many issues for us and will likely cause more in the future, should we look into reverting it and getting back to the good old ASM implementation?

[stephanosio]

Important bits like these get lost when translating to C.

[ithinuel]

That’s a good point. The ISB is included in __set_CONTROL, so the barrier is not lost, but it would be good to transfer the comment about pre-fetched instructions.

[ithinuel]

Thank you for your valuable feedback.
The idea of this change was initiated by the difficulties encountered while learning about zephyr and its implementation.

I understand all your points and agree with most of them. However, since its introduction, the code has evolved to include a significant amount of conditional features inclusion which compounds with accommodations for the various architectural variants (v6m, v7m, v8m.main, v8m.base etc) makes some of the code difficult to read and keep track of.
isr_wrapper.S literally had nearly as much instruction lines (36) as pre-processor (30), and this is counting the blocks like this as 8instructions for 5pre-processor.

In the various comparison I made, the generated code was on par or better than the previous solution. The most recent comparison I did was built with west build --sysbuild -p -b nrf5340dk/nrf5340/cpuapp tests/boot/with_mcumgr at a2ed816 and 4b276c4 where the generated code for _isr_wrapper is effectively 1 instruction smaller than the ASM implementation.

In a number of places, the generated code is/was either suboptimal or incorrect. Eg in this instance (which hasn’t been changed as part of this PR), it would fail to build for Cortex-M23 with BUILTIN_STACK_GUARD enabled and will generate sub-optimal code with unnecessary pop/push sequences. So the ASM implementation is not free from latent issues and I obviously intend to fix these aswell in upcoming contributions.

A notable pain point is around manual in-lining of irq locking/unlocking which makes it hard to keep them all consistent and to introduce changes. Eg, the implementation of SMP on Armv6-m will require to
enable SoC specific synchronisation between core. Identifying and propagating the required changes will be challenging.
The issues raised so far are actually all related to missing calls __enable_irq()/__disable_irq().

Due to the nature of the change, I was expecting some breakage to have sipped through the checks (all CI passed). I am still ready to investigate and document the cause of any issue that may still arise. Hopefully, this hasn’t inconvenienced too many people and I appreciate the patience of those who have been.

So I don’t think reverting would be an appropriate move and I remain convinced this is a good thing for the maintainability.

[gmarull]

CMSIS is actually a problem: #57246, I hope it gets some attention.