Workspace boards folder

[tuna-f1sh]

Related to #159: would you be open to a workspace boards folder specifically for hardware targeting CANnectivity that probably don't warrant being added to upstream in Zephyr?

I've created a V2 of my Entree board that supports CANnecitivity. I have a fork which includes a 'boards' folder in the CANnectivity workspace: main...tuna-f1sh:cannectivity:stm32g01b (still slightly WIP).

It seems like a nice solution for boards specifically designed for CANnectivity, which cannot be defined with an overlay but where the uses within Zephyr as a 'board' are less obvious.

[henrikbrixandersen]

Related to #159: would you be open to a workspace boards folder specifically for hardware targeting CANnectivity that probably don't warrant being added to upstream in Zephyr?

No, sorry. I maintain CANnectivity, not BSPs.

I've created a V2 of my Entree board that supports CANnecitivity. I have a fork which includes a 'boards' folder in the CANnectivity workspace: main...tuna-f1sh:cannectivity:stm32g01b (still slightly WIP).

It seems like a nice solution for boards specifically designed for CANnectivity, which cannot be defined with an overlay but where the uses within Zephyr as a 'board' are less obvious.

I may be a nice solution for you, but I would be stuck with maintaining ports for boards I don't have and don't really have an interest in maintaining support for.

Long story short, board support needs to go into upstream Zephyr if a board overlay is needed in CANnectivity. Another option is to keep your board support + CANnectivity board overlay in a downstream repository.

[tuna-f1sh]

Understandable and I thought that might be the case. Thanks reply. I'll probably keep the boards folder in the project repo and suggest using the -DBOARD_ROOT define for the build.