Re: Passing information from bootloader to Zephyr
Daniel Thompson <daniel.thompson@...>
On 24/07/17 17:34, Erwan Gouriou wrote:
On 24 July 2017 at 18:03, Daniel Thompson <daniel.thompson@... <mailto:daniel.thompson@...>> wrote: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?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
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.