4.7 Power PC bare builds

[Joel Sherrill <joel@OARcorp.com>]

Chris Johns wrote:
> gmarsden at cogeco.ca wrote:
> 
>> Using 4.6.99.2 snapshot, Centos 4.0 (redhat) host
>> If I try and build rtems with the following, I get two
>> problems in the build and what looks like a compiler bug
>> when I try and run the network demo application.
>>
>> ../rtems-4.6.99.2/configure --prefix=/opt/rtems-4.7 
>> --target=powerpc-rtems4.7 --disable-rtems-inlines --disable-posix
>> --disable-itron --enable-networking --enable-bare-cpu-model="mpc8260" 
>> --enable-bare-cpu-cflags="-g -mcpu=603e -O2
>> -fomit-frame-pointer -mstrict-align -Dmpc8260 -DPPC_ABI=PPC_ABI_EABI 
>> -DPPC_ASM=PPC_ASM_ELF" --enable-rtemsbsp="bare"
>>
> 
> I do not think the 'bare' options are present anymore. The 'bare' idea 
> has evolved into multilib support which is much better. See:
> 
>  http://www.rtems.org/wiki/index.php/Multilib_RTEMS
> 
>> 1. The build breaks down when it trys to build the
>> serial and networking chips in libchip. I don't know whether it should 
>> be even trying to build these.
> 
> 
> I do not think these are built in the current multilib support.

If it is upder cpukit, then it is in the multilib source.
Otherwise, it is assumed to potentially need information from
the BSP.  Maybe a header file, maybe a setting, maybe a variable
to set a clock speed, etc.

>> 2. The --enable-bare-cpu-cflags are not passed to gcc when
>> I do the subsequent "gmake all"
>>
>> 3. When I work around the above and build an app, there
>> is a problem reenabling interrupts in the inline function
>> _CORE_semaphore_Seize_isr_disable in rtems_semaphore_obtain.
>> It seems to be a compiler bug where it uses the wrong value when it 
>> restores the MSR. I copied a renamed version of the
>> inline function into the semobtain.c file and the networking demo now 
>> works.

Are you using the tools shipped with 4.6?  There are known issues
when moving to newer compilers which might be part of this.

--joel