On 24/07/17 19:03, Marti Bolivar wrote:
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
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
simplify this work.
I especially want to highlight this part: ^^
Erwan, I noticed while looking at a recent PR  that
UARTs have a status = "disabled" property in DTS (not
in this change, was already there).
But in fact, when Zephyr is chain-loaded by mcuboot, at
one of the UARTs is not disabled, since mcuboot uses it
and doesn't disable it before jumping to the next
the clocks are reconfigured from their reset defaults,
is on, etc.
It seems like this will inevitably cause problems as
DTS continues to get more sophisticated (not just for
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
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
And if connected to HW, should it be enabled and clocked?
Linux uses mix of Kconfig/dt. Kconfig for compilation/dt for
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
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.
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.