BSP variants

[Gedare Bloom]

On Fri, Apr 19, 2013 at 1:32 PM, Claus, Ric <claus at slac.stanford.edu> wrote:
> Thanks, Joel.  That helped clarify some things.  The problem turned out to be that the case statement in <cpu>/acinclude.m4: entries of the form 'lpc32xx )' match anything that _starts_ with 'lpc32xx'.  Thus 'zynq )' matches neither 'zc702' nor 'zedboard', which is why I was getting 'Invalid BSP', the catch-all case.  Not at all obvious if you don't know this syntax.  So, is there a BSP naming convention I'm not aware of?  Maybe I should be calling these things 'zynq_zc702' and 'zynq_zedbaord' so that 'zynq )' finds them and descends into the zynq/ BSP directory?  Kind of ugly.
>
I don't know.

> Another question: based on which board RTEMS is being built for ('zc702' or 'zedboard'), I need to do something different in zynq/Makefile.am.  I can't quickly figure out how to do that.  Variables set in <bsp>/make/custom/*.cfg don't seem to be available in Makefile.am nor configure.ac.  The RTEMS_BSPOPTS_SET macro is able to compare its second argument with the BSP value currently being worked on by the build system, but I can't find the source for that macro.  I'd like to do something like:
>
> AC_SUBST([BSP_3RD_PATH],[$(RTEMS_ROOT)/$(RTEMS_BSP)])
>
> where $(RTEMS_BSP) is the name of the BSP currently being worked on, $(RTEMS_ROOT) is the root directory from which to locate the third party software, and @BSP_3RD_PATH@ is used by Makefile.am to address which files go into the BSP,  for example.  As stated in a previous post, the user would have to edit this line in configure.ac to specify where s/he has placed the third party software before attempting to build RTEMS with one of these BSPs.  Is this a reasonable approach?  Maybe all this is documented somewhere I just haven't come across yet.  If so, please point me to it.
>

You can create your own conditional check with AM_CONDITIONAL in
configure.ac to use in Makefile.am. See
libbsp/powerpc/motorola_powerpc/configure.ac how it creates a
conditional called QEMU depending on the value of RTEMS_BSP and then
in Makefile.am how it checks if QEMU ... endif.

I think it would be better to somehow specify the path to the third
party software as a parameter to either configure or make, but I'm not
so sure how to do that. Probably it would be good for us to figure out
a usable solution, since this seems a recurring issue c.f. the stm32f
post.

-Gedare

> Thanks,
>             Ric
>
> ________________________________________
> From: Joel Sherrill [Joel.Sherrill at OARcorp.com]
> Sent: Thursday, April 18, 2013 6:30 PM
> To: Claus, Ric
> Cc: rtems-devel at rtems.org
> Subject: Re: BSP variants
>
> BSP variants are recognised by *.cfg in make/custom.
>
> configure. ac uses some macros to define conditional variables differently based on the variant. Look BSP SETOPTS or similar in the arm lpc BSPs or PowerPC gen5200 for examples.
>
> --joel
>
> "Claus, Ric" <claus at slac.stanford.edu> wrote:
>
>
> I'm not understanding how to build multiple BSP variants from a single libbsp/<cpu>/<bsp> directory.  The ARM lpc32xx does this, for example.  Configuring to for a BSP named lpc32xx_mzx ends with the message:
>
> target architecture: arm.
> available BSPs: lpc32xx_mzx.
>
> even though there is no libbsp/*/lpc32xx_mzx directory and it isn't mentioned in libbsp/<cpu>/acinclude.m4.  Doing 'make all' then goes and builds everything, as expected.  Where is the lpc32xx_mzx target defined?  Is it in the make/custom directory?
>
> When I follow this same pattern with the names zc702 and zedboard for the zynq BSP directory, the configure works, but the 'make all' fails with 'Invalid BSP'.
>
>         Thanks,
>                         Ric
>
>
>
> _______________________________________________
> rtems-devel mailing list
> rtems-devel at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel
>
> _______________________________________________
> rtems-devel mailing list
> rtems-devel at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel