The New kconfig-frontends Configuration
NuttX has recently completed the switch a purely manual configuration to the use of the kconfig-frontends tools. These are the same tools used to configure the Linux kernel, uClibc, busybox, buildroot, and numerous other packages.
- The website for the kconfig-frontends is here: http://ymorin.is-a-geek.org/projects/kconfig-frontends
.
- A modified version of kconfig-frontends for Windows is here: https://github.com/uvc-ingenieure/kconfig-frontends
- There are some general usage notes in the top-level README.txt file.
- There are some build instructions in the GIT repository as well.
This Wiki page addresses the conversion of the legacy configurations to use the kconfig-frontends tools. Unfortunately, the legacy configurations are not compatible with the new, kconfig-frontends configurations. In fact, if you use the kconfig-frontends tools with the legacy the resulting configuration will be damaged and probably will not work correctly for you.
All of the boards in the NuttX source tree have been converted to use the new configuration based on the kconfig-frontends tools. If, however, you have a private configuration for your board that uses the older configuration, you will need to convert that configuration to the newer configuration format if you would like the use the newer releases of NuttX.
Differences between the Legacy Configurations and the kconfig-frontends Configurations
The legacy configurations consisted of three files:
- A
defconfig
file that contained the configuration of NuttX. This file is a compressed configurations file. It was copied to the top-level NuttX directory as.config
during the configuration process, then regenerated using themake olddefconfig
command. - An
appconfig
file that contained the configuration of the NuttX applications (usually at../apps
). This file was copied into the top-level application directory as.config
. - A
Make.defs
file that contained build instructions for the make system. This file was copied to the top-level NuttX directory, retaining its nameMake.defs
.
The new, kconfig-frontends configurations differ in the following ways:
- There is no
appconfig
file. The configuration of the applications is now included in thedefconfig
file. This difference is necessary to support a seamless configuration of NuttX and the associated applications. - In the automated configuration, there are many new configuration settings that are required but that do nothing in NuttX. These new configuration settings only enable additional menus and are only necessary to provide a good user experience when running the configuration tool. However, these do-nothing settings will not be set in the legacy configuration and that is why the legacy configurations will be corrupted if
make menuconfig
is used without first converting the legacy configuration to use the kconfig-frontends tools.
Converting Legacy Configurations to Use kconfig-mconf
Here are the steps I use to convert a legacy configuration to use the kconfig-frontends tools. The whole process requires around 20 minutes (but could take longer if you unfamiliar with NuttX).
- First, I build the
tools/cmpconfig
utility. This is a small program that can be used to compare two configurations. This is done by simply executing:
cd nuttx/tools make -f Makefile.host cmpconfig
I use this cmpconfig
tool to perform repetitive comparisons between the new candidate configuration and existing configuration. Since I will do this multiple times, I usually create two tiny scripts to make life easier:
tstit.sh
will copy the defconfig
file and then do make menuconfig
. This little script might look like the following (where xxx
and yyy
are the board and the configuration that you are converting, aaa
is the architecture of the chip, and ccc
is the chip name):
#!/bin/sh cp boards/aaa/ccc/xxx/configs/yyy/defconfig .config make menuconfig
And cmpit.sh
which will compare the new, candidate configuration with old, legacy configuration. NOTE that the NuttX defconfig
files are in a compressed format but the .config
file is in an uncompressed format. In this case, we are assuming that your old defconfig
file is a manually created file in the uncompressed .config
format and so can be compared with tools/cmpconfig
:
#!/bin/sh tools/cmpconfig boards/aaa/ccc/xxx/configs/yyy/defconfig defconfig
Back to the conversion:
- Then I look at the old
boards/aaa/ccc/xxx/configs/yyy/appconfig
file. The format of the oldappconfig
file was a series of lines likeCONFIGURED_APPS += examples/hello
. Each of these must be replaced with the corresponding configuration setting in thedefconfig
file. For the case ofCONFIGURED_APPS += examples/hello
, the correct setting isCONFIG_EXAMPLES_HELLO=y
. Edit the oldboards/aaa/ccc/xxx/configs/yyy/defconfig
and add this setting manually.
Most of the conversions between CONFIGURED_APPS
paths and configuration settings are pretty obvious. The general name rule is: CONFIGURED_APPS += aaa/bbb
will become CONFIG_AAA_BBB=y
. One exception to this rule is CONFIGURED_APPS += nshlib
which needs to become CONFIG_NSH_LIBRARY=y
.
Then begins the iterative steps:
- Run
tstit.sh
. When the configuration menus come up, do nothing except exit and save the new configuration. - Run
cmpit.sh | grep file1
. This will show you all of the definitions in the original, legacy configuration that do not appear in the new, candidate configuration. Each of these is a mini-research project! Most legacy configurations contain many definitions that do nothing. As examples, networking may be disabled but all of the network settings may still be present in the olddefconfig
. USB may be disabled, but all of the USB settings may still be present. Priority inheritance will be disabled by settings related to priority inheritance may still be defined. etc. - Edit
boards/aaa/ccc/xxx/configs/yyy/defconfig
to eliminate the difference and runtstit.sh
again. Usually this consists of just removing all of the unnecessary settings in the olddefconfig
file.
Iterate the above until cmpit.sh | grep file1
indicates there are no definitions in the original defconfig
that do not also appear in the new .config
file. Then perform one final check:
- Run
cmpit.sh | grep file2
. This will show you all of the new definitions that will be added to the configuration file. There will be quite a few. Just review them and make sure that nothing really crazy got added. - Then create the new
defconfig
file. To do this, you must use this special makefile target. This will generate a new file calleddefconfig
in your top level directory in the compresseddefconfig
format:
make savdefconfig
- Then replace the
boards/aaa/ccc/xxx/configs/yyy/defconfig
with the newly createddefconfig
file. - Remove the old, now unused
boards/aaa/ccc/xxx/configs/yyy/appconfig
file.
Then you need to test the new configuration. Build it like this (on Linux, Cygwin or MSYS. The configure and build steps differ slightly for the native Windows build):
tools/configure.sh xxx:yyy make
Before entering the make
command, make sure that your PATH
environment variable includes the full path to the directory containing the toolchain binaries. Otherwise, the make will be unable to find the compiler and related tools.
If the new configuration builds and behaves as did the old configuration, you are done. Congratulations!
Frequent differences in the configuration and how to fix them
CONFIG_NSH_CONSOLE
You will see this warning:
file1: CONFIG_NSH_CONSOLE=y
Just confirm your defconfig has this define:
CONFIG_NSH_LIBRARY=y
CONFIG_EXAMPLES_NSH_CXXINITIALIZE
You will see this warning:
file1: CONFIG_EXAMPLES_NSH_CXXINITIALIZE=y
Just confirm your defconfig has this define:
CONFIG_EXAMPLES_NSH=y
CONFIG_EXAMPLES_UIP_DRIPADDR
You will see this warning:
file1: CONFIG_EXAMPLES_UIP_DRIPADDR=0x0a000001
Just confirm you have enabled it:
CONFIG_EXAMPLES_UIP=y
CONFIG_MMCSD_SDIO
You will see this warn:
file1: CONFIG_MMCSD_SDIO=y
This define is configured automatically by ARCH_HAVE_SDIO then for STM32 you need to define it:
CONFIG_STM32_SDIO=y
CONFIG_MMCSD_SPI
You will see this warnning:
file1: CONFIG_MMCSD_SPI=y
Just confirm at least one SPI is configured for your arch. Examples for STM32:
CONFIG_STM32_SPI1=y
CONFIG_PL2303_EPBULKIN
You will see this warning message:
file1: CONFIG_PL2303_EPBULKIN=3
Just confirm USB Device is enabled:
CONFIG_USBDEV=y
Case it is not enabled it is safe to remove these CONFIG_PL2303_xxxxx lines.
CONFIG_USBDEV_MAXPOWER
You will see this warning message:
file1: CONFIG_USBDEV_MAXPOWER=100
Just confirm USB Device is enabled:
CONFIG_USBDEV=y
Case it is not enable it is safe to remove all these CONFIG_USBDEV_xxxxx lines.
CONFIG_USBMSC_BULKINREQLEN
You will see this warning message:
file1: CONFIG_USBMSC_BULKINREQLEN=256
Just confirm that USB Mass Storage is enabled:
CONFIG_USBMSC=y
Case it is not enabled it is safe to remove all these CONFIG_USBMSC_xxxxx lines.
CONFIG_RTC_FREQUENCY
You will see this warning message:
file1: CONFIG_RTC_FREQUENCY=1
Just confirm that RTC Date/Time is not enable (CONFIG_RTC_DATETIME=n) and high resolution support is enabled:
CONFIG_RTC_DATETIME=n CONFIG_RTC_HIRES=y
Case RTC Date/Time it is enabled (CONFIG_RTC_DATETIME=y) and high resolution is disabled (CONFIG_RTC_HIRES=n) then it is safe to remove this CONFIG_RTC_FREQUENCY lines. If RTC is disabled (CONFIG_RTC=n) it is safe to remove all these CONFIG_RTC_xxxxx lines.
CONFIG_SCHED_WORKPERIOD
You will see this warning message:
file1: CONFIG_SCHED_WORKPERIOD=50000
Just verify if Schedule Workquee is disabled:
CONFIG_SCHED_WORKQUEUE=n
If so, then it is safe to remove this CONFIG_SCHED_WORKPERIOD line. Case Schedule Workqueue is enabled, then High Priority Workqueue needs to be enabled:
CONFIG_SCHED_HPWORK=y
CONFIG_SEM_NNESTPRIO
You will receive this warning message:
file1: CONFIG_SEM_NNESTPRIO=0
Just confirm if Priority Inheritance is disabled:
CONFIG_PRIORITY_INHERITANCE=n
Case it is disabled it is safe to remove this CONFIG_SEM_NNESTPRIO line.
CONFIG_SIG_SIGWORK
You will receive this warning message:
CONFIG_SIG_SIGWORK=17
Just verify if Schedule Workquee is disabled:
CONFIG_SCHED_WORKQUEUE=n
If so, then it is safe to remove this CONFIG_SIG_SIGWORK line.
CONFIG_NSH_TELNET
If you are receiving this warning:
file1: CONFIG_NSH_TELNET=y
Confirm if you remembered to enable telnetd:
CONFIG_NETUTILS_TELNETD=y
CONFIG_NSH_IOBUFFER_SIZE=512
You will see this warning message:
file1: CONFIG_NSH_IOBUFFER_SIZE=512
Just confirm that telnet is defined (CONFIG_NSH_TELNET=y). If telnet is defined then confirm telned is defined too (CONFIG_NETUTILS_TELNETD=y). If telnet is not defined it is safe to remove this line.
CONFIG_LCD_NOGETRUN
You will see this warning message:
file1: CONFIG_LCD_NOGETRUN=y
First you need to confirm that LCD is enable (CONFIG_LCD=y) otherwise just remove this line.
CONFIG_EXAMPLES_NXHELLO_BGCOLOR
Sometimes cmpfile will warn about BGCOLOR:
file1: CONFIG_EXAMPLES_NXHELLO_BGCOLOR=0x0011
First you need verify if NX is disabled ("CONFIG_NX=n" or no reference to CONFIG_NX). Case it is disabled then the right thing to do is remove this CONFIG_EXAMPLES_NXHELLO_BGCOLOR line. Case it is defined ("CONFIG_NX=y") then this warning message is happening because CONFIG_EXAMPLES_NXHELLO_DEFAULT_COLORS is defined by default which will ignore your BGCOLOR.
To fix it just add this definition before your BGCOLOR:
CONFIG_EXAMPLES_NXHELLO_DEFAULT_COLORS=n
CONFIG_EXAMPLES_NXHELLO_FONTID
Sometimes cmpfile will warn about FONTID:
CONFIG_EXAMPLES_NXHELLO_FONTID=6
To fix it just add this definition before FONTID:
CONFIG_EXAMPLES_NXHELLO_DEFAULT_FONT=n