kernel: remove single thread support

[dcpleung]

This removes single thread supports. Changes are done to
remove CONFIG_MULTITHREADING and #ifdef enclosed by it.

This includes the following reverts which can be trivially
applied:

Revert "drivers: flash: w25qxxdv: Avoid locking when not threaded"
This reverts commit 392da5b.

Revert "drivers: flash: nrf: Avoid locking when not threaded"
This reverts commit 408ea14.

Revert "tests/kernel/threads/no-multithreading: Disable USERSPACE"
This reverts commit 2f95e24.

Revert "tests/kernel: Add a test for CONFIG_MULTITHREADING=n"
This reverts commit 7bbd3a7.

Revert "kernel: Final spin in !MULTITHREADING should be locked"
This reverts commit 8daafd4.

Revert "kernel: Restore CONFIG_MULTITHREADING=n behavior"
This reverts commit 3d14615.

Revert "ext: simplelink: host driver: depend on multithreading"
This reverts commit 4d912b0.

Relates to #9808

Signed-off-by: Daniel Leung daniel.leung@intel.com

[codecov-io]

Codecov Report

Merging #10275 into master will increase coverage by <.01%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master   #10275      +/-   ##
==========================================
+ Coverage   53.05%   53.06%   +<.01%     
==========================================
  Files         214      214              
  Lines       26201    26196       -5     
  Branches     5645     5645              
==========================================
- Hits        13901    13900       -1     
+ Misses      10028    10024       -4     
  Partials     2272     2272

Impacted Files	Coverage Δ
kernel/include/ksched.h	94.25% <ø> (ø)	⬆️
kernel/init.c	74.57% <ø> (+1.99%)	⬆️
kernel/thread.c	93.46% <ø> (ø)	⬆️
kernel/sched.c	91.94% <ø> (+0.33%)	⬆️
include/kernel.h	98.52% <ø> (ø)	⬆️
lib/thread_entry.c	75% <ø> (+15%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 10c6a0c...85eb3bb. Read the comment docs.

[dcpleung]

Do not merge yet. There is a xtensa_asm2 sample app which requires single thread. Need to figure out what to do with it.

[carlescufi]

@dcpleung

Thanks for looking into this.

MCUboot uses this option to save on ROM space.
Before we merge this, please build MCUboot and let's make sure we do not add to the ROM footprint. Instructions for building with Zephyr are here.
I suggest using nrf52_pca10040 as a board.

There are several current applications that require the bootloader to fit in 16KB of flash. @sjanc is currently developing one.

Also copied the relevant people: @nvlsianpu and @d3zd3z

[nvlsianpu]

@carlescufi Thanks for info. will check things on Monday.

[andyross]

No complaints about removing the feature, given that the first user ran into bumps with wanting to have drivers work in the mode, which wasn't the original intent.

Still, there are a bunch of bytes to save in code size if you know you will never swap. Even if that's bitrotten currently, Ben had the zephyr minimal kernel down below something like 3kb when it was committed.

Basically, we can remove this now, but I'll bet we want it back at some point. Though doing it again from scratch is probably no more work than fixing what we have.

[nashif]

16KB of flash

really? we have mcuboot now building in < 16kb flash? AFAIK when this was introduced we almost got it to fit just below 20k

[andyross]

Oh, and you can junk the asm2 thing. That's a testbed for the very lowest level of the Xtensa platform integration. When I did the same thing for x86 I split it out into a separate layer with its own makefile, which worked better. Making that work in the context of a Zephyr build was, in hindsight, more work than it was worth.

And there's no loss of test coverage if you junk it. Needless to say we hit all that code in the context of the other tests by definition. It's just a unit test.

[carlescufi]

really? we have mcuboot now building in < 16kb flash? AFAIK when this was introduced we almost got it to fit just below 20k

we do, at least for Nordic targets. @sjanc can give you the exact ROM footprint.

[dcpleung]

I tried building mcuboot with board nrf52_pca10040, and there was about 3KB increase in flash size. According to the build output, before this patch, flash used 29096 bytes (and SRAM 22444 bytes). After applying this patch, the flash used 32152 bytes (and SRAM 22796 bytes).

[carlescufi]

@dcpleung 3KB is a lot of flash in the Nordic range of devices. Is there something we can do to compensate here?

[dcpleung]

I compared the .config files and set the following in mcuboot's prj.conf:

CONFIG_TIMESLICING=n
CONFIG_SIMPLE_FATAL_ERROR_HANDLER=y
CONFIG_NUM_PREEMPT_PRIORITIES=0
CONFIG_NUM_COOP_PRIORITIES=1

However, the flash size is still 2KB larger at 31540 bytes.

Removing sem_lock and k_sem_* function calls in drivers/flash/soc_flash_nrf.c results in built binary with flash size of 30792 bytes (less 748 bytes). The remaining additions are all from the thread initialization and scheduler functions. Those adds up to about 1.6K according to the output of readelf.

[carlescufi]

Temporarily nacking until we have a better understanding of the consequences of merging this for MCUboot.

[sjanc]

Hi, yes we use that option for our bootloader build

currently what we have is
Memory region Used Size Region Size %age Used
FLASH: 14064 B 16 KB 85.84%

If we enable CONFIG_MULTITHREADING=y this numbers grow to
FLASH: 17100 B 16 KB 104.37%

So we would require extra flash page just for bootloader.

[sjanc]

we must fit 16k

[nvlsianpu]

As @sjanc said
Mcuboot must fit in 16 KB.

[nashif]

yes we use that option for our bootloader build

Is the configuration you are using available somewhere?

[sjanc]

We basically disabled everything we could

Disable console and logs

CONFIG_CONSOLE=n
CONFIG_SYS_LOG=n
CONFIG_BOOT_HAVE_LOGGING=n
CONFIG_DEBUG=n

Disable not needed OS features

CONFIG_SYSTEM_CLOCK_DISABLE=y
CONFIG_SYS_POWER_MANAGEMENT=n
CONFIG_ARM_CORE_MPU=n
CONFIG_ARM_MPU_ENABLE=n
CONFIG_ARM_MPU_NRF52X=n
CONFIG_MULTITHREADING=n

CONFIG_MAIN_STACK_SIZE=10240
CONFIG_BOOT_SIGNATURE_TYPE_RSA=n
CONFIG_BOOT_SIGNATURE_TYPE_ECDSA_P256=y
CONFIG_FLASH=y

And I'd rather target 12k in future, not other way around :-)

[nvlsianpu]

@sjanc - can you attach .config file you have while compiling the minimal mcuboot on nrf52?

[d3zd3z]

This change is pretty much a show stopper for some MCUboot uses, at least from what it looks like with the code size.

There really is a need to be able to use Zephyr more as a BSP for a bare-metal application (such as a bootloader) than as an RTOS. Realistically, if this merges, small constrained devices would have to use another solution (such as MyNewt) to be able to build the bootloader.

[d3zd3z]

Also, this would prevent us from being able to build the secure side of a trusted firmware solution using Zephyr. This both has to be small, and specifically must not have a scheduler in it.

What is being added to MCUboot that requires multi-threading (and how do I stop this?). The bootloader should not have a scheduler in it.

-2

[d3zd3z]

Running without a scheduler is a requirement for multiple applications, including MCUboot and the secure side of a trusted firmware application. Both of these require advanced scrutiny, and require that there be as little code as possible. This isn't just about the size of the code, but about auditing/validating the code as well, especially from a security perspective.

There are people already uncomfortable that MCUboot uses Zephyr at all, and have only been placated by telling them that most of Zephyr is not being included, and Zephyr is only being used for board support, and minimal drivers (generally flash and UART).

[hongshui3000]

A single-threaded programming model can be defined to standardize, single-threaded applications. If you simply remove it will undoubtedly narrow the scope of use.

[sjanc]

Why not just simply require from drivers to depend on multi threading support if that is needed by driver? That would give nice early build error.

[andrewboie]

We need to come to some kind of resolution on this at least for the short term 1.14 release. Right now, with multithreading disabled, the application runs with interrupts disabled. See my findings #14454

There are some good points being made and I have no particular stake or preference on which way this goes, but if we keep this feature, I suggest we should make it a no-op/unsupported for 1.14 to address these issues, and then do a proper well-tested implementation for 1.15.

[nashif]

outdated, close