boot: zephyr: Capture lost early and late log events

[JayToltTech]

Problem

When using SWO deferred logging, I noticed lost early and late log messages in my swoviewer.

Summary

• Fix boot_log_sem initial count from 1 to 0 so zephyr_boot_log_stop() actually blocks until the logging thread finishes draining — previously the semaphore was already signaled at init, so k_sem_take returned immediately without waiting
• Start the deferred logging thread with K_NO_WAIT instead of a polling-interval delay so log messages are processed immediately
• Wake the logging thread in zephyr_boot_log_stop() via k_wakeup() so it drains the buffer without waiting for the next polling interval

Test plan

• Verify all deferred log messages appear before MCUboot jumps to app
• Verify no log messages are lost on fast boots (no swap)

[Copilot]

Pull request overview

This PR updates MCUboot’s Zephyr port logging behavior to reduce lost deferred logs and to avoid unnecessarily disabling logging when serial recovery is active and the log transport is not UART.

Changes:

• Start the custom deferred log processing thread immediately (K_NO_WAIT) rather than after the polling interval delay.
• Wake the log processing thread during shutdown via k_wakeup() to drain logs without waiting for the next sleep interval.
• Make ZEPHYR_BOOT_LOG_STOP() conditional on CONFIG_LOG_BACKEND_UART (no-op for non-UART backends).

Comments suppressed due to low confidence (1)

boot/zephyr/main.c:486

• zephyr_boot_log_stop() intends to wait for the logging thread to exit, but boot_log_sem is defined with an initial count of 1, so the first k_sem_take(..., K_FOREVER) will typically return immediately and not wait for boot_log_thread_func() to k_sem_give(). To make this a real join/drain, initialize the semaphore to 0 (or take it before starting the thread) so zephyr_boot_log_stop() blocks until the thread signals completion.

     * This can be reworked using a thread_join() API once a such will be
     * available in zephyr.
     * see https://github.com/zephyrproject-rtos/zephyr/issues/21500
     */
    (void)k_sem_take(&boot_log_sem, K_FOREVER);

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[JayToltTech]

zephyr_boot_log_stop() intends to wait for the logging thread to exit, but boot_log_sem is defined with an initial count of 1, so the first k_sem_take(..., K_FOREVER) will typically return immediately and not wait for boot_log_thread_func() to k_sem_give(). To make this a real join/drain, initialize the semaphore to 0 (or take it before starting the thread) so zephyr_boot_log_stop() blocks until the thread signals completion.

I updated this based on the Copilot feedback. Can someone double check this to confirm it's corrected behavior? It sounds correct to me...

[nordicjm]

Fix is ok but title is wrong, change to boot: zephyr: Fix deferred logging before jumping to app or similar

[nordicjm]

by title, I mean git commit title, that needs updating