[PATCH] RTEMS BSP Buildset

[Chris Johns]

On 10/8/19 1:23 am, Jonathan Brandmeyer wrote:
> 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.

Yes this is nice but I am not sure how the RSB config language can do this.
There are no loops in the language and I do not want to hard code in Python
specific support for a package. There is also multiple options needing to be
appended together to make a full set the user needs. The option handling and the
build script are a long way from each other.

I unfortunately have limited time to put into this so keeping to the config
language is the easiest path.

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

There is this ..

https://git.rtems.org/rtems-source-builder/tree/rtems/config/tools/rtems-kernel-common.cfg#n94

where `--with-rtems-cxx` is picked up with ..

%if %{defined with_rtems_cxx}
 %define rtems_cxx 1
%endif

If the `--with-*` and `--without-*` support can be used it means less or no
changes to the RSB python code base.

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

Yes and if placed in a library and with separate text and data it can be fiddly.
I place the code in same file as `Init()` and then call each from Init someway.
This makes sure I always have the code I want.

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

If you are using an openly available target like the Microzed then we want to
have the options set for that user. A user of such a board should not need to
dig into the detail to find a suitable set of settings. Removing BSP_OPTS would
mean we would need to figure out how this needs to be handled.

I would like to find a way so a single kernel build that can adjust to target
variations at runtime. FDT is one method or part of the solution but we would
need to make sure the BSP is consistent and across all BSPs.

Chris