Re: [riot-devel] Issue with implementation of multiple boards in one directory
Hi, I think the question is what mapping you want to have between a board (the physical hardware) and a RIOT board. If the mapping should be 1:1, than one physical board could have different CPUs and configurations. If you however agree with a 1:n mapping, than having different RIOT boards for each configuration of a board is fine. With the issues you presented in mind, I'd say a 1:n mapping might be the solution with the least maintenance overhead, provided that `boards/common` is heavily used to avoid duplication. Kind regards, Marian On Mon, 26 Aug 2019 15:34:30 +0200 Bas Stottelaar wrote: > Hi Gaëten, > > BOARD_MODULE is used by the Silicon Labs SLWSTK6000b because it is one board > with many supported CPU daughter boards (different CPU, other radio configs). > You would buy that board, but also need to buy this daughter board separately. > > A similar approach is used by the EFM32 CPU family. The (incomplete) list of > daughter boards is here: > https://github.com/RIOT-OS/RIOT/blob/master/boards/slwstk6000b/modules.txt > > Kind regards, > Bas > > > Op 26 aug. 2019 om 14:41 heeft Gaëtan Harter > > het volgende geschreven: > > > > Dear RIOT developers, > > > > as part of migrating CPU and CPU_MODEL definition to `Makefile.features` I > > am facing custom handling of multiple boards in the same directory with > > sometime creative handling but not a proper build system integration. > > > > There are multiple issues with this: > > * none of the alternative boards are ever be compiled in the CI > > * when testing, giving multiple variables to specify a board is not really > > handled > > * building the separate boards is not handled with `BUILD_IN_DOCKER` > > * custom non standard configuration variables that are not properly handled > > in the whole build system > > > > The current implementation are currently done through: > > > > * Using a default `CPU_MODEL ?= default_model` however the `CPU_MODEL` > > variable is not passed to docker > > * mulle (2 possibilities) > > * pba-d-01-kw2x (3 possibilities) > > * cc2538dk (no documentation but I think this one is just a mis-write and > > not a wanted thing) > > * Using a `STM32F103C8_FLASH_HACK` variable to just set a different > > `CPU_MODEL`. It applies to `bluepill` and `blackpill` but is just > > documented for the `bluepill` > > * An undocumented `BOARD_MODULE` variable that triggers a wildcard then a > > grep to find `CPU_MODEL` (yes it queries your filesystem for a static > > mapping). Its generic with many possible values but only implemented for 2 > > "board modules" > > > > I would like to know who really uses these boards modifications, and what > > we should do with them. Why were they implemented in the first place > > instead of having separate boards? Would have prevented having them merged? > > > > Should we just split all these boards, it would currently result in 5 or 6 > > boards (depending on the blackpill). > > > > Should we keep support for multiple boards together? if yes, can we limit > > to only changing `CPU_MODEL` through this variable and remove the other > > custom handling? Still knowing they would not be automatically tested by CI. > > > > I am willing to take care of the required changes when a direction is > > decided. > > > > Regards, > > Gaëtan - cladmi > > ___ > > devel mailing list > > devel@riot-os.org > > https://lists.riot-os.org/mailman/listinfo/devel pgpBuYZdn2LCd.pgp Description: OpenPGP digital signature ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Issue with implementation of multiple boards in one directory
Hi Gaëten, BOARD_MODULE is used by the Silicon Labs SLWSTK6000b because it is one board with many supported CPU daughter boards (different CPU, other radio configs). You would buy that board, but also need to buy this daughter board separately. A similar approach is used by the EFM32 CPU family. The (incomplete) list of daughter boards is here: https://github.com/RIOT-OS/RIOT/blob/master/boards/slwstk6000b/modules.txt Kind regards, Bas > Op 26 aug. 2019 om 14:41 heeft Gaëtan Harter het > volgende geschreven: > > Dear RIOT developers, > > as part of migrating CPU and CPU_MODEL definition to `Makefile.features` I am > facing custom handling of multiple boards in the same directory with sometime > creative handling but not a proper build system integration. > > There are multiple issues with this: > * none of the alternative boards are ever be compiled in the CI > * when testing, giving multiple variables to specify a board is not really > handled > * building the separate boards is not handled with `BUILD_IN_DOCKER` > * custom non standard configuration variables that are not properly handled > in the whole build system > > The current implementation are currently done through: > > * Using a default `CPU_MODEL ?= default_model` however the `CPU_MODEL` > variable is not passed to docker > * mulle (2 possibilities) > * pba-d-01-kw2x (3 possibilities) > * cc2538dk (no documentation but I think this one is just a mis-write and > not a wanted thing) > * Using a `STM32F103C8_FLASH_HACK` variable to just set a different > `CPU_MODEL`. It applies to `bluepill` and `blackpill` but is just documented > for the `bluepill` > * An undocumented `BOARD_MODULE` variable that triggers a wildcard then a > grep to find `CPU_MODEL` (yes it queries your filesystem for a static > mapping). Its generic with many possible values but only implemented for 2 > "board modules" > > I would like to know who really uses these boards modifications, and what we > should do with them. > Why were they implemented in the first place instead of having separate > boards? Would have prevented having them merged? > > Should we just split all these boards, it would currently result in 5 or 6 > boards (depending on the blackpill). > > Should we keep support for multiple boards together? if yes, can we limit to > only changing `CPU_MODEL` through this variable and remove the other custom > handling? Still knowing they would not be automatically tested by CI. > > I am willing to take care of the required changes when a direction is decided. > > Regards, > Gaëtan - cladmi > ___ > devel mailing list > devel@riot-os.org > https://lists.riot-os.org/mailman/listinfo/devel ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] Issue with implementation of multiple boards in one directory
Dear RIOT developers, as part of migrating CPU and CPU_MODEL definition to `Makefile.features` I am facing custom handling of multiple boards in the same directory with sometime creative handling but not a proper build system integration. There are multiple issues with this: * none of the alternative boards are ever be compiled in the CI * when testing, giving multiple variables to specify a board is not really handled * building the separate boards is not handled with `BUILD_IN_DOCKER` * custom non standard configuration variables that are not properly handled in the whole build system The current implementation are currently done through: * Using a default `CPU_MODEL ?= default_model` however the `CPU_MODEL` variable is not passed to docker * mulle (2 possibilities) * pba-d-01-kw2x (3 possibilities) * cc2538dk (no documentation but I think this one is just a mis-write and not a wanted thing) * Using a `STM32F103C8_FLASH_HACK` variable to just set a different `CPU_MODEL`. It applies to `bluepill` and `blackpill` but is just documented for the `bluepill` * An undocumented `BOARD_MODULE` variable that triggers a wildcard then a grep to find `CPU_MODEL` (yes it queries your filesystem for a static mapping). Its generic with many possible values but only implemented for 2 "board modules" I would like to know who really uses these boards modifications, and what we should do with them. Why were they implemented in the first place instead of having separate boards? Would have prevented having them merged? Should we just split all these boards, it would currently result in 5 or 6 boards (depending on the blackpill). Should we keep support for multiple boards together? if yes, can we limit to only changing `CPU_MODEL` through this variable and remove the other custom handling? Still knowing they would not be automatically tested by CI. I am willing to take care of the required changes when a direction is decided. Regards, Gaëtan - cladmi ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
