On 5/19/23, Nathan Hartman <hartman.nat...@gmail.com> wrote: > On Fri, May 19, 2023 at 8:24 AM Milan Obuch <nuttx-...@dino.sk> 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 <my_config>'. >> >> 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 boards/<archname>/<chipname>/<boardname>/config/mynewcustomconfig $ mv defconfig boards/<archname>/<chipname>/<boardname>/config/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/xxxx) 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
