BSP names

Sebastian Huber sebastian.huber at
Tue Jul 23 07:36:08 UTC 2019

On 21/07/2019 04:08, Chris Johns wrote:
> On 19/7/19 11:41 pm, Joel Sherrill wrote:
>> On Fri, Jul 19, 2019 at 4:33 AM Sebastian Huber
>> <sebastian.huber at  <mailto:sebastian.huber at>>
>> wrote:
>>      Hello,
>>      I worked a bit with Doorstop and found the YAML file quite interesting.
>>      The file format is not without problems:
>>      However, for simple configuration stuff it is easy to write, read and
>>      process. Changes can be reviewed well in Git (content is spread over lines).
>>      I experiment currently a bit with using a YAML file to define the RTEMS
>>      build.
>>      How should BSPs be identified in the future? Should a BSP name be unique
>>      across architectures or do we want to use an "arch/bsp" tuple?
>> Yes.:)
> Yes and +1.
> This is the format I have standardised on for everything but building RTEMS, ie
> rtems_waf which means libbsd. The kernel has the --target triplet and the bsp.

Ok, good.

Some background information about what I am experimenting. To make the 
ECSS standard happy, we have to deliver a Software Configuration File 
(SCF) for example. This overlaps a bit with the information necessary to 
build RTEMS. I would like to concentrate the information in Doorstop 
maintained files and generate different outputs based on the intended 
usage, e.g. an SCF or build files (Makefile, waf). Another example is 
that we may have a requirement like this: The compiler flags for the XYZ 
BSP shall be "-O2 -g -mleon3". We could add the compiler flags to a 
BSP-specific configuration item which has a "cflags: -O2 -g -mleon3" 
attribute. We can use this attribute to generate a human readable 
requirement in an Software Requirements Specification (SRS) and the 
build file. The compiler flags just have one master data, everything 
else is derived and produced by tools.

Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

More information about the devel mailing list