[PATCH] RTEMS BSP Buildset

[Jonathan Brandmeyer]

On Wed, Aug 7, 2019 at 7:07 PM Chris Johns <chrisj at rtems.org> wrote:

> 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

A variation on this, is that you could provide an option prefix that
is used to forward options to a particular configuration stage, using
GCC's `-Wa,` and `-Wl,` (aka -Xassembler and -Xlinker) as a model.
That way you don't have to decide at the RSB level by hand which
options are worth supporting natively and which ones aren't - all of
them are supported uniformly.  Reasonable prefixes might be `-Xbsp`
and `-Xlibbsd`, for example.

> 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.

With an option-forwarding prefix, then its easy to decide that the
options which should be supported natively are only the ones that are
common to all of the BSP's.  For example, --enable-cxx and
--enable-fortran should definitely be covered by the top-level driver,
for example.

>
> 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.

I'm also keenly interested in seeing how far the device tree support
gets.  At least for the Zynq family, passing some options to RTEMS
from the bootloader via device tree could be a convenient workflow.

My project is leveraging the existing weak symbol support for
overriding some of the default clock speeds.  It mostly works.
However, the nature of weak symbol support in the linker makes this
fragile.  Its easy to make a subtle change in the link command line
that silently pulls in RTEMS incorrect (for my board) definition of
the symbol instead of the one I intended to provide from my sources.

The situation with the Zynq also begs the question, what exactly
justifies a new BSP?  As near as I can tell,
xilinx_zynq_{zc702,zc706,zedboard} only exist as separate BSP's to
provide different default values for the various BSP_OPTs.

-- 
Jonathan Brandmeyer