Re: Passing information from bootloader to Zephyr


Marti Bolivar <marti.bolivar@...>
 



On 24 July 2017 at 12: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.

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).

OK, so it sounds like these DT changes aren't expressing expectations about the state of the peripheral.

But based on David's response, it does seem like it matters to Zephyr what state the peripherals are in when the bootloader hands over control, and that's not currently managed as it should be.

Should we just let this sit until it causes concrete problems? Any ideas from the Zephyr devs on how they'd like to see this managed (noting that this thread is cross-posted to dev-mcuboot)?

Thanks,
Marti
 



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.