BSP variants
Claus, Ric
claus at slac.stanford.edu
Fri Apr 19 17:32:25 UTC 2013
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.
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.
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
More information about the devel
mailing list