Difference between revisions of "Kconfig"
m (→^ Kconfig NXP dual core setting: - search for setting and meaning of `zephyr,sram-cpu1-partition`) |
m (Kconfig formatting rules and variable name length limit) |
||
| Line 53: | Line 53: | ||
<!-- comment --> | <!-- comment --> | ||
| + | |||
| + | |||
| + | == [[#top|^]] Kconfig formatting and variable names == | ||
| + | |||
| + | Kconfig variable name length appears to have a finite length rule, which when broken causes a silent failure of Kconfig processing tools to assign a value to the given variable. The following Expressif documentation page goes into a bit of detail on this topic: | ||
| + | |||
| + | * https://docs.espressif.com/projects/esp-idf/en/stable/esp32/api-reference/kconfig.html#kconfig-formatting-rules | ||
| + | |||
| + | A summary excerpt from this Expressif page is: | ||
| + | |||
| + | <pre> | ||
| + | |||
| + | Kconfig Formatting Rules | ||
| + | |||
| + | The following attributes of Kconfig files are standardized: | ||
| + | |||
| + | Within any menu, option names should have a consistent prefix. The prefix length is currently set to at least 3 characters. | ||
| + | |||
| + | The indentation style is 4 characters created by spaces. All sub-items belonging to a parent item are indented by one level deeper. For example, menu is indented by 0 characters, the config inside of the menu by 4 characters, the help of the config by 8 characters and the text of the help by 12 characters. | ||
| + | |||
| + | No trailing spaces are allowed at the end of the lines. | ||
| + | |||
| + | The maximum length of options is set to 40 characters. | ||
| + | |||
| + | The maximum length of lines is set to 120 characters. | ||
| + | |||
| + | Format checker | ||
| + | |||
| + | tools/check_kconfigs.py is provided for checking the Kconfig formatting rules. The checker checks all Kconfig and Kconfig.projbuild files in the ESP-IDF directory and generates a new file with suffix .new with some recommendations how to fix issues (if there are any). Please note that the checker cannot correct all rules and the responsibility of the developer is to check and make final corrections in order to pass the tests. For example, indentations will be corrected if there isn’t some misleading previous formatting but it cannot come up with a common prefix for options inside a menu. | ||
| + | |||
| + | </pre> | ||
| + | |||
| + | Note: Expressif's Kconfig format checker looks like an interesting tool. NEED to investigate this script - 2022-12-23 Friday. | ||
| + | |||
| + | <!-- comment --> | ||
| + | |||
== [[#top|^]] Kconfig NXP dual core setting == | == [[#top|^]] Kconfig NXP dual core setting == | ||
Revision as of 15:38, 23 December 2022
Zephyr RTOS building blocks :: Device Tree Source :: Kconfig :: cmake :: `west` manifest files
Keywords: multi-core dual-core SECOND_CORE_BOOT_ADDRESS_MCUX code-cpu1-partition
This Neela Nurseries page dedicated to notes on Kconfig configuration system, and language. Agood starting point is at Zephyr's latest documentation as of Zephyr 3.2.99. The following link is itself one of five Zephyr docs pages linked from a parent doc page:
Need to revisit this link to identify its specific topics . . .
Some more useful articles on Kconfig, hosted at Nordic Semi:
Above Kconfig articles linked to from https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/zephyr/guides/build/index.html#kconfig.
Contents
^ To Invoke Menuconfig From Other Than Project Root
If `zephyr_app` is a project, possibly a "remote" project in a multicore project, and is located two directories below the root of the larger mulitcore, effectively multi-app project, then the following invocation will succeed in opening Kconfig's interactive `menuconfig` interface:
$ west build -b zephyr_app -t menuconfig -- -DBOARD_ROOT=../..
^ Kconfig Interactive Use To Enable IIS2DH
Following messages do not show the interactive, ncurses based Kconfig configuration program. But these do show where Kconfig stores a modified configuration file in a given project:
ted@localhost:~/projects/zephyr-based/z4-sandbox-kionix-work/kionix-driver-demo$ west build -t menuconfig -- west build: running target menuconfig [0/1] cd /home/ted/projects/zephyr-based/z4-sandbox-kionix-work/kionix-dri...ed/projects/zephyr-based/z4-sandbox-kionix-work/kionix-driver-demo/Kconfig Loaded configuration '/home/ted/projects/zephyr-based/z4-sandbox-kionix-work/kionix-driver-demo/build/zephyr/.config' Configuration saved to '/home/ted/projects/zephyr-based/z4-sandbox-kionix-work/kionix-driver-demo/build/zephyr/.config' ted@localhost:~/projects/zephyr-based/z4-sandbox-kionix-work/kionix-driver-demo$
^ Kconfig formatting and variable names
Kconfig variable name length appears to have a finite length rule, which when broken causes a silent failure of Kconfig processing tools to assign a value to the given variable. The following Expressif documentation page goes into a bit of detail on this topic:
A summary excerpt from this Expressif page is:
Kconfig Formatting Rules
The following attributes of Kconfig files are standardized:
Within any menu, option names should have a consistent prefix. The prefix length is currently set to at least 3 characters.
The indentation style is 4 characters created by spaces. All sub-items belonging to a parent item are indented by one level deeper. For example, menu is indented by 0 characters, the config inside of the menu by 4 characters, the help of the config by 8 characters and the text of the help by 12 characters.
No trailing spaces are allowed at the end of the lines.
The maximum length of options is set to 40 characters.
The maximum length of lines is set to 120 characters.
Format checker
tools/check_kconfigs.py is provided for checking the Kconfig formatting rules. The checker checks all Kconfig and Kconfig.projbuild files in the ESP-IDF directory and generates a new file with suffix .new with some recommendations how to fix issues (if there are any). Please note that the checker cannot correct all rules and the responsibility of the developer is to check and make final corrections in order to pass the tests. For example, indentations will be corrected if there isn’t some misleading previous formatting but it cannot come up with a common prefix for options inside a menu.
Note: Expressif's Kconfig format checker looks like an interesting tool. NEED to investigate this script - 2022-12-23 Friday.
^ Kconfig NXP dual core setting
We're getting an error when building multicore app. Error is:
Load components for LPC55S69: driver_common component is included. driver_reset component is included. device_CMSIS component is included. CMSIS_Include_core_cm component is included. driver_lpc_gpio component is included. driver_pint component is included. driver_inputmux component is included. driver_inputmux_connections component is included. driver_flexcomm_usart component is included. driver_flexcomm component is included. driver_lpc_iocon component is included. CMake Error at CMakeLists.txt:150 (message): LPC55S69_CPU1_BOOT_ADDRESS out of sync with CONFIG_SECOND_CORE_BOOT_ADDRESS_MCUX: 0x30000 != 0x3a000 -- Configuring incomplete, errors occurred! See also "~/projects-sandbox/workspace-for-nexus/nexus-gateway-firmware/samples/multicore-sample-moved/build/CMakeFiles/CMakeOutput.log". See also "~/projects-sandbox/workspace-for-nexus/nexus-gateway-firmware/samples/multicore-sample-moved/build/CMakeFiles/CMakeError.log".
Searching for this Kconfig symbol from Zephyr project root:
ted@localhost1:~/projects-sandbox/workspace-out-of-tree/zephyr$ grep -nr SECOND_CORE_BOOT_ADDRESS_MCUX ./*
./boards/arm/lpcxpresso55s69/CMakeLists.txt:25: -offset ${CONFIG_SECOND_CORE_BOOT_ADDRESS_MCUX}
./soc/arm/nxp_lpc/lpc54xxx/Kconfig.soc:54:config SECOND_CORE_BOOT_ADDRESS_MCUX
./soc/arm/nxp_lpc/lpc54xxx/soc.c:134:#define CORE_M0_BOOT_ADDRESS ((void *)CONFIG_SECOND_CORE_BOOT_ADDRESS_MCUX)
./soc/arm/nxp_lpc/lpc55xxx/Kconfig.soc:135:config SECOND_CORE_BOOT_ADDRESS_MCUX
ted@localhost1:~/projects-sandbox/workspace-out-of-tree/zephyr$
From file `zephyr/soc/arm/nxp_lpc/lpc55xxx/Kconfig.soc`:
118 code-cpu1-partition 119 config SECOND_CORE_MCUX 120 bool "LPC55xxx's second core" 121 depends on HAS_MCUX 122 help 123 Driver for second core startup 124 125 config SECOND_IMAGE_MCUX 126 depends on SECOND_CORE_MCUX 127 string "Binary image of second core's code" 128 help 129 This points to the image file for the the binary code that will be 130 used by the second core. 131 132 # Workaround for not being able to have commas in macro arguments 133 DT_CHOSEN_Z_CODE_CPU1_PARTITION := zephyr,code-cpu1-partition 134 135 config SECOND_CORE_BOOT_ADDRESS_MCUX 136 depends on SECOND_CORE_MCUX 137 hex "Address the second core will boot at" 138 default $(dt_chosen_reg_addr_hex,$(DT_CHOSEN_Z_CODE_CPU1_PARTITION)) 139 help 140 This is the address the second core will boot from. 141 142 endif # SOC_SERIES_LPC55XXX
We need to search further and understand how the Kconfig stanza at line 138 in excerpt just above works. This line appears to make use of what may be a Kconfig function, as discussed in this Zephyr 3.2.0 document on Custom Kconfig Preprocessor Functions.
ted@localhost1:~/projects-sandbox/workspace-out-of-tree/zephyr$ grep -nr DT_CHOSEN_Z_CODE_CPU1_PARTITION ./*
./soc/arm/nxp_lpc/lpc55xxx/Kconfig.soc:133:DT_CHOSEN_Z_CODE_CPU1_PARTITION := zephyr,code-cpu1-partition
./soc/arm/nxp_lpc/lpc55xxx/Kconfig.soc:138: default $(dt_chosen_reg_addr_hex,$(DT_CHOSEN_Z_CODE_CPU1_PARTITION))
Binary file ./soc/arm/nxp_lpc/lpc55xxx/.Kconfig.soc.swp matches
ted@localhost1:~/projects-sandbox/workspace-out-of-tree/zephyr$ grep -nr zephyr,code-cpu1-partition ./*
./boards/arm/lpcxpresso55s69/lpcxpresso55s69_cpu0.dts:39: zephyr,code-cpu1-partition = &slot1_partition;
./boards/arm/lpcxpresso55s69/CMakeLists.txt:20: #offset is taken from zephyr,code-cpu1-partition
./soc/arm/nxp_lpc/lpc55xxx/Kconfig.soc:133:DT_CHOSEN_Z_CODE_CPU1_PARTITION := zephyr,code-cpu1-partition
Binary file ./soc/arm/nxp_lpc/lpc55xxx/.Kconfig.soc.swp matches
ted@localhost1:~/projects-sandbox/workspace-out-of-tree/zephyr$ cd ./boards/arm/lpcxpresso55s69
ted@localhost1:~/projects-sandbox/workspace-out-of-tree/zephyr/boards/arm/lpcxpresso55s69$ ls
board.cmake Kconfig.defconfig lpcxpresso55s69_cpu1_defconfig lpcxpresso55s69_ns_defconfig pinmux.c
CMakeLists.txt lpcxpresso55s69_cpu0_defconfig lpcxpresso55s69_cpu1.dts lpcxpresso55s69_ns.dts pre_dt_board.cmake
doc lpcxpresso55s69_cpu0.dts lpcxpresso55s69_cpu1.yaml lpcxpresso55s69_ns.yaml
Kconfig.board lpcxpresso55s69_cpu0.yaml lpcxpresso55s69.dtsi lpcxpresso55s69-pinctrl.dtsi
ted@localhost1:~/projects-sandbox/workspace-out-of-tree/zephyr/boards/arm/lpcxpresso55s69$ grep -nr slot1_partition ./*
./lpcxpresso55s69_cpu0.dts:39: zephyr,code-cpu1-partition = &slot1_partition;
./lpcxpresso55s69_cpu1.dts:23: zephyr,code-partition = &slot1_partition;
./lpcxpresso55s69.dtsi:129: slot1_partition: partition@30000 {
./lpcxpresso55s69_ns.dts:31: zephyr,code-partition = &slot1_partition;
ted@localhost1:~/projects-sandbox/workspace-out-of-tree/zephyr/boards/arm/lpcxpresso55s69$
^ A Simpler Search
A search for setting and meaning of `zephyr,sram-cpu1-partition`:
The token `zephyr,code-cpu1-partition` seems important, as it is the value assigned to DT_CHOSEN_Z_CODE_CPU1_PARTITION in ./soc/arm/nxp_lpc/lpc55xxx/Kconfig.soc:133. A search for part of this token gives the following `grep` search results labeled here (1). From these results we see most lines are build artifacts from compiling a couple of samples in the local Zephyr source tree. But the very first result looks like a device tree source line, which declares a device tree alias:
Grep search results 1
ted@localhost1:~/projects-sandbox/workspace-out-of-tree/zephyr$ grep -nr code-cpu1-partition ./* ./boards/arm/lpcxpresso55s69/lpcxpresso55s69_cpu0.dts:39: zephyr,code-cpu1-partition = &slot1_partition; ./boards/arm/lpcxpresso55s69/CMakeLists.txt:20: #offset is taken from zephyr,code-cpu1-partition ./samples/drivers/ipm/ipm_mcux/build/zephyr/zephyr.dts:13: zephyr,code-cpu1-partition = &slot1_partition; Binary file ./samples/drivers/ipm/ipm_mcux/build/zephyr/edt.pickle matches ./samples/drivers/ipm/ipm_mcux/build/zephyr/dts.cmake:7:set_target_properties(devicetree_target PROPERTIES "DT_CHOSEN|zephyr,code-cpu1-partition" "/soc/peripheral@50000000/flash-controller@34000/flash@0/partitions/partition@30000") ./samples/drivers/ipm/ipm_mcux/build/zephyr/zephyr.dts.pre:853: zephyr,code-cpu1-partition = &slot1_partition; ./samples/drivers/ipm/build/zephyr/zephyr.dts:13: zephyr,code-cpu1-partition = &slot1_partition; Binary file ./samples/drivers/ipm/build/zephyr/edt.pickle matches ./samples/drivers/ipm/build/zephyr/dts.cmake:7:set_target_properties(devicetree_target PROPERTIES "DT_CHOSEN|zephyr,code-cpu1-partition" "/soc/peripheral@50000000/flash-controller@34000/flash@0/partitions/partition@30000") ./samples/drivers/ipm/build/zephyr/zephyr.dts.pre:853: zephyr,code-cpu1-partition = &slot1_partition; ./soc/arm/nxp_lpc/lpc55xxx/Kconfig.soc:133:DT_CHOSEN_Z_CODE_CPU1_PARTITION := zephyr,code-cpu1-partition ted@localhost1:~/projects-sandbox/workspace-out-of-tree/zephyr$
File ./boards/arm/lpcxpresso55s69/lpcxpresso55s69_cpu0.dts:39 contains the following excerpted code:
17 cpus {
18 /delete-node/ cpu@1;
19 };
20
21 aliases{
22 sw0 = &user_button_1;
23 sw1 = &user_button_2;
24 sw2 = &user_button_3;
25 watchdog0 = &wwdt0;
26 /* For pwm test suites */
27 pwm-0 = &sc_timer;
28 pwm-led0 = &red_pwm_led;
29 red-pwm-led = &red_pwm_led;
30 sdhc0 = &sdhc0;
31 accel0 = &mma8652fc;
32 sdhc0 = &sdif;
33 };
34
35 chosen {
36 zephyr,sram = &sram0;
37 zephyr,flash = &flash0;
38 zephyr,code-partition = &slot0_partition;
39 zephyr,code-cpu1-partition = &slot1_partition;
40 zephyr,sram-cpu1-partition = &sram3;
41 zephyr,console = &flexcomm0;
42 zephyr,shell-uart = &flexcomm0;
43 zephyr,entropy = &rng;
44 };
Ahh and from this we see token `zephyr,sram-cpu1-partition` is not a device tree alias but rather a "Zephyr chosen". This looks like it may be similar to a device tree alias. Must confirm . . .
