nios2 auto configureed BSP

[Hill, Jeff]

Hi,

Attached is the current state of the README, configure.ac, alteraSysConfigMap.txt, and Makefile.am from my attempt at a simple Altera Nios2 RTEMS BSP, which is auto generating an RTEMS linker script memory region base address include file, and also a device base address header file using the Altera sopcinfo extension hardware design file as its only input. This BSP is a bit novel because it is for a highly configurable soft core processor. For example, every Nios2 processor potentially has a unique cache line size.

I can see that a previous Nios2 BSP used some host based tools to accomplish this same purpose using the Altera ptf extension file as their input, but my understanding is that this Altera proprietary ptf file format is no longer generated by QSYS; QSYS is Altera's latest high level cpu/hardware system generation tool - which I am using. I'm not certain, but perhaps basing the RTEMS tools on the (probably undocumented) Altera internal ptf file protocol might be hard to maintain in the long run so I decided to try to implement something simple that auto-configured off the default Altera Hardware Access Layer (HAL). This approach is auto-configuring host based tools off of a very limited number of the Altera C header files, but not including any Altera source code when building object code that actually runs in the target. This approach was also fairly easy to implement so I gave it a try, but now I will need to see if anyone (everyone) thinks I am crazy :-]

In particular, the first part of the attached Makefile.am might be viewed as being controversial because it orchestrates building of host executable tools in the BSP, and I know full well that this sort of thing is normally done in the tools path during the RTEMS build. Furthermore, because these are not target object build lines, the typical high level automake macros are not used, and you will see that these lines look instead more like traditional make file syntax.

My defense:

Currently I am thinking that the auto configuration lines at the top of Makefile.am, which build host executables, are a reasonable compromise because such tools are easily implemented when they can be dependent on the Altera generated source code. Altera expects their users to use Altera auto-generated source code to configure the user's software systems so perhaps this approach can have improved longevity. Its necessary to build these tools in the BSP because only the BSP knows the path to the Altera sopcinfo hardware design file and the Altera HAL generating tools supplied by a particular Altera distribution. These BSP specific host tools facilitate extracting the proper information out of the Altera generated HAL w/o requiring that Altera source code be included into RTEMS target code.

I maybe could have used more of the typical automake macros if I knew how to write pattern matching rules for automake, but I don't know how to do that and some quick web searches weren't encouraging. Nevertheless, I am also guessing that the auto configuration lines at the top of Makefile.am are reasonably portable, if a bit harder to maintain compared to traditional automake macros because we are working at a lower level closer to legacy make syntax, so maybe it's an reasonable compromise.

Open to any and all suggestions, thanks.

Jeff Hill


-------------- next part --------------
A non-text attachment was scrubbed...
Name: configure.ac
Type: application/octet-stream
Size: 1588 bytes
Desc: configure.ac
URL: <http://lists.rtems.org/pipermail/users/attachments/20120703/22e08796/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Makefile.am
Type: application/octet-stream
Size: 10698 bytes
Desc: Makefile.am
URL: <http://lists.rtems.org/pipermail/users/attachments/20120703/22e08796/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: README
Type: application/octet-stream
Size: 1375 bytes
Desc: README
URL: <http://lists.rtems.org/pipermail/users/attachments/20120703/22e08796/attachment-0002.obj>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: alteraSysConfigMap.txt
URL: <http://lists.rtems.org/pipermail/users/attachments/20120703/22e08796/attachment.txt>