Re: Passing information from bootloader to Zephyr

David Brown

On Mon, Jul 24, 2017 at 11:47:47AM -0400, Marti Bolivar wrote:
It's likely future work, but it seems inevitable we'll have to define
exactly the state of the device that mcuboot provides to the chainloaded
image. Having a place to put formal definitions will simplify this work.

I especially want to highlight this part: ^^

Erwan, I noticed while looking at a recent PR [1] that the STM32 UARTs have a 
status = "disabled" property in DTS (not introduced in this change, was already

But in fact, when Zephyr is chain-loaded by mcuboot, at least one of the UARTs
is not disabled, since mcuboot uses it to log and doesn't disable it before
jumping to the next image. Further the clocks are reconfigured from their reset
defaults, the PLL is on, etc.

It seems like this will inevitably cause problems as the Zephyr DTS continues
to get more sophisticated (not just for STM32).

Am I missing something here?
I don't think so. Part of the definition of the bootloader needs to
be to describe what state it leaves things in. For most
compatibility, it would seem best to leave things in as close to reset
state as possible. Ideally, that would shut down any clocks, etc.

Unfortunately, when booting apps that do use the serial port, turning
off the clock like this will usually result in gibberish coming over
the serial port. This probably doesn't hurt much, but can be

The Mynewt approach has been to not use the serial port in the
bootloader. We could consider the uart use to be a debugging feature,
and recommend it be turned off for production.

Otherwise, we would want to add code to disable any clocks that were
started. I'm not sure there is an easy way to do this in the mcuboot
code without introducing target-specific code.


Join to automatically receive all group messages.