On Wed, Aug 7, 2019 at 7:07 PM Chris Johns <chr...@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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel