search

zephyrproject-rtos / zephyr

Primary Git Repository for the Zephyr Project. Zephyr is a new generation, scalable, optimized, secure RTOS for multiple hardware architectures.
https://docs.zephyrproject.org
Apache License 2.0
10.86k stars 6.62k forks source link

Kconfig: build system ignores 'default' values for some symbols in SoCs-level 'Kconfig.defconfig' after HWMv2 was applied #72793

Open kokas-a opened 6 months ago

kokas-a commented 6 months ago

Describe the bug After HWMv2 model was applied, build system ignores config XIP that configured on SoC level of Kconfig.

Synopsys nSIM platforms has following levels of XIP configs:

  1. arch/Kconfig applied for ARC architecture in general via imply XIP
  2. soc/snps/nsim/Kconfig.defconfig via default n
  3. (optional) board/snps/nsim/ ${board}_defconfig

If XIP configuration is not set on board level explicitly, then 2nd level (SoC-level) config is also skipped. And final configuration is taken from arch-level via imply XIP and assigned with XIP=y value.

To Reproduce Steps to reproduce the behavior:

  1. west build -b nsim/nsim_em samples/hello_world
  2. cat build/zephyr/.config | grep XIP
  3. See incorrect behavior: CONFIG_XIP=y

Expected behavior CONFIG_XIP=n in .config file, as config XIP was not explicitly defined on board level. It defined with n value on SoC level.

Environment (please complete the following information):

kokas-a commented 6 months ago

The issue touches not only ARC nSIM platforms. For example, tlsr9518adk80d board has the same way of including XIP configs, and final result is CONFIG_XIP=y despite it turned off on SoC level.

nashif commented 5 months ago

@kokas-a is this resolved now with #73433

kokas-a commented 5 months ago

Hi @nashif , https://github.com/zephyrproject-rtos/zephyr/pull/73433 provides workaround as a temporary solution, but it does not fix root cause itself. Additionally, issues with the risc-v platform have not yet been resolved (see my additional comment here).

evgeniy-paltsev commented 5 months ago

@nashif I've updated the issue name so it would be more clear.

It's not ARC-related (or architecture related) issue, but a regression in Kconfig configuration system introduced with HW model v2.

It seems to be that we now handle the imply keyword incorrectly - so if we imply some Kconfig symbol in kernel Kconfig we can't override it in SoCs-level Kconfig.defconfig file. It causes some symbol to be enabled even if we disable it in on SoC level.

For this particular symbol (CONFIG_XIP) we've found ARC and RISC-V SoC which configuration was affected by this issue, however I expect that there is more issues with other symbols.

github-actions[bot] commented 3 months ago

This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.

github-actions[bot] commented 1 week ago

This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.

nordicjm commented 58 minutes ago

I don't see a bug here, the default is correctly set to n, in the arch level you have a Kconfig that implies it, imply is not default, imply takes prescience over default and is on par with a select statement.

nordicjm commented 45 minutes ago

It's not ARC-related (or architecture related) issue, but a regression in Kconfig configuration system introduced with HW model v2.

Incorrect, you had the exact same CONFIG_XIP=n in your board defconfig files in hwmv1: https://github.com/zephyrproject-rtos/zephyr/blob/v3.6-branch/boards/arc/nsim/nsim_em_defconfig#L7