ARM Getting Started Assistance: Beagleboard, Zedboard, or STM32F4Discovery?

[Joel Sherrill]

On 2/2/2015 10:21 AM, Jonathan Brandmeyer wrote:
> On Sun, Feb 1, 2015 at 4:53 PM, Joel Sherrill <joel.sherrill at oarcorp.com> wrote:
>>
>> On February 1, 2015 4:40:45 PM MST, Ben Gras <beng at shrike-systems.com> wrote:
>>> Dear all,
>>>
>>> I took a quick look at why the beagle bsp fails to link. It seems
>>> there is a multilib interaction I don't really understand that is
>>> causing the symbol to be missing. (The symbol appears in some library
>>> arch variants and not in others.) I'm not too familiar with how that
>>> works so I can't find a clean solution right now.
>> Building multilib is rather useless to most people. It builds the cpukit for every arm CPU variant GCC knows. In this case, the error is in a variant we don't have a BSP for. You only need one of the variants. More below.
>>
>> Build rtems for a single BSP and drop the multilib option. For some BSPs, you might see an issue linking a dynamic loading test. I saw  it on the Pi last week but the other test ran.
> I must have misunderstood something fundamental about how RTEMS builds
> then.  I used multilibs this first round specifically because several
> different architecture variants were being requested.  ARM-V7M,
> ARM-v7ME, and ARM-V7A are all quite different from each other.  I had
> rather assumed that RTEMS generic code would get compiled for each
> architecture variant, and then the BSP would build for only its own
> variant with the right flags to pick up the correct subarch.
When the option to build muiltilib was added, that was the long term
goal. But
it has really been used only to check that cpukit/ code is not dependent on
BSP or device driver code in an unacceptable way.

Plus that is really only a useful option to an end user when you distribute
binaries. We could then build all cpukit/ variants and all BSPs. That could
cut down the build time for a binary distribution of all BSPs.

BUT.... our view to shipping binaries of RTEMS or tools has changed. We
want you to build from source. We want you to know you have everything
and can reproduce it. It is actually better for a real project long term if
you can put EVERY source line under your internal configuration management,
look at any line of code, be sure your binary came from the source you
have, etc. 

This transition in view of the power of open source is causing a shift
in how
we run as a project. We also are in the process of updating all project
support tools. In the last two years, we have moved from CVS to git,
Mediawiki+Bugzilla to Trac, and have prototypes of a replacement
build system and continuous integration and testing support. We are
a 25 year old project and this is a necessary part of living this long.
What were state of the art tools a decade ago is no longer the case.
> Rebuilding only one BSP per build directory and explicitly
> --disable-multilib works around the build failures for beagleboard and
> stm32 testsuite programs.  When building in this mode, does each BSP
> need a different --prefix?  Or can they all be installed to the same
> prefix?
No. You can use the same prefix as the tools or somewhere else. When you
build things after installing, you will include the BSP specific
directory somehow
in the build. BSPs are installed in $prefix/$target/$bsp so you can have all
of them in parallel.

Note that we don't force you to use any particular build system for your
application. We just need you to pass the right arguments in to the build
and link.
> Thanks,
> Jonathan
> _______________________________________________
> users mailing list
> users at rtems.org
> http://lists.rtems.org/mailman/listinfo/users

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985