CONFIG_MULTITHREADING=n builds call main() with interrupts locked

[carlescufi]

For consistency with multithreaded builds, main() should be called with interrupts unlocked and ready to go.

[andyross]

The root cause here is that where the default Zephyr thread startup sets the lock state to a known value inside arch code, where we are at the end of _Cstart() is unspecified. We never took a lock, so we can't release it.

There needs to be an arch hook for "enable interrupts unconditionally", either a new API call or a special key value that can be passed to irq_unlock().

[carlescufi]

Raising priority because this cannot be easily worked around on the application code in a way that is cross-arch and clean.

[carlescufi]

@agross-linaro @andyross I also notice that even when enabling interrupts I see behavior that is not explained by my code. Could it be that the ISR wrapper in https://github.com/zephyrproject-rtos/zephyr/blob/master/arch/arm/core/isr_wrapper.S#L42 also needs conditional compilation based on CONFIG_MULTITHREADING?
Right now this is completely preventing proper use of MCUboot.

[agross-oss]

If no multithreading then yeah this shouldn't be setting the context switch.

[carlescufi]

@agross-linaro I've disabled CONFIG_SYS_POWER_MANAGEMENT and CONFIG_PREEMPT_ENABLE and I believe that should compile out all of the code we don't need, though confirmation would be appreciated.

[carlescufi]

Added an MCUboot issue to be resolved once this one is closed: mcu-tools/mcuboot#302

[andyross]

Drop priority as there's an active workaround and it's not blocking work. It remains a real bug and needs a fix for 1.13.

[nashif]

@andyross ping

[nashif]

@carlescufi would be great to specify why all of this is needed, are we still going after the few kilobytes from the kernel or is there some other rationale for having this supported?

[carlescufi]

@carlescufi would be great to specify why all of this is needed, are we still going after the few kilobytes from the kernel or is there some other rationale for having this supported?

The idea is to be able to use Zephyr as an almost "bare-metal" development platform. Threads and threading can be expensive in RAM and ROM footprint, but Zephyr provides a lot of value beyond its RTOS underpinnings:

• A flexible build and configuration system
• A hardware description language along with an API to access it
• Platform and architecture-agnostic primitives for basic operations such as booting and handling interrupts
• In some cases (flash drivers are a good example) basic driver functionality under a single API

I personally believe that maintaining the possibility of using Zephyr in this way it's added value at a (relative) low cost for the project, so I would be very much in favor of formally defining the requirements and limitations and then officially supporting this "feature".

[carlescufi]

which is 18.4% at 5836 bytes.

Hmm, I measure 4290 bytes for the whole kernel above, so most of this overhead is probably coming from somewhere else and when multithreading is enabled, probably thru logging. With log minimal enable I get;

[109/114] Linking C executable zephyr/zephyr_prebuilt.elf
Memory region         Used Size  Region Size  %age Used
           FLASH:       33780 B        48 KB     68.73%
            SRAM:       25120 B       256 KB      9.58%
        IDT_LIST:          88 B         2 KB      4.30%

There are some additional benchmarks here.

[nashif]

single threading is scheduled for deprecation, so lower priority.

[pabigot]

Why keep this open? It's unlikely that the decision will change, and if it does part of the task will be to identify all the things that need to work, in which case this issue will be rediscovered. Keeping it open affects the low bug count which can now impact release.

I'd rather close all these issues and move on. Maybe discuss next triage.

[nashif]

clearing assignee as this feature is being deprecated, we can talk about this next and discuss if someone will step up and own this and if those issues will be assigned to them. The bug is open, but the code is still in the tree, even with deprecation. Deprecated code does not mean we stop fixing bugs.

[pabigot]

@ioannisg re our discussion earlier today.

[github-actions]

This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.

[carlescufi]

reopening as this still applies

[ioannisg]

@carlescufi you reopened this, however, I am not sure if this still applies. CONFIG_MULTITHREADING=n is only maintained on Cortex-M, for now, and I can confirm that in Cortex-M this is not an issue.

[carlescufi]

@carlescufi you reopened this, however, I am not sure if this still applies. CONFIG_MULTITHREADING=n is only maintained on Cortex-M, for now, and I can confirm that in Cortex-M this is not an issue.

I agree, as long as you confirm that this is not an issue with Cortex-M then we can close this @ioannisg

[ioannisg]

3b89cf1

@carlescufi ^^
We even have a unit tests that covers it. :)

[carlescufi]

Thanks for confirming @ioannisg. Closing this now.