On 24/07/17 16:47, 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 there).
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?

The enabled property doesn't describe whether the peripheral is active or not at bootloader handover. It is more like whether that peripheral is connected to something useful. DT describes the hardware, including the board, so if a UART is not pinned out somewhere in the board design it should not be enabled in the DT.

Also, are you reviewing the SoC DT include file or the board description?

The patch you linked to seems to be mostly SoC include files. It is normal for all peripherals to be disabled in SoC include files. It is only when the pinout for the board is decided that we know what peripherals should actually be enabled (and what pinmux settings to use for them).


Daniel.

Thanks,
Marti
[1] https://github.com/zephyrproject-rtos/zephyr/pull/888
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@...
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel