1. Messages
  2. Passing information from bootloader to Zephyr

Re: Passing information from bootloader to Zephyr

Marti Bolivar <marti.bolivar@...>
 



On 24 July 2017 at 12:34, Erwan Gouriou <erwan.gouriou@...> wrote:


On 24 July 2017 at 18:03, Daniel Thompson <daniel.thompson@...> wrote:
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.
And if connected to HW, should it be enabled and clocked?
Linux uses mix of Kconfig/dt. Kconfig for compilation/dt for activation. Do we want the same in Zephyr and keep these 2 levels of configuration?
Another option would be to add a property in device tree to declare activation at boot.
Andy.G you may already have thought about this?
Sorry if I have gone off topic.

A little bit :), perhaps.

This thread is about clocks, peripherals, etc. which mcuboot may use and what should happen to them before control is passed to Zephyr; please note that this thread is also posted to the mcuboot developer list. The above seem like they may be unrelated as they sound like Zephyr internals.
 


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@...ct.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel
Join {devel@lists.zephyrproject.org to automatically receive all group messages.