On 24/07/17 17:34, Erwan Gouriou wrote:

On 24 July 2017 at 18:03, Daniel Thompson <daniel.thompson@... <mailto:daniel.thompson@linaro.org>> 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.

I'd describe it that Linux uses *drivers* for activation. For example, it is the driver that makes the appropriate calls (usually via clock framework, etc) to enable and clock its peripheral.

So KConfig controls whether the driver is includes a driver or not (driver not compiled -> no activation).

Similar, in Linux, DT is just a data structure and doesn't really *do* anything. However by describing hardware it does enable the kernel to probe for drivers whose hardware cannot be automatically detected (no hardware detected -> no 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.

Currently zephyr has the two layers of separation although the mechanism is different, although in my opinion, the driver is still ending up doing all the activation.

DT support is realized as a pre-processor that enriches the configuration space by defining CONFIG_ symbols with special names. For example
CONFIG_UART_STM32_PORT_2_NAME,
CONFIG_UART_STM32_PORT_2_BASE_ADDRESS, etc.

KConfig controls both whether the driver as a whole is enabled *and* whether that driver should enable port 2. The driver then uses the symbols provided by DT to fill out a DEVICE[_AND_API]_INIT() macro.

The main difference versus Linux is that, on Zephyr, KConfig can control whether or not port 2 is enabled. Thus if hardware is omitted from the DT you will discover this at build time. This is good for code size (an application that doesn't use UART2 doesn't need to change the DT just to eliminate the overhead) but appears also makes the status field in DT pretty much redundant anyway.

Daniel.