Skip to content

boards: concept for defining board revisions #7975

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
wants to merge 4 commits into from
Closed

boards: concept for defining board revisions #7975

wants to merge 4 commits into from

Conversation

haukepetersen
Copy link
Contributor

based on #7973 (which is a trivial minimal cleanup thing)

This PR is meant to quickly demonstrate an idea I had this morning, possibly enabling us to prevent some code duplication in the future: The idea is to introduce a revision number/value for boards, enabling us to cope better with these minimal changes/impacts that board revisions have on the actual board code/configuration.

Rationale: When developing hardware, a board goes typically through a number of (development) revisions, until the design is considered stable/working. The changes between these revisions are from a software perspective mostly very small (changed pin mappings, oscillators, or maybe different radio, etc). It would be nice to model these revisions in software to be able to quickly adapt and maintain code with not much overhead.

As of now, we keep separate board folders for every board revision (e.g. remote reva, revb, pa). Or alternatively we drop (early) development revisions completely and only support the (stable/latest) revision of a certain board (as just done for the calliope-mini), but this approach makes it pretty cumbersome to keep on using the old hardware revisions (which is sometimes a shame).

So this PR presents an idea for using BOARDREV as board revision specifier, enabling us to specify not only the board to build for, but also a specific revision. So for example one can do now:

BOARD=msb-430 BOARDREV=h make all ...
BOARD=msb-430 BOARDREV=plain make all ...
BOARD=msb-430 make all ... (defaults to 'plain' msb-340)
or
BOARD=wsn430 BOARDREV=1v3b make all ...
BOARD=wsn430 BOARDREV=1v4 make all ... 
BOARD=wsn430 make ... (defaults to '1v4')

The board revision can for each board of course be set to a default value (typically the newest revision), or a board implementation could throw an error if none is set. For boards without revisions the variable is just ignored, so nothing changes for them.

Open issues / questions to answer:

  • Error handling in case given revision is invalid: build process should terminate with errer
  • The CI needs adaption: need to find a way for info-boards-supported to list revisions somehow?!
  • Maybe some other name is better suited then BOARDREV? Shoul we use something more generic like BOARDFLAVOR or BOARDSPEC? Idea is to use the same concept for boards that are similar but not really revisions of each other -> nucleos:
BOARD=nucleo32 BOARDREV=l159 make ...
BOARD=nculeo32 BOARDREV=f411 make ...
BOARD=nucleo144 BOARDREF=f746 make ...

@haukepetersen haukepetersen added Area: boards Area: Board ports Area: build system Area: Build system Discussion: RFC The issue/PR is used as a discussion starting point about the item of the issue/PR State: WIP State: The PR is still work-in-progress and its code is not in its final presentable form yet labels Nov 9, 2017
@haukepetersen haukepetersen mentioned this pull request Nov 9, 2017
Closed
@PeterKietzmann
Copy link
Member

@x3ro might be interested

@kaspar030
Copy link
Contributor

Maybe some other name is better suited then BOARDREV? Shoul we use something more generic like BOARDFLAVOR or BOARDSPEC?

How about BOARD_VARIANT?

@haukepetersen
Copy link
Contributor Author

How about BOARD_VARIANT?

It like music :-) Maybe not quite, but I like it.

Anyway, I think the wording question is only secondary for now. First of all:

  • do we all agree, that introducing a concept for variants is a good idea?
  • does anyone see a (possible simple) way, to enable Murdock to build not only the straight list of boards but also all variants of a board? If we can't make this work efficiently, this might be a show-stopper...

@haukepetersen
Copy link
Contributor Author

Side note: from a user perspective, we might event make the variant selection completely transparent making use of alias names (#7976), e.g.:

ALIAS.wsn430-v1_4       = wsn430
VARIANT.wsn430-v1_4     = 1v4
ALIAS.wsn430-v1_3b      = wsn430
VARIANT.wsn430-v1_3b    = 1v3b
ALIAS.remote-reva       = remote
VARIANT.remote-reva     = reva

ALIAS_TARGET := $(ALIAS.$(BOARD))
ifneq (,$(ALIAS_TARGET))
  override BOARD = $(ALIAS_TARGET)
endif
VARIANT_TARGET := $(VARIANT,$(BOARD))
ifneq (,$(VARIANT_TARGET))
  override BOARD_VARIANT := $(VARIANT_TARGET)
endif

@cladmi
Copy link
Contributor

cladmi commented Nov 10, 2017

Some care should be taken to differentiate board revision and boards that have a lot in common.

Because for wsn430 boards, even if they are called 1.3 and 1.4 they are two different boards with different radios and existed and still both exist and are deployed in IoT-LAB. The "version number" is just a bad naming convention.
The first is the 860MHz version with a highly configurable radio and the other one a 2.4 GHz version.

Are both boards revisions "compatible" enough to be abstracted. If at some point, examples need to test for a board variant, I think we lost.

@haukepetersen
Copy link
Contributor Author

I think that is something we need to define: do we want to abstract revisions (e.g. calliope-mini 0.3 vs 1.0), or are we taking this rather from a software point of view (hence variants) where we simply say: if the code is very similar, make them variants of each other (this would apply to the wsn430). I tend to the latter...

Are both boards revisions "compatible" enough to be abstracted. If at some point, examples need to test for a board variant, I think we lost.

No sure I understand this point correctly. But to make it clear: the CI MUST always build/test all available variants/revisions!

This was referenced Nov 15, 2017
Closed
Closed
@cladmi
Copy link
Contributor

cladmi commented Nov 16, 2017

Is the goal to use the revision be a high level thing, to simplify user life (at APPLICATION configuration /command line parsing time) or for the developer to write boards support ?

Because its two different things, and requires two different ways of solving it.
One is public, the other one is internal only.

This was referenced Nov 16, 2017
Merged
Closed
@haukepetersen
Copy link
Contributor Author

will not pursue this any longer, reopen at will...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees

@cladmi cladmi

@jnohlgard jnohlgard

@miri64 miri64

@aabadie aabadie

@kaspar030 kaspar030

Labels
Area: boards Area: Board ports Area: build system Area: Build system Discussion: RFC The issue/PR is used as a discussion starting point about the item of the issue/PR State: WIP State: The PR is still work-in-progress and its code is not in its final presentable form yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
7 participants
@haukepetersen @PeterKietzmann @kaspar030 @cladmi @jnohlgard @miri64 @aabadie