headers
Claus, Ric | 1 Feb 2011 03:48
Picon
Favicon

Migrating a BSP to 4.11

Hi All,

  I'm trying to migrate a custom BSP from RTEMS 4.9.2 to 4.11 (which has been far from self evident).  I am now
getting bursts of the following error message when the testsuites are built.  Could someone please tell me
what's causing it and where to start looking?  What section is being wanted?

	Thanks very
much!

	Ric

/reg/common/package/gnu/rtems-4.11/lib/gcc/powerpc-rtems4.11/4.5.1/../../../../powerpc-rtems4.11/bin/ld:
../../../../../rce405/lib/librtemsbsp.a(exc_bspsupport.rel): the target (ppc_exc_msr_bits) of
a R_PPC_SDAREL16 relocation is in the wrong output section (.data)

_______________________________________________
rtems-users mailing list
rtems-users@...
http://www.rtems.org/mailman/listinfo/rtems-users
Permalink | Reply | 1 comment |
headers
Till Straumann | 1 Feb 2011 04:27
Picon
Favicon

Re: Migrating a BSP to 4.11

On 01/31/2011 08:48 PM, Claus, Ric wrote:
> Hi All,
>
> I'm trying to migrate a custom BSP from RTEMS 4.9.2 to 4.11 (which
> has been far from self evident).  I am now getting bursts of the
> following error message when the testsuites are built.  Could someone
> please tell me what's causing it and where to start looking?

<background>
The PPC sysv ABI reserves one register (the eabi reserves two)
which remains constant throughout the execution of the program.
It points to a memory area which can be addressed in both
a time- and space-efficient way (many instructions can access
a datum within +/- 32k off where that base register points to
directly).

Since the space in this area is limited it is best used for
small data objects, hence the acronym SDA for Small Data Area.

The compiler can locate data in the SDA and emits special
relocations for these data. The linker must make sure all
these data are within a single 64k section. In order for this
to work the compiler puts such data in '.sdata' or '.sbss'
sections which must be gathered by the linker into a single
output section (which must be <64k for the link to succeed).
</background>

Most likely, your linker script (if you designed a BSP then you most
likely copy/pasted a linker script) does not correctly define/use the
.sdata, .sbss (and in case of eabi: .sdata2  and .sbss2) sections.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mick Davis | 1 Feb 2011 06:56
Picon
Picon

Arm Endianness

Hi

We're porting a large rtems application from an m68k to an Arm 926ejs 
processor.

Because the application must communicate with the old processor, and 
because the code unfortunately makes assumptions about endianness in 
some places, the change from big endian to little endian data is 
complicating the effort.

My research suggests its possible to run the Arm in a Big Endian 
configuration.  I was wondering if anyone has ported RTEMS to a big 
endian Arm before, and if they could outline what's involved ?

Thanks

--

-- 

Mick Davis
Goanna Technologies Pty Ltd
+61 8 9444 2634

"Shock your lizard today!"
_______________________________________________
rtems-users mailing list
rtems-users@...
http://www.rtems.org/mailman/listinfo/rtems-users
Permalink | Reply | 0 comments |
headers
Kim Barrett | 1 Feb 2011 19:33
Picon

Re: rtems git status...

On Jan 26, 2011, at 7:04 AM, Ralf Corsepius wrote:
> On 01/24/2011 12:15 PM, lee wrote:
>> Hi all...
>> 
>> anyone know if/of the git status in rtems?
> 
> Several people have tried to convert RTEMS CVS to git, but so far, without visible success. All tools
somewhere have failed or screwed things up.

In case this helps, someone in the boost community is working on a new svn->git conversion tool that will
faithfully preserve *all* of the history in the source svn repository.  Of course, that's svn as the
source, and rtems is in cvs, and I don't know how good the cvs->svn migration path really is (having only
been indirectly through that process once myself).

For more information, search for messages from John Weigley in this thread:
http://groups.google.com/group/boost-list/browse_thread/thread/6d0d01eb3cac4abf/fba16dc408446ca7

_______________________________________________
rtems-users mailing list
rtems-users@...
http://www.rtems.org/mailman/listinfo/rtems-users
Permalink | Reply | 0 comments |
headers
Rohan Kangralkar | 2 Feb 2011 19:04
Picon
Favicon

Confused with directory structure

Hi all,

I am confused with the *.h placed under c/src/lib/libcpu/XXX/include for exaple c/src/lib/libcpu/bfin/include    and  *.h place under cpukit/score/cpu/XXX/rtems/XXX/*.h.

It looks alike the *.h placed under c/src/lib/libcpu/XXX/include are used only for peripheral dependent files   and

*.h place under cpukit/score/cpu/XXX/rtems/XXX/*.h. are core CPU dependent files.

I want to place some code and i am confused with the placement of the defines so i need some clarity on the confusion i have.


Thanks
Rohan JK

_______________________________________________
rtems-users mailing list
rtems-users@...
http://www.rtems.org/mailman/listinfo/rtems-users
Permalink | Reply | 0 comments |
headers
Sebastian Huber | 3 Feb 2011 11:35
Picon
Favicon

MPCI Driver

Hello,

a MPCI (Multiprocessor Communications Interface) driver must provide these
functions:

/**
 *  This type defines the Multiprocessor Communications
 *  Interface (MPCI) Table.  This table defines the user-provided
 *  MPCI which is a required part of a multiprocessor system.
 *
 *  For non-blocking local operations that become remote operations,
 *  we need a timeout.  This is a per-driver timeout: default_timeout
 */
typedef struct {
  /** This fields contains the timeout for MPCI operations in ticks. */
  uint32_t                   default_timeout;
  /** This field contains the maximum size of a packet supported by this
   *  MPCI layer.  This size places a limit on the size of a message
   *  which can be transmitted over this interface.
   **/
  size_t                     maximum_packet_size;
  /** This field points to the MPCI initialization entry point. */
  MPCI_initialization_entry  initialization;
  /** This field points to the MPCI get packet entry point. */
  MPCI_get_packet_entry      get_packet;
  /** This field points to the MPCI return packet entry point. */
  MPCI_return_packet_entry   return_packet;
  /** This field points to the MPCI send packet entry point. */
  MPCI_send_entry            send_packet;
  /** This field points to the MPCI receive packet entry point. */
  MPCI_receive_entry         receive_packet;
} MPCI_Control;

I have a question regarding the send packet entry.  Does the send packet also
include a return packet semantic?  This would imply that the usage of a packet
after a call to the send packet entry is invalid.

Locking at the code is a bit confusing.  For example in
_Message_queue_MP_Send_request_packet() we get a packet, prepare the packet and
hand it over to _MPCI_Send_request_packet().  Since no references to the packet
are stored, I assume that _MPCI_Send_request_packet() will release the packet.
 Inside _MPCI_Send_request_packet() we make a call to send packet, but no call
to return packet.  So I assume that a send packet implies a packet return.  On
the other hand we use some packet values after the send packet (lines 275 to
278 in mpci.c).  Is this correct?

Have a nice day!

--

-- 
Sebastian Huber, embedded brains GmbH

Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany
Phone   : +49 89 18 90 80 79-6
Fax     : +49 89 18 90 80 79-9
E-Mail  : sebastian.huber@...
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
rtems-users mailing list
rtems-users@...
http://www.rtems.org/mailman/listinfo/rtems-users
Permalink | Reply | 0 comments |
headers
Kirspel, Kevin | 7 Feb 2011 18:27

ARM Cortex-M3

I am building a RTEMS port to an STM32 Cortex-M3.  I am building the port for RTEMS version 4.9.  I have built binutils-2.18 and gcc-4.3.2 with thumb2 support (I had to change t-rtems under GCC to output thumb2 multilib).  When configuring RTEMS, the configure script cannot find newlib.  Looking at config.log, I get the following error when checking for newlib:

 

configure:4709: checking for RTEMS newlib

configure:4736: arm-rtems-gcc --pipe -o conftest -mcpu=cortex-m3 -mthumb -mstructure-size-boundary=8 -O0 -g   conftest.c  >&5

collect2: ld terminated with signal 11 [Segmentation fault]

/usr/local/gcc-4.3.2/lib/gcc/arm-rtems/4.3.2/../../../../arm-rtems/bin/ld: warning: cannot find entry symbol _start; defaulting to 00008000

/usr/local/gcc-4.3.2/lib/gcc/arm-rtems/4.3.2/../../../../arm-rtems/bin/ld: /usr/local/gcc-4.3.2/lib/gcc/arm-rtems/4.3.2/../../../../arm-rtems/lib/libg.a(lib_a-dummysys.o)(not_required_by_rtems): warning: interworking not enabled.

  first occurrence: /home/kirspelk/tmp/ccOqIF65.o: thumb call to arm

/usr/local/gcc-4.3.2/lib/gcc/arm-rtems/4.3.2/../../../../arm-rtems/bin/ld: BFD (GNU Binutils) 2.18 assertion fail ../../binutils-2.18/bfd/elf32-arm.c:6532

/home/kirspelk/tmp/ccOqIF65.o: In function `main':

/home/kirspelk/sandbox/opti_touch/b_rtems_cortexm3/arm-rtems/c/cortexm3/cpukit/conftest.c:12: dangerous relocation:

configure:4743: $? = 1

 

It looks like configure is looking in the “gcc-4.3.2/arm-rtems/lib” directory to determine a valid newlib library.  The thumb2 newlib library is under “gcc-4.3.2/arm-rtems/lib/thumb/thumb2”.  How should I go about correcting this issue?  Is this even the issue or is it something else?

 

Kevin Kirspel

_______________________________________________
rtems-users mailing list
rtems-users@...
http://www.rtems.org/mailman/listinfo/rtems-users
Permalink | Reply | 8 comments |
headers
Ralf Corsepius | 7 Feb 2011 18:46
Favicon

Re: ARM Cortex-M3

On 02/07/2011 06:27 PM, Kirspel, Kevin wrote:
> I am building a RTEMS port to an STM32 Cortex-M3.  I am building the port for RTEMS version 4.9.  I have built
binutils-2.18 and gcc-4.3.2 with thumb2 support (I had to change t-rtems under GCC to output thumb2 multilib).
... except that these versions are hopelessly outdated (You will really 
want to use the rtems-4.11 versions), there shouldn't be much wrong with 
this.

>  When configuring RTEMS, the configure script cannot find newlib.
Do you have newlib inside of your gcc-source tree?

>  Looking at config.log, I get the following error when checking for newlib:
>
> configure:4709: checking for RTEMS newlib
> configure:4736: arm-rtems-gcc --pipe -o conftest -mcpu=cortex-m3 -mthumb
-mstructure-size-boundary=8 -O0 -g   conftest.c>&5
> collect2: ld terminated with signal 11 [Segmentation fault]
This looks like you are using an installed arm-rtems-gcc (likely 
something even more outdated than rtems-4.9) to building your compiler.

=> There is something going wrong much earlier.

> /usr/local/gcc-4.3.2/lib/gcc/arm-rtems/4.3.2/../../../../arm-rtems/bin/ld: warning: cannot
find entry symbol _start; defaulting to 00008000
> /usr/local/gcc-4.3.2/lib/gcc/arm-rtems/4.3.2/../../../../arm-rtems/bin/ld:
/usr/local/gcc-4.3.2/lib/gcc/arm-rtems/4.3.2/../../../../arm-rtems/lib/libg.a(lib_a-dummysys.o)(not_required_by_rtems):
warning: interworking not enabled.
>    first occurrence: /home/kirspelk/tmp/ccOqIF65.o: thumb call to arm
> /usr/local/gcc-4.3.2/lib/gcc/arm-rtems/4.3.2/../../../../arm-rtems/bin/ld: BFD (GNU
Binutils) 2.18 assertion fail ../../binutils-2.18/bfd/elf32-arm.c:6532
> /home/kirspelk/tmp/ccOqIF65.o: In function `main':
>
/home/kirspelk/sandbox/opti_touch/b_rtems_cortexm3/arm-rtems/c/cortexm3/cpukit/conftest.c:12:
dangerous relocation:
> configure:4743: $? = 1
>
> It looks like configure is looking in the "gcc-4.3.2/arm-rtems/lib" directory to determine a valid
newlib library.  The thumb2 newlib library is under "gcc-4.3.2/arm-rtems/lib/thumb/thumb2".  How
should I go about correcting this issue?
Theoretically, extending arm/t-rtems, adding newlib to the source tree 
(usually adding a sym-link) should be all that is required.

>  Is this even the issue or is it something else?
Likely - Unfortunately, provided what you tell, it's hard to guess what 
this could be. Likely several things at once.

Ralf
_______________________________________________
rtems-users mailing list
rtems-users@...
http://www.rtems.org/mailman/listinfo/rtems-users
Permalink | Reply | 7 comments |
headers
Kirspel, Kevin | 7 Feb 2011 18:57

RE: ARM Cortex-M3

Newlib is symbolically linked to the gcc-source tree.  The binutils and gcc versions I am using were used in a
RTEMS 4.9 port of the NXP LPC3250 MCU.  The LPC3250 RTEMS port configures and compiles fine.  Maybe these
versions of binutils and gcc are my problem with the cortex m3.  I will try the rtems-4.11 versions and see
what happens. 

-----Original Message-----
From: Ralf Corsepius [mailto:ralf.corsepius@...] 
Sent: Monday, February 07, 2011 12:47 PM
To: Kirspel, Kevin
Cc: rtems-users@...
Subject: Re: ARM Cortex-M3

On 02/07/2011 06:27 PM, Kirspel, Kevin wrote:
> I am building a RTEMS port to an STM32 Cortex-M3.  I am building the port for RTEMS version 4.9.  I have built
binutils-2.18 and gcc-4.3.2 with thumb2 support (I had to change t-rtems under GCC to output thumb2 multilib).
... except that these versions are hopelessly outdated (You will really 
want to use the rtems-4.11 versions), there shouldn't be much wrong with 
this.

>  When configuring RTEMS, the configure script cannot find newlib.
Do you have newlib inside of your gcc-source tree?

>  Looking at config.log, I get the following error when checking for newlib:
>
> configure:4709: checking for RTEMS newlib
> configure:4736: arm-rtems-gcc --pipe -o conftest -mcpu=cortex-m3 -mthumb
-mstructure-size-boundary=8 -O0 -g   conftest.c>&5
> collect2: ld terminated with signal 11 [Segmentation fault]
This looks like you are using an installed arm-rtems-gcc (likely 
something even more outdated than rtems-4.9) to building your compiler.

=> There is something going wrong much earlier.

> /usr/local/gcc-4.3.2/lib/gcc/arm-rtems/4.3.2/../../../../arm-rtems/bin/ld: warning: cannot
find entry symbol _start; defaulting to 00008000
> /usr/local/gcc-4.3.2/lib/gcc/arm-rtems/4.3.2/../../../../arm-rtems/bin/ld:
/usr/local/gcc-4.3.2/lib/gcc/arm-rtems/4.3.2/../../../../arm-rtems/lib/libg.a(lib_a-dummysys.o)(not_required_by_rtems):
warning: interworking not enabled.
>    first occurrence: /home/kirspelk/tmp/ccOqIF65.o: thumb call to arm
> /usr/local/gcc-4.3.2/lib/gcc/arm-rtems/4.3.2/../../../../arm-rtems/bin/ld: BFD (GNU
Binutils) 2.18 assertion fail ../../binutils-2.18/bfd/elf32-arm.c:6532
> /home/kirspelk/tmp/ccOqIF65.o: In function `main':
>
/home/kirspelk/sandbox/opti_touch/b_rtems_cortexm3/arm-rtems/c/cortexm3/cpukit/conftest.c:12:
dangerous relocation:
> configure:4743: $? = 1
>
> It looks like configure is looking in the "gcc-4.3.2/arm-rtems/lib" directory to determine a valid
newlib library.  The thumb2 newlib library is under "gcc-4.3.2/arm-rtems/lib/thumb/thumb2".  How
should I go about correcting this issue?
Theoretically, extending arm/t-rtems, adding newlib to the source tree 
(usually adding a sym-link) should be all that is required.

>  Is this even the issue or is it something else?
Likely - Unfortunately, provided what you tell, it's hard to guess what 
this could be. Likely several things at once.

Ralf

_______________________________________________
rtems-users mailing list
rtems-users@...
http://www.rtems.org/mailman/listinfo/rtems-users
Permalink | Reply | 1 comment |
headers
Sebastian Huber | 7 Feb 2011 23:03
Picon
Favicon

Re: ARM Cortex-M3

Hello,

my understanding is that we have to change the ABI to support the
ARMv7-M architecture, see also:

http://www.rtems.org/pipermail/rtems-users/2010-October/007603.html

We have now a copyright assignment with the FSF for GCC, so in theory we
could integrate this patch.  I currently lack time to test it.

For a new development I recommend the CVS head.

Have a nice day!
_______________________________________________
rtems-users mailing list
rtems-users@...
http://www.rtems.org/mailman/listinfo/rtems-users
Permalink | Reply | 0 comments |

Gmane