Re: How to start contributing towards RTEMS project
Thanks all for the wonderful response. I hope this post will help others as well who want to contribute to RTEMS development. Currently I have enabled all the testcases on raspberry pi including the libmm tests. Will start some running some tests to get the feel. Also, meanwhile I will get the setup ready for LM4F120 as well. Thanks Ritesh On Tue, Sep 3, 2013 at 2:19 AM, Alan Cudmore wrote: > The Raspberry Pi could use drivers: > SPI / SD card access, > I2C Bus > Ethernet ( this could be hard since it is a USB device ) , > HDMI/graphics console, > Sound? > > Alan > > > On 9/2/2013 4:35 PM, Karel Gardas wrote: > >> On 09/ 2/13 07:33 AM, Ritesh Harjani wrote: >> >>> I have Raspberry pi + ti stellaris lm4f120 launchpad, if it helps. >>> >> >> Well, if you'd like to do some coding exercise, then what about to write >> a driver for LM4F120's EEPROM? I've hoped to do this myself but my project >> has grown up to the size which does not fit into LM4F120's FLASH nor RAM so >> I'm "migrating" it to STM32F4 now... >> >> Cheers, >> Karel >> > > ___ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
Re: How to start contributing towards RTEMS project
The Raspberry Pi could use drivers: SPI / SD card access, I2C Bus Ethernet ( this could be hard since it is a USB device ) , HDMI/graphics console, Sound? Alan On 9/2/2013 4:35 PM, Karel Gardas wrote: On 09/ 2/13 07:33 AM, Ritesh Harjani wrote: I have Raspberry pi + ti stellaris lm4f120 launchpad, if it helps. Well, if you'd like to do some coding exercise, then what about to write a driver for LM4F120's EEPROM? I've hoped to do this myself but my project has grown up to the size which does not fit into LM4F120's FLASH nor RAM so I'm "migrating" it to STM32F4 now... Cheers, Karel ___ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
Re: How to start contributing towards RTEMS project
On 09/ 2/13 07:33 AM, Ritesh Harjani wrote: I have Raspberry pi + ti stellaris lm4f120 launchpad, if it helps. Well, if you'd like to do some coding exercise, then what about to write a driver for LM4F120's EEPROM? I've hoped to do this myself but my project has grown up to the size which does not fit into LM4F120's FLASH nor RAM so I'm "migrating" it to STM32F4 now... Cheers, Karel ___ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
Re: STM32F4 failure on semaphore release in termios.
On 09/ 2/13 01:20 PM, Sebastian Huber wrote: 0xe576 <+10>: bl 0xe4d8 <_Chain_Head> 0xe57a <+14>: str r0, [r7, #20] 0xe57c <+16>: ldr r3, [r7, #20] 0xe57e <+18>: ldr r3, [r3, #0] Above you read head->next. 0xe580 <+20>: str r3, [r7, #16] 0xe582 <+22>: ldr r3, [r7, #16] 0xe584 <+24>: ldr r3, [r3, #0] Above you read head->next->next; I think its the instruction above which fails since r3 has a bogus value of 0x1a010003. It looks like that the chain is corrupt. Yes, it also looks so from C point of view and while debugging C code. The question is why. Now I'm trying to duplicate this issue on vanilla STM32F4 BSP from RTEMS HEAD and with the latest toolchain compiled on Ubuntu. Honestly speaking this combination provides completely different hello example -- I mean binary behaves in different way so I'll need to add logic analyser as I don't have logic shifter hardware connected to USART 3 which is used by default on STM32F4 BSP. Anyway, I'll keep you posted about the progress... Thanks for your help! Karel ___ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
Re: How to start contributing towards RTEMS project
Welcome! The lm4f120 was newly added as a bsp. Trying out both with vanilla rtems to "see" running code is a good place to start. Then testing libmm would be good, especially to see what might be available on the TI board. -Gedare On Sep 2, 2013 1:33 AM, "Ritesh Harjani" wrote: > Hi Everyone, > > This mail is to get some help from you guys on *"how to start > contributing towards RTEMS project"* > > *Background work done*: > > 1. With the help of Hesham and community posts, I have setup the > rtems-4.11 toolchain for arm > on fedora 19, 64bit. > 2. Synced the rtems-4.11 source as well as Gsoc 2013 libmm project. > 3. Setup Qemu emulator. > > I have little background on ARM processors and I am interested to > help/contribute in any of of ARM development/porting project. I am > interested in memory management on ARM, but I am very much ok to work on > any project based on the needs from RTEMS community. > > I have Raspberry pi + ti stellaris lm4f120 launchpad, if it helps. > > Since I am currently unfamiliar with RTEMS environment, it will be good if > someone can guide as to where to start off from and with which project. > > > Thanks > Ritesh > > > > > > > ___ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
[PATCH] score: Use unsigned long for atomic integers
Use unsigned long instead of uint_fast32_t since C11 provides only a
ATOMIC_LONG_LOCK_FREE macro constant. This makes it also possible to
use properly typed integer literals like 123UL. It is now clear which
compatible type should be used for the atomic integer.
---
cpukit/score/include/rtems/score/atomic.h | 72 +++---
cpukit/score/include/rtems/score/cpustdatomic.h | 56
testsuites/smptests/smpatomic01/tasks.c |4 +-
testsuites/smptests/smpatomic02/tasks.c |4 +-
testsuites/smptests/smpatomic03/tasks.c |6 +-
testsuites/smptests/smpatomic04/tasks.c |6 +-
testsuites/smptests/smpatomic05/tasks.c |6 +-
testsuites/smptests/smpatomic06/tasks.c |6 +-
testsuites/smptests/smpatomic07/tasks.c |6 +-
testsuites/smptests/smpatomic08/init.c | 78 +++---
10 files changed, 122 insertions(+), 122 deletions(-)
diff --git a/cpukit/score/include/rtems/score/atomic.h
b/cpukit/score/include/rtems/score/atomic.h
index e085dea..b4e7a76 100644
--- a/cpukit/score/include/rtems/score/atomic.h
+++ b/cpukit/score/include/rtems/score/atomic.h
@@ -48,12 +48,12 @@ extern "C" {
* @param object an atomic type pointer of object.
* @param value a value to be stored into object.
*/
-static inline void _Atomic_Init_uint(
- volatile Atomic_Uint *object,
- uint_fast32_t value
+static inline void _Atomic_Init_ulong(
+ volatile Atomic_Ulong *object,
+ unsigned long value
)
{
- _CPU_atomic_Init_uint(object, value);
+ _CPU_atomic_Init_ulong(object, value);
}
static inline void _Atomic_Init_ptr(
@@ -72,12 +72,12 @@ static inline void _Atomic_Init_ptr(
*
* The order shall not be ATOMIC_ORDER_RELEASE.
*/
-static inline uint_fast32_t _Atomic_Load_uint(
- volatile Atomic_Uint *object,
+static inline unsigned long _Atomic_Load_ulong(
+ volatile Atomic_Ulong *object,
Atomic_Order order
)
{
- return _CPU_atomic_Load_uint( object, order );
+ return _CPU_atomic_Load_ulong( object, order );
}
static inline uintptr_t _Atomic_Load_ptr(
@@ -97,13 +97,13 @@ static inline uintptr_t _Atomic_Load_ptr(
*
* The order shall not be ATOMIC_ORDER_ACQUIRE.
*/
-static inline void _Atomic_Store_uint(
- volatile Atomic_Uint *object,
- uint_fast32_t value,
+static inline void _Atomic_Store_ulong(
+ volatile Atomic_Ulong *object,
+ unsigned long value,
Atomic_Order order
)
{
- _CPU_atomic_Store_uint( object, value, order );
+ _CPU_atomic_Store_ulong( object, value, order );
}
static inline void _Atomic_Store_ptr(
@@ -124,13 +124,13 @@ static inline void _Atomic_Store_ptr(
*
* @retval a result value before add ops.
*/
-static inline uint_fast32_t _Atomic_Fetch_add_uint(
- volatile Atomic_Uint *object,
- uint_fast32_t value,
+static inline unsigned long _Atomic_Fetch_add_ulong(
+ volatile Atomic_Ulong *object,
+ unsigned long value,
Atomic_Order order
)
{
- return _CPU_atomic_Fetch_add_uint( object, value, order );
+ return _CPU_atomic_Fetch_add_ulong( object, value, order );
}
static inline uintptr_t _Atomic_Fetch_add_ptr(
@@ -151,13 +151,13 @@ static inline uintptr_t _Atomic_Fetch_add_ptr(
*
* @retval a result value before sub ops.
*/
-static inline uint_fast32_t _Atomic_Fetch_sub_uint(
- volatile Atomic_Uint *object,
- uint_fast32_t value,
+static inline unsigned long _Atomic_Fetch_sub_ulong(
+ volatile Atomic_Ulong *object,
+ unsigned long value,
Atomic_Order order
)
{
- return _CPU_atomic_Fetch_sub_uint( object, value, order );
+ return _CPU_atomic_Fetch_sub_ulong( object, value, order );
}
static inline uintptr_t _Atomic_Fetch_sub_ptr(
@@ -178,13 +178,13 @@ static inline uintptr_t _Atomic_Fetch_sub_ptr(
*
* @retval a result value before or ops.
*/
-static inline uint_fast32_t _Atomic_Fetch_or_uint(
- volatile Atomic_Uint *object,
- uint_fast32_t value,
+static inline unsigned long _Atomic_Fetch_or_ulong(
+ volatile Atomic_Ulong *object,
+ unsigned long value,
Atomic_Order order
)
{
- return _CPU_atomic_Fetch_or_uint( object, value, order );
+ return _CPU_atomic_Fetch_or_ulong( object, value, order );
}
static inline uintptr_t _Atomic_Fetch_or_ptr(
@@ -205,13 +205,13 @@ static inline uintptr_t _Atomic_Fetch_or_ptr(
*
* @retval a result value before and ops.
*/
-static inline uint_fast32_t _Atomic_Fetch_and_uint(
- volatile Atomic_Uint *object,
- uint_fast32_t value,
+static inline unsigned long _Atomic_Fetch_and_ulong(
+ volatile Atomic_Ulong *object,
+ unsigned long value,
Atomic_Order order
)
{
- return _CPU_atomic_Fetch_and_uint( object, value, order );
+ return _CPU_atomic_Fetch_and_ulong( object, value, order );
}
static inline uintptr_t _Atomic_Fetch_and_ptr(
@@ -232,13 +232,13 @@ static inline uintptr_t _Atomic_Fetch_and_ptr(
*
* @retval a result value before exchange ops.
*/
-static inline uint_fast32_t _Atomic_Exchange_uint(
- volatile Atomic_Uint *obj
Re: STM32F4 failure on semaphore release in termios.
On 2013-08-31 23:07, Karel Gardas wrote:
On 08/30/13 08:58 AM, Sebastian Huber wrote:
On 2013-08-28 23:30, Karel Gardas wrote:
_Internal_error_Occurred (the_source=RTEMS_FATAL_SOURCE_EXCEPTION,
is_internal=false, the_error=536875260)
If you get an exception like this, then you can use in GDB to figure out
the context (the actual program counter of the exception is not the
direct value of register_pc):
Breakpoint 6, _Internal_error_Occurred
(the_source=RTEMS_FATAL_SOURCE_EXCEPTION, is_internal=false,
the_error=1049524) at
../../../../../../rtems/c/src/../../cpukit/score/src/interr.c:35
35 _User_extensions_Fatal( the_source, is_internal, the_error );
(gdb) p/x *(CPU_Exception_frame *)the_error
$1 = {
Thanks for this nice trick!
(gdb) p/x *(CPU_Exception_frame *)the_error
$2 = {register_r0 = 0x20006acc, register_r1 = 0x1a010004, register_r2 = 0x0,
register_r3 = 0x1a010003, register_r4 = 0x20006ab8, register_r5 = 0x20001794,
register_r6 = 0x20006d80, register_r7 = 0x20003c70, register_r8 = 0x20003e7c,
register_r9 = 0x20001440, register_r10 = 0x0, register_r11 = 0x18fc0,
register_r12 = 0x0, register_sp = 0x0, register_lr = 0xe57b, register_pc =
0xe584, register_xpsr = 0x2100, vector = 0x3, vfp_context = 0x1}
(gdb) dis 0xe584
warning: bad breakpoint number at or near '0xe584'
(gdb) disas 0xe584
Dump of assembler code for function _Chain_Get_first_unprotected:
0xe56c <+0>: push{r7, lr}
0xe56e <+2>: subsp, #24
0xe570 <+4>: addr7, sp, #0
0xe572 <+6>: strr0, [r7, #4]
0xe574 <+8>: ldrr0, [r7, #4]
0xe576 <+10>:bl0xe4d8 <_Chain_Head>
0xe57a <+14>:strr0, [r7, #20]
0xe57c <+16>:ldrr3, [r7, #20]
0xe57e <+18>:ldrr3, [r3, #0]
Above you read head->next.
0xe580 <+20>:strr3, [r7, #16]
0xe582 <+22>:ldrr3, [r7, #16]
0xe584 <+24>:ldrr3, [r3, #0]
Above you read head->next->next;
I think its the instruction above which fails since r3 has a bogus value of
0x1a010003. It looks like that the chain is corrupt.
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
Re: [PATCH] bsp/lm4f120: new BSP to support TI LM4F120 XL LaunchPad board
On 09/ 2/13 12:55 PM, Sebastian Huber wrote: On 2013-09-02 11:03, Eugeniy Meshcheryakov wrote: Hi Sebastian, Could you also commit patch titled [PATCH 1/2] bsp/lm3s69xx: add macros for UART CTS/RTS pin configuration ? The definitions from that patch are used for UART setup. Isn't it this one? http://git.rtems.org/rtems/commit/?id=526f895efe74dfc6b1fc8f98ac546543d49178be Yes, it is. I think everything's all right now -- at least from the TI LMx BSPs point of view. Thanks! Karel ___ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
Re: [PATCH] bsp/lm4f120: new BSP to support TI LM4F120 XL LaunchPad board
On 2013-09-02 11:03, Eugeniy Meshcheryakov wrote: Hi Sebastian, Could you also commit patch titled [PATCH 1/2] bsp/lm3s69xx: add macros for UART CTS/RTS pin configuration ? The definitions from that patch are used for UART setup. Isn't it this one? http://git.rtems.org/rtems/commit/?id=526f895efe74dfc6b1fc8f98ac546543d49178be -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
Re: RTEMS on top of linux or FreeBSD?
On 08/31/2013 04:55 PM, Gedare Bloom wrote: Ralf/Chris, The original poster was asking a different question about executing RTEMS within a host OS environment. May-be, may-be not, I don't want to be sure. Let's wait for the OP to clarify. In the past, questions on "running RTEMS on top of..."/"How to run RTEMS on Linux/Cygwin", "There is no RTEMS app" , often have new-comers', often language-barrier limited/typo-struck questions related to the toolchains. When responding, I didn't even realize this posting could mean something else. Ralf ___ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
Re: [PATCH] bsp/lm4f120: new BSP to support TI LM4F120 XL LaunchPad board
Thanks Eugeniy and Karel for sorting this out. http://git.rtems.org/rtems/commit/?id=0c47440c6a8bc6bab476bf787fb784490377a326 -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
