__ASSERT() triggers with `CONFIG_MULTITHREADING=n`

[carlescufi]

This assertion:

https://github.com/zephyrproject-rtos/zephyr/blob/master/arch/arm/core/thread.c#L63

Triggers on Arm with CONFIG_MULTITHREADING=n. I don't think it should.

[carlescufi]

CC @andrewboie @andyross

[carlescufi]

We are investigating MCUboot triggering a fault on Arm with @nvlsianpu and we enabled asserts and hit this immediately. Removing the assert allows us to continue, but can this have side-effects?
There are not many projects out there using CONFIG_MULTITHREADING=n I guess.

[carlescufi]

One of the faults that we have seen is triggering on accessing this line: https://github.com/zephyrproject-rtos/zephyr/blob/master/arch/arm/core/swap.c#L60.

Is swap() supposed to be called when using CONFIG_MULTITHREADING=n?

[nvlsianpu]

The assertion message was: ASSERTION FAIL [(priority) == -1] @ /home/anpu/codedev/zephyr_2/arch/arm/core/thread.c:63:

[carlescufi]

Note that we are hitting the assert even before we reach main(). And what bothers me is that the stack trace shows prepare_multithreading(). Should we really be calling that with multithreading disabled?

[andyross]

This is almost certainly something I broke. I'll take it. I guess we never wrote a test for MULITTHREADING=n, huh?

[Olivier-ProGlove]

It might not fix this specific issue - but it might...

But when porting MCUBoot to our platform I had an issue with one of our drivers that was used by the bootloader. After investigating the problem I found out the issue was _impl_k_sem_take() used by our driver only supports multithreading.

In this pull-request #8368, I added non-mutlithreading support to _impl_k_sem_take()

[andyross]

Fix for the crash is up in #8370. Was fairly straightforward.

Note that I didn't dig through and try to "slim down" the link, which was Ben's original goal with this feature. Post-1.12, it seems very likely we're pulling stuff into the build now that we shouldn't be.