On 24 July 2017 at 13:50, Daniel Thompson <daniel.thompson@... <mailto:daniel.thompson@...>> wrote: On 24/07/17 17:34, Erwan Gouriou wrote: On 24 July 2017 at 18:03, Daniel Thompson <daniel.thompson@... <mailto:daniel.thompson@...> <mailto:daniel.thompson@... <mailto: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. 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. Sorry, I'm not following how this is relevant to the questions about the bootloader/Zephyr boundary. Am I missing something?
Not sure. ;-)
Mostly it is illustrating that the DT status of a peripheral is (pretty much) unrelated to the mcuboot protocols to hand over peripherals.
Another minor point is that while it is reasonable for mcuboot to expect zephyr drivers to be able to handle peripherals that mcuboot has already activated, it is unlikely that a zephyr application will know how to *deactivate* peripherals that it doesn't need (since to keep application code size down all knowledge of such peripheral ends up being compiled out). This is a minor point, mostly because I can't think of many peripherals that mcuboot would need and that zephyr leaves idle. Nevertheless if they do exist, they risk wasting power of mcuboot does not declock/depower them during a boot.
