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 <basstottel...@gmail.com> 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 <gaetan.har...@fu-berlin.de> > > 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
