> Rename Make.defs to Makefile To be clear, here I'm referring to ../boards/nucleo-f446re/src/Make.defs
On Thu, May 20, 2021 at 2:27 PM Abdelatif Guettouche <abdelatif.guettou...@gmail.com> wrote: > > I just copied the nucleo-fe446re board without the common directory. > > Here are the steps I took: > Add the correct custom board CONFIGs to nsh/defconfig (and remove some > of the old ones) > Rename Make.defs to Makefile > Add include $(TOPDIR)/boards/Board.mk to the end of the file. > > ./tools/configure.sh ../boards/nucleo-f446re/configs/nsh > make > > Builds fine. > > On Thu, May 20, 2021 at 2:14 PM Abdelatif Guettouche > <abdelatif.guettou...@gmail.com> wrote: > > > > (It looks like we dropped the list somehow, I'm bringing it back...) > > > > > There is no way this common file is going into my custom board. > > > > If you don't want it; just remove it. But you'll have to adapt your > > Make.defs file. Mainly adding "include $(TOPDIR)/boards/Board.mk" at > > the end. > > Other small things could be required. Adapt it from a different board > > that doesn't have a common directory, an STM32F7 for example, it will > > be simpler. > > > > > > On Thu, May 20, 2021 at 2:11 PM Sebastien Lorquet <sebast...@lorquet.fr> > > wrote: > > > > > > This entirely defeat the purpose of a custom board. > > > > > > There is no way this common file is going into my custom board. > > > > > > What to do? Do I need TWO custom dirs? One for the board and one for the > > > custom stuff? > > > > > > Sebastien > > > > > > Le 20/05/2021 à 15:08, Abdelatif Guettouche a écrit : > > > > It should then also be the same case as #2206, you'll need the common > > > > directory: > > > > https://github.com/apache/incubator-nuttx/issues/2206#issuecomment-721141748 > > > > > > > > For STM32 (and other chips that have the "common" directory > > > > structure), the stm32/board_dir/src/Make.defs file is not complete. > > > > It needs the stm32/common/Makefile in order to get everything hooked > > > > into the build system. > > > > > > > > On Thu, May 20, 2021 at 2:01 PM Sebastien Lorquet > > > > <sebast...@lorquet.fr> wrote: > > > >> It was the defconfig from nucleo-f446re:nsh, only modified to use a > > > >> custom board with relpath. > > > >> > > > >> The same failure happens with the stm32f427i-disco:nsh configuration. > > > >> > > > >> > > > >> I have the same issues as described in 2206 > > > >> > > > >> I have tried running: tools/configure.sh ../my_own_nucleo/configs/nsh > > > >> > > > >> And the log shows: > > > >> > > > >> LN: include/arch to arch/arm/include > > > >> LN: include/arch/board to > > > >> /home/slo/nut/nuttx/boards/arm/stm32/nucleo-f446re/include > > > >> LN: include/arch/chip to arch/arm/include/stm32 > > > >> LN: arch/arm/src/board to > > > >> /home/slo/nut/nuttx/boards/arm/stm32/nucleo-f446re/../common > > > >> LN: arch/arm/src/board/board to > > > >> /home/slo/nut/nuttx/boards/arm/stm32/nucleo-f446re/src > > > >> LN: arch/arm/src/chip to arch/arm/src/stm32 > > > >> LN: /home/slo/nut/nuttx/drivers/platform to > > > >> /home/slo/nut/nuttx/drivers/dummy > > > >> > > > >> and it builds, because it uses the original dev board > > > >> > > > >> So in fact using configure with a custom board path DOES NOT work. It > > > >> just configures whatever built in board is indicated in the config > > > >> file. > > > >> > > > >> Then I tried to change the board path using make menuconfig, then make > > > >> again, and then it stops building as before: '*** No rule to make > > > >> target 'libboard.a'.' > > > >> > > > >> Sebastien > > > >> > > > >> > > > >> Le 20/05/2021 à 13:44, Abdelatif Guettouche a écrit : > > > >>> Hi, > > > >>> > > > >>> Is it possible to share the defconfig? I just tried with an old one > > > >>> (based on STM32) and I have a clean build. > > > >>> The relevant configs that need to be correctly set are: > > > >>> CONFIG_ARCH_BOARD_CUSTOM=y > > > >>> CONFIG_ARCH_BOARD_CUSTOM_DIR="../boards/stm32/board-dir" > > > >>> CONFIG_ARCH_BOARD_CUSTOM_DIR_RELPATH=y > > > >>> CONFIG_ARCH_BOARD_CUSTOM_NAME="Custom-STM32-Board" > > > >>> > > > >>> On Thu, May 20, 2021 at 10:47 AM Sebastien Lorquet > > > >>> <sebast...@lorquet.fr> wrote: > > > >>>> Hello, > > > >>>> > > > >>>> I have to update the nuttx in our project from pre-apache to last > > > >>>> version. > > > >>>> > > > >>>> We would like to use the external board feature. > > > >>>> > > > >>>> As a test I copied the nucleo-f446re folder in boards/arm to > > > >>>> somewhere > > > >>>> else (sibling to apps and nuttx), renamed it, and pointed to it in > > > >>>> the > > > >>>> configuration. make menuconfig was happy with that. > > > >>>> > > > >>>> However the build fails: > > > >>>> > > > >>>> IN: fs/libfs.a -> staging/libfs.a > > > >>>> make[1]: Entering directory '/home/slo/nut/nuttx/binfmt' > > > >>>> CC: binfmt_globals.c > > > >>>> CC: binfmt_initialize.c > > > >>>> CC: binfmt_register.c > > > >>>> CC: binfmt_unregister.c > > > >>>> CC: binfmt_loadmodule.c > > > >>>> CC: binfmt_unloadmodule.c > > > >>>> CC: binfmt_execmodule.c > > > >>>> CC: binfmt_exec.c > > > >>>> CC: binfmt_copyargv.c > > > >>>> CC: binfmt_dumpmodule.c > > > >>>> CC: builtin.c > > > >>>> AR (create): libbinfmt.a binfmt_globals.o binfmt_initialize.o > > > >>>> binfmt_register.o binfmt_unregister.o binfmt_loadmodule.o > > > >>>> binfmt_unloadmodule.o binfmt_execmodule.o binfmt_exec.o > > > >>>> binfmt_copyargv.o binfmt_dumpmodule.o builtin.o > > > >>>> make[1]: Leaving directory '/home/slo/nut/nuttx/binfmt' > > > >>>> IN: binfmt/libbinfmt.a -> staging/libbinfmt.a > > > >>>> make[1]: Entering directory '/home/slo/nut/nuttx/arch/arm/src' > > > >>>> make[2]: Entering directory '/home/slo/nut/my_own_nucleo/src' > > > >>>> make[2]: *** No rule to make target 'libboard.a'. Stop. > > > >>>> make[2]: Leaving directory '/home/slo/nut/my_own_nucleo/src' > > > >>>> make[1]: *** [Makefile:152: board/libboard.a] Error 2 > > > >>>> make[1]: Leaving directory '/home/slo/nut/nuttx/arch/arm/src' > > > >>>> make: *** [tools/Makefile.unix:422: nuttx] Error 2 > > > >>>> > > > >>>> Looks like a Makefile (or just a rule) is missing. Is it a bug in > > > >>>> this > > > >>>> board/arch or in my own method or a problem in the external board > > > >>>> build > > > >>>> system? > > > >>>> > > > >>>> I'm using a relative board path. > > > >>>> > > > >>>> I'll add a github issue when the problem is understood. > > > >>>> > > > >>>> Sebastien > > > >>>>
