Page History

Converting Legacy Configurations to Use kconfig-mconf

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 the make 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 name Make.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 the defconfig 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 old appconfig file was a series of lines like CONFIGURED_APPS += examples/hello. Each of these must be replaced with the corresponding configuration setting in the defconfig file. For the case of CONFIGURED_APPS += examples/hello, the correct setting is CONFIG_EXAMPLES_HELLO=y. Edit the old boards/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 old defconfig. 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 run tstit.sh again. Usually this consists of just removing all of the unnecessary settings in the old defconfig 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 called defconfig in your top level directory in the compressed defconfig format:

  make savdefconfig

• Then replace the boards/aaa/ccc/xxx/configs/yyy/defconfig with the newly created defconfig 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