ELCE: DT, Kconfig, EDTS path forward

[carlescufi]

Meeting at ELCE 2018.10.24
@nashif @galak @erwango @mbolivar @carlescufi

• Run DT before Kconfig (DONE)

  • Remove #if CONFIG_ from all board/ and dts/ files
  • Use -DSHIELD= to enable building of a shield (Use -DSHIELD= to enable building of a shield #12102)
  • Build system needs to look by default for board, arch and soc .conf and .overlay files
  • Find the exact arch and soc name to locate SoC-specific overlays, requires a 2-pass DT approach: First pass to find out arch and soc, second pass is actually DT (PR [DNM][RFC] dts: Get SoC from dts and not from kconfig generated autoconfig.h #9925)
  • Change build system so that DT runs before Kconfig

• Have DT generate Kconfig fragment enabling the compatibles: CONFIG_DT_COMPAT_STM32_SPI=y so that if the user enables CONFIG_SPI=y then the right driver is enabled.

• By default only drivers/subsystems that are enabled in _defconfig via device class (CONFIG_SPI=y for example) are compiled in, others are not compiled.

• Merge in EDTS

• Code generation

  • Freeze requirements (Requirements for driver devices generation using device tree #10904)
  • Decide on templating engine
    • COG (Generated driver instantiation prototype  #8561)
    • Jinja2 ([RFC] Template prototype using jinja2 templating engine #10957)

• Create a dts-ng branch where both the EDTS and later maybe code generation can be pushed for collaboration.

[galak]

Here are the defines we need to remove board/*/*.dts and dts/

CONFIG_BOARD_EM_STARTERKIT_R23
CONFIG_BOOTLOADER_MCUBOOT
CONFIG_BT
CONFIG_CODE_HYPERFLASH
CONFIG_CODE_ITCM
CONFIG_CODE_QSPI
CONFIG_FS_FLASH_MAP_STORAGE
CONFIG_FS_FLASH_STORAGE_PARTITION
CONFIG_MCUMGR_SMP_UART
CONFIG_MODEM_WNCM14A2A
CONFIG_SOC_EMSK_EM11D
CONFIG_SOC_EMSK_EM7D
CONFIG_SOC_EMSK_EM9D
CONFIG_UART_1_NRF_UARTE
CONFIG_UART_MCUX_2
CONFIG_USB_UART_CONSOLE
CONFIG_XIP

[SebastianBoe]

I believe that this is what will require the most work and break compatibility the hardest:

Remove #if CONFIG_ from all board/ and dts/ files

the rest looks fairly straightforward.

I would like to discuss our strategies for getting these Kconfig symbols out of DT. For instance CONFIG_BOOTLOADER_MCUBOOT. I agree with the assessment of @mbolivar , who has worked on the MCUboot integration, that taking the MCUBoot partitions out of the scope of DT is the best approach here[0].

I am aware that communicating flash partitioning layout information between the bootloader and the kernel is one of the responsibilities of DT. But I believe that although this has worked well for other DT users, it does not work well for us.

[0] #9925 (comment)

Can we agree on this, or are there any viable alternatives?

[erwango]

@carlescufi :

Have DT generate Kconfig fragment enabling the compatibles: CONFIG_DT_COMPAT_STM32_SPI=y so that if the user enables CONFIG_SPI=y then the right driver is enabled.

About that point: you mentioned a reason why COMPAT flags should remain CONFIG_DT_XXX since having them in DT_ namespace would not work (possible but would not enable the expected usage). Can you state here the reason again?

[carlescufi]

@carlescufi :

Have DT generate Kconfig fragment enabling the compatibles: CONFIG_DT_COMPAT_STM32_SPI=y so that if the user enables CONFIG_SPI=y then the right driver is enabled.

About that point: you mentioned a reason why COMPAT flags should remain CONFIG_DT_XXX since having them in DT_ namespace would not work (possible but would not enable the expected usage). Can you state here the reason again?

@erwango I edited this now

There are 2 things here: one is that we generate compatible defines or flags, which are not used right now at all. Those can live in the DT_ namespace. The other is that in the future we want to base compilation of drivers on compatible-based Kconfig options. This is different and will come later, and will have to be defined at a later time.

[erwango]

@carlescufi ,

EDITED: ok so kept in #11180 then

[carlescufi]

This is not really relevant anymore, and the missing bits are covered by #8499