[PATCH] RTEMS BSP Buildset

[Chris Johns]

On 8/8/19 6:15 am, Jonathan Brandmeyer wrote:
> On Sun, Jul 21, 2019 at 6:13 PM <chrisj at rtems.org> wrote:
>>
>> This series of patches adds BSP buildset support to the RSB. A top level
>> BSP buildset can be added that can include the tools, kernel and 3rd party
>> packages, such as libbsd. A single buildset command will build and install
>> a complete BSP development environment:
>>
>>  $ ../source-builder/sb-buildset --prefix=$HOME/development/bbb \
>>                                  --log=bbb.txt \
>>                                  5/bsps/beagleboneblack
> 
> What is the correct way to pass additional configuration options to
> the different configuration stages?

This is a good question and I thought it would arise when adding the BSP support
so thank you, I welcome it. It supports my view vertical integration of software
stacks for RTEMS is important to users.

> My team is using the xilinx_zynq_zedboard BSP, except that we use a
> number of different customizations.
> 
> We enable fortran support when building the toolchain.  We use a few
> --enable and --disable options to RTEMS configure, as well as pass
> BSP_ZYNQ_RAM_LENGTH and BSP_CONSOLE_MINOR as arguments to RTEMS'
> configure.

I dislike BSP_OPTS for a few reason; I will not expand on that topic here. I can
....

1. Add option support to the RSB. I am not exactly sure how this could be made
to work but something like ...

 --enable-bspopt-bsp-zynq-ram-length=256

The important BSP_OPTS could be listed in a config file for the BSP to convert
them to RTEMS configure command line values.

2. Add support for RTEMS configure options. This can be done in a similar way to
the languages for gcc as there is only a few valid ones left.

3. Add generic support to the BSP or ARM default workspace initialise code to
call something like `bsp_workspace_begin()` and `bsp_workspace_end()` that are
weak functions in RTEMS returning the linkcmd values. A user can add these
functions to their BSP support code to override. This type of support would let
the RPi use the generic support.

4. Do all the above and ban any new BSP_OPTS being added to a BSP in preference
of weak symbol runtime calls. I feel a number of existing BSP_OPTS could be
removed this way.

Chris