Recommended configuration practices question
Hi, I started testing NuttX on Raspberry Pi Pico board, using FreeBSD as host for building. I was able to build NuttX using all configuration files for this board (but one - nshsram, it does not finish, but I don't care about it for now). All those configurations use default UART placement (pins 0, 1). These pins are not available on 01space board RP2040-0.42LCD, so I changed UART placement to pins 28, 29 running 'make menuconfig'. This way, .config in NuttX working/build directory is modified, and resulting binary (or uf2 for this board) file works as expected. This file, however, gets deleted when running 'make distclean' for different build. Thus I run 'make savedefconfig', altering defconfig file in working directory. This gets deleted on 'make distclean' as well, so I manually created new directory, where I copied defconfig file - boards/arm/rp2040/raspberrypi-pico/configs/nsh_28_29, and now my config is listed in 'tools/configure.sh -L' output, so I can use it as any other config file. So my questions now - is this intended way for saving and reusing config file? While it works for me, I'd like to have my configs separated from standard source files, maybe as third parallel directory to standard nuttx and apps, with ability to see them in 'tools/configure.sh -L' output, and using my configuration with 'tools/configure.sh '. Any hints for this one? Regards, Milan
Re: Recommended configuration practices question
On Fri, May 19, 2023 at 2:24 PM Milan Obuch wrote: > > Hi, > > I started testing NuttX on Raspberry Pi Pico board, using FreeBSD as > host for building. I was able to build NuttX using all configuration > files for this board (but one - nshsram, it does not finish, but I > don't care about it for now). All those configurations use default UART > placement (pins 0, 1). > > These pins are not available on 01space board RP2040-0.42LCD, so I > changed UART placement to pins 28, 29 running 'make menuconfig'. This > way, .config in NuttX working/build directory is modified, and > resulting binary (or uf2 for this board) file works as expected. > > This file, however, gets deleted when running 'make distclean' for > different build. Thus I run 'make savedefconfig', altering defconfig > file in working directory. This gets deleted on 'make distclean' as > well, so I manually created new directory, where I copied defconfig > file - boards/arm/rp2040/raspberrypi-pico/configs/nsh_28_29, and now my > config is listed in 'tools/configure.sh -L' output, so I can use it as > any other config file. > > So my questions now - is this intended way for saving and reusing > config file? While it works for me, I'd like to have my configs > separated from standard source files, maybe as third parallel directory > to standard nuttx and apps, with ability to see them in > 'tools/configure.sh -L' output, and using my configuration with > 'tools/configure.sh '. > > Any hints for this one? Hey there Milan my fellow BSD daemon :-) :-) I am also working that way.. because nuttx and nuttx-apps are git submodules of my project repo and I want to work on a release and this is the cleanest way to maintain. Also I have a custom board. I keep my custom application and board definition outside those two release directories according to these hints: https://nuttx.apache.org/docs/latest/guides/customboards.html https://nuttx.apache.org/docs/latest/guides/customapps.html You can create your own board definition based on existing board definition, just copy whole directory, update names, and update required pin definitions. If the board differs a lot and it is not yet in the upstream you can send a PR so everyone also can use it :-) Note that board is just kind of description and setup of the "hardware product", while all common code resides in the arch/ (MCU with internal peripherals) and drivers/ (external peripherals onboard). https://github.com/apache/nuttx/tree/master/arch https://github.com/apache/nuttx/tree/master/drivers Here is the full description of the directory structure: https://nuttx.apache.org/docs/latest/quickstart/organization.html I noticed that some boards definitions are more kind of template rather than ready for use fully featured setups (i.e. devkits with not much peripherals onboard). User needs to adapt these boards configuration for particular needs. I guess this was done so far directly in the source code. But with custom board approach you can just copy selected board config and update it as you wish. Hope that helps :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
Re: Recommended configuration practices question
On Fri, May 19, 2023 at 8:24 AM Milan Obuch wrote: > Hi, > > I started testing NuttX on Raspberry Pi Pico board, using FreeBSD as > host for building. I was able to build NuttX using all configuration > files for this board (but one - nshsram, it does not finish, but I > don't care about it for now). All those configurations use default UART > placement (pins 0, 1). > > These pins are not available on 01space board RP2040-0.42LCD, so I > changed UART placement to pins 28, 29 running 'make menuconfig'. This > way, .config in NuttX working/build directory is modified, and > resulting binary (or uf2 for this board) file works as expected. > > This file, however, gets deleted when running 'make distclean' for > different build. Thus I run 'make savedefconfig', altering defconfig > file in working directory. This gets deleted on 'make distclean' as > well, so I manually created new directory, where I copied defconfig > file - boards/arm/rp2040/raspberrypi-pico/configs/nsh_28_29, and now my > config is listed in 'tools/configure.sh -L' output, so I can use it as > any other config file. > > So my questions now - is this intended way for saving and reusing > config file? While it works for me, I'd like to have my configs > separated from standard source files, maybe as third parallel directory > to standard nuttx and apps, with ability to see them in > 'tools/configure.sh -L' output, and using my configuration with > 'tools/configure.sh '. > > Any hints for this one? > > Regards, > Milan There are various possibilities: After running 'make savedefconfig' you would normally want to copy the resulting defconfig file somewhere. You could copy it to a new config under the board in question, and if you feel this configuration could be helpful to the wider community, you could opt to open a PR to upstream it. Or you could create your own variant of the board by copying the whole board directory and then customizing it. The copy could be in-tree (in boards/arm64/) or out-of-tree (leaving the nuttx sources alone and putting your board in another directory, which you can specify). This option (copying the whole board directory) makes sense if you want to customize more than just the config and don't plan to upstream your customizations. As a side note, if you are customizing any in-tree nuttx sources, it's probably a good idea to create your own long-lived branch, keep your master branch up-to-date with upstream, add your customizations to your private branch, and occasionally merge updates from master into your branch. Or you could base your branch off of a release tag if you prefer to use released versions. Hope this helps, Nathan
Re: Recommended configuration practices question
On 5/19/23, Nathan Hartman wrote: > On Fri, May 19, 2023 at 8:24 AM Milan Obuch wrote: > >> Hi, >> >> I started testing NuttX on Raspberry Pi Pico board, using FreeBSD as >> host for building. I was able to build NuttX using all configuration >> files for this board (but one - nshsram, it does not finish, but I >> don't care about it for now). All those configurations use default UART >> placement (pins 0, 1). >> >> These pins are not available on 01space board RP2040-0.42LCD, so I >> changed UART placement to pins 28, 29 running 'make menuconfig'. This >> way, .config in NuttX working/build directory is modified, and >> resulting binary (or uf2 for this board) file works as expected. >> >> This file, however, gets deleted when running 'make distclean' for >> different build. Thus I run 'make savedefconfig', altering defconfig >> file in working directory. This gets deleted on 'make distclean' as >> well, so I manually created new directory, where I copied defconfig >> file - boards/arm/rp2040/raspberrypi-pico/configs/nsh_28_29, and now my >> config is listed in 'tools/configure.sh -L' output, so I can use it as >> any other config file. >> >> So my questions now - is this intended way for saving and reusing >> config file? While it works for me, I'd like to have my configs >> separated from standard source files, maybe as third parallel directory >> to standard nuttx and apps, with ability to see them in >> 'tools/configure.sh -L' output, and using my configuration with >> 'tools/configure.sh '. >> >> Any hints for this one? >> >> Regards, >> Milan > > > > There are various possibilities: > > After running 'make savedefconfig' you would normally want to copy the > resulting defconfig file somewhere. > I think we need a better Documentation about it. Reading Milan's question makes it clean that the information is missing. In fact searching for savedefconfig in our documentation returns nothing: https://nuttx.apache.org/docs/latest/search.html?q=savedefconfig&check_keywords=yes&area=default# Do you have suggestion there in the documentation we could put it? I think we could have a "Creating my custom configuration" in the Getting Started, or maybe we could create a main entry "Developing with NuttX" and include it. Also it is important to explain that this defconfig is used to create a board profile, then you can use with configure.sh boardname:boardprofile > You could copy it to a new config under the board in question, and if you > feel this configuration could be helpful to the wider community, you could > opt to open a PR to upstream it. > Been more clear and more didactic: After running "make savedefconfig" you can create a directory inside your board config that will retain your config customization: $ make savedefconfig $ mkdir boardsconfig/mynewcustomconfig $ mv defconfig boardsconfig/mynewcustomconfig/ > Or you could create your own variant of the board by copying the whole > board directory and then customizing it. The copy could be in-tree (in > boards/arm64/) or out-of-tree (leaving the nuttx sources alone and > putting your board in another directory, which you can specify). This > option (copying the whole board directory) makes sense if you want to > customize more than just the config and don't plan to upstream your > customizations. > This is a good option! Mainly when you have a board that is not in the mainline, your a personal board that will not be accepted on mainline. Normally all boards in the mainline need to be available to the public, if it is a personal board it should be kept in your local repository. > As a side note, if you are customizing any in-tree nuttx sources, it's > probably a good idea to create your own long-lived branch, keep your master > branch up-to-date with upstream, add your customizations to your private > branch, and occasionally merge updates from master into your branch. Or you > could base your branch off of a release tag if you prefer to use released > versions. > Thank is also a great suggestion! We need to have it documented to avoid spending time saying it again and again! :-) BR, Alan
