From funnyvoice at tlabs.ac.za Wed Jul 1 11:13:09 2009 From: funnyvoice at tlabs.ac.za (lee) Date: Wed, 01 Jul 2009 13:13:09 +0200 Subject: i386-gdb-stub compile error And rtems_shell _init error Message-ID: <1246446789.6918.10.camel@lee.tlabs.ac.za> Hi... Excuse all the questions all two of them... 1.) When I try to start the rtems shell with: rtems_shell_init("SHLL",RTEMS_MINIMUM_STACK_SIZE * 4,100,"/dev/console",0,1); the compiler gives me this warning: test.c:195: error: too few arguments to function 'rtems_shell_init' I've checked rtems/shell.h for the correct usage, and this is from a exact example again... not sure what the problem is... clearly compiling is using something else as rtems_shell_init or not? 2.) When I try to compile the gdb debugging example given in i386/shared/comm/GDB-HOWTO , the compiler gives me this error : opt/rtems-4.10/i386-rtems4.10/pc386/lib/librtemsbsp.a(i386-stub.o): In function `debug_error': /opt/rtems/c/src/lib/libbsp/i386/pc386/../../i386/shared/comm/i386-stub.c:575: undefined reference to `remote_debug' /opt/rtems-4.10/i386-rtems4.10/pc386/lib/librtemsbsp.a(i386-stub.o): In function `getpacket': /opt/rtems/c/src/lib/libbsp/i386/pc386/../../i386/shared/comm/i386-stub.c:504: undefined reference to `remote_debug' /opt/rtems/c/src/lib/libbsp/i386/pc386/../../i386/shared/comm/i386-stub.c:504: undefined reference to `remote_debug' /opt/rtems-4.10/i386-rtems4.10/pc386/lib/librtemsbsp.a(i386-stub.o): In function `handle_exception': /opt/rtems/c/src/lib/libbsp/i386/pc386/../../i386/shared/comm/i386-stub.c:758: undefined reference to `remote_debug' /opt/rtems/c/src/lib/libbsp/i386/pc386/../../i386/shared/comm/i386-stub.c:808: undefined reference to `remote_debug' Im busy figuring out what this means... not having much luck... anyone got any ideas... "extern int remote_debug"?? what is the use for this variable.... Kind Regards Much Love Lee From joel.sherrill at OARcorp.com Wed Jul 1 12:00:59 2009 From: joel.sherrill at OARcorp.com (Joel Sherrill) Date: Wed, 1 Jul 2009 07:00:59 -0500 Subject: i386-gdb-stub compile error And rtems_shell _init error In-Reply-To: <1246446789.6918.10.camel@lee.tlabs.ac.za> References: <1246446789.6918.10.camel@lee.tlabs.ac.za> Message-ID: <4A4B4FFB.9030706@oarcorp.com> lee wrote: > Hi... > > Excuse all the questions all two of them... > > 1.) When I try to start the rtems shell with: > > rtems_shell_init("SHLL",RTEMS_MINIMUM_STACK_SIZE * > 4,100,"/dev/console",0,1); > > the compiler gives me this warning: > > test.c:195: error: too few arguments to function 'rtems_shell_init' > > I've checked rtems/shell.h for the correct usage, and this is from a > exact example again... not sure what the problem is... clearly compiling > is using something else as rtems_shell_init or not? > > The calling sequence changed in the past few months on the CVS head. If you are looking at the telnetd example for the call, you will need to update your tree. testsuites/samples/fileio also calls it. > 2.) When I try to compile the gdb debugging example given in > i386/shared/comm/GDB-HOWTO , the compiler gives me this error : > > opt/rtems-4.10/i386-rtems4.10/pc386/lib/librtemsbsp.a(i386-stub.o): In > function `debug_error': > /opt/rtems/c/src/lib/libbsp/i386/pc386/../../i386/shared/comm/i386-stub.c:575: undefined reference to `remote_debug' > /opt/rtems-4.10/i386-rtems4.10/pc386/lib/librtemsbsp.a(i386-stub.o): In > function `getpacket': > /opt/rtems/c/src/lib/libbsp/i386/pc386/../../i386/shared/comm/i386-stub.c:504: undefined reference to `remote_debug' > /opt/rtems/c/src/lib/libbsp/i386/pc386/../../i386/shared/comm/i386-stub.c:504: undefined reference to `remote_debug' > /opt/rtems-4.10/i386-rtems4.10/pc386/lib/librtemsbsp.a(i386-stub.o): In > function `handle_exception': > /opt/rtems/c/src/lib/libbsp/i386/pc386/../../i386/shared/comm/i386-stub.c:758: undefined reference to `remote_debug' > /opt/rtems/c/src/lib/libbsp/i386/pc386/../../i386/shared/comm/i386-stub.c:808: undefined reference to `remote_debug' > > extern int remote_debug; /* debug > 0 prints ill-formed commands in valid packets & checksum errors */ You will have to declare this in your program somewhere so you can set the initial gdb protocol debug level. > Im busy figuring out what this means... not having much luck... anyone > got any ideas... "extern int remote_debug"?? what is the use for this > variable.... > > > Kind Regards Much Love > Lee > > _______________________________________________ > rtems-users mailing list > rtems-users at rtems.org > http://www.rtems.org/mailman/listinfo/rtems-users > --joel From chrisj at rtems.org Wed Jul 1 12:01:44 2009 From: chrisj at rtems.org (Chris Johns) Date: Wed, 01 Jul 2009 22:01:44 +1000 Subject: i386-gdb-stub compile error And rtems_shell _init error In-Reply-To: <1246446789.6918.10.camel@lee.tlabs.ac.za> References: <1246446789.6918.10.camel@lee.tlabs.ac.za> Message-ID: <4A4B5028.20506@rtems.org> lee wrote: > Hi... > > Excuse all the questions all two of them... > > 1.) When I try to start the rtems shell with: > > rtems_shell_init("SHLL",RTEMS_MINIMUM_STACK_SIZE * > 4,100,"/dev/console",0,1); > > the compiler gives me this warning: > > test.c:195: error: too few arguments to function 'rtems_shell_init' > > I've checked rtems/shell.h for the correct usage, and this is from a > exact example again... not sure what the problem is... clearly compiling > is using something else as rtems_shell_init or not? > I use: /** * Start the RTEMS Shell. */ void shell_start () { rtems_status_code sc; printf ("Starting shell....\n\n"); sc = rtems_shell_init ("fstst", 60 * 1024, 150, "/dev/console", 0, 1, NULL); if (sc != RTEMS_SUCCESSFUL) printf ("error: starting shell: %s (%d)\n", rtems_status_text (sc), sc); } I suspect something has changed and the documentation is not up to date. > > 2.) When I try to compile the gdb debugging example given in > i386/shared/comm/GDB-HOWTO , the compiler gives me this error : > > opt/rtems-4.10/i386-rtems4.10/pc386/lib/librtemsbsp.a(i386-stub.o): In > function `debug_error': > /opt/rtems/c/src/lib/libbsp/i386/pc386/../../i386/shared/comm/i386-stub.c:575: undefined reference to `remote_debug' > /opt/rtems-4.10/i386-rtems4.10/pc386/lib/librtemsbsp.a(i386-stub.o): In > function `getpacket': > /opt/rtems/c/src/lib/libbsp/i386/pc386/../../i386/shared/comm/i386-stub.c:504: undefined reference to `remote_debug' > /opt/rtems/c/src/lib/libbsp/i386/pc386/../../i386/shared/comm/i386-stub.c:504: undefined reference to `remote_debug' > /opt/rtems-4.10/i386-rtems4.10/pc386/lib/librtemsbsp.a(i386-stub.o): In > function `handle_exception': > /opt/rtems/c/src/lib/libbsp/i386/pc386/../../i386/shared/comm/i386-stub.c:758: undefined reference to `remote_debug' > /opt/rtems/c/src/lib/libbsp/i386/pc386/../../i386/shared/comm/i386-stub.c:808: undefined reference to `remote_debug' > > Im busy figuring out what this means... not having much luck... anyone > got any ideas... "extern int remote_debug"?? what is the use for this > variable.... > Not sure. I attach the file I use with this code in main: #if pc586 int arg; for (arg = 1; arg < argc; arg++) if (strcmp (argv[arg], "--gdb") == 0) pc386_gdb_init (); #endif This from the file system test code you can find here: http://www.rtems.org/ftp/pub/rtems/people/chrisj/file-system/rfs-20090612.tar.gz Regards Chris -------------- next part -------------- A non-text attachment was scrubbed... Name: pc386-gdb.c Type: text/x-csrc Size: 558 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pc386-gdb.h Type: text/x-chdr Size: 228 bytes Desc: not available URL: From fabricio at dea.inpe.br Wed Jul 1 13:02:50 2009 From: fabricio at dea.inpe.br (=?iso-8859-1?Q?Fabr=EDcio_de_Novaes_Kucinskis?=) Date: Wed, 1 Jul 2009 10:02:50 -0300 Subject: Possible error in the C User's Guide Message-ID: <20090701132637.A297F128A47@satelite.dea.inpe.br> Hello, In the C User?s Guide for RTEMS 4.9.2, at the botton of page 157 (REGION_GET_SEGMENT), the description for RTEMS_WAIT woudn't be "task will wait for a segment" instead of a ?wait for a semaphore?? Regards, Fabr?cio. -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel at gaisler.com Wed Jul 1 13:08:39 2009 From: daniel at gaisler.com (Daniel Hellstrom) Date: Wed, 01 Jul 2009 15:08:39 +0200 Subject: Multiprocessor problems In-Reply-To: <4A3A5C62.5080504@oarcorp.com> References: <22282CD520B39B4AB380985121DF4B0E0FFFF4CA68@MAIL03.ug.kth.se> <4A16C4D7.9020800@oarcorp.com> <4A3A0170.7060906@gaisler.com> <4A3A5C62.5080504@oarcorp.com> Message-ID: <4A4B5FD7.7060701@gaisler.com> Hi Joel, I have attached a patch which introduces a new "early" MP initialization routine. This works for SPARC/LEON3 MP. Daniel Joel Sherrill wrote: > Can you provide a patch Daniel? > > Daniel Hellstrom wrote: > >> Hi, >> >> The problem seems to be the initialization of _Objects_Local_node in >> multiprocessor enabled kernels. Since the _MPCI_Initialization() >> initializes _Objects_Local_node later than the first semaphores and >> tasks are created, this makes the IDs assigned to created objects >> incorrect. >> >> In single processor systems the _Objects_Local_node is a constant set >> to 1, but in multiprocessor systems it is initially set to zero and >> then initialized by _MPCI_Initialization(). >> >> The problem you experience is probably the same problem I ran into >> this week when running on a dual core SPARC/LEON3 system. Two tasks >> are created before the node number is setup correctly. See below >> print out from GRMON after breaking at Init(): >> >> grmon> thread info >> >> Name | Type | Id | Prio | Time (h:m:s) | Entry >> point | PC | State >> --------------------------------------------------------------------------------------------------------------------------------------- >> >> Int. | internal | 0x09000001 | 255 | 0.000000 | >> ?? | 0x0 | READY >> --------------------------------------------------------------------------------------------------------------------------------------- >> >> Int. | classic | 0x09000002 | 0 | 0.000000 | ?? >> | 0x0 | Wsem >> --------------------------------------------------------------------------------------------------------------------------------------- >> >> * UI1 | classic | 0x0a010001 | 1 | 0.000000 | >> RAM_END | 0x40001368 Init + >> 0x4 | READY >> --------------------------------------------------------------------------------------------------------------------------------------- >> >> >> As you can see the node number is 0 rather than 1 or 2 in the ID field. >> >> The bug appears when the first MPCI packet is received on the target >> node, the ISR calls _MCPI_Announce which tries to release a >> semaphore, the blocked thread are thought to be global and the system >> crashes. The function deciding if it is a global or local object >> simply checks if they are of the same node, not if the node number is >> zero. >> >> RTEMS_INLINE_ROUTINE bool _Objects_Is_local_node( >> uint32_t node >> ) >> { >> return ( node == _Objects_Local_node ); >> } >> >> To test that this theory holds I changed the declaration of >> _Objects_Local_node to extern instead of SCORE_EXTERN, and declared >> it in my project initialy initialized to the node number. The LEON3 >> dual core system now works and I have successfully managed to get >> semaphores and tasks interacting between the two nodes. >> >> uint16_t _Objects_Local_node = CONFIGURE_MP_NODE_NUMBER; >> >> >> >> I suggest that the initialization of _Objects_Local_node is moved to >> be initialized earlier. >> >> Regards, >> Daniel Hellstrom >> >> >> >> Joel Sherrill wrote: >> >> >> >>> Roger Dahlkvist wrote: >>> >>> >>> >>> >>>> Hi, >>>> >>>> I'm using a timer ISR polling method checking for new messages from >>>> other nodes. Unfortunately the system crashes as soon as >>>> rtems_multiprocessing_announce is called. >>>> >>>> >>>> >>> >>> There are no interrupts enabled until the initialization task is >>> switched >>> in. >>> >>> I have wondered if it wouldn't make sense to have the MP initialization >>> sycnhronization done either explicitly by the application (like >>> initialization >>> of TCP/IP) or implicitly by the init thread like C++ global >>> constructors. >>> >>> You can try moving this code from exinit.c to threadhandler.c where and >>> protect it somehow from being executed more than once. >>> >>> #if defined(RTEMS_MULTIPROCESSING) >>> if ( _System_state_Is_multiprocessing ) { >>> _MPCI_Initialization(); >>> _MPCI_Internal_packets_Send_process_packet( >>> MPCI_PACKETS_SYSTEM_VERIFY >>> ); >>> } >>> #endif >>> >>> Then you will at least be able to get your interrupts and call MP >>> announce >>> to complete system initialization. >>> >>> >>> >>> >>>> However, rtems_multiprocessing_announce works just fine if it's >>>> called just after the initialization phase, before the >>>> initinitialization task is started. That's really strange. >>>> >>>> So for example, if I make one node get initialized and started >>>> faster than the other node (using less drivers etc), I'll be able >>>> to create global objects. and as long as the other node has not >>>> started the initialization task, the message is received and the >>>> global objects table is updated, so it can be identified later on. >>>> But I can't use them since furter calls to >>>> rtems_multiprocessing_announce will fail. >>>> >>>> At this point I feel like I have tested just about everything, with >>>> no luck. It's urgent that I get MP to work properly. I'm using Nios >>>> II processors and I have defined my own MPCI routines. I'm >>>> confident that they work properly and I have verified that the >>>> system crashes before they are even invoked. >>>> >>>> Is there anyone with MP experience who might have a clue of what's >>>> causing my problems? Any help is MUCH appreciated. >>>> >>>> //Roger >>>> >>>> _______________________________________________ >>>> rtems-users mailing list >>>> rtems-users at rtems.org >>>> http://www.rtems.org/mailman/listinfo/rtems-users >>>> >>>> >>>> >>> >>> >>> >>> >> >> >> > > > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Object_Local_node.patch URL: From daniel at gaisler.com Wed Jul 1 13:14:03 2009 From: daniel at gaisler.com (Daniel Hellstrom) Date: Wed, 01 Jul 2009 15:14:03 +0200 Subject: Multiprocessor problems In-Reply-To: <4A3A5CA8.7010807@oarcorp.com> References: <22282CD520B39B4AB380985121DF4B0E0FFFF4CA68@MAIL03.ug.kth.se> <4A16C4D7.9020800@oarcorp.com> <4A3A0170.7060906@gaisler.com> <4A3A2F8A.4030206@gaisler.com> <4A3A5CA8.7010807@oarcorp.com> Message-ID: <4A4B611B.6060808@gaisler.com> Hello, The init task name is defined by confdef.h, it is possible to set the init task name to a custom name using the CONFIGURE_INIT_TASK_NAME define, for example: #define CONFIGURE_INIT_TASK_NAME rtems_build_name('U', 'I', '0'+CONFIGURE_MP_NODE_NUMBER, ' ') Perhaps a patch is not needed in this case? Daniel Joel Sherrill wrote: > Provide a patch and I will merge it. :) > > --joel > > Daniel Hellstrom wrote: > >> Hi, >> >> On a similar MP topic, all Init tasks have the same name "UI1" >> regardless of CPU node. I have seen in the mptests that the >> CONFIGURE_INIT_TASK_ATTRIBUTES is set to RTEMS_GLOBAL, this means >> that the rtems_ident_task() can not be used to look up the ID of the >> remote node's Init task. Perhaps the Init task name could be >> {'U','I','0'+nodeid,'\0'} instead? >> >> >> GRMON thread info output from the two LEON3 CPUs, CPU0 >> [0x40000000-0x43FFFFFF0] and CPU1 [0x44000000-0x47FFFFFF0]: >> >> grlib> sym rtems-mp1 >> read 1456 symbols >> entry point: 0x40000000 >> grlib> thread info >> >> Name | Type | Id | Prio | Time (h:m:s) | Entry >> point | PC | State >> --------------------------------------------------------------------------------------------------------------------------------------- >> >> Int. | internal | 0x09010001 | 255 | 0.000000 | >> _BSP_Thread_Idle_body | 0x400030a4 _BSP_Thread_Idle_body + >> 0x0 | READY >> --------------------------------------------------------------------------------------------------------------------------------------- >> >> Int. | classic | 0x09010002 | 0 | 0.005648 | >> _MPCI_Receive_server | 0x4000c66c _Thread_Dispatch + >> 0xd8 | Wsem >> --------------------------------------------------------------------------------------------------------------------------------------- >> >> * UI1 | classic | 0x0a010001 | 1 | 0.000000 | >> Init | 0x40001368 Init + >> 0x4 | READY >> --------------------------------------------------------------------------------------------------------------------------------------- >> >> >> grlib> sym rtems-mp2 >> read 1456 symbols >> entry point: 0x44000000 >> grlib> thread info >> >> Name | Type | Id | Prio | Time (h:m:s) | Entry >> point | PC | State >> --------------------------------------------------------------------------------------------------------------------------------------- >> >> Int. | internal | 0x09020001 | 255 | 0.000000 | >> _BSP_Thread_Idle_body | 0x440030a4 _BSP_Thread_Idle_body + >> 0x0 | READY >> --------------------------------------------------------------------------------------------------------------------------------------- >> >> Int. | classic | 0x09020002 | 0 | 0.005661 | >> _MPCI_Receive_server | 0x4400c66c _Thread_Dispatch + >> 0xd8 | Wsem >> --------------------------------------------------------------------------------------------------------------------------------------- >> >> * UI1 | classic | 0x0a020001 | 1 | 0.000000 | >> Init | 0x40001368 _RAM_SIZE + >> 0x3c00136c | READY >> --------------------------------------------------------------------------------------------------------------------------------------- >> >> >> >> Daniel >> >> >> >> Daniel Hellstrom wrote: >> >> >> >>> Hi, >>> >>> The problem seems to be the initialization of _Objects_Local_node in >>> multiprocessor enabled kernels. Since the _MPCI_Initialization() >>> initializes _Objects_Local_node later than the first semaphores and >>> tasks are created, this makes the IDs assigned to created objects >>> incorrect. >>> >>> In single processor systems the _Objects_Local_node is a constant >>> set to 1, but in multiprocessor systems it is initially set to zero >>> and then initialized by _MPCI_Initialization(). >>> >>> The problem you experience is probably the same problem I ran into >>> this week when running on a dual core SPARC/LEON3 system. Two tasks >>> are created before the node number is setup correctly. See below >>> print out >> >> >from GRMON after breaking at Init(): >> >> >>> grmon> thread info >>> >>> Name | Type | Id | Prio | Time (h:m:s) | Entry >>> point | PC | >>> State >>> --------------------------------------------------------------------------------------------------------------------------------------- >>> >>> Int. | internal | 0x09000001 | 255 | 0.000000 | >>> ?? | 0x0 | READY >>> --------------------------------------------------------------------------------------------------------------------------------------- >>> >>> Int. | classic | 0x09000002 | 0 | 0.000000 | ?? >>> | 0x0 | Wsem >>> --------------------------------------------------------------------------------------------------------------------------------------- >>> >>> * UI1 | classic | 0x0a010001 | 1 | 0.000000 | >>> RAM_END | 0x40001368 Init + >>> 0x4 | READY >>> --------------------------------------------------------------------------------------------------------------------------------------- >>> >>> >>> As you can see the node number is 0 rather than 1 or 2 in the ID field. >>> >>> The bug appears when the first MPCI packet is received on the target >>> node, the ISR calls _MCPI_Announce which tries to release a >>> semaphore, the blocked thread are thought to be global and the >>> system crashes. The function deciding if it is a global or local >>> object simply checks if they are of the same node, not if the node >>> number is zero. >>> >>> RTEMS_INLINE_ROUTINE bool _Objects_Is_local_node( >>> uint32_t node >>> ) >>> { >>> return ( node == _Objects_Local_node ); >>> } >>> >>> To test that this theory holds I changed the declaration of >>> _Objects_Local_node to extern instead of SCORE_EXTERN, and declared >>> it in my project initialy initialized to the node number. The LEON3 >>> dual core system now works and I have successfully managed to get >>> semaphores and tasks interacting between the two nodes. >>> >>> uint16_t _Objects_Local_node = CONFIGURE_MP_NODE_NUMBER; >>> >>> >>> >>> I suggest that the initialization of _Objects_Local_node is moved to >>> be initialized earlier. >>> >>> Regards, >>> Daniel Hellstrom >>> >>> >>> >>> Joel Sherrill wrote: >>> >>> >>> >>> >>> >>>> Roger Dahlkvist wrote: >>>> >>>> >>>> >>>> >>>> >>>>> Hi, >>>>> >>>>> I'm using a timer ISR polling method checking for new messages >>>>> from other nodes. Unfortunately the system crashes as soon as >>>>> rtems_multiprocessing_announce is called. >>>>> >>>>> >>>>> >>>>> >>>> >>>> There are no interrupts enabled until the initialization task is >>>> switched >>>> in. >>>> >>>> I have wondered if it wouldn't make sense to have the MP >>>> initialization >>>> sycnhronization done either explicitly by the application (like >>>> initialization >>>> of TCP/IP) or implicitly by the init thread like C++ global >>>> constructors. >>>> >>>> You can try moving this code from exinit.c to threadhandler.c where >>>> and >>>> protect it somehow from being executed more than once. >>>> >>>> #if defined(RTEMS_MULTIPROCESSING) >>>> if ( _System_state_Is_multiprocessing ) { >>>> _MPCI_Initialization(); >>>> _MPCI_Internal_packets_Send_process_packet( >>>> MPCI_PACKETS_SYSTEM_VERIFY >>>> ); >>>> } >>>> #endif >>>> >>>> Then you will at least be able to get your interrupts and call MP >>>> announce >>>> to complete system initialization. >>>> >>>> >>>> >>>> >>>> >>>>> However, rtems_multiprocessing_announce works just fine if it's >>>>> called just after the initialization phase, before the >>>>> initinitialization task is started. That's really strange. >>>>> >>>>> So for example, if I make one node get initialized and started >>>>> faster than the other node (using less drivers etc), I'll be able >>>>> to create global objects. and as long as the other node has not >>>>> started the initialization task, the message is received and the >>>>> global objects table is updated, so it can be identified later on. >>>>> But I can't use them since furter calls to >>>>> rtems_multiprocessing_announce will fail. >>>>> >>>>> At this point I feel like I have tested just about everything, >>>>> with no luck. It's urgent that I get MP to work properly. I'm >>>>> using Nios II processors and I have defined my own MPCI routines. >>>>> I'm confident that they work properly and I have verified that the >>>>> system crashes before they are even invoked. >>>>> >>>>> Is there anyone with MP experience who might have a clue of what's >>>>> causing my problems? Any help is MUCH appreciated. >>>>> >>>>> //Roger >>>>> >>>>> _______________________________________________ >>>>> rtems-users mailing list >>>>> rtems-users at rtems.org >>>>> http://www.rtems.org/mailman/listinfo/rtems-users >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> _______________________________________________ >>> rtems-users mailing list >>> rtems-users at rtems.org >>> http://www.rtems.org/mailman/listinfo/rtems-users >>> >>> >>> >>> >>> >> >> >> > > > From joel.sherrill at OARcorp.com Wed Jul 1 13:46:15 2009 From: joel.sherrill at OARcorp.com (Joel Sherrill) Date: Wed, 1 Jul 2009 08:46:15 -0500 Subject: RTEMS schedualing example In-Reply-To: References: Message-ID: <4A4B68A7.3000008@oarcorp.com> Nasim Zehra wrote: > dear users, > can any one post any example showing schedualing of two or more than two tasks using rate monotonic directives?This example should be other than that described in RTEMS c user guide manual ans should be in running condition.I am having a bit confusion using these directives.Will be very thankful to you. > > testsuites/libtests/rtmonuse has 5 tasks. > regards > -------- > nasim zahra > _______________________________________________ > rtems-users mailing list > rtems-users at rtems.org > http://www.rtems.org/mailman/listinfo/rtems-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 From funnyvoice at tlabs.ac.za Wed Jul 1 13:59:12 2009 From: funnyvoice at tlabs.ac.za (lee) Date: Wed, 01 Jul 2009 15:59:12 +0200 Subject: Exception ?? Message-ID: <1246456752.6918.19.camel@lee.tlabs.ac.za> Hi All again.... Im running a very simple test program, called hello.exe... So I got the shell working.. thanx again... then tried the gdb... got gdb compiled works fine.... but when I run the target after compiling it i get 0x0a10003 thread 3 exception error? The name of this thread is "UI1"... but cant seem to find this anywhere in source... I grepped just about the entire source tree.... any idea what this could be...??? This happens when I invoke : set_debug_traps(); Here is the startup: i386_stub_glue_init(BSP_UART_COM1); /* Init GDB stub itself */ //set_debug_traps(); /* * Init GDB break in capability, * has to be called after * set_debug_traps */ i386_stub_glue_init_breakin(); I've put a breakpoint somewhere in the source.... anyone have similar problem... Kind Regards Lee From daron.chabot at gmail.com Wed Jul 1 15:29:25 2009 From: daron.chabot at gmail.com (Daron Chabot) Date: Wed, 1 Jul 2009 11:29:25 -0400 Subject: Exception ?? In-Reply-To: <1246456752.6918.19.camel@lee.tlabs.ac.za> References: <1246456752.6918.19.camel@lee.tlabs.ac.za> Message-ID: <50cc54100907010829g5d57d049g71f4aeecbe9bd2da@mail.gmail.com> Exception 3 is a breakpoint exception on the i386 :-) "UI1"... That sounds like the "Init" thread. You are generating a breakpoint from Init... FYI, I have used these commands to initialize the remote-debugging stub and stop program execution, waiting for the host gdb session to connect (over rs-232): init_remote_gdb(); rtems_task_wake_after(25); /* 1 tick == 10 ms */ breakpoint(); -- dc On Wed, Jul 1, 2009 at 9:59 AM, lee wrote: > Hi All again.... > > Im running a very simple test program, called hello.exe... > > So I got the shell working.. thanx again... then tried the gdb... got > gdb compiled works fine.... but when I run the target after compiling it > i get 0x0a10003 thread 3 exception error? The name of this thread is > "UI1"... but cant seem to find this anywhere in source... I grepped just > about the entire source tree.... any idea what this could be...??? > > This happens when I invoke : > > set_debug_traps(); > > Here is the startup: > > > > ?i386_stub_glue_init(BSP_UART_COM1); > > > ?/* Init GDB stub itself */ > ?//set_debug_traps(); > > ?/* > ? * Init GDB break in capability, > ? * has to be called after > ? * set_debug_traps > ? */ > ?i386_stub_glue_init_breakin(); > > > I've put a breakpoint somewhere in the source.... anyone have similar > problem... > > Kind Regards > Lee > > _______________________________________________ > rtems-users mailing list > rtems-users at rtems.org > http://www.rtems.org/mailman/listinfo/rtems-users > From funnyvoice at tlabs.ac.za Thu Jul 2 12:36:07 2009 From: funnyvoice at tlabs.ac.za (lee) Date: Thu, 02 Jul 2009 14:36:07 +0200 Subject: Rtems VME.h VMEDMA.h example of using these API's ? Message-ID: <1246538167.6918.22.camel@lee.tlabs.ac.za> Hi... Does anyone have an example of using just these 2 API's for the vme universe driver? Kind Regards Lee From strauman at slac.stanford.edu Thu Jul 2 14:26:19 2009 From: strauman at slac.stanford.edu (Till Straumann) Date: Thu, 02 Jul 2009 09:26:19 -0500 Subject: Rtems VME.h VMEDMA.h example of using these API's ? In-Reply-To: <1246538167.6918.22.camel@lee.tlabs.ac.za> References: <1246538167.6918.22.camel@lee.tlabs.ac.za> Message-ID: <4A4CC38B.1070801@slac.stanford.edu> lee wrote: > Hi... > > > Does anyone have an example of using just these 2 API's for the vme > universe driver? > > Kind Regards > Lee > > _______________________________________________ > rtems-users mailing list > rtems-users at rtems.org > http://www.rtems.org/mailman/listinfo/rtems-users > I'll send you two example off-line... T. From joel.sherrill at OARcorp.com Fri Jul 3 15:16:59 2009 From: joel.sherrill at OARcorp.com (Joel Sherrill) Date: Fri, 3 Jul 2009 10:16:59 -0500 Subject: Multiprocessor problems In-Reply-To: <4A4B5FD7.7060701@gaisler.com> References: <22282CD520B39B4AB380985121DF4B0E0FFFF4CA68@MAIL03.ug.kth.se> <4A16C4D7.9020800@oarcorp.com> <4A3A0170.7060906@gaisler.com> <4A3A5C62.5080504@oarcorp.com> <4A4B5FD7.7060701@gaisler.com> Message-ID: <4A4E20EB.6020807@oarcorp.com> Daniel Hellstrom wrote: > Hi Joel, > > I have attached a patch which introduces a new "early" MP initialization > routine. This works for SPARC/LEON3 MP. > > Committed to the head. Does this also need to go on the 4.9 branch? What were you testing with? --joel > Daniel > > > Joel Sherrill wrote: > > >> Can you provide a patch Daniel? >> >> Daniel Hellstrom wrote: >> >> >>> Hi, >>> >>> The problem seems to be the initialization of _Objects_Local_node in >>> multiprocessor enabled kernels. Since the _MPCI_Initialization() >>> initializes _Objects_Local_node later than the first semaphores and >>> tasks are created, this makes the IDs assigned to created objects >>> incorrect. >>> >>> In single processor systems the _Objects_Local_node is a constant set >>> to 1, but in multiprocessor systems it is initially set to zero and >>> then initialized by _MPCI_Initialization(). >>> >>> The problem you experience is probably the same problem I ran into >>> this week when running on a dual core SPARC/LEON3 system. Two tasks >>> are created before the node number is setup correctly. See below >>> print out from GRMON after breaking at Init(): >>> >>> grmon> thread info >>> >>> Name | Type | Id | Prio | Time (h:m:s) | Entry >>> point | PC | State >>> --------------------------------------------------------------------------------------------------------------------------------------- >>> >>> Int. | internal | 0x09000001 | 255 | 0.000000 | >>> ?? | 0x0 | READY >>> --------------------------------------------------------------------------------------------------------------------------------------- >>> >>> Int. | classic | 0x09000002 | 0 | 0.000000 | ?? >>> | 0x0 | Wsem >>> --------------------------------------------------------------------------------------------------------------------------------------- >>> >>> * UI1 | classic | 0x0a010001 | 1 | 0.000000 | >>> RAM_END | 0x40001368 Init + >>> 0x4 | READY >>> --------------------------------------------------------------------------------------------------------------------------------------- >>> >>> >>> As you can see the node number is 0 rather than 1 or 2 in the ID field. >>> >>> The bug appears when the first MPCI packet is received on the target >>> node, the ISR calls _MCPI_Announce which tries to release a >>> semaphore, the blocked thread are thought to be global and the system >>> crashes. The function deciding if it is a global or local object >>> simply checks if they are of the same node, not if the node number is >>> zero. >>> >>> RTEMS_INLINE_ROUTINE bool _Objects_Is_local_node( >>> uint32_t node >>> ) >>> { >>> return ( node == _Objects_Local_node ); >>> } >>> >>> To test that this theory holds I changed the declaration of >>> _Objects_Local_node to extern instead of SCORE_EXTERN, and declared >>> it in my project initialy initialized to the node number. The LEON3 >>> dual core system now works and I have successfully managed to get >>> semaphores and tasks interacting between the two nodes. >>> >>> uint16_t _Objects_Local_node = CONFIGURE_MP_NODE_NUMBER; >>> >>> >>> >>> I suggest that the initialization of _Objects_Local_node is moved to >>> be initialized earlier. >>> >>> Regards, >>> Daniel Hellstrom >>> >>> >>> >>> Joel Sherrill wrote: >>> >>> >>> >>> >>>> Roger Dahlkvist wrote: >>>> >>>> >>>> >>>> >>>> >>>>> Hi, >>>>> >>>>> I'm using a timer ISR polling method checking for new messages from >>>>> other nodes. Unfortunately the system crashes as soon as >>>>> rtems_multiprocessing_announce is called. >>>>> >>>>> >>>>> >>>>> >>>> There are no interrupts enabled until the initialization task is >>>> switched >>>> in. >>>> >>>> I have wondered if it wouldn't make sense to have the MP initialization >>>> sycnhronization done either explicitly by the application (like >>>> initialization >>>> of TCP/IP) or implicitly by the init thread like C++ global >>>> constructors. >>>> >>>> You can try moving this code from exinit.c to threadhandler.c where and >>>> protect it somehow from being executed more than once. >>>> >>>> #if defined(RTEMS_MULTIPROCESSING) >>>> if ( _System_state_Is_multiprocessing ) { >>>> _MPCI_Initialization(); >>>> _MPCI_Internal_packets_Send_process_packet( >>>> MPCI_PACKETS_SYSTEM_VERIFY >>>> ); >>>> } >>>> #endif >>>> >>>> Then you will at least be able to get your interrupts and call MP >>>> announce >>>> to complete system initialization. >>>> >>>> >>>> >>>> >>>> >>>>> However, rtems_multiprocessing_announce works just fine if it's >>>>> called just after the initialization phase, before the >>>>> initinitialization task is started. That's really strange. >>>>> >>>>> So for example, if I make one node get initialized and started >>>>> faster than the other node (using less drivers etc), I'll be able >>>>> to create global objects. and as long as the other node has not >>>>> started the initialization task, the message is received and the >>>>> global objects table is updated, so it can be identified later on. >>>>> But I can't use them since furter calls to >>>>> rtems_multiprocessing_announce will fail. >>>>> >>>>> At this point I feel like I have tested just about everything, with >>>>> no luck. It's urgent that I get MP to work properly. I'm using Nios >>>>> II processors and I have defined my own MPCI routines. I'm >>>>> confident that they work properly and I have verified that the >>>>> system crashes before they are even invoked. >>>>> >>>>> Is there anyone with MP experience who might have a clue of what's >>>>> causing my problems? Any help is MUCH appreciated. >>>>> >>>>> //Roger >>>>> >>>>> _______________________________________________ >>>>> rtems-users mailing list >>>>> rtems-users at rtems.org >>>>> http://www.rtems.org/mailman/listinfo/rtems-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 From joel.sherrill at OARcorp.com Fri Jul 3 20:37:22 2009 From: joel.sherrill at OARcorp.com (Joel Sherrill) Date: Fri, 3 Jul 2009 15:37:22 -0500 Subject: Was RTEMS user in Fermilabs Discovery? Message-ID: <4A4E6C02.1090009@oarcorp.com> Hi, I saw that Fermilab?s announced the discovery of a new particle, the Omega-sub-b (?_b ), and wondered if RTEMS and EPICS played a role in this. -- 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 From asporner at googlemail.com Fri Jul 3 20:44:55 2009 From: asporner at googlemail.com (Andrew Sporner) Date: Fri, 3 Jul 2009 22:44:55 +0200 Subject: Was RTEMS user in Fermilabs Discovery? In-Reply-To: <4A4E6C02.1090009@oarcorp.com> References: <4A4E6C02.1090009@oarcorp.com> Message-ID: <5cbbb9e90907031344m6f83c678h5bbc24ca837777d1@mail.gmail.com> Years ago when I was an intern at feynman computer center it was mostly big-Os stuff. I do recall Risc/Os being used for the 68K based stuff and even the ACP/Maps which at the time was the biggest supercomputer, but that was some time ago. Andy On Fri, Jul 3, 2009 at 10:37 PM, Joel Sherrill wrote: > Hi, > > I saw that Fermilab?s announced the discovery > of a new particle, the Omega-sub-b (?_b ), and > wondered if RTEMS and EPICS played a role in > this. > > -- > 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 > > > _______________________________________________ > rtems-users mailing list > rtems-users at rtems.org > http://www.rtems.org/mailman/listinfo/rtems-users > From asporner at googlemail.com Fri Jul 3 20:45:44 2009 From: asporner at googlemail.com (Andrew Sporner) Date: Fri, 3 Jul 2009 22:45:44 +0200 Subject: Was RTEMS user in Fermilabs Discovery? In-Reply-To: <5cbbb9e90907031344m6f83c678h5bbc24ca837777d1@mail.gmail.com> References: <4A4E6C02.1090009@oarcorp.com> <5cbbb9e90907031344m6f83c678h5bbc24ca837777d1@mail.gmail.com> Message-ID: <5cbbb9e90907031345h26b9bd45ud7ddd799d1d70994@mail.gmail.com> Just realized I goofed that, it was the I860 stuff. 2009/7/3 Andrew Sporner : > Years ago when I was an intern at feynman computer center it was mostly > big-Os stuff. ?I do recall Risc/Os being used for the 68K based stuff and even > the ACP/Maps which at the time was the biggest supercomputer, but that was > some time ago. > > Andy > > On Fri, Jul 3, 2009 at 10:37 PM, Joel Sherrill wrote: >> Hi, >> >> I saw that Fermilab?s announced the discovery >> of a new particle, the Omega-sub-b (?_b ), and >> wondered if RTEMS and EPICS played a role in >> this. >> >> -- >> 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 >> >> >> _______________________________________________ >> rtems-users mailing list >> rtems-users at rtems.org >> http://www.rtems.org/mailman/listinfo/rtems-users >> > From joel.sherrill at OARcorp.com Fri Jul 3 20:49:41 2009 From: joel.sherrill at OARcorp.com (Joel Sherrill) Date: Fri, 3 Jul 2009 15:49:41 -0500 Subject: Was RTEMS user in Fermilabs Discovery? In-Reply-To: <5cbbb9e90907031345h26b9bd45ud7ddd799d1d70994@mail.gmail.com> References: <4A4E6C02.1090009@oarcorp.com> <5cbbb9e90907031344m6f83c678h5bbc24ca837777d1@mail.gmail.com> <5cbbb9e90907031345h26b9bd45ud7ddd799d1d70994@mail.gmail.com> Message-ID: <4A4E6EE5.6030003@oarcorp.com> Andrew Sporner wrote: > Just realized I goofed that, it was the I860 stuff. > > 2009/7/3 Andrew Sporner : > >> Years ago when I was an intern at feynman computer center it was mostly >> big-Os stuff. I do recall Risc/Os being used for the 68K based stuff and even >> the ACP/Maps which at the time was the biggest supercomputer, but that was >> some time ago. >> I found some requirement docs on the web from there that indicates that they do use RTEMS on at least some control equipment. Just curious if it made the lab stuff for this discovery. --joel >> Andy >> >> On Fri, Jul 3, 2009 at 10:37 PM, Joel Sherrill wrote: >> >>> Hi, >>> >>> I saw that Fermilab?s announced the discovery >>> of a new particle, the Omega-sub-b (?_b ), and >>> wondered if RTEMS and EPICS played a role in >>> this. >>> >>> -- >>> 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 >>> >>> >>> _______________________________________________ >>> rtems-users mailing list >>> rtems-users at rtems.org >>> http://www.rtems.org/mailman/listinfo/rtems-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 From siddons at bnl.gov Fri Jul 3 21:30:00 2009 From: siddons at bnl.gov (D. Peter Siddons) Date: Fri, 03 Jul 2009 17:30:00 -0400 Subject: Was RTEMS user in Fermilabs Discovery? In-Reply-To: <4A4E6C02.1090009@oarcorp.com> References: <4A4E6C02.1090009@oarcorp.com> Message-ID: <4A4E7858.1080400@bnl.gov> Hi Joel, According to the FNAL web site, both D0 and CDF use EPICS as part of their control system, but I couldn't find any reference to RTEMS. The new particle came from CDF. The D0 page has info about VxWorks. That said, many EPICS folks are looking hard at RTEMS as it becomes more visible in projects like Stanford's LCLS. Pete. Joel Sherrill wrote: > Hi, > > I saw that Fermilab?s announced the discovery > of a new particle, the Omega-sub-b (?_b ), and > wondered if RTEMS and EPICS played a role in > this. > -- D. Peter Siddons Detector Development Group Leader National Synchrotron Light Source Brookhaven National Laboratory Upton, NY 11973 email: siddons at bnl.gov Phone: (631) 344-2738 From jszhang3 at gmail.com Fri Jul 3 23:12:22 2009 From: jszhang3 at gmail.com (JiSheng Zhang) Date: Sat, 4 Jul 2009 07:12:22 +0800 Subject: [GSOC] Dynamic object file loading status Message-ID: <2df346410907031612j6cafcd0o6c80adfdd16b8147@mail.gmail.com> Hi all, My coding started on 15 June. It's too late. I hope I can catch up with other students. As for the project status: I have implemented a loader under Linux. The code is based on bionic(android libc) linker, but the object file loading and symbol resolving and ?relocation will be rewritten. It seems ?that object file loading and parsing, symbol resolving and relocation works fine. But the object is entirely readed into memory, ?we only need to load sections such as .text .data .symtab etc. So I rewrite some code of the loader, now the resolving and relocation doesn't work! (Segmentation fault). The reason is that before call update_symbols I need to update the section table first. This will be fixed this week. All the code is attached. Limitation:only support x86 now, need to implement relocation on other arch. Some Q&A: Why I choose implement a loader under Linux? Because the debug is easy, once the loader under Linux completed, it can be easily ported to rtems. Why git? I often have no internet access. So code.google.com is not an idea project hosting place. I choose github. Comments are welcomed. Thanks, JiSheng -------------- next part -------------- A non-text attachment was scrubbed... Name: linker.tar.bz2 Type: application/x-bzip2 Size: 9760 bytes Desc: not available URL: From joel.sherrill at OARcorp.com Sat Jul 4 14:46:07 2009 From: joel.sherrill at OARcorp.com (Joel Sherrill) Date: Sat, 4 Jul 2009 09:46:07 -0500 Subject: Was RTEMS user in Fermilabs Discovery? In-Reply-To: <4A4E7858.1080400@bnl.gov> References: <4A4E6C02.1090009@oarcorp.com> <4A4E7858.1080400@bnl.gov> Message-ID: <4A4F6B2F.4070102@oarcorp.com> D. Peter Siddons wrote: > Hi Joel, > According to the FNAL web site, both D0 and CDF use EPICS as part of > their control system, but I couldn't find any reference to RTEMS. The > new particle came from CDF. The D0 page has info about VxWorks. That > said, many EPICS folks are looking hard at RTEMS as it becomes more > visible in projects like Stanford's LCLS. > I found this document online which is recent and does mention RTEMS with no hint to me as to whether it is really used or in what. http://docdb.fnal.gov/ILC/DocDB/0003/000325/015/NML_ControlsRequirements.doc Hard to know anything. --joel > Pete. > > > Joel Sherrill wrote: > >> Hi, >> >> I saw that Fermilab?s announced the discovery >> of a new particle, the Omega-sub-b (?_b ), and >> wondered if RTEMS and EPICS played a role in >> this. >> >> > > From joel.sherrill at OARcorp.com Sat Jul 4 14:59:58 2009 From: joel.sherrill at OARcorp.com (Joel Sherrill) Date: Sat, 4 Jul 2009 09:59:58 -0500 Subject: [GSOC] Dynamic object file loading status In-Reply-To: <2df346410907031612j6cafcd0o6c80adfdd16b8147@mail.gmail.com> References: <2df346410907031612j6cafcd0o6c80adfdd16b8147@mail.gmail.com> Message-ID: <4A4F6E6E.3090004@oarcorp.com> JiSheng Zhang wrote: > Hi all, > > My coding started on 15 June. It's too late. I hope I can catch up > with other students. > > If you are debugging code, then you are probably on track. :) > As for the project status: > I have implemented a loader under Linux. The code is based on > bionic(android libc) linker, but the object file loading and symbol > resolving and relocation will be rewritten. It seems that object > file loading and parsing, symbol resolving and relocation works fine. > But the object is entirely readed into memory, we only need to load > sections such as .text .data .symtab etc. So I rewrite some code of > the loader, now the resolving and relocation doesn't work! > (Segmentation fault). The reason is that before call update_symbols I > need to update the section table first. This will be fixed this week. > All the code is attached. > Holiday weekend in the States. Hopefully I will get to try it next week when it works. > Limitation:only support x86 now, need to implement relocation on other arch. > > Random comments: + What is the license for Android libc? I recall BSD. Is this right? + What version did you use? Isolate RTEMS specific changes and try to get them as ifdef's into their code base. Document procedure for getting their source and updating it. Getting updates from third party source like this is a fact of life and you need to ensure that it is easy to do so in the future. + The procedure for users creating and loading their own modules must be very clearly documented. > Some Q&A: > Why I choose implement a loader under Linux? Because the debug is > easy, once the loader under Linux completed, it can be easily ported > to rtems. > I think many of us have done the same thing. Many of the posix tests I wrote for RTEMS were developed under Linux first. :) > Why git? I often have no internet access. So code.google.com is not an > idea project hosting place. I choose github. > > code.google.com doesn't have to be your source code control site. But you have to drop code their in the end to get Google to pay you. So putting the intermediate and final drops on their is a good thing. > Comments are welcomed. > > Thanks, > JiSheng > From joel.sherrill at OARcorp.com Sat Jul 4 15:04:13 2009 From: joel.sherrill at OARcorp.com (Joel Sherrill) Date: Sat, 4 Jul 2009 10:04:13 -0500 Subject: Summer of Code Students/Mentors Announcement Message-ID: <4A4F6F6D.8030600@oarcorp.com> Hi, We are at mid-term. Mentors will be doing reviews next week so a payment can be made to you. Students should be submitting progress reports anyway but I would really appreciate a mid-term report to the user's list. I want to collect them and put out an overall mid-term report. --joel From daniel at gaisler.com Sat Jul 4 14:58:38 2009 From: daniel at gaisler.com (Daniel Hellstrom) Date: Sat, 04 Jul 2009 16:58:38 +0200 Subject: Multiprocessor problems In-Reply-To: <4A4E20EB.6020807@oarcorp.com> References: <22282CD520B39B4AB380985121DF4B0E0FFFF4CA68@MAIL03.ug.kth.se> <4A16C4D7.9020800@oarcorp.com> <4A3A0170.7060906@gaisler.com> <4A3A5C62.5080504@oarcorp.com> <4A4B5FD7.7060701@gaisler.com> <4A4E20EB.6020807@oarcorp.com> Message-ID: <4A4F6E1E.9090908@gaisler.com> Joel Sherrill wrote: > Daniel Hellstrom wrote: > >> Hi Joel, >> >> I have attached a patch which introduces a new "early" MP >> initialization routine. This works for SPARC/LEON3 MP. >> >> > > Committed to the head. Does this also need to go on the 4.9 branch? Have not investigated this, am on my summer holidays now until 1:st aug. > > What were you testing with? SPARC/LEON3 Dual Core, 256MB SDRAM, 5 Timers, 2 UARTs, PCI and Ethernet. Booting from RAM using GRMON, and from FLASH using mkprom. Daniel > > --joel > >> Daniel >> >> >> Joel Sherrill wrote: >> >> >> >>> Can you provide a patch Daniel? >>> >>> Daniel Hellstrom wrote: >>> >>> >>> >>>> Hi, >>>> >>>> The problem seems to be the initialization of _Objects_Local_node >>>> in multiprocessor enabled kernels. Since the _MPCI_Initialization() >>>> initializes _Objects_Local_node later than the first semaphores and >>>> tasks are created, this makes the IDs assigned to created objects >>>> incorrect. >>>> >>>> In single processor systems the _Objects_Local_node is a constant >>>> set to 1, but in multiprocessor systems it is initially set to zero >>>> and then initialized by _MPCI_Initialization(). >>>> >>>> The problem you experience is probably the same problem I ran into >>>> this week when running on a dual core SPARC/LEON3 system. Two tasks >>>> are created before the node number is setup correctly. See below >>>> print out from GRMON after breaking at Init(): >>>> >>>> grmon> thread info >>>> >>>> Name | Type | Id | Prio | Time (h:m:s) | Entry >>>> point | PC | >>>> State >>>> --------------------------------------------------------------------------------------------------------------------------------------- >>>> >>>> Int. | internal | 0x09000001 | 255 | 0.000000 | >>>> ?? | 0x0 | READY >>>> --------------------------------------------------------------------------------------------------------------------------------------- >>>> >>>> Int. | classic | 0x09000002 | 0 | 0.000000 | ?? >>>> | 0x0 | Wsem >>>> --------------------------------------------------------------------------------------------------------------------------------------- >>>> >>>> * UI1 | classic | 0x0a010001 | 1 | 0.000000 | >>>> RAM_END | 0x40001368 Init + >>>> 0x4 | READY >>>> --------------------------------------------------------------------------------------------------------------------------------------- >>>> >>>> >>>> As you can see the node number is 0 rather than 1 or 2 in the ID >>>> field. >>>> >>>> The bug appears when the first MPCI packet is received on the >>>> target node, the ISR calls _MCPI_Announce which tries to release a >>>> semaphore, the blocked thread are thought to be global and the >>>> system crashes. The function deciding if it is a global or local >>>> object simply checks if they are of the same node, not if the node >>>> number is zero. >>>> >>>> RTEMS_INLINE_ROUTINE bool _Objects_Is_local_node( >>>> uint32_t node >>>> ) >>>> { >>>> return ( node == _Objects_Local_node ); >>>> } >>>> >>>> To test that this theory holds I changed the declaration of >>>> _Objects_Local_node to extern instead of SCORE_EXTERN, and declared >>>> it in my project initialy initialized to the node number. The LEON3 >>>> dual core system now works and I have successfully managed to get >>>> semaphores and tasks interacting between the two nodes. >>>> >>>> uint16_t _Objects_Local_node = CONFIGURE_MP_NODE_NUMBER; >>>> >>>> >>>> >>>> I suggest that the initialization of _Objects_Local_node is moved >>>> to be initialized earlier. >>>> >>>> Regards, >>>> Daniel Hellstrom >>>> >>>> >>>> >>>> Joel Sherrill wrote: >>>> >>>> >>>> >>>> >>>> >>>>> Roger Dahlkvist wrote: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> Hi, >>>>>> >>>>>> I'm using a timer ISR polling method checking for new messages >>>>>> from other nodes. Unfortunately the system crashes as soon as >>>>>> rtems_multiprocessing_announce is called. >>>>>> >>>>>> >>>>> >>>>> There are no interrupts enabled until the initialization task is >>>>> switched >>>>> in. >>>>> >>>>> I have wondered if it wouldn't make sense to have the MP >>>>> initialization >>>>> sycnhronization done either explicitly by the application (like >>>>> initialization >>>>> of TCP/IP) or implicitly by the init thread like C++ global >>>>> constructors. >>>>> >>>>> You can try moving this code from exinit.c to threadhandler.c >>>>> where and >>>>> protect it somehow from being executed more than once. >>>>> >>>>> #if defined(RTEMS_MULTIPROCESSING) >>>>> if ( _System_state_Is_multiprocessing ) { >>>>> _MPCI_Initialization(); >>>>> _MPCI_Internal_packets_Send_process_packet( >>>>> MPCI_PACKETS_SYSTEM_VERIFY >>>>> ); >>>>> } >>>>> #endif >>>>> >>>>> Then you will at least be able to get your interrupts and call MP >>>>> announce >>>>> to complete system initialization. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> However, rtems_multiprocessing_announce works just fine if it's >>>>>> called just after the initialization phase, before the >>>>>> initinitialization task is started. That's really strange. >>>>>> >>>>>> So for example, if I make one node get initialized and started >>>>>> faster than the other node (using less drivers etc), I'll be able >>>>>> to create global objects. and as long as the other node has not >>>>>> started the initialization task, the message is received and the >>>>>> global objects table is updated, so it can be identified later >>>>>> on. But I can't use them since furter calls to >>>>>> rtems_multiprocessing_announce will fail. >>>>>> >>>>>> At this point I feel like I have tested just about everything, >>>>>> with no luck. It's urgent that I get MP to work properly. I'm >>>>>> using Nios II processors and I have defined my own MPCI routines. >>>>>> I'm confident that they work properly and I have verified that >>>>>> the system crashes before they are even invoked. >>>>>> >>>>>> Is there anyone with MP experience who might have a clue of >>>>>> what's causing my problems? Any help is MUCH appreciated. >>>>>> >>>>>> //Roger >>>>>> >>>>>> _______________________________________________ >>>>>> rtems-users mailing list >>>>>> rtems-users at rtems.org >>>>>> http://www.rtems.org/mailman/listinfo/rtems-users >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >>> >> >> >> > > > From siddons at bnl.gov Sat Jul 4 15:59:45 2009 From: siddons at bnl.gov (D. Peter Siddons) Date: Sat, 04 Jul 2009 11:59:45 -0400 Subject: problem with iostream Message-ID: <4A4F7C71.70003@bnl.gov> I am upgrading my bsp to rtems-4.9 from 4.7. I took the tool rpms. I used alien to make debs and installed them on my Ubuntu Jaunty. I have got to the point where everything seems to build OK until it tries to link the iostream example. I get the following: 272/testsuites/samples/iostream' m68k-rtems4.9-g++ -B../../../../../uC5272/lib/ -specs bsp_specs -qrtems -m5200 -O4 -fomit-frame-pointer -m5200 -o cxx_iostream.exe init.o /opt/rtems-4.9/lib/gcc/m68k-rtems4.9/4.3.2/../../../../m68k-rtems4.9/bin/ld: error: no memory region specified for loadable section `.text._ZSt18__throw_bad_typeidv' collect2: ld returned 1 exit status Any suggestions? Pete. -- D. Peter Siddons Detector Development Group Leader National Synchrotron Light Source Brookhaven National Laboratory Upton, NY 11973 email: siddons at bnl.gov Phone: (631) 344-2738 From joel.sherrill at OARcorp.com Sat Jul 4 16:48:03 2009 From: joel.sherrill at OARcorp.com (Joel Sherrill) Date: Sat, 4 Jul 2009 11:48:03 -0500 Subject: problem with iostream In-Reply-To: <4A4F7C71.70003@bnl.gov> References: <4A4F7C71.70003@bnl.gov> Message-ID: <4A4F87C3.2020903@oarcorp.com> D. Peter Siddons wrote: > I am upgrading my bsp to rtems-4.9 from 4.7. I took the tool rpms. I > used alien to make debs and installed them on my Ubuntu Jaunty. I have > got to the point where everything seems to build OK until it tries to > link the iostream example. I get the following: > > 272/testsuites/samples/iostream' > m68k-rtems4.9-g++ -B../../../../../uC5272/lib/ -specs bsp_specs -qrtems > -m5200 -O4 -fomit-frame-pointer -m5200 -o cxx_iostream.exe init.o > /opt/rtems-4.9/lib/gcc/m68k-rtems4.9/4.3.2/../../../../m68k-rtems4.9/bin/ld: > error: no memory region specified for loadable section > `.text._ZSt18__throw_bad_typeidv' > collect2: ld returned 1 exit status > > Any suggestions? > error: no memory region specified for loadable section Compare the linker scripts in /opt with the one for your BSP. Apparently there is a section not in your linkcmds. > Pete. > > > From strauman at slac.stanford.edu Sun Jul 5 14:35:10 2009 From: strauman at slac.stanford.edu (Till Straumann) Date: Sun, 05 Jul 2009 09:35:10 -0500 Subject: support for PTHREAD_MUTEX_RECURSIVE ? Message-ID: <4A50BA1E.7020303@slac.stanford.edu> It seems that rtems-4.9.2 already implements support for recursive pthread mutexes under the hood and yet there is no static initializer nor pthread_mutexattr_settype()/pthread_mutexattr_gettype(). Wouldn't it be easy and worthwhile to add these? WKR -- Till From joel.sherrill at OARcorp.com Sun Jul 5 15:09:13 2009 From: joel.sherrill at OARcorp.com (Joel Sherrill) Date: Sun, 5 Jul 2009 10:09:13 -0500 Subject: support for PTHREAD_MUTEX_RECURSIVE ? In-Reply-To: <4A50BA1E.7020303@slac.stanford.edu> References: <4A50BA1E.7020303@slac.stanford.edu> Message-ID: <4A50C219.4080807@oarcorp.com> Till Straumann wrote: > It seems that rtems-4.9.2 already implements > support for recursive pthread mutexes under > the hood and yet there is no static initializer > nor pthread_mutexattr_settype()/pthread_mutexattr_gettype(). > Wouldn't it be easy and worthwhile to add these? > > Yes. It has been on the todo list but hasn't made the top. I don't think it would be difficult to implement but it would take a bit of time and require adding a test. The test coverage of the cpukit directories score, sapi, posix and rtems is ~98.5% and we don't want any new features to negatively impact that. --joel > WKR > -- Till > > _______________________________________________ > rtems-users mailing list > rtems-users at rtems.org > http://www.rtems.org/mailman/listinfo/rtems-users > From joel.sherrill at OARcorp.com Mon Jul 6 14:53:27 2009 From: joel.sherrill at OARcorp.com (Joel Sherrill) Date: Mon, 6 Jul 2009 09:53:27 -0500 Subject: support for PTHREAD_MUTEX_RECURSIVE ? In-Reply-To: <4A50BA1E.7020303@slac.stanford.edu> References: <4A50BA1E.7020303@slac.stanford.edu> Message-ID: <4A520FE7.2020007@oarcorp.com> Till Straumann wrote: > It seems that rtems-4.9.2 already implements > support for recursive pthread mutexes under > the hood and yet there is no static initializer > nor pthread_mutexattr_settype()/pthread_mutexattr_gettype(). > Wouldn't it be easy and worthwhile to add these? > > Till I added the basics for supporting these to posix/src along with a switch in pthread_mutex_init. Now it is up to you to translate the types into supercore attributes and provide a test. :-D > WKR > -- Till > > _______________________________________________ > rtems-users mailing list > rtems-users at rtems.org > http://www.rtems.org/mailman/listinfo/rtems-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 From joel.sherrill at OARcorp.com Mon Jul 6 15:17:30 2009 From: joel.sherrill at OARcorp.com (Joel Sherrill) Date: Mon, 6 Jul 2009 10:17:30 -0500 Subject: Summer of Code Mid-Term Report Invite Message-ID: <4A52158A.8060001@oarcorp.com> Hi, I think I just sent all students and mentors an invitation to edit a Google doc for the mid-term report. If you are a SoC student or mentor and didn't get one, I apologize. Please ping me and I will invite you. I was trying to add 14 people from memory. -- 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 From joel.sherrill at OARcorp.com Mon Jul 6 20:20:40 2009 From: joel.sherrill at OARcorp.com (Joel Sherrill) Date: Mon, 6 Jul 2009 15:20:40 -0500 Subject: ALERT GSoC Mid-Term Mentors and Students Message-ID: <4A525C98.8060207@oarcorp.com> Hi, Please visit http://socghop.appspot.com, go to the bottom on the left hand side where the list of things to click on is. Fill out whatever there is to fill out. Mentors and students.. if you have any issues with the webapp or each other or me, just let me know. If the student gets "passed" at the bottom, they get paid. Don't let them down. -- 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 From manuel.coutinho at edisoft.pt Tue Jul 7 08:53:44 2009 From: manuel.coutinho at edisoft.pt (Manuel Coutinho) Date: Tue, 7 Jul 2009 09:53:44 +0100 Subject: Semaphore release - not owner of resource return In-Reply-To: <4A1C8038.9000504@oarcorp.com> References: <000601c9de1a$4f2599b0$680aa8c0@ecmcoutinho> <4A1C8038.9000504@oarcorp.com> Message-ID: <000901c9fee0$6ef15950$680aa8c0@ecmcoutinho> By the way, is there a special reason why locked binary semaphores cannot be deleted and simple binary semaphores can? (just came across this section of the code...) I am thinking of this problem because of PR788 (Priority inheritance mechanism may activate a deleted task). If locked simple binary semaphores and locked binary semaphores are impossible to be deleted, then this bug may be fixed easily (since only these two types of semaphores can have priority inheritance protocol). Thanks Kind regards Manuel Coutinho > -----Original Message----- > From: Joel Sherrill [mailto:joel.sherrill at oarcorp.com] > Sent: Wednesday, May 27, 2009 12:50 AM > To: Manuel Coutinho > Cc: rtems-users at rtems.com > Subject: Re: Semaphore release - not owner of resource return > > Manuel Coutinho wrote: > > > > Hi > > > > > > > > Was checking some RTEMS code and stumbled upon the error > > RTEMS_NOT_OWNER_OF_RESOURCE when we do a semaphore release -> threadA > > obtains a semaphore and threadB releases it. > > > > From what I understood, this error can only happen with a binary > > semaphore with priority inherence or ceiling. > > > > > > > > > > > > extract of the rtems_semaphore_create directive: > > > > > > > > if ( _Attributes_Is_*binary*_semaphore( attribute_set ) ) { > > > > the_mutex_attributes.lock_nesting_behavior = > > CORE_MUTEX_NESTING_ACQUIRES; > > > > > > > > switch ( the_mutex_attributes.discipline ) { > > > > case CORE_MUTEX_DISCIPLINES_FIFO: > > > > case CORE_MUTEX_DISCIPLINES_PRIORITY: > > > > the_mutex_attributes.only_owner_release = FALSE; > > > > break; > > > > case CORE_MUTEX_DISCIPLINES_PRIORITY_CEILING: > > > > case CORE_MUTEX_DISCIPLINES_PRIORITY_INHERIT: > > > > the_mutex_attributes.only_owner_release = TRUE; > > > > break; > > > > } > > > > } > > > > > > > > My question is: why does this give an error with binary and not with > > simple binaries? > > > > > > > > From what I understand about this functionality, a use for this could > > be when the thread (threadA) is taking a long time or is in error and > > another thread (threadB) tries to release all the semaphores that > > threadA obtained and afterwards wants to delete threadA (or something > > of the sort). So this, in principle, could be valid for both binary > > and simple binary semaphores, no? > > > > > > > > Is there an implementation issue as to why this is not possible to do > > with binary semaphores (am just guessing, but if this is possible with > > simple binary.why not with binary)? > > > Simple binary are used by applications to do condition synchronization. > This > means the sem is created locked, taskA blocks waiting for signal > (unlock) and > an isr or taskB unlocks it to unblock taskA. By design and intention, the > task that locks is NEVER the unlocking task. > > In contrast RTEMS binary semaphores (e.g. mutexes) are used for critical > sections (a.k.a. mutual exclusion) and are always locked/unlocked by the > same thread. > > > > > > > > Thanks > > > > Kind Regards > > > > Manuel Coutinho > > From joel.sherrill at OARcorp.com Tue Jul 7 12:03:26 2009 From: joel.sherrill at OARcorp.com (Joel Sherrill) Date: Tue, 7 Jul 2009 07:03:26 -0500 Subject: Semaphore release - not owner of resource return In-Reply-To: <000901c9fee0$6ef15950$680aa8c0@ecmcoutinho> References: <000601c9de1a$4f2599b0$680aa8c0@ecmcoutinho> <4A1C8038.9000504@oarcorp.com> <000901c9fee0$6ef15950$680aa8c0@ecmcoutinho> Message-ID: <4A53398E.3070708@oarcorp.com> Manuel Coutinho wrote: > By the way, is there a special reason why locked binary semaphores cannot be > deleted and simple binary semaphores can? (just came across this section of > the code...) > The general thinking is that when locked they indicate some task is in a critical section. If you delete them, then you are potentially negatively impacting that critical section. There may also have been some discussion of how do you deal with any inherited priority. In general it avoids dealing with complicated side-effects of cleaning up. Simple binary semaphores are used for condition synchronization --not critical sections. They are locked when a task is waiting on someone to announce a condition (e.g. often an ISR occurred). The task waiting will naturally wake up with RTEMS_OBJECT_WAS_DELETED. So this one takes care of itself in a natural and clean way. > I am thinking of this problem because of PR788 (Priority inheritance > mechanism may activate a deleted task). > > If locked simple binary semaphores and locked binary semaphores are > impossible to be deleted, then this bug may be fixed easily (since only > these two types of semaphores can have priority inheritance protocol). > > Simple binary can't have inheritance or ceiling. Only true binary. But go on... explain your idea. > Thanks > Kind regards > Manuel Coutinho > > >> -----Original Message----- >> From: Joel Sherrill [mailto:joel.sherrill at oarcorp.com] >> Sent: Wednesday, May 27, 2009 12:50 AM >> To: Manuel Coutinho >> Cc: rtems-users at rtems.com >> Subject: Re: Semaphore release - not owner of resource return >> >> Manuel Coutinho wrote: >> >>> Hi >>> >>> >>> >>> Was checking some RTEMS code and stumbled upon the error >>> RTEMS_NOT_OWNER_OF_RESOURCE when we do a semaphore release -> threadA >>> obtains a semaphore and threadB releases it. >>> >>> From what I understood, this error can only happen with a binary >>> semaphore with priority inherence or ceiling. >>> >>> >>> >>> >>> >>> extract of the rtems_semaphore_create directive: >>> >>> >>> >>> if ( _Attributes_Is_*binary*_semaphore( attribute_set ) ) { >>> >>> the_mutex_attributes.lock_nesting_behavior = >>> CORE_MUTEX_NESTING_ACQUIRES; >>> >>> >>> >>> switch ( the_mutex_attributes.discipline ) { >>> >>> case CORE_MUTEX_DISCIPLINES_FIFO: >>> >>> case CORE_MUTEX_DISCIPLINES_PRIORITY: >>> >>> the_mutex_attributes.only_owner_release = FALSE; >>> >>> break; >>> >>> case CORE_MUTEX_DISCIPLINES_PRIORITY_CEILING: >>> >>> case CORE_MUTEX_DISCIPLINES_PRIORITY_INHERIT: >>> >>> the_mutex_attributes.only_owner_release = TRUE; >>> >>> break; >>> >>> } >>> >>> } >>> >>> >>> >>> My question is: why does this give an error with binary and not with >>> simple binaries? >>> >>> >>> >>> From what I understand about this functionality, a use for this could >>> be when the thread (threadA) is taking a long time or is in error and >>> another thread (threadB) tries to release all the semaphores that >>> threadA obtained and afterwards wants to delete threadA (or something >>> of the sort). So this, in principle, could be valid for both binary >>> and simple binary semaphores, no? >>> >>> >>> >>> Is there an implementation issue as to why this is not possible to do >>> with binary semaphores (am just guessing, but if this is possible with >>> simple binary.why not with binary)? >>> >>> >> Simple binary are used by applications to do condition synchronization. >> This >> means the sem is created locked, taskA blocks waiting for signal >> (unlock) and >> an isr or taskB unlocks it to unblock taskA. By design and intention, the >> task that locks is NEVER the unlocking task. >> >> In contrast RTEMS binary semaphores (e.g. mutexes) are used for critical >> sections (a.k.a. mutual exclusion) and are always locked/unlocked by the >> same thread. >> >>> >>> Thanks >>> >>> Kind Regards >>> >>> Manuel Coutinho >>> >>> > > > From manuel.coutinho at edisoft.pt Tue Jul 7 16:11:54 2009 From: manuel.coutinho at edisoft.pt (Manuel Coutinho) Date: Tue, 7 Jul 2009 17:11:54 +0100 Subject: Semaphore release - not owner of resource return In-Reply-To: <4A53398E.3070708@oarcorp.com> References: <000601c9de1a$4f2599b0$680aa8c0@ecmcoutinho> <4A1C8038.9000504@oarcorp.com> <000901c9fee0$6ef15950$680aa8c0@ecmcoutinho> <4A53398E.3070708@oarcorp.com> Message-ID: <000d01c9ff1d$a5141120$680aa8c0@ecmcoutinho> Ok :) Now I understand: Simple binary semaphores cannot have priority inheritance or ceiling. But RTEMS is currently allowing this. A simple binary semaphore can be created with one of priority protocols and the holder threads priority is increased/decreased accordingly. Suppose this is a bug of RTEMS then: do not allow creation of simple binary semaphores with priority ceiling or priority inheritance protocols. Regarding bug PR788, forget my previous suggestion. My mind was not good at the time! However, had another "solution": When a thread is deleted, all the semaphores it holds are set free. This is actually the same behavior as specified in ARINC 653. Of course, some modifications have to be performed to accomplish this. But is there any special reason not to implement this behavior (apart from the O(n) complexity issue)? Kind regards Manuel Coutinho > -----Original Message----- > From: Joel Sherrill [mailto:joel.sherrill at oarcorp.com] > Sent: Tuesday, July 07, 2009 1:03 PM > To: Manuel Coutinho > Cc: rtems-users at rtems.com > Subject: Re: Semaphore release - not owner of resource return > > Manuel Coutinho wrote: > > By the way, is there a special reason why locked binary semaphores > cannot be > > deleted and simple binary semaphores can? (just came across this section > of > > the code...) > > > > The general thinking is that when locked they indicate > some task is in a critical section. If you delete them, then > you are potentially negatively impacting that critical > section. > > There may also have been some discussion of how do you > deal with any inherited priority. > > In general it avoids dealing with complicated side-effects > of cleaning up. > > Simple binary semaphores are used for condition > synchronization --not critical sections. They are locked > when a task is waiting on someone to announce a > condition (e.g. often an ISR occurred). The task waiting will > naturally wake up with RTEMS_OBJECT_WAS_DELETED. > So this one takes care of itself in a natural and clean way. > > I am thinking of this problem because of PR788 (Priority inheritance > > mechanism may activate a deleted task). > > > > If locked simple binary semaphores and locked binary semaphores are > > impossible to be deleted, then this bug may be fixed easily (since only > > these two types of semaphores can have priority inheritance protocol). > > > > > Simple binary can't have inheritance or ceiling. Only > true binary. > > But go on... explain your idea. > > Thanks > > Kind regards > > Manuel Coutinho > > > > > >> -----Original Message----- > >> From: Joel Sherrill [mailto:joel.sherrill at oarcorp.com] > >> Sent: Wednesday, May 27, 2009 12:50 AM > >> To: Manuel Coutinho > >> Cc: rtems-users at rtems.com > >> Subject: Re: Semaphore release - not owner of resource return > >> > >> Manuel Coutinho wrote: > >> > >>> Hi > >>> > >>> > >>> > >>> Was checking some RTEMS code and stumbled upon the error > >>> RTEMS_NOT_OWNER_OF_RESOURCE when we do a semaphore release -> threadA > >>> obtains a semaphore and threadB releases it. > >>> > >>> From what I understood, this error can only happen with a binary > >>> semaphore with priority inherence or ceiling. > >>> > >>> > >>> > >>> > >>> > >>> extract of the rtems_semaphore_create directive: > >>> > >>> > >>> > >>> if ( _Attributes_Is_*binary*_semaphore( attribute_set ) ) { > >>> > >>> the_mutex_attributes.lock_nesting_behavior = > >>> CORE_MUTEX_NESTING_ACQUIRES; > >>> > >>> > >>> > >>> switch ( the_mutex_attributes.discipline ) { > >>> > >>> case CORE_MUTEX_DISCIPLINES_FIFO: > >>> > >>> case CORE_MUTEX_DISCIPLINES_PRIORITY: > >>> > >>> the_mutex_attributes.only_owner_release = FALSE; > >>> > >>> break; > >>> > >>> case CORE_MUTEX_DISCIPLINES_PRIORITY_CEILING: > >>> > >>> case CORE_MUTEX_DISCIPLINES_PRIORITY_INHERIT: > >>> > >>> the_mutex_attributes.only_owner_release = TRUE; > >>> > >>> break; > >>> > >>> } > >>> > >>> } > >>> > >>> > >>> > >>> My question is: why does this give an error with binary and not with > >>> simple binaries? > >>> > >>> > >>> > >>> From what I understand about this functionality, a use for this could > >>> be when the thread (threadA) is taking a long time or is in error and > >>> another thread (threadB) tries to release all the semaphores that > >>> threadA obtained and afterwards wants to delete threadA (or something > >>> of the sort). So this, in principle, could be valid for both binary > >>> and simple binary semaphores, no? > >>> > >>> > >>> > >>> Is there an implementation issue as to why this is not possible to do > >>> with binary semaphores (am just guessing, but if this is possible with > >>> simple binary.why not with binary)? > >>> > >>> > >> Simple binary are used by applications to do condition synchronization. > >> This > >> means the sem is created locked, taskA blocks waiting for signal > >> (unlock) and > >> an isr or taskB unlocks it to unblock taskA. By design and intention, > the > >> task that locks is NEVER the unlocking task. > >> > >> In contrast RTEMS binary semaphores (e.g. mutexes) are used for > critical > >> sections (a.k.a. mutual exclusion) and are always locked/unlocked by > the > >> same thread. > >> > >>> > >>> Thanks > >>> > >>> Kind Regards > >>> > >>> Manuel Coutinho > >>> > >>> > > > > > > From roxana.leontie at gmail.com Thu Jul 9 16:47:44 2009 From: roxana.leontie at gmail.com (Roxana Leontie) Date: Thu, 9 Jul 2009 12:47:44 -0400 Subject: anybody is using fb_vga? Message-ID: Hi, For those of you who don't know me I an the student working on the Nano-X project. I want to know if anyone (or an application that you are aware of - except Nano-X) that is using fb_vga? I want to make sure I am not breaking any interface with my changes. Roxana -------------- next part -------------- An HTML attachment was scrubbed... URL: From jszhang3 at gmail.com Thu Jul 9 19:34:48 2009 From: jszhang3 at gmail.com (JiSheng Zhang) Date: Fri, 10 Jul 2009 03:34:48 +0800 Subject: [GSOC]Dynamic object file loading:basic working version Message-ID: <2df346410907091234p446e6af1q50ec9dfe4228e305@mail.gmail.com> Hi all, Now basic symbol resolving and relocation works! The code is attached. For test just make and then ./demo -l ./t.o -s get. If you should see something like "******5******" plus various debug message. Explanation: t.c looks like this: /*****************/ int ttt=5; int get() { return ttt; } /****************/ so t.o should have at least one relocation and two symbols. readelf -S t.o and readelf -s t.o prove this. the dynamic linker load t.o and parsing it, then it loading all needed sections, finally it will do symbol resolving and relocation. For test I just point entry to the start of ".text" that is get function, then call this function via entry, we should get the result:5 TODO next week: 1.lookup external symbol which is exported by demo 2.support symbol resolving exported by object file which is dynamic loaded Regards, JiSheng -------------- next part -------------- A non-text attachment was scrubbed... Name: objdl.tar.gz Type: application/x-gzip Size: 9972 bytes Desc: not available URL: From joel.sherrill at OARcorp.com Thu Jul 9 19:57:17 2009 From: joel.sherrill at OARcorp.com (Joel Sherrill) Date: Thu, 9 Jul 2009 14:57:17 -0500 Subject: [GSOC]Dynamic object file loading:basic working version In-Reply-To: <2df346410907091234p446e6af1q50ec9dfe4228e305@mail.gmail.com> References: <2df346410907091234p446e6af1q50ec9dfe4228e305@mail.gmail.com> Message-ID: <4A564B9D.3090507@oarcorp.com> Good job! Random questions: + unload_library isn't implemented yet in the linker.c + does the loaded library get a call to initialize itself? + will you need some help getting a comparable demo application on RTEMS? + The code uses at least pthread_mutex. This means that it will require POSIX to be enabled in RTEMS. Is this the only thing forcing RTEMS POSIX thread support to be enabled? [NOTE: I don't know if this is a big deal or not. at this point, it is just a requirement on the code.] + Is this really as self-contained as it looks? :-D And can you update the google docs page that has the general SoC Status for all RTEMS projects? If I didn't send you permission, just ping me and I will add you. --joel JiSheng Zhang wrote: > Hi all, > Now basic symbol resolving and relocation works! The code is attached. > For test just make and then ./demo -l ./t.o -s get. If you should see > something like "******5******" plus various debug message. > Explanation: > t.c looks like this: > /*****************/ > int ttt=5; > int get() > { > return ttt; > > } > /****************/ > so t.o should have at least one relocation and two symbols. readelf -S > t.o and readelf -s t.o prove this. > the dynamic linker load t.o and parsing it, then it loading all needed > sections, finally it will do symbol resolving and relocation. > > For test I just point entry to the start of ".text" that is get > function, then call this function via entry, we should get the > result:5 > > TODO next week: > 1.lookup external symbol which is exported by demo > 2.support symbol resolving exported by object file which is dynamic loaded > > Regards, > JiSheng > -- 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 From jszhang3 at gmail.com Fri Jul 10 04:21:36 2009 From: jszhang3 at gmail.com (JiSheng Zhang) Date: Fri, 10 Jul 2009 12:21:36 +0800 Subject: [GSOC]Dynamic object file loading:basic working version In-Reply-To: <4A564B9D.3090507@oarcorp.com> References: <2df346410907091234p446e6af1q50ec9dfe4228e305@mail.gmail.com> <4A564B9D.3090507@oarcorp.com> Message-ID: <2df346410907092121o455b76e7wd0878d67dab7d068@mail.gmail.com> Hi Dr.Joel, 2009/7/10 Joel Sherrill : > Good job! > > Random questions: > > + unload_library isn't implemented yet in the linker.c on TODO list, it's simple;) > + does the loaded library get a call to initialize itself? Do you mean the initialization used for constructor in c++? Will be added in next week. > + will you need some help getting a comparable demo > ?application on RTEMS? Thanks, Once I come across a problem, I will ask on maillist > + The code uses at least pthread_mutex. ?This means that > ?it will require POSIX to be enabled in RTEMS. ?Is this the > ?only thing forcing RTEMS POSIX thread support to be > ?enabled? ?[NOTE: I don't know if this is a big deal or not. > ?at this point, it is just a requirement on the code.] Hmmm, pthread_mutex can be replaced by rtems_semapohore, the real problem is that the code uses open\read\lseek etc. Are these functions included in POSIX? Are there rtems' native functions? > + Is this really as self-contained as it looks? :-D > > And can you update the google docs page that has > the general SoC Status for all RTEMS projects? ?If OK, I will update it tonight or tomorrow > I didn't send you permission, just ping me and I > will add you. > > --joel Regards, JiSheng From sebastian.huber at embedded-brains.de Fri Jul 10 12:04:25 2009 From: sebastian.huber at embedded-brains.de (Sebastian Huber) Date: Fri, 10 Jul 2009 14:04:25 +0200 Subject: RFC: Interrupt Manager Extension changes Message-ID: <4A572E49.4040407@embedded-brains.de> Hi, the Interrupt Manager Extension is documented here: http://www.rtems.com/doxygen/cpukit/html/group__rtems__interrupt__extension.html In order to support the legacy API and FreeBSD interrupt handlers better I would like to change the interrupt handler signature from typedef void (*rtems_interrupt_handler)(rtems_vector_number, void *); to typedef void (*rtems_interrupt_handler)(void *); The current signature was primarily chosen to support the Classic API in the future without overhead. This turned out to be impractical. I would also like to change the return code for requests with an invalid vector number from RTEMS_INVALID_NUMBER to RTEMS_INVALID_ID since the vector number acts like an object ID in this context. I would like to add a new API for interrupt handlers which should be executed within a task context: /** * @brief Initializes the interrupt server task. * * The task will have the priority @a priority, the stack size @a stack_size, * the modes @a modes and the attributes @a attributes. Interrupt handlers can * be installed on the server with rtems_interrupt_server_handler_install() and * removed with rtems_interrupt_server_handler_remove(). In case of an * interrupt the request will be forwarded to the server. The handlers are * executed within the server context. If one handler blocks on something this * may delay the processing of other handlers. * * @note This function may block. * * @return * - On success @c RTEMS_SUCCESSFUL shall be returned. * - If the interrupt server task is already initialized * @c RTEMS_INCORRECT_STATE shall be returned. * - Other error states are BSP specific. */ rtems_status_code rtems_interrupt_server_initialize( rtems_task_priority priority, size_t stack_size, rtems_mode modes, rtems_attribute attributes ); /** * @brief Installs the interrupt handler routine @a handler for the interrupt * vector with number @a vector. * * The handler routine will be executed on the interrupt server task. * * @note This function may block. * * @see rtems_interrupt_handler_install(). * * @return * - On success @c RTEMS_SUCCESSFUL shall be returned. * - If the interrupt handler server is not initialized * @c RTEMS_INCORRECT_STATE shall be returned. * - For other errors see rtems_interrupt_handler_install(). */ rtems_status_code rtems_interrupt_server_handler_install( rtems_vector_number vector, const char *info, rtems_option options, rtems_interrupt_handler handler, void *arg ); /** * @brief Removes the interrupt handler routine @a handler with argument @a arg * for the interrupt vector with number @a vector. * * @note This function may block. * * @see rtems_interrupt_handler_remove(). * * @return * - On success @c RTEMS_SUCCESSFUL shall be returned. * - If the interrupt handler server is not initialized * @c RTEMS_INCORRECT_STATE shall be returned. * - For other errors see rtems_interrupt_handler_remove(). */ rtems_status_code rtems_interrupt_server_handler_remove( rtems_vector_number vector, rtems_interrupt_handler handler, void *arg ); 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 at embedded-brains.de PGP : Public key available on request Diese Nachricht ist keine gesch?ftliche Mitteilung im Sinne des EHUG. From strauman at slac.stanford.edu Fri Jul 10 15:50:40 2009 From: strauman at slac.stanford.edu (Till Straumann) Date: Fri, 10 Jul 2009 10:50:40 -0500 Subject: RFC: Interrupt Manager Extension changes In-Reply-To: <4A572E49.4040407@embedded-brains.de> References: <4A572E49.4040407@embedded-brains.de> Message-ID: <4A576350.3040803@slac.stanford.edu> I like the idea of a facility to let interrupt handlers execute from a task context. However, IMO it would be far more flexible and useful if there was not just one server task (which still could be the default) but if when installing the ISR one could optionally request a new/separate task (with desired priority etc.). -- Till Sebastian Huber wrote: > Hi, > > the Interrupt Manager Extension is documented here: > > http://www.rtems.com/doxygen/cpukit/html/group__rtems__interrupt__extension.html > > In order to support the legacy API and FreeBSD interrupt handlers better I > would like to change the interrupt handler signature from > > typedef void (*rtems_interrupt_handler)(rtems_vector_number, void *); > > to > > typedef void (*rtems_interrupt_handler)(void *); > > The current signature was primarily chosen to support the Classic API in the > future without overhead. This turned out to be impractical. > > I would also like to change the return code for requests with an invalid vector > number from RTEMS_INVALID_NUMBER to RTEMS_INVALID_ID since the vector number > acts like an object ID in this context. > > I would like to add a new API for interrupt handlers which should be executed > within a task context: > > /** > * @brief Initializes the interrupt server task. > * > * The task will have the priority @a priority, the stack size @a stack_size, > * the modes @a modes and the attributes @a attributes. Interrupt handlers can > * be installed on the server with rtems_interrupt_server_handler_install() and > * removed with rtems_interrupt_server_handler_remove(). In case of an > * interrupt the request will be forwarded to the server. The handlers are > * executed within the server context. If one handler blocks on something this > * may delay the processing of other handlers. > * > * @note This function may block. > * > * @return > * - On success @c RTEMS_SUCCESSFUL shall be returned. > * - If the interrupt server task is already initialized > * @c RTEMS_INCORRECT_STATE shall be returned. > * - Other error states are BSP specific. > */ > rtems_status_code rtems_interrupt_server_initialize( > rtems_task_priority priority, > size_t stack_size, > rtems_mode modes, > rtems_attribute attributes > ); > > /** > * @brief Installs the interrupt handler routine @a handler for the interrupt > * vector with number @a vector. > * > * The handler routine will be executed on the interrupt server task. > * > * @note This function may block. > * > * @see rtems_interrupt_handler_install(). > * > * @return > * - On success @c RTEMS_SUCCESSFUL shall be returned. > * - If the interrupt handler server is not initialized > * @c RTEMS_INCORRECT_STATE shall be returned. > * - For other errors see rtems_interrupt_handler_install(). > */ > rtems_status_code rtems_interrupt_server_handler_install( > rtems_vector_number vector, > const char *info, > rtems_option options, > rtems_interrupt_handler handler, > void *arg > ); > > /** > * @brief Removes the interrupt handler routine @a handler with argument @a arg > * for the interrupt vector with number @a vector. > * > * @note This function may block. > * > * @see rtems_interrupt_handler_remove(). > * > * @return > * - On success @c RTEMS_SUCCESSFUL shall be returned. > * - If the interrupt handler server is not initialized > * @c RTEMS_INCORRECT_STATE shall be returned. > * - For other errors see rtems_interrupt_handler_remove(). > */ > rtems_status_code rtems_interrupt_server_handler_remove( > rtems_vector_number vector, > rtems_interrupt_handler handler, > void *arg > ); > > Have a nice day! > > From hiyangxi at gmail.com Sat Jul 11 05:27:34 2009 From: hiyangxi at gmail.com (xi yang) Date: Sat, 11 Jul 2009 15:27:34 +1000 Subject: [GSOC2009] Skyeye shutdown device patch for 1.2.8 branch of SKYEYE Message-ID: <552cfe40907102227kc8f5789jf4579135ddc5750d@mail.gmail.com> Index: device/nandflash/nandflash_smallblock.c =================================================================== --- device/nandflash/nandflash_smallblock.c (revision 691) +++ device/nandflash/nandflash_smallblock.c (working copy) @@ -516,7 +516,7 @@ #endif nf->writebuffer=(u8*)malloc(dev->pagedumpsize); //nf->memsize=528*32*4096; - if ((nf->fdump= open(dev->dump, FILE_FLAG)) < 0) + if ((nf->fdump= open(dev->dump, FILE_FLAG, FILE_MODE)) < 0) { free(nf); printf("error open nandflash dump!\n"); Index: device/nandflash/nandflash_smallblock.h =================================================================== --- device/nandflash/nandflash_smallblock.h (revision 691) +++ device/nandflash/nandflash_smallblock.h (working copy) @@ -27,6 +27,8 @@ #define FILE_FLAG (O_RDWR | O_CREAT) #endif +#define FILE_MODE (0x777) + #if (defined(__MINGW32__) || defined(__BEOS__)) #define POSIX_SHARE_MEMORY_BROKEN #endif Index: memory/ram.c =================================================================== --- memory/ram.c (revision 691) +++ memory/ram.c (working copy) @@ -261,10 +261,10 @@ void * state; switch(size){ case 8: - *(uint8_t *)value = (uint8_t)mem_read_byte (offset); + *value = (uint8_t)mem_read_byte (offset); break; case 16: - *(uint16_t *)value = (uint16_t)mem_read_halfword(offset); + *value = (uint16_t)mem_read_halfword(offset); break; case 32: *value = mem_read_word(offset); Index: arch/arm/common/armemu.c =================================================================== --- arch/arm/common/armemu.c (revision 691) +++ arch/arm/common/armemu.c (working copy) @@ -676,7 +676,15 @@ } io_do_cycle (state); state->NumInstrs++; - + if (skyeye_config.shutdown_device.status){ + if (skyeye_config.shutdown_device.max_ins){ + if (state->NumInstrs >= skyeye_config.shutdown_device.max_ins){ + fprintf(stderr, "Shutdown_device:max_ins expired\n"); + exit(2); + } + } + } + #ifdef MODET /* Provide Thumb instruction decoding. If the processor is in Thumb mode, then we can simply decode the Thumb instruction, and map it @@ -5069,6 +5077,11 @@ MEM_STORE_LOG("WORD"); BUSUSEDINCPCN; + + if(skyeye_config.shutdown_device.status){ + if(address == skyeye_config.shutdown_device.shutdown_addr) + exit(0); + } #ifndef MODE32 if (DESTReg == 15) state->Reg[15] = ECC | ER15INT | R15PC | EMODE; Index: utils/config/skyeye_config.h =================================================================== --- utils/config/skyeye_config.h (revision 691) +++ utils/config/skyeye_config.h (working copy) @@ -100,6 +100,21 @@ } machine_config_t; +/* + * If status of shutdown device is 1, when "shutdown_addr" + * (align on 8bytes) is written, SKYEYE simulator exits. + * If the number of executed instructions by skyeye simulator + * is bigger than "max_instructions", then skyeye return with + * value 2 +*/ +typedef struct shutdown_config +{ + unsigned int status; + u32 shutdown_addr; + unsigned long long max_ins; +}shutdown_config_t; + + #define MAX_BANK 8 #define MAX_STR 1024 @@ -183,6 +198,7 @@ int do_dummy_option (); int do_arch_option (); int do_cpu_option (); +int do_shutdown_option (); int do_mach_option (); int do_mem_bank_option (); int do_net_option (); @@ -248,6 +264,7 @@ //mem_config_t mem; //chy 2003-09-12, now support more io banks // ioaddr_config_t ioaddr; //used for ARMul_notIOaddr funciton + shutdown_config_t shutdown_device; net_config_t net[NET_MAXNICNUM_PER_HOST]; uart_config_t uart; log_config_t log; @@ -280,10 +297,12 @@ {"arch", do_arch_option, 0, 1}, {"cpu", do_cpu_option, 0, 1}, {"mach", do_mach_option, 0, 1}, + {"shutdown_device", do_shutdown_option,0, 1}, /*mem option */ {"mem_bank", do_mem_bank_option, 0, MAX_BANK}, + {"net", do_net_option, 0, 10}, {"energy", do_energy_option, 0, 1}, {"uart", do_uart_option, 0, MAX_UART_DEVICE_NUM}, Index: utils/config/skyeye_options.c =================================================================== --- utils/config/skyeye_options.c (revision 691) +++ utils/config/skyeye_options.c (working copy) @@ -79,6 +79,9 @@ config->uart.count = 0; atexit(skyeye_uart_cleanup); + config->shutdown_device.status = 0; + config->shutdown_device.max_ins = 0; + /*ywc 2005-04-01 */ config->no_dbct = 1; /*default, dbct is off */ //teawater add for new tb manage function 2005.07.10---------------------------- @@ -247,6 +250,44 @@ } int +do_shutdown_option (skyeye_option_t * this_option, int num_params, + const char *params[]) +{ + int ret; + char *value; + shutdown_config_t *shutdown = &(skyeye_config.shutdown_device); + if(ret = strncmp(params[0],"addr=",5)){ + SKYEYE_ERR ("Error, Wrong parameter for shutdown_device\n"); + return -1; + } + value = &(params[0][5]); + if(value[0]=='0' && (value[1] == 'x' || value[1] == 'X')) + shutdown->shutdown_addr = (unsigned int)strtoul(value,NULL,16); + else + shutdown->shutdown_addr = (unsigned int)strtoul(value,NULL,10); + if(shutdown->shutdown_addr & 0x7){ + SKYEYE_ERR ("Error, shutdown address needs align on 8 bytes\n"); + return -1; + } + + if(ret = strncmp(params[1],"max_ins=",8)){ + SKYEYE_ERR ("Error, Wrong parameter for shutdown_device\n"); + return -1; + } + value = &(params[1][8]); + if(value[0]=='0' && (value[1] == 'x' || value[1] == 'X')) + shutdown->max_ins = strtoull(value,NULL,16); + else + shutdown->max_ins = strtoull(value,NULL,10); + + shutdown->status = 1; + + printf("Shutdown addr=%x, max_ins=%x\n",shutdown->shutdown_addr,shutdown->max_ins); + return 1; +} + + +int do_mem_bank_option (skyeye_option_t * this_option, int num_params, const char *params[]) { From sebastian.huber at embedded-brains.de Mon Jul 13 07:55:08 2009 From: sebastian.huber at embedded-brains.de (Sebastian Huber) Date: Mon, 13 Jul 2009 09:55:08 +0200 Subject: RFC: Interrupt Manager Extension changes In-Reply-To: <4A576350.3040803@slac.stanford.edu> References: <4A572E49.4040407@embedded-brains.de> <4A576350.3040803@slac.stanford.edu> Message-ID: <4A5AE85C.1030704@embedded-brains.de> Till Straumann wrote: > I like the idea of a facility to let interrupt handlers execute > from a task context. > > However, IMO it would be far more flexible and useful if there was not > just one server task (which still could be the default) but if > when installing the ISR one could optionally request a new/separate > task (with desired priority etc.). [...] Yes, this is indeed more useful. I added a server identifier, so that you can install the handlers on a particular server. Some problems: Do we want a default server? How do we initialize the default server? How do we refer to the default server? At the moment we have one default server which is identified by RTEMS_ID_NONE. In case of more than one running server it is implementation dependent which one is the default server. A simple implementation may look like: One task, one counting semaphore and one list for each server. The interrupt handler disables the corresponding interrupt vector on the interrupt controller, adds one item to the list and increments the counting semaphore. The server continuously decrements the semaphore and fetches one item at a time. It processes the item and enables the corresponding interrupt vector on the interrupt controller afterwards. If we want so support shared interrupts, we need also a counter for each vector to count the number of shared server handlers per vector. This ensures that we only enable the vector if each handler was processed. /** * @brief Initializes an interrupt server task. * * The task will have the priority @a priority, the stack size @a stack_size, * the modes @a modes and the attributes @a attributes. The identifier of the * server task will be returned in @a server. Interrupt handlers can be * installed on the server with rtems_interrupt_server_handler_install() and * removed with rtems_interrupt_server_handler_remove() using this identifier. * In case of an interrupt the request will be forwarded to the server. The * handlers are executed within the server context. If one handler blocks on * something this may delay the processing of other handlers. * * @note This function may block. * * @return * - On success @c RTEMS_SUCCESSFUL shall be returned. * - If the @a server pointer is @c NULL @c RTEMS_INVALID_ADDRESS shall be * returned. * - Other error states are BSP specific. */ rtems_status_code rtems_interrupt_server_initialize( rtems_task_priority priority, size_t stack_size, rtems_mode modes, rtems_attribute attributes, rtems_id *server ); /** * @brief Installs the interrupt handler routine @a handler for the interrupt * vector with number @a vector on the server @a server. * * The handler routine will be executed on the corresponding interrupt server * task. A server identifier of @c RTEMS_ID_NONE may be used to install the * handler on some available server. * * @note This function may block. * * @see rtems_interrupt_handler_install(). * * @return * - On success @c RTEMS_SUCCESSFUL shall be returned. * - If the interrupt handler server is not initialized * @c RTEMS_INCORRECT_STATE shall be returned. * - For other errors see rtems_interrupt_handler_install(). */ rtems_status_code rtems_interrupt_server_handler_install( rtems_id server, rtems_vector_number vector, const char *info, rtems_option options, rtems_interrupt_handler handler, void *arg ); /** * @brief Removes the interrupt handler routine @a handler with argument @a arg * for the interrupt vector with number @a vector from the server @a server. * * @note This function may block. * * @see rtems_interrupt_handler_remove(). * * @return * - On success @c RTEMS_SUCCESSFUL shall be returned. * - If the interrupt handler server is not initialized * @c RTEMS_INCORRECT_STATE shall be returned. * - For other errors see rtems_interrupt_handler_remove(). */ rtems_status_code rtems_interrupt_server_handler_remove( rtems_id server, rtems_vector_number vector, rtems_interrupt_handler handler, void *arg ); -- 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 at embedded-brains.de PGP : Public key available on request Diese Nachricht ist keine gesch?ftliche Mitteilung im Sinne des EHUG. From sebastian.huber at embedded-brains.de Mon Jul 13 07:58:57 2009 From: sebastian.huber at embedded-brains.de (Sebastian Huber) Date: Mon, 13 Jul 2009 09:58:57 +0200 Subject: RFC: Interrupt Manager Extension changes In-Reply-To: <4A5AE85C.1030704@embedded-brains.de> References: <4A572E49.4040407@embedded-brains.de> <4A576350.3040803@slac.stanford.edu> <4A5AE85C.1030704@embedded-brains.de> Message-ID: <4A5AE941.7@embedded-brains.de> Sebastian Huber wrote: > Till Straumann wrote: >> I like the idea of a facility to let interrupt handlers execute >> from a task context. >> >> However, IMO it would be far more flexible and useful if there was not >> just one server task (which still could be the default) but if >> when installing the ISR one could optionally request a new/separate >> task (with desired priority etc.). > [...] > > Yes, this is indeed more useful. I added a server identifier, so that you can > install the handlers on a particular server. Some problems: > > Do we want a default server? > How do we initialize the default server? > How do we refer to the default server? Maybe we can use the NULL pointer for @a server in rtems_interrupt_server_initialize() for the default server initialization. -- 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 at embedded-brains.de PGP : Public key available on request Diese Nachricht ist keine gesch?ftliche Mitteilung im Sinne des EHUG. From kenneth.j.peters at jpl.nasa.gov Mon Jul 13 15:16:30 2009 From: kenneth.j.peters at jpl.nasa.gov (Peters, Kenneth J) Date: Mon, 13 Jul 2009 08:16:30 -0700 Subject: New floating point Wiki page Message-ID: The issue where building the RTEMS kernel with "-msoft-float" removes all floating-point context handling from RTEMS seems to rise up periodically. It seems to result from many BSPs (the sparc ones are examples) setting CPU_HARDWARE_FP FALSE as a result of using -msoft-float to compile the kernel, so that kernel FP support is defined out. Since the only explanations of this are scattered around the mailing list archives, I have written a Wiki page titled "Floating Point Support" (under "How To's") to try to provide a complete explanation. Please take a look and correct my mistakes. Ken Peters From peter.o.mueller at gmx.de Mon Jul 13 16:06:29 2009 From: peter.o.mueller at gmx.de (Peter Mueller) Date: Mon, 13 Jul 2009 18:06:29 +0200 Subject: C-Code generator from UML state charts - new version 1.6.2 Message-ID: Hello list readers, SinelaboreRT is a console application that generates C-code from UML state charts. The UML state charts can be designed with Cadifra UML editor, Enterprise Architect, UModel or Magic Draw. The generation process can be widely adjusted to your needs and produces code that can even run in an ISR. SinelaboreRT was built especially for embedded real-time/low-power systems: - Generates human readable C-code - No run-time environment needed - Fits well in different system designs (foreground/background, RTOS- based ...) - No gap anymore between design and code - Simple integration in different development environments - Low cost - Support for automatic test-case generation - Simulation in interactive or batch mode. - Interactive and remote controlled visual mode! - Optionally generating trace code - Creation of state tables from UML state charts If you want to give it a try please visit www.sinelabore.com and take a look in the manual. There is a demo versions available. With best regards, Peter Mueller -- Peter Mueller pmueller at sinelabore.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.corsepius at rtems.org Mon Jul 13 16:16:05 2009 From: ralf.corsepius at rtems.org (Ralf Corsepius) Date: Mon, 13 Jul 2009 18:16:05 +0200 Subject: SPAM: Re: C-Code generator from UML state charts - new version 1.6.2 In-Reply-To: References: Message-ID: <4A5B5DC5.8010705@rtems.org> Peter Mueller wrote: > Hello list readers, Please stop abusing this list for advertisments of closed source products which are not even related to rtems. I consider this posing of yours to be simply SPAM. Ralf From leonp at plris.com Mon Jul 13 16:36:31 2009 From: leonp at plris.com (Leon Pollak) Date: Mon, 13 Jul 2009 19:36:31 +0300 Subject: SPAM: Re: C-Code generator from UML state charts - new version 1.6.2 In-Reply-To: <4A5B5DC5.8010705@rtems.org> References: <4A5B5DC5.8010705@rtems.org> Message-ID: <200907131936.31576.leonp@plris.com> On Monday July 13 2009, Ralf Corsepius wrote: > Peter Mueller wrote: > > Hello list readers, > > Please stop abusing this list for advertisments of closed source > products which are not even related to rtems. > > I consider this posting of yours to be simply SPAM. > You are absolutely right. As for me, I promise that I will NEVER even look into the direction of Sinelabore, not to mention their products. And call everybody to do the same. -- Dr.Leon M.Pollak Director PLR Information Systems Ltd. From roxana.leontie at gmail.com Mon Jul 13 23:15:02 2009 From: roxana.leontie at gmail.com (Roxana Leontie) Date: Mon, 13 Jul 2009 19:15:02 -0400 Subject: QEMU and RTEMS problem on Ubuntu Message-ID: Hi all, I have been trying to set up a new development environment, because my previous one (I was working on a VM that had fedora 10 in it) was getting kind-of slow. I choose ubuntu just because I already had it as a dual boot on my PC. So here it is my problem: I am using - kernel: Linux 2.6.28-13-generic - qemu version: 0.10 or 0.9.1 (both of them create the same problem on ubuntu) - grub version: GNU GRUB version 1.96 When running an rtems example (say hello - from pc386) i am seeing a 1-2 minutes delay before the grub> prompt appears ( since I am seeing "Welcome to GRUB!" until i see the "GNU GRUB version 1.96" and the grub> prompt) Had anyone else encountered this problem before? Any solutions/suggestions? Roxana -------------- next part -------------- An HTML attachment was scrubbed... URL: From jszhang3 at gmail.com Tue Jul 14 04:50:15 2009 From: jszhang3 at gmail.com (JiSheng Zhang) Date: Tue, 14 Jul 2009 12:50:15 +0800 Subject: QEMU and RTEMS problem on Ubuntu In-Reply-To: References: Message-ID: <2df346410907132150s4e97a231qe139802a96011837@mail.gmail.com> I used grub 1.96+ qemu+ rtems two years ago, there is no such problem. how do you make the disk image?and how install grub into its mbr? Maybe there is some problem there Jisheng From ralf.corsepius at rtems.org Tue Jul 14 05:05:17 2009 From: ralf.corsepius at rtems.org (Ralf Corsepius) Date: Tue, 14 Jul 2009 07:05:17 +0200 Subject: QEMU and RTEMS problem on Ubuntu In-Reply-To: References: Message-ID: <4A5C120D.1050408@rtems.org> Roxana Leontie wrote: > Hi all, > > I have been trying to set up a new development environment, because my > previous one (I was working on a VM that had fedora 10 in it) was getting > kind-of slow. I choose ubuntu just because I already had it as a dual boot > on my PC. > > So here it is my problem: > I am using > - kernel: Linux 2.6.28-13-generic > - qemu version: 0.10 or 0.9.1 (both of them create the same problem on > ubuntu) > - grub version: GNU GRUB version 1.96 > When running an rtems example (say hello - from pc386) i am seeing a 1-2 > minutes delay before the grub> prompt appears ( since I am seeing "Welcome > to GRUB!" until i see the "GNU GRUB version 1.96" and the grub> prompt) > > Had anyone else encountered this problem before? Any solutions/suggestions? AFAICT, the major difference between Ubuntu and most other linux distros is Ubuntu using grub2 (c.f. above: grub-1.96) instead of grub[1] (e.g.: Fedora 11: grub-0.97). So, I am inclined to think you might either have tripped over a bug in grub2 or a grub/grub2 incompatibility. Ralf From jszhang3 at gmail.com Tue Jul 14 05:10:26 2009 From: jszhang3 at gmail.com (JiSheng Zhang) Date: Tue, 14 Jul 2009 13:10:26 +0800 Subject: QEMU and RTEMS problem on Ubuntu In-Reply-To: <4A5C120D.1050408@rtems.org> References: <4A5C120D.1050408@rtems.org> Message-ID: <2df346410907132210k35a9392foaf22c5aae170aa1@mail.gmail.com> 2009/7/14 Ralf Corsepius : > AFAICT, the major difference between Ubuntu and most other linux distros > is Ubuntu using grub2 (c.f. above: grub-1.96) instead of grub[1] > (e.g.: Fedora 11: grub-0.97). > > So, I am inclined to think you might either have tripped over a bug in > grub2 or a grub/grub2 incompatibility. > > Ralf > hmmm, ubuntu 9.10 will use grub2(grub 1.96). I tried grub2 and qemu two years ago, there's no problem. May be related with how Roxana make the disk image Jisheng From roxana.leontie at gmail.com Tue Jul 14 17:01:07 2009 From: roxana.leontie at gmail.com (Roxana Leontie) Date: Tue, 14 Jul 2009 13:01:07 -0400 Subject: QEMU and RTEMS problem on Ubuntu In-Reply-To: <4A5C120D.1050408@rtems.org> References: <4A5C120D.1050408@rtems.org> Message-ID: Ralf the difference between Ubuntu and Fedora (grub2 vs grub[1]) is not something that I have to worry about. I am using a rtems-boot.img from Chris Johns that has the grub version 1.96 on it and can read the ext2 file system. This is what I have tried so far: 1.- removed all hdd's except the vfat partition as hda(then as hdb) - same result 2.- booted from a linux image ( the qemu small image ),then copied rtems-grub.cfg to the root of the filesystem. After that I booted again from the rtems floppy, hoping it will find the rtems-grub.cfg there. (no result) 3. - booted with hda as the linux image( a valid image - rather our fake zero-ed image) and hdb as the fat local directory. Still the same delay. 4. - booted from the linux small image and mounted the hdb vfat partition. All was good. Except ls listed the rtems-grub.cfg as rtems-gr.cfg. Might this be the cause ? Any other toughts? Thanks, Roxana On Tue, Jul 14, 2009 at 1:05 AM, Ralf Corsepius wrote: > Roxana Leontie wrote: > >> Hi all, >> >> I have been trying to set up a new development environment, because my >> previous one (I was working on a VM that had fedora 10 in it) was getting >> kind-of slow. I choose ubuntu just because I already had it as a dual boot >> on my PC. >> >> So here it is my problem: >> I am using >> - kernel: Linux 2.6.28-13-generic >> - qemu version: 0.10 or 0.9.1 (both of them create the same problem on >> ubuntu) >> - grub version: GNU GRUB version 1.96 >> When running an rtems example (say hello - from pc386) i am seeing a 1-2 >> minutes delay before the grub> prompt appears ( since I am seeing >> "Welcome >> to GRUB!" until i see the "GNU GRUB version 1.96" and the grub> prompt) >> >> Had anyone else encountered this problem before? Any >> solutions/suggestions? >> > AFAICT, the major difference between Ubuntu and most other linux distros is > Ubuntu using grub2 (c.f. above: grub-1.96) instead of grub[1] > (e.g.: Fedora 11: grub-0.97). > > So, I am inclined to think you might either have tripped over a bug in > grub2 or a grub/grub2 incompatibility. > > Ralf > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jszhang3 at gmail.com Tue Jul 14 17:13:47 2009 From: jszhang3 at gmail.com (JiSheng Zhang) Date: Wed, 15 Jul 2009 01:13:47 +0800 Subject: QEMU and RTEMS problem on Ubuntu In-Reply-To: References: <4A5C120D.1050408@rtems.org> Message-ID: <2df346410907141013k18781d07j25f52656e26fd914@mail.gmail.com> I have tried to build floppy image myself as I did two years ago but failed, this is the error message which grub-setup prints: grub-setup: info: the size of fd0 is 2880 grub-setup: info: the size of fd0 is 2880 grub-setup: info: the size of fd0 is 2880 grub-setup: info: the size of fd0 is 2880 grub-setup: info: the size of fd0 is 2880 grub-setup: info: the size of fd0 is 2880 grub-setup: info: getting the size of /tmp/loop/boot/grub/boot.img grub-setup: info: reading /tmp/loop/boot/grub/boot.img grub-setup: info: getting the size of /tmp/loop/boot/grub/boot.img grub-setup: info: getting the size of /tmp/loop/boot/grub/core.img grub-setup: info: reading /tmp/loop/boot/grub/core.img grub-setup: info: getting the size of /tmp/loop/boot/grub/core.img grub-setup: info: the size of fd0 is 2880 grub-setup: info: the size of fd0 is 2880 grub-setup: info: setting the root device to `fd0' grub-setup: info: dos partition is -1, bsd partition is -1 grub-setup: warn: Your embedding area is unusually small. core.img won't fit in it. grub-setup: warn: Embedding is not possible. GRUB can only be installed in this setup by using blocklists. However, blocklists are UNRELIABLE and its use is discouraged. grub-setup: info: attempting to read the core image `/tmp/loop/boot/grub/core.img' from GRUB grub-setup: info: the size of fd0 is 2880 grub-setup: info: the size of fd0 is 2880 grub-setup: info: couldn't open the core image grub-setup: info: error message = file not found grub-setup: info: attempting to read the core image `/grub/core.img' from GRUB again grub-setup: info: the size of fd0 is 2880 grub-setup: info: the size of fd0 is 2880 grub-setup: info: couldn't open the core image grub-setup: info: error message = file not found grub-setup: info: attempting to read the core image `/grub/core.img' from GRUB again grub-setup: info: the size of fd0 is 2880 grub-setup: info: the size of fd0 is 2880 grub-setup: info: couldn't open the core image grub-setup: info: error message = file not found grub-setup: info: attempting to read the core image `/grub/core.img' from GRUB again grub-setup: info: the size of fd0 is 2880 grub-setup: info: the size of fd0 is 2880 grub-setup: info: couldn't open the core image grub-setup: info: error message = file not found grub-setup: info: attempting to read the core image `/grub/core.img' from GRUB again grub-setup: info: the size of fd0 is 2880 grub-setup: info: the size of fd0 is 2880 grub-setup: info: couldn't open the core image grub-setup: info: error message = file not found grub-setup: error: Cannot read `/grub/core.img' correctly IMHO, there's a lot of bugs in grub2 now. So it's better to use grub, it is OK 2009/7/15 Roxana Leontie : > Ralf the difference between Ubuntu and Fedora (grub2 vs grub[1]) is not > something that I have to worry about. I am using a rtems-boot.img from Chris > Johns that has the grub version 1.96 on it and can read the ext2 file > system. I got the same results when using the img form Chris Johns JiSheng From chrisj at rtems.org Wed Jul 15 00:08:56 2009 From: chrisj at rtems.org (Chris Johns) Date: Wed, 15 Jul 2009 10:08:56 +1000 Subject: QEMU and RTEMS problem on Ubuntu In-Reply-To: <2df346410907141013k18781d07j25f52656e26fd914@mail.gmail.com> References: <4A5C120D.1050408@rtems.org> <2df346410907141013k18781d07j25f52656e26fd914@mail.gmail.com> Message-ID: <4A5D1E18.7090009@rtems.org> JiSheng Zhang wrote: > > IMHO, there's a lot of bugs in grub2 now. So it's better to use grub, it is OK > I build grub2 and use it without any problems on Fedora. The only issue I have had is the ata.o module. Do not use this one. > > 2009/7/15 Roxana Leontie : >> Ralf the difference between Ubuntu and Fedora (grub2 vs grub[1]) is not >> something that I have to worry about. I am using a rtems-boot.img from Chris >> Johns that has the grub version 1.96 on it and can read the ext2 file >> system. > I got the same results when using the img form Chris Johns Interesting. I have not followed what host you are using. Is it Ubuntu ? Do you have a working grub image that Roxana can use ? Regards Chris From jszhang3 at gmail.com Wed Jul 15 02:53:14 2009 From: jszhang3 at gmail.com (JiSheng Zhang) Date: Wed, 15 Jul 2009 10:53:14 +0800 Subject: QEMU and RTEMS problem on Ubuntu In-Reply-To: <4A5D1E18.7090009@rtems.org> References: <4A5C120D.1050408@rtems.org> <2df346410907141013k18781d07j25f52656e26fd914@mail.gmail.com> <4A5D1E18.7090009@rtems.org> Message-ID: <2df346410907141953k4583ab50g4b4d2fe11f134a8b@mail.gmail.com> 2009/7/15 Chris Johns : > JiSheng Zhang wrote: >> >> IMHO, there's a lot of bugs in grub2 now. So it's better to use grub, it >> is OK >> > > I build grub2 and use it without any problems on Fedora. The only issue I > have had is the ata.o module. Do not use this one. > >> >> 2009/7/15 Roxana Leontie : >>> >>> Ralf the difference between Ubuntu and Fedora (grub2 vs grub[1]) is not >>> something that I have to worry about. I am using a rtems-boot.img from >>> Chris >>> Johns that has the grub version 1.96 on it and can read the ext2 file >>> system. >> >> I got the same results when using the img form Chris Johns > > Interesting. I have not followed what host you are using. Is it Ubuntu ? I'm using debian unstable > > Do you have a working grub image that Roxana can use ? > I don't know how to make grub2 image(there's filesystem on it). I just make a grub floppy image which filesystem is ext2. But how can I send the image to Roxana? I have no pub ftp\http etc. If we don't need make filesystem on floppy image, there's no problem with grub2(just dd if=boot.img etc.) > Regards > Chris > Thanks, Jisheng From jszhang3 at gmail.com Wed Jul 15 03:17:55 2009 From: jszhang3 at gmail.com (JiSheng Zhang) Date: Wed, 15 Jul 2009 11:17:55 +0800 Subject: QEMU and RTEMS problem on Ubuntu In-Reply-To: <2df346410907141953k4583ab50g4b4d2fe11f134a8b@mail.gmail.com> References: <4A5C120D.1050408@rtems.org> <2df346410907141013k18781d07j25f52656e26fd914@mail.gmail.com> <4A5D1E18.7090009@rtems.org> <2df346410907141953k4583ab50g4b4d2fe11f134a8b@mail.gmail.com> Message-ID: <2df346410907142017uf5df3d8o3da6739275d3a846@mail.gmail.com> OK I have send the floppy image to her Any idea about how to make an grub2 floppy image? Jisheng 2009/7/15 JiSheng Zhang : > 2009/7/15 Chris Johns : >> JiSheng Zhang wrote: >>> >>> IMHO, there's a lot of bugs in grub2 now. So it's better to use grub, it >>> is OK >>> >> >> I build grub2 and use it without any problems on Fedora. The only issue I >> have had is the ata.o module. Do not use this one. >> >>> >>> 2009/7/15 Roxana Leontie : >>>> >>>> Ralf the difference between Ubuntu and Fedora (grub2 vs grub[1]) is not >>>> something that I have to worry about. I am using a rtems-boot.img from >>>> Chris >>>> Johns that has the grub version 1.96 on it and can read the ext2 file >>>> system. >>> >>> I got the same results when using the img form Chris Johns >> >> Interesting. I have not followed what host you are using. Is it Ubuntu ? > I'm using debian unstable >> >> Do you have a working grub image that Roxana can use ? >> > I don't know how to make grub2 image(there's filesystem on it). I just > make a grub floppy image which filesystem is ext2. But how can I send > the image to Roxana? I have no pub ftp\http etc. > > If we don't need make filesystem on floppy image, there's no problem > with grub2(just dd if=boot.img etc.) >> Regards >> Chris >> > Thanks, > Jisheng > From roxana.leontie at gmail.com Wed Jul 15 23:56:50 2009 From: roxana.leontie at gmail.com (Roxana Leontie) Date: Wed, 15 Jul 2009 19:56:50 -0400 Subject: QEMU and RTEMS problem on Ubuntu Message-ID: > > OK I have send the floppy image to her Thanks I got the email and I tested the image and it worked. I will try to improve the floppy.img you sent and post an update for future references. > Any idea about how to make an grub2 floppy image? > > > Jisheng Roxana -------------- next part -------------- An HTML attachment was scrubbed... URL: From chrisj at rtems.org Thu Jul 16 23:47:33 2009 From: chrisj at rtems.org (Chris Johns) Date: Fri, 17 Jul 2009 09:47:33 +1000 Subject: QEMU and RTEMS problem on Ubuntu In-Reply-To: <2df346410907142017uf5df3d8o3da6739275d3a846@mail.gmail.com> References: <4A5C120D.1050408@rtems.org> <2df346410907141013k18781d07j25f52656e26fd914@mail.gmail.com> <4A5D1E18.7090009@rtems.org> <2df346410907141953k4583ab50g4b4d2fe11f134a8b@mail.gmail.com> <2df346410907142017uf5df3d8o3da6739275d3a846@mail.gmail.com> Message-ID: <4A5FBC15.6010503@rtems.org> JiSheng Zhang wrote: > OK I have send the floppy image to her > > Any idea about how to make an grub2 floppy image? > The script I use is here: http://www.rtems.org/ftp/pub/rtems/people/chrisj/grub/g2-rtems-floppy.sh Regards Chris From daron.chabot at gmail.com Fri Jul 17 01:25:07 2009 From: daron.chabot at gmail.com (Daron Chabot) Date: Thu, 16 Jul 2009 21:25:07 -0400 Subject: mvme6100 support Message-ID: <50cc54100907161825p5cac46a0m66be86ebc544b646@mail.gmail.com> Just looking at the cvs HEAD, it seems as though the mvme5500 bsp may also support the mvme6100 board. Is this correct ? Or should I instead be inquiring about the "beatnik" bsp for 6100 support ? Thanks. -- dc From feng at bnl.gov Fri Jul 17 01:51:34 2009 From: feng at bnl.gov (Feng, Kate) Date: Thu, 16 Jul 2009 21:51:34 -0400 Subject: mvme6100 support References: <50cc54100907161825p5cac46a0m66be86ebc544b646@mail.gmail.com> Message-ID: I wrote and upgraded the mvme5500 BSP to disco BSP to support the mvme6100 board. At that time, the performance of the network on the mvme6100 board was not important, but the decision for the choice of H/W for my project was urgent. Thus, the code for the network is not really ready for a formal release yet. It seems that the network code for beatnik BSP needs to be optimized or rewritten as well based on the version I obtained from Till Straumann a while ago. I do not know if he had any chance to improve the netowrk performance ever since then. At this point, I have at least two other higher priority tasks to be completed before I have a chance to finish rewriting the network code for the mvme6100 board to boost up its performance, although it could be a fun project. Cheers, Kate ________________________________ From: rtems-users-bounces at rtems.org on behalf of Daron Chabot Sent: Thu 7/16/2009 9:25 PM To: RTEMS Subject: mvme6100 support Just looking at the cvs HEAD, it seems as though the mvme5500 bsp may also support the mvme6100 board. Is this correct ? Or should I instead be inquiring about the "beatnik" bsp for 6100 support ? Thanks. -- dc _______________________________________________ rtems-users mailing list rtems-users at rtems.org http://www.rtems.org/mailman/listinfo/rtems-users From joel.sherrill at OARcorp.com Fri Jul 17 02:19:36 2009 From: joel.sherrill at OARcorp.com (Joel Sherrill) Date: Thu, 16 Jul 2009 21:19:36 -0500 Subject: mvme6100 support In-Reply-To: References: <50cc54100907161825p5cac46a0m66be86ebc544b646@mail.gmail.com> Message-ID: <4A5FDFB8.6050500@oarcorp.com> Feng, Kate wrote: > I wrote and upgraded the mvme5500 BSP to disco BSP to support the > mvme6100 board. At that time, the performance of the network on > the mvme6100 board was not important, but the decision for the > choice of H/W for my project was urgent. Thus, the code for > the network is not really ready for a formal release yet. It seems that the > network code for beatnik BSP needs to be optimized or rewritten as well > based on the version I obtained from Till Straumann a while ago. > I do not know if he had any chance to improve the netowrk > performance ever since then. > So .. it should work to ... a) build for mvme5500 and run on mvme6100? b) add alias to build for mvme6100 and fix x odd issues for mvme6100 Does this mean the network driver works? How bad is "not optimized" really? Just asking because I know you are a perfectionist and wanted to get an accurate description of the status. :) --joel > > At this point, I have at least two other higher priority tasks to be > completed before I have a chance to finish rewriting the network > code for the mvme6100 board to boost up its performance, although it > could be a fun project. > > Cheers, > Kate > > ________________________________ > > From: rtems-users-bounces at rtems.org on behalf of Daron Chabot > Sent: Thu 7/16/2009 9:25 PM > To: RTEMS > Subject: mvme6100 support > > > > Just looking at the cvs HEAD, it seems as though the mvme5500 bsp may > also support the mvme6100 board. Is this correct ? > > Or should I instead be inquiring about the "beatnik" bsp for 6100 support ? > > Thanks. > > > -- dc > _______________________________________________ > rtems-users mailing list > rtems-users at rtems.org > http://www.rtems.org/mailman/listinfo/rtems-users > > > _______________________________________________ > rtems-users mailing list > rtems-users at rtems.org > http://www.rtems.org/mailman/listinfo/rtems-users > From nasimz at lums.edu.pk Fri Jul 17 04:42:44 2009 From: nasimz at lums.edu.pk (Nasim Zehra) Date: Fri, 17 Jul 2009 10:42:44 +0600 Subject: Dynamic scheduling Message-ID: Does rtems support dynamic scheduling??if yes what managers are useful for this purpose? nasim From Thomas.Doerfler at embedded-brains.de Fri Jul 17 06:49:20 2009 From: Thomas.Doerfler at embedded-brains.de (Thomas Doerfler) Date: Fri, 17 Jul 2009 08:49:20 +0200 Subject: Dynamic scheduling In-Reply-To: References: Message-ID: <4A601EF0.1050907@embedded-brains.de> Hi, what exactly do you call "dynamic scheduling"? The term seems a bit "open" to me, but maybe I am simpy ignorant :-) wkr, Thomas. Nasim Zehra wrote: > Does rtems support dynamic scheduling??if yes what managers are useful for this purpose? > > nasim > _______________________________________________ > rtems-users mailing list > rtems-users at rtems.org > http://www.rtems.org/mailman/listinfo/rtems-users -- -------------------------------------------- Embedded Brains GmbH Thomas Doerfler Obere Lagerstrasse 30 D-82178 Puchheim Germany email: Thomas.Doerfler at embedded-brains.de Phone: +49-89-18908079-2 Fax: +49-89-18908079-9 From nasimz at lums.edu.pk Fri Jul 17 06:57:32 2009 From: nasimz at lums.edu.pk (Nasim Zehra) Date: Fri, 17 Jul 2009 12:57:32 +0600 Subject: Dynamic scheduling In-Reply-To: <4A601EF0.1050907@embedded-brains.de> References: , <4A601EF0.1050907@embedded-brains.de> Message-ID: like EDF, Minimum Laxity first.Actually i m having observation that rtems has only rate monotonic .static scheduling scheme, manager.May be it does not support dynamic one?I guess timer or clock directives are helpful in this regard, but i am having problem using timer directive..that what should be written in place of *user_data when timer is fired.Moreover whether should we create timer directive in main "init" function or should we create and delete then like rate monotonic periods inside the task ,mentioned in the example of rate monotonic manager. nasim ________________________________________ From: Thomas Doerfler [Thomas.Doerfler at embedded-brains.de] Sent: Friday, July 17, 2009 12:49 PM To: Nasim Zehra Cc: rtems-users at rtems.org Subject: Re: Dynamic scheduling Hi, what exactly do you call "dynamic scheduling"? The term seems a bit "open" to me, but maybe I am simpy ignorant :-) wkr, Thomas. Nasim Zehra wrote: > Does rtems support dynamic scheduling??if yes what managers are useful for this purpose? > > nasim > _______________________________________________ > rtems-users mailing list > rtems-users at rtems.org > http://www.rtems.org/mailman/listinfo/rtems-users -- -------------------------------------------- Embedded Brains GmbH Thomas Doerfler Obere Lagerstrasse 30 D-82178 Puchheim Germany email: Thomas.Doerfler at embedded-brains.de Phone: +49-89-18908079-2 Fax: +49-89-18908079-9 From nasimz at lums.edu.pk Fri Jul 17 07:03:41 2009 From: nasimz at lums.edu.pk (Nasim Zehra) Date: Fri, 17 Jul 2009 13:03:41 +0600 Subject: CPU_USAGE_REPORT() Problem Message-ID: Hi, i am having five tasks and i want cpu usage report table. just after five tasks creation ,i am having table like that ID NAME SECONDS PERCENT 0x09010001 IDLE 0.000000 0.000 0x0A010001 UI1 0.001260 100.000 0x0A010002 TA1 0.000000 0.000 0x0A010003 TA2 0.000000 0.000 0x0A010004 TA3 0.000000 0.000 0x0A010005 TA4 0.000000 0.000 0x0A010006 TA5 0.000000 0.000 ----OK bcz idle is by defaul..rest of having 0 exec time..good......But don't know what UI1 is ?????? ok then after execution of all the tasks i am having table like that ID NAME SECONDS PERCENT 0x09010001 IDLE 0.000000 0.000 0x0A010001 UI1 0.000787 0.024 0x0A010002 TA1 2.216917 70.157 0x0A010004 TA3 0.001027 0.032 0x0A010006 TA5 0.000000 0.000 --still made at UI1..what is it? and where TA2 AND TA4 have gone????? although i tried to solve this problem by defining array of task name and id of size 7 instead of five.I know it is ridiculus to do this...it should have no effect on this problem.any solution? nasim From nasimz at lums.edu.pk Fri Jul 17 07:09:25 2009 From: nasimz at lums.edu.pk (Nasim Zehra) Date: Fri, 17 Jul 2009 13:09:25 +0600 Subject: CPU_USAGE_REPORT() Problem In-Reply-To: References: Message-ID: moreover it does not give info. like Ticks since last reset = 1600 Total Units = 1608 mentioned in c user guide of rtem. I am using rtems 4.8. rtems newer than 4.7 use seconds approach instead of ticks ?in rtems 4.8 ,using cpu_usage_report(),can i get ticks info instead of seconds? nasim ________________________________________ From: rtems-users-bounces at rtems.org [rtems-users-bounces at rtems.org] On Behalf Of Nasim Zehra [nasimz at lums.edu.pk] Sent: Friday, July 17, 2009 1:03 PM To: rtems-users at rtems.org Subject: CPU_USAGE_REPORT() Problem Hi, i am having five tasks and i want cpu usage report table. just after five tasks creation ,i am having table like that ID NAME SECONDS PERCENT 0x09010001 IDLE 0.000000 0.000 0x0A010001 UI1 0.001260 100.000 0x0A010002 TA1 0.000000 0.000 0x0A010003 TA2 0.000000 0.000 0x0A010004 TA3 0.000000 0.000 0x0A010005 TA4 0.000000 0.000 0x0A010006 TA5 0.000000 0.000 ----OK bcz idle is by defaul..rest of having 0 exec time..good......But don't know what UI1 is ?????? ok then after execution of all the tasks i am having table like that ID NAME SECONDS PERCENT 0x09010001 IDLE 0.000000 0.000 0x0A010001 UI1 0.000787 0.024 0x0A010002 TA1 2.216917 70.157 0x0A010004 TA3 0.001027 0.032 0x0A010006 TA5 0.000000 0.000 --still made at UI1..what is it? and where TA2 AND TA4 have gone????? although i tried to solve this problem by defining array of task name and id of size 7 instead of five.I know it is ridiculus to do this...it should have no effect on this problem.any solution? nasim _______________________________________________ rtems-users mailing list rtems-users at rtems.org http://www.rtems.org/mailman/listinfo/rtems-users From manuel.coutinho at edisoft.pt Fri Jul 17 08:15:13 2009 From: manuel.coutinho at edisoft.pt (Manuel Coutinho) Date: Fri, 17 Jul 2009 09:15:13 +0100 Subject: CPU_USAGE_REPORT() Problem In-Reply-To: References: Message-ID: <000001ca06b6$b5f49500$680aa8c0@ecmcoutinho> Hi The UI1 is your "Init" task. You can change the name (and entry point and other parameters) using the confdefs.h options. RTEMS counts the percentage through the number of clock ticks that occur during the execution of each task. As to the other problems, have no response to them (don't know your system that well). Regards Manuel Coutinho > -----Original Message----- > From: rtems-users-bounces at rtems.org [mailto:rtems-users-bounces at rtems.org] > On Behalf Of Nasim Zehra > Sent: Friday, July 17, 2009 8:09 AM > To: Nasim Zehra > Cc: rtems-users at rtems.org > Subject: RE: CPU_USAGE_REPORT() Problem > > moreover it does not give info. like > > Ticks since last reset = 1600 > Total Units = 1608 > mentioned in c user guide of rtem. > I am using rtems 4.8. rtems newer than 4.7 use seconds approach instead of > ticks ?in rtems 4.8 ,using cpu_usage_report(),can i get ticks info instead > of seconds? > > nasim > ________________________________________ > From: rtems-users-bounces at rtems.org [rtems-users-bounces at rtems.org] On > Behalf Of Nasim Zehra [nasimz at lums.edu.pk] > Sent: Friday, July 17, 2009 1:03 PM > To: rtems-users at rtems.org > Subject: CPU_USAGE_REPORT() Problem > > Hi, > i am having five tasks and i want cpu usage report table. > just after five tasks creation ,i am having table like that > ID NAME SECONDS PERCENT > 0x09010001 IDLE 0.000000 0.000 > 0x0A010001 UI1 0.001260 100.000 > 0x0A010002 TA1 0.000000 0.000 > 0x0A010003 TA2 0.000000 0.000 > 0x0A010004 TA3 0.000000 0.000 > 0x0A010005 TA4 0.000000 0.000 > 0x0A010006 TA5 0.000000 0.000 > > ----OK bcz idle is by defaul..rest of having 0 exec time..good......But > don't know what UI1 is ?????? > > ok then after execution of all the tasks i am having table like that > > ID NAME SECONDS PERCENT > 0x09010001 IDLE 0.000000 0.000 > 0x0A010001 UI1 0.000787 0.024 > 0x0A010002 TA1 2.216917 70.157 > 0x0A010004 TA3 0.001027 0.032 > 0x0A010006 TA5 0.000000 0.000 > > --still made at UI1..what is it? and where TA2 AND TA4 have gone????? > although i tried to solve this problem by defining array of task name and > id of size 7 instead of five.I know it is ridiculus to do this...it should > have no effect on this problem.any solution? > > > nasim > _______________________________________________ > rtems-users mailing list > rtems-users at rtems.org > http://www.rtems.org/mailman/listinfo/rtems-users > _______________________________________________ > rtems-users mailing list > rtems-users at rtems.org > http://www.rtems.org/mailman/listinfo/rtems-users From manuel.coutinho at edisoft.pt Fri Jul 17 08:20:38 2009 From: manuel.coutinho at edisoft.pt (Manuel Coutinho) Date: Fri, 17 Jul 2009 09:20:38 +0100 Subject: Dynamic scheduling In-Reply-To: References: , <4A601EF0.1050907@embedded-brains.de> Message-ID: <000101ca06b7$7768d020$680aa8c0@ecmcoutinho> RTEMS has fixed-priority scheduling. RTEMS does not support dynamic scheduling. Actually, the rate monotonic that is referred only makes tasks to be periodic. It does not implement the Rate Monotonic Scheduler. The application must correctly assign the tasks priorities in order for the Rate Monotonic Scheduler to work. Note that is good that RTEMS does this because other scheduler variants can be easily implemented (e.g Deadline Monotonic). Also, there are system models, for example, non-preemptive or in which the task releases are well defined, in which the Rate Monotonic Scheduler is NOT the optimal scheduler. Hope this helps Regards Manuel Coutinho > -----Original Message----- > From: rtems-users-bounces at rtems.org [mailto:rtems-users-bounces at rtems.org] > On Behalf Of Nasim Zehra > Sent: Friday, July 17, 2009 7:58 AM > To: Thomas Doerfler > Cc: rtems-users at rtems.org > Subject: RE: Dynamic scheduling > > like EDF, Minimum Laxity first.Actually i m having observation that rtems > has only rate monotonic .static scheduling scheme, manager.May be it does > not support dynamic one?I guess timer or clock directives are helpful in > this regard, but i am having problem using timer directive..that what > should be written in place of *user_data when timer is fired.Moreover > whether should we create timer directive in main "init" function or should > we create and delete then like rate monotonic periods inside the task > ,mentioned in the example of rate monotonic manager. > > nasim > ________________________________________ > From: Thomas Doerfler [Thomas.Doerfler at embedded-brains.de] > Sent: Friday, July 17, 2009 12:49 PM > To: Nasim Zehra > Cc: rtems-users at rtems.org > Subject: Re: Dynamic scheduling > > Hi, > > what exactly do you call "dynamic scheduling"? The term seems a bit > "open" to me, but maybe I am simpy ignorant :-) > > wkr, > Thomas. > > Nasim Zehra wrote: > > Does rtems support dynamic scheduling??if yes what managers are useful > for this purpose? > > > > nasim > > _______________________________________________ > > rtems-users mailing list > > rtems-users at rtems.org > > http://www.rtems.org/mailman/listinfo/rtems-users > > > -- > > -------------------------------------------- > Embedded Brains GmbH > Thomas Doerfler Obere Lagerstrasse 30 > D-82178 Puchheim Germany > email: Thomas.Doerfler at embedded-brains.de > Phone: +49-89-18908079-2 > Fax: +49-89-18908079-9 > _______________________________________________ > rtems-users mailing list > rtems-users at rtems.org > http://www.rtems.org/mailman/listinfo/rtems-users From nasimz at lums.edu.pk Fri Jul 17 09:07:33 2009 From: nasimz at lums.edu.pk (Nasim Zehra) Date: Fri, 17 Jul 2009 15:07:33 +0600 Subject: CPU_USAGE_REPORT() Problem In-Reply-To: <000001ca06b6$b5f49500$680aa8c0@ecmcoutinho> References: , <000001ca06b6$b5f49500$680aa8c0@ecmcoutinho> Message-ID: if this is init function ,should it not have maximum execution seconds than any other of the tasks?becuase it is suspended and then is resumed after completion of all the tasks.Answers for other problems still are required. nasim ________________________________________ From: Manuel Coutinho [manuel.coutinho at edisoft.pt] Sent: Friday, July 17, 2009 2:15 PM To: Nasim Zehra Cc: rtems-users at rtems.org Subject: RE: CPU_USAGE_REPORT() Problem Hi The UI1 is your "Init" task. You can change the name (and entry point and other parameters) using the confdefs.h options. RTEMS counts the percentage through the number of clock ticks that occur during the execution of each task. As to the other problems, have no response to them (don't know your system that well). Regards Manuel Coutinho > -----Original Message----- > From: rtems-users-bounces at rtems.org [mailto:rtems-users-bounces at rtems.org] > On Behalf Of Nasim Zehra > Sent: Friday, July 17, 2009 8:09 AM > To: Nasim Zehra > Cc: rtems-users at rtems.org > Subject: RE: CPU_USAGE_REPORT() Problem > > moreover it does not give info. like > > Ticks since last reset = 1600 > Total Units = 1608 > mentioned in c user guide of rtem. > I am using rtems 4.8. rtems newer than 4.7 use seconds approach instead of > ticks ?in rtems 4.8 ,using cpu_usage_report(),can i get ticks info instead > of seconds? > > nasim > ________________________________________ > From: rtems-users-bounces at rtems.org [rtems-users-bounces at rtems.org] On > Behalf Of Nasim Zehra [nasimz at lums.edu.pk] > Sent: Friday, July 17, 2009 1:03 PM > To: rtems-users at rtems.org > Subject: CPU_USAGE_REPORT() Problem > > Hi, > i am having five tasks and i want cpu usage report table. > just after five tasks creation ,i am having table like that > ID NAME SECONDS PERCENT > 0x09010001 IDLE 0.000000 0.000 > 0x0A010001 UI1 0.001260 100.000 > 0x0A010002 TA1 0.000000 0.000 > 0x0A010003 TA2 0.000000 0.000 > 0x0A010004 TA3 0.000000 0.000 > 0x0A010005 TA4 0.000000 0.000 > 0x0A010006 TA5 0.000000 0.000 > > ----OK bcz idle is by defaul..rest of having 0 exec time..good......But > don't know what UI1 is ?????? > > ok then after execution of all the tasks i am having table like that > > ID NAME SECONDS PERCENT > 0x09010001 IDLE 0.000000 0.000 > 0x0A010001 UI1 0.000787 0.024 > 0x0A010002 TA1 2.216917 70.157 > 0x0A010004 TA3 0.001027 0.032 > 0x0A010006 TA5 0.000000 0.000 > > --still made at UI1..what is it? and where TA2 AND TA4 have gone????? > although i tried to solve this problem by defining array of task name and > id of size 7 instead of five.I know it is ridiculus to do this...it should > have no effect on this problem.any solution? > > > nasim > _______________________________________________ > rtems-users mailing list > rtems-users at rtems.org > http://www.rtems.org/mailman/listinfo/rtems-users > _______________________________________________ > rtems-users mailing list > rtems-users at rtems.org > http://www.rtems.org/mailman/listinfo/rtems-users From feng1 at bnl.gov Fri Jul 17 11:06:25 2009 From: feng1 at bnl.gov (Kate Feng) Date: Fri, 17 Jul 2009 07:06:25 -0400 Subject: mvme6100 support In-Reply-To: <4A5FDFB8.6050500@oarcorp.com> References: <50cc54100907161825p5cac46a0m66be86ebc544b646@mail.gmail.com> <4A5FDFB8.6050500@oarcorp.com> Message-ID: <4A605B31.3020005@bnl.gov> Joel Sherrill wrote: > Feng, Kate wrote: >> I wrote and upgraded the mvme5500 BSP to disco BSP to support the >> mvme6100 board. At that time, the performance of the network on >> the mvme6100 board was not important, but the decision for the >> choice of H/W for my project was urgent. Thus, the code for >> the network is not really ready for a formal release yet. It seems >> that the >> network code for beatnik BSP needs to be optimized or rewritten as >> well >> based on the version I obtained from Till Straumann a while ago. I >> do not know if he had any chance to improve the netowrk >> performance ever since then. > So .. it should work to ... > > a) build for mvme5500 and run on mvme6100? Not the mvme5500 BSP in the current RTEMS release. I could rename "disco" BSP back to "mvme5500" BSP for the RTEMS release, except the network driver was/is really not ready for the open release yet. > b) add alias to build for mvme6100 and fix x odd > issues for mvme6100 > > Does this mean the network driver works? How > bad is "not optimized" really? Yes, the network driver for the mvme6100 works, at least for the one project I tested, but a workaround that have degraded the actual performance of the H/W by my estimation of at least two. It was not written for the real-time performance because there were somethings missing. I had to quickly move on to a different H/W platform because the DDR memory date rate is too slow for my project, not because of the network driver. I actually started to rewrite the driver to meet the requirement of the real-time programming. However, it kept getting interrupted by my other higher priority projects that I could not get this project completed. It should be fun to get it finished, but it is more important to get my other projects done at this point. Regards, Kate > > Just asking because I know you are a perfectionist and > wanted to get an accurate description of the status. :) > > --joel >> >> At this point, I have at least two other higher priority tasks to be >> completed before I have a chance to finish rewriting the network >> code for the mvme6100 board to boost up its performance, although it >> could be a fun project. >> >> Cheers, >> Kate >> >> ________________________________ >> >> From: rtems-users-bounces at rtems.org on behalf of Daron Chabot >> Sent: Thu 7/16/2009 9:25 PM >> To: RTEMS >> Subject: mvme6100 support >> >> >> >> Just looking at the cvs HEAD, it seems as though the mvme5500 bsp may >> also support the mvme6100 board. Is this correct ? >> >> Or should I instead be inquiring about the "beatnik" bsp for 6100 >> support ? >> >> Thanks. >> >> >> -- dc >> _______________________________________________ >> rtems-users mailing list >> rtems-users at rtems.org >> http://www.rtems.org/mailman/listinfo/rtems-users >> >> >> _______________________________________________ >> rtems-users mailing list >> rtems-users at rtems.org >> http://www.rtems.org/mailman/listinfo/rtems-users >> > From daron.chabot at gmail.com Fri Jul 17 11:37:24 2009 From: daron.chabot at gmail.com (Daron Chabot) Date: Fri, 17 Jul 2009 07:37:24 -0400 Subject: mvme6100 support In-Reply-To: <4A605B31.3020005@bnl.gov> References: <50cc54100907161825p5cac46a0m66be86ebc544b646@mail.gmail.com> <4A5FDFB8.6050500@oarcorp.com> <4A605B31.3020005@bnl.gov> Message-ID: <50cc54100907170437t57d47200weef29be47251f403@mail.gmail.com> On Fri, Jul 17, 2009 at 7:06 AM, Kate Feng wrote: > Joel Sherrill wrote: >> >> Feng, Kate wrote: >>> >>> I wrote and upgraded the mvme5500 BSP to disco BSP to support the >>> mvme6100 board. ?At that time, the performance of the network on >>> the mvme6100 board was not important, but the decision for the >>> choice of H/W for my project was urgent. ?Thus, the code for >>> the network is not really ready for a formal release yet. ?It seems that >>> the >>> network code for beatnik BSP needs to be ?optimized or rewritten ?as well >>> based on the version I obtained from Till Straumann a while ago. ?I do >>> not know if he had any chance to improve the netowrk >>> performance ever since then. >> >> So .. it should work to ... >> >> a) build for mvme5500 and run on mvme6100? > > Not the mvme5500 BSP ?in the current RTEMS release. As in my original posting, I am not referring to the current (4.9.2) release, but to the mvme5500 BSP as it stands in the cvs HEAD version. This enum from mvme5500/include/bsp.h seems to imply run-time detection of board type: /* Board type */ typedef enum { undefined = 0, MVME5500, MVME6100 } BSP_BoardTypes; So, as Joel asked, with the version on cvs HEAD, is it possible to build for the 5500 and _run_ on the 6100 ? BTW -- Kate, I am now working at BNL with the NSLS2 controls group :-) so, I may be able to help with the mvme6100 bsp issues. -- dc > I could rename "disco" BSP ?back to "mvme5500" BSP > for the RTEMS release, except the network driver was/is > really not ready for the open release yet. >> >> b) add alias to build for mvme6100 and fix x odd >> ? ?issues for mvme6100 >> >> Does this mean the network driver works? ?How >> bad is "not optimized" really? > > Yes, the network driver for the mvme6100 works, at > least for the one project I tested, but a workaround that > have degraded the actual performance of the H/W by my > estimation of at least two. > It was not written for the real-time performance because > there were somethings missing. ?I had to quickly move on > to a different H/W platform because the DDR memory > date rate is too slow for my project, not because of the > network driver. ?I actually started to rewrite the driver to > meet the requirement of the real-time programming. > However, it kept getting interrupted by my other higher > priority projects that I could not get this project > completed. ?It should be fun to get it finished, but > it is more important to get my other projects done at > this point. > > Regards, > Kate >> >> Just asking because I know you are a perfectionist and >> wanted to get an accurate description of the status. :) >> >> --joel >>> >>> ?At this point, I have at least two other higher priority tasks to be >>> completed before I have a chance to ?finish rewriting the network >>> code for the mvme6100 board to boost up its performance, although it >>> could be a fun project. >>> ?Cheers, >>> Kate >>> >>> ________________________________ >>> >>> From: rtems-users-bounces at rtems.org on behalf of Daron Chabot >>> Sent: Thu 7/16/2009 9:25 PM >>> To: RTEMS >>> Subject: mvme6100 support >>> >>> >>> >>> Just looking at the cvs HEAD, it seems as though the mvme5500 bsp may >>> also support the mvme6100 board. Is this correct ? >>> >>> Or should I instead be inquiring about the "beatnik" bsp for 6100 support >>> ? >>> >>> Thanks. >>> >>> >>> -- dc >>> _______________________________________________ >>> rtems-users mailing list >>> rtems-users at rtems.org >>> http://www.rtems.org/mailman/listinfo/rtems-users >>> >>> >>> _______________________________________________ >>> rtems-users mailing list >>> rtems-users at rtems.org >>> http://www.rtems.org/mailman/listinfo/rtems-users >>> >> > > From feng1 at bnl.gov Fri Jul 17 12:23:19 2009 From: feng1 at bnl.gov (Kate Feng) Date: Fri, 17 Jul 2009 08:23:19 -0400 Subject: mvme6100 support for CVS head In-Reply-To: <50cc54100907170437t57d47200weef29be47251f403@mail.gmail.com> References: <50cc54100907161825p5cac46a0m66be86ebc544b646@mail.gmail.com> <4A5FDFB8.6050500@oarcorp.com> <4A605B31.3020005@bnl.gov> <50cc54100907170437t57d47200weef29be47251f403@mail.gmail.com> Message-ID: <4A606D37.1030204@bnl.gov> Daron Chabot wrote: > On Fri, Jul 17, 2009 at 7:06 AM, Kate Feng wrote: > >> Joel Sherrill wrote: >> >>> Feng, Kate wrote: >>> >>>> I wrote and upgraded the mvme5500 BSP to disco BSP to support the >>>> mvme6100 board. At that time, the performance of the network on >>>> the mvme6100 board was not important, but the decision for the >>>> choice of H/W for my project was urgent. Thus, the code for >>>> the network is not really ready for a formal release yet. It seems that >>>> the >>>> network code for beatnik BSP needs to be optimized or rewritten as well >>>> based on the version I obtained from Till Straumann a while ago. I do >>>> not know if he had any chance to improve the netowrk >>>> performance ever since then. >>>> >>> So .. it should work to ... >>> >>> a) build for mvme5500 and run on mvme6100? >>> >> Not the mvme5500 BSP in the current RTEMS release. >> > > As in my original posting, I am not referring to the current (4.9.2) > release, but to the mvme5500 BSP as it stands > in the cvs HEAD version. > > This enum from mvme5500/include/bsp.h seems to imply run-time > detection of board type: > /* Board type */ > typedef enum { > undefined = 0, > MVME5500, > MVME6100 > } BSP_BoardTypes; > > So, as Joel asked, with the version on cvs HEAD, is it possible to > build for the 5500 and _run_ on the 6100 ? > I will have to submit the network driver for the mvme6100. I just wish one to be aware that the current driver is not written in the typical RTEMS real-time fashion, and its performance could be boosted -up to at least an estimated factor of two. Thus, one should not use that as a template for other network driver. Speaking of the CVS head, back in April, I had to modify some shared files to solve the issue with the RTEMS work space and C program heap before I submitted the updated code for mvme5500 BSP. I did not send the patch for the shared files back then because I only had it tested for the case when rtems_unified_work_area is false. Joel, is the code updated ? The code should be updated before mvme5500, mvme6100, and I think any other PPC can work. Did I miss something ? Kate > BTW -- Kate, I am now working at BNL with the NSLS2 controls group :-) > so, I may be able to help with the mvme6100 bsp issues. > > > -- dc > > >> I could rename "disco" BSP back to "mvme5500" BSP >> for the RTEMS release, except the network driver was/is >> really not ready for the open release yet. >> >>> b) add alias to build for mvme6100 and fix x odd >>> issues for mvme6100 >>> >>> Does this mean the network driver works? How >>> bad is "not optimized" really? >>> >> Yes, the network driver for the mvme6100 works, at >> least for the one project I tested, but a workaround that >> have degraded the actual performance of the H/W by my >> estimation of at least two. >> It was not written for the real-time performance because >> there were somethings missing. I had to quickly move on >> to a different H/W platform because the DDR memory >> date rate is too slow for my project, not because of the >> network driver. I actually started to rewrite the driver to >> meet the requirement of the real-time programming. >> However, it kept getting interrupted by my other higher >> priority projects that I could not get this project >> completed. It should be fun to get it finished, but >> it is more important to get my other projects done at >> this point. >> >> Regards, >> Kate >> >>> Just asking because I know you are a perfectionist and >>> wanted to get an accurate description of the status. :) >>> >>> --joel >>> >>>> At this point, I have at least two other higher priority tasks to be >>>> completed before I have a chance to finish rewriting the network >>>> code for the mvme6100 board to boost up its performance, although it >>>> could be a fun project. >>>> Cheers, >>>> Kate >>>> >>>> ________________________________ >>>> >>>> From: rtems-users-bounces at rtems.org on behalf of Daron Chabot >>>> Sent: Thu 7/16/2009 9:25 PM >>>> To: RTEMS >>>> Subject: mvme6100 support >>>> >>>> >>>> >>>> Just looking at the cvs HEAD, it seems as though the mvme5500 bsp may >>>> also support the mvme6100 board. Is this correct ? >>>> >>>> Or should I instead be inquiring about the "beatnik" bsp for 6100 support >>>> ? >>>> >>>> Thanks. >>>> >>>> >>>> -- dc >>>> _______________________________________________ >>>> rtems-users mailing list >>>> rtems-users at rtems.org >>>> http://www.rtems.org/mailman/listinfo/rtems-users >>>> >>>> >>>> _______________________________________________ >>>> rtems-users mailing list >>>> rtems-users at rtems.org >>>> http://www.rtems.org/mailman/listinfo/rtems-users >>>> >>>> >> From joel.sherrill at OARcorp.com Fri Jul 17 12:36:19 2009 From: joel.sherrill at OARcorp.com (Joel Sherrill) Date: Fri, 17 Jul 2009 07:36:19 -0500 Subject: CPU_USAGE_REPORT() Problem In-Reply-To: References: Message-ID: <4A607043.6020007@oarcorp.com> Nasim Zehra wrote: > Hi, > i am having five tasks and i want cpu usage report table. > just after five tasks creation ,i am having table like that > ID NAME SECONDS PERCENT > 0x09010001 IDLE 0.000000 0.000 > 0x0A010001 UI1 0.001260 100.000 > 0x0A010002 TA1 0.000000 0.000 > 0x0A010003 TA2 0.000000 0.000 > 0x0A010004 TA3 0.000000 0.000 > 0x0A010005 TA4 0.000000 0.000 > 0x0A010006 TA5 0.000000 0.000 > > ----OK bcz idle is by defaul..rest of having 0 exec time..good......But don't know what UI1 is ?????? > > ok then after execution of all the tasks i am having table like that > > ID NAME SECONDS PERCENT > 0x09010001 IDLE 0.000000 0.000 > 0x0A010001 UI1 0.000787 0.024 > 0x0A010002 TA1 2.216917 70.157 > 0x0A010004 TA3 0.001027 0.032 > 0x0A010006 TA5 0.000000 0.000 > > --still made at UI1..what is it? and where TA2 AND TA4 have gone????? > UI1 is the default name of the user initialization task. Tasks missing indicates that they have exited or been deleted. The percentage doesn't get close to 100% because the report wasn't reset after they were deleted. With no source code, this is an educated guess on TA2 and TA4 > although i tried to solve this problem by defining array of task name and id of size 7 instead of five.I know it is ridiculus to do this...it should have no effect on this problem.any solution? > > Array is just used by the tests. Name is stored internal to TCB, > nasim > _______________________________________________ > rtems-users mailing list > rtems-users at rtems.org > http://www.rtems.org/mailman/listinfo/rtems-users > From joel.sherrill at OARcorp.com Fri Jul 17 12:37:29 2009 From: joel.sherrill at OARcorp.com (Joel Sherrill) Date: Fri, 17 Jul 2009 07:37:29 -0500 Subject: CPU_USAGE_REPORT() Problem In-Reply-To: References: Message-ID: <4A607089.5050504@oarcorp.com> Nasim Zehra wrote: > moreover it does not give info. like > > Ticks since last reset = 1600 > Total Units = 1608 > mentioned in c user guide of rtem. > I am using rtems 4.8. rtems newer than 4.7 use seconds approach instead of ticks ?in rtems 4.8 ,using cpu_usage_report(),can i get ticks info instead of seconds? > > Are you running on a sparc on sis or tsim? I have noticed that the last few lines of output do not always get flushed through RTEMS and the simulator as you are shutting down on those. --joel > nasim > ________________________________________ > From: rtems-users-bounces at rtems.org [rtems-users-bounces at rtems.org] On Behalf Of Nasim Zehra [nasimz at lums.edu.pk] > Sent: Friday, July 17, 2009 1:03 PM > To: rtems-users at rtems.org > Subject: CPU_USAGE_REPORT() Problem > > Hi, > i am having five tasks and i want cpu usage report table. > just after five tasks creation ,i am having table like that > ID NAME SECONDS PERCENT > 0x09010001 IDLE 0.000000 0.000 > 0x0A010001 UI1 0.001260 100.000 > 0x0A010002 TA1 0.000000 0.000 > 0x0A010003 TA2 0.000000 0.000 > 0x0A010004 TA3 0.000000 0.000 > 0x0A010005 TA4 0.000000 0.000 > 0x0A010006 TA5 0.000000 0.000 > > ----OK bcz idle is by defaul..rest of having 0 exec time..good......But don't know what UI1 is ?????? > > ok then after execution of all the tasks i am having table like that > > ID NAME SECONDS PERCENT > 0x09010001 IDLE 0.000000 0.000 > 0x0A010001 UI1 0.000787 0.024 > 0x0A010002 TA1 2.216917 70.157 > 0x0A010004 TA3 0.001027 0.032 > 0x0A010006 TA5 0.000000 0.000 > > --still made at UI1..what is it? and where TA2 AND TA4 have gone????? > although i tried to solve this problem by defining array of task name and id of size 7 instead of five.I know it is ridiculus to do this...it should have no effect on this problem.any solution? > > > nasim > _______________________________________________ > rtems-users mailing list > rtems-users at rtems.org > http://www.rtems.org/mailman/listinfo/rtems-users > _______________________________________________ > rtems-users mailing list > rtems-users at rtems.org > http://www.rtems.org/mailman/listinfo/rtems-users > From joel.sherrill at OARcorp.com Fri Jul 17 14:01:43 2009 From: joel.sherrill at OARcorp.com (Joel Sherrill) Date: Fri, 17 Jul 2009 09:01:43 -0500 Subject: Dynamic scheduling In-Reply-To: <000101ca06b7$7768d020$680aa8c0@ecmcoutinho> References: , <4A601EF0.1050907@embedded-brains.de> <000101ca06b7$7768d020$680aa8c0@ecmcoutinho> Message-ID: <4A608447.80803@oarcorp.com> Manuel Coutinho wrote: > RTEMS has fixed-priority scheduling. RTEMS does not support dynamic > scheduling. > > Actually, the rate monotonic that is referred only makes tasks to be > periodic. It does not implement the Rate Monotonic Scheduler. The > application must correctly assign the tasks priorities in order for the Rate > Monotonic Scheduler to work. > http://en.wikipedia.org/wiki/Rate-monotonic_scheduling is a pretty good article. I have never seen any claim that the RMS priority assignment rule must be done by the operating system. In the original Lui/Layland paper which defined RMS and two analysis algorithms, the only requirement laid on the OS was that it support priority based scheduling with preemption. As defined there, RMS and RMA are fundamentally offline algorithms to place guarantees on task set schedulability if you follow the priority assignment rule and perform analysis. With that said, I know there are software schedulers out there which use the period information to schedule tasks. This is not a requirement. > Note that is good that RTEMS does this because other scheduler variants can > be easily implemented (e.g Deadline Monotonic). Also, there are system > models, for example, non-preemptive or in which the task releases are well > defined, in which the Rate Monotonic Scheduler is NOT the optimal scheduler. > > Hope this helps > Regards > Manuel Coutinho > > >> -----Original Message----- >> From: rtems-users-bounces at rtems.org [mailto:rtems-users-bounces at rtems.org] >> On Behalf Of Nasim Zehra >> Sent: Friday, July 17, 2009 7:58 AM >> To: Thomas Doerfler >> Cc: rtems-users at rtems.org >> Subject: RE: Dynamic scheduling >> >> like EDF, Minimum Laxity first.Actually i m having observation that rtems >> has only rate monotonic .static scheduling scheme, manager.May be it does >> not support dynamic one?I guess timer or clock directives are helpful in >> this regard, but i am having problem using timer directive..that what >> should be written in place of *user_data when timer is fired.Moreover >> whether should we create timer directive in main "init" function or should >> we create and delete then like rate monotonic periods inside the task >> ,mentioned in the example of rate monotonic manager. >> >> nasim >> ________________________________________ >> From: Thomas Doerfler [Thomas.Doerfler at embedded-brains.de] >> Sent: Friday, July 17, 2009 12:49 PM >> To: Nasim Zehra >> Cc: rtems-users at rtems.org >> Subject: Re: Dynamic scheduling >> >> Hi, >> >> what exactly do you call "dynamic scheduling"? The term seems a bit >> "open" to me, but maybe I am simpy ignorant :-) >> >> wkr, >> Thomas. >> >> Nasim Zehra wrote: >> >>> Does rtems support dynamic scheduling??if yes what managers are useful >>> >> for this purpose? >> >>> nasim >>> _______________________________________________ >>> rtems-users mailing list >>> rtems-users at rtems.org >>> http://www.rtems.org/mailman/listinfo/rtems-users >>> >> -- >> >> -------------------------------------------- >> Embedded Brains GmbH >> Thomas Doerfler Obere Lagerstrasse 30 >> D-82178 Puchheim Germany >> email: Thomas.Doerfler at embedded-brains.de >> Phone: +49-89-18908079-2 >> Fax: +49-89-18908079-9 >> _______________________________________________ >> rtems-users mailing list >> rtems-users at rtems.org >> http://www.rtems.org/mailman/listinfo/rtems-users >> > > _______________________________________________ > rtems-users mailing list > rtems-users at rtems.org > http://www.rtems.org/mailman/listinfo/rtems-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 From joel.sherrill at OARcorp.com Fri Jul 17 14:12:31 2009 From: joel.sherrill at OARcorp.com (Joel Sherrill) Date: Fri, 17 Jul 2009 09:12:31 -0500 Subject: mvme6100 support for CVS head In-Reply-To: <4A606D37.1030204@bnl.gov> References: <50cc54100907161825p5cac46a0m66be86ebc544b646@mail.gmail.com> <4A5FDFB8.6050500@oarcorp.com> <4A605B31.3020005@bnl.gov> <50cc54100907170437t57d47200weef29be47251f403@mail.gmail.com> <4A606D37.1030204@bnl.gov> Message-ID: <4A6086CF.6000507@oarcorp.com> Kate Feng wrote: > Daron Chabot wrote: > >> On Fri, Jul 17, 2009 at 7:06 AM, Kate Feng wrote: >> >> >>> Joel Sherrill wrote: >>> >>> >>>> Feng, Kate wrote: >>>> >>>> >>>>> I wrote and upgraded the mvme5500 BSP to disco BSP to support the >>>>> mvme6100 board. At that time, the performance of the network on >>>>> the mvme6100 board was not important, but the decision for the >>>>> choice of H/W for my project was urgent. Thus, the code for >>>>> the network is not really ready for a formal release yet. It seems that >>>>> the >>>>> network code for beatnik BSP needs to be optimized or rewritten as well >>>>> based on the version I obtained from Till Straumann a while ago. I do >>>>> not know if he had any chance to improve the netowrk >>>>> performance ever since then. >>>>> >>>>> >>>> So .. it should work to ... >>>> >>>> a) build for mvme5500 and run on mvme6100? >>>> >>>> >>> Not the mvme5500 BSP in the current RTEMS release. >>> >>> >> As in my original posting, I am not referring to the current (4.9.2) >> release, but to the mvme5500 BSP as it stands >> in the cvs HEAD version. >> >> This enum from mvme5500/include/bsp.h seems to imply run-time >> detection of board type: >> /* Board type */ >> typedef enum { >> undefined = 0, >> MVME5500, >> MVME6100 >> } BSP_BoardTypes; >> >> So, as Joel asked, with the version on cvs HEAD, is it possible to >> build for the 5500 and _run_ on the 6100 ? >> >> > I will have to submit the network driver for the mvme6100. I just wish > one to be aware that the current driver is not written in the typical RTEMS > real-time fashion, and its performance could be boosted -up to at least > an estimated factor of two. Thus, one should not use that as a template > for other network driver. > > Speaking of the CVS head, back in April, I had to modify some shared files > to solve the issue with the RTEMS work space and C program heap > before I submitted the updated code for mvme5500 BSP. I did not send > the patch for the shared files back then because I only had it tested > for the case > when rtems_unified_work_area is false. Joel, is the code updated ? > The code should be updated before mvme5500, mvme6100, and I think > any other PPC can work. Did I miss something ? > > I have no idea what the problem you are referring to is. :) Give me a description or half-baked old patch and I will look at it. --joel > Kate > > >> BTW -- Kate, I am now working at BNL with the NSLS2 controls group :-) >> so, I may be able to help with the mvme6100 bsp issues. >> >> >> -- dc >> >> >> >>> I could rename "disco" BSP back to "mvme5500" BSP >>> for the RTEMS release, except the network driver was/is >>> really not ready for the open release yet. >>> >>> >>>> b) add alias to build for mvme6100 and fix x odd >>>> issues for mvme6100 >>>> >>>> Does this mean the network driver works? How >>>> bad is "not optimized" really? >>>> >>>> >>> Yes, the network driver for the mvme6100 works, at >>> least for the one project I tested, but a workaround that >>> have degraded the actual performance of the H/W by my >>> estimation of at least two. >>> It was not written for the real-time performance because >>> there were somethings missing. I had to quickly move on >>> to a different H/W platform because the DDR memory >>> date rate is too slow for my project, not because of the >>> network driver. I actually started to rewrite the driver to >>> meet the requirement of the real-time programming. >>> However, it kept getting interrupted by my other higher >>> priority projects that I could not get this project >>> completed. It should be fun to get it finished, but >>> it is more important to get my other projects done at >>> this point. >>> >>> Regards, >>> Kate >>> >>> >>>> Just asking because I know you are a perfectionist and >>>> wanted to get an accurate description of the status. :) >>>> >>>> --joel >>>> >>>> >>>>> At this point, I have at least two other higher priority tasks to be >>>>> completed before I have a chance to finish rewriting the network >>>>> code for the mvme6100 board to boost up its performance, although it >>>>> could be a fun project. >>>>> Cheers, >>>>> Kate >>>>> >>>>> ________________________________ >>>>> >>>>> From: rtems-users-bounces at rtems.org on behalf of Daron Chabot >>>>> Sent: Thu 7/16/2009 9:25 PM >>>>> To: RTEMS >>>>> Subject: mvme6100 support >>>>> >>>>> >>>>> >>>>> Just looking at the cvs HEAD, it seems as though the mvme5500 bsp may >>>>> also support the mvme6100 board. Is this correct ? >>>>> >>>>> Or should I instead be inquiring about the "beatnik" bsp for 6100 support >>>>> ? >>>>> >>>>> Thanks. >>>>> >>>>> >>>>> -- dc >>>>> _______________________________________________ >>>>> rtems-users mailing list >>>>> rtems-users at rtems.org >>>>> http://www.rtems.org/mailman/listinfo/rtems-users >>>>> >>>>> >>>>> _______________________________________________ >>>>> rtems-users mailing list >>>>> rtems-users at rtems.org >>>>> http://www.rtems.org/mailman/listinfo/rtems-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 From jszhang3 at gmail.com Fri Jul 17 16:28:06 2009 From: jszhang3 at gmail.com (JiSheng Zhang) Date: Sat, 18 Jul 2009 00:28:06 +0800 Subject: QEMU and RTEMS problem on Ubuntu In-Reply-To: <4A5FBC15.6010503@rtems.org> References: <4A5C120D.1050408@rtems.org> <2df346410907141013k18781d07j25f52656e26fd914@mail.gmail.com> <4A5D1E18.7090009@rtems.org> <2df346410907141953k4583ab50g4b4d2fe11f134a8b@mail.gmail.com> <2df346410907142017uf5df3d8o3da6739275d3a846@mail.gmail.com> <4A5FBC15.6010503@rtems.org> Message-ID: <2df346410907170928l3d4dc4d9v9ac710f23ff5e51c@mail.gmail.com> 2009/7/17 Chris Johns : > JiSheng Zhang wrote: >> >> OK I have send the floppy image to her >> >> Any idea about how to make an grub2 floppy image? >> > > The script I use is here: > > http://www.rtems.org/ftp/pub/rtems/people/chrisj/grub/g2-rtems-floppy.sh the last step "grub-setup" will failed now. Fortunately, it seems that someone in #haiku is one of the developers of grub2 and he helped me to make a ext2 floppy image with grub2 installed. It works. Regards, Jisheng From feng1 at bnl.gov Fri Jul 17 18:31:06 2009 From: feng1 at bnl.gov (Kate Feng) Date: Fri, 17 Jul 2009 14:31:06 -0400 Subject: mvme6100 support for CVS head In-Reply-To: <4A6086CF.6000507@oarcorp.com> References: <50cc54100907161825p5cac46a0m66be86ebc544b646@mail.gmail.com> <4A5FDFB8.6050500@oarcorp.com> <4A605B31.3020005@bnl.gov> <50cc54100907170437t57d47200weef29be47251f403@mail.gmail.com> <4A606D37.1030204@bnl.gov> <4A6086CF.6000507@oarcorp.com> Message-ID: <4A60C36A.8010709@bnl.gov> Joel Sherrill wrote: > Kate Feng wrote: >> Daron Chabot wrote: >> >>> On Fri, Jul 17, 2009 at 7:06 AM, Kate Feng wrote: >>> >>>> Joel Sherrill wrote: >>>> >>>>> Feng, Kate wrote: >>>>> >>>>>> I wrote and upgraded the mvme5500 BSP to disco BSP to support the >>>>>> mvme6100 board. At that time, the performance of the network on >>>>>> the mvme6100 board was not important, but the decision for the >>>>>> choice of H/W for my project was urgent. Thus, the code for >>>>>> the network is not really ready for a formal release yet. It >>>>>> seems that >>>>>> the >>>>>> network code for beatnik BSP needs to be optimized or rewritten >>>>>> as well >>>>>> based on the version I obtained from Till Straumann a while ago. >>>>>> I do >>>>>> not know if he had any chance to improve the netowrk >>>>>> performance ever since then. >>>>>> >>>>> So .. it should work to ... >>>>> >>>>> a) build for mvme5500 and run on mvme6100? >>>>> >>>> Not the mvme5500 BSP in the current RTEMS release. >>>> >>> As in my original posting, I am not referring to the current (4.9.2) >>> release, but to the mvme5500 BSP as it stands >>> in the cvs HEAD version. >>> >>> This enum from mvme5500/include/bsp.h seems to imply run-time >>> detection of board type: >>> /* Board type */ >>> typedef enum { >>> undefined = 0, >>> MVME5500, >>> MVME6100 >>> } BSP_BoardTypes; >>> >>> So, as Joel asked, with the version on cvs HEAD, is it possible to >>> build for the 5500 and _run_ on the 6100 ? >>> >> I will have to submit the network driver for the mvme6100. I just wish >> one to be aware that the current driver is not written in the typical >> RTEMS >> real-time fashion, and its performance could be boosted -up to at least >> an estimated factor of two. Thus, one should not use that as a template >> for other network driver. >> >> Speaking of the CVS head, back in April, I had to modify some >> shared files >> to solve the issue with the RTEMS work space and C program heap >> before I submitted the updated code for mvme5500 BSP. I did not send >> the patch for the shared files back then because I only had it tested >> for the case >> when rtems_unified_work_area is false. Joel, is the code updated ? >> The code should be updated before mvme5500, mvme6100, and I think >> any other PPC can work. Did I miss something ? >> >> > I have no idea what the problem you are referring to is. :) > > Give me a description or half-baked old patch and I will look > at it. > - The attached is the half-baked patch for the CVS head, which I only tested it with mvme5500 BSP briefly. Regarding the network driver for the mvme6100, it was ported quickly from the beatnik BSP, which was written by Till Straumann. Thus, the performance would be similar to that of the beatnik BSP. If both Joel and Till does not mind that I release a work-around version in the CVS head, I will find time to package it, if that helps. However, I only used the driver to boot up the BSP so that I could test my project. Perhaps, has one rewritten it to improve its performance since the mvme6100 boards are heavily used for others' projects ? Please advise. Sincerely, Kate -------------- next part -------------- A non-text attachment was scrubbed... Name: CVS-RTEMS4.10-libbsp.diff Type: text/x-patch Size: 4463 bytes Desc: not available URL: From chrisj at rtems.org Fri Jul 17 21:38:51 2009 From: chrisj at rtems.org (Chris Johns) Date: Sat, 18 Jul 2009 07:38:51 +1000 Subject: QEMU and RTEMS problem on Ubuntu In-Reply-To: <2df346410907170928l3d4dc4d9v9ac710f23ff5e51c@mail.gmail.com> References: <4A5C120D.1050408@rtems.org> <2df346410907141013k18781d07j25f52656e26fd914@mail.gmail.com> <4A5D1E18.7090009@rtems.org> <2df346410907141953k4583ab50g4b4d2fe11f134a8b@mail.gmail.com> <2df346410907142017uf5df3d8o3da6739275d3a846@mail.gmail.com> <4A5FBC15.6010503@rtems.org> <2df346410907170928l3d4dc4d9v9ac710f23ff5e51c@mail.gmail.com> Message-ID: <4A60EF6B.1040109@rtems.org> JiSheng Zhang wrote: > 2009/7/17 Chris Johns : >> JiSheng Zhang wrote: >>> OK I have send the floppy image to her >>> >>> Any idea about how to make an grub2 floppy image? >>> >> The script I use is here: >> >> http://www.rtems.org/ftp/pub/rtems/people/chrisj/grub/g2-rtems-floppy.sh > > the last step "grub-setup" will failed now. Fortunately, it seems that > someone in #haiku is one of the developers of grub2 and he helped me > to make a ext2 floppy image with grub2 installed. It works. > Was this a problem with the script or some thing else ? Regards Chris From nasimz at lums.edu.pk Mon Jul 20 03:43:08 2009 From: nasimz at lums.edu.pk (Nasim Zehra) Date: Mon, 20 Jul 2009 09:43:08 +0600 Subject: CPU_USAGE_REPORT() Problem In-Reply-To: <4A607089.5050504@oarcorp.com> References: , <4A607089.5050504@oarcorp.com> Message-ID: hi I am using rtems 4.8 for sparc and loen for compilation and link purpose.And then simulating its binary file through TSIM simulator.I am not shutting down on those.Moreover i am resetting too. using rtems_cpu_usage_report( ); rtems_cpu_usage_reset( ); both. and i m doing this when init task is resumed after execution of all the tasks. nasim ________________________________________ From: Joel Sherrill [joel.sherrill at oarcorp.com] Sent: Friday, July 17, 2009 6:37 PM To: Nasim Zehra Cc: rtems-users at rtems.org Subject: Re: CPU_USAGE_REPORT() Problem Nasim Zehra wrote: > moreover it does not give info. like > > Ticks since last reset = 1600 > Total Units = 1608 > mentioned in c user guide of rtem. > I am using rtems 4.8. rtems newer than 4.7 use seconds approach instead of ticks ?in rtems 4.8 ,using cpu_usage_report(),can i get ticks info instead of seconds? > > Are you running on a sparc on sis or tsim? I have noticed that the last few lines of output do not always get flushed through RTEMS and the simulator as you are shutting down on those. --joel > nasim > ________________________________________ > From: rtems-users-bounces at rtems.org [rtems-users-bounces at rtems.org] On Behalf Of Nasim Zehra [nasimz at lums.edu.pk] > Sent: Friday, July 17, 2009 1:03 PM > To: rtems-users at rtems.org > Subject: CPU_USAGE_REPORT() Problem > > Hi, > i am having five tasks and i want cpu usage report table. > just after five tasks creation ,i am having table like that > ID NAME SECONDS PERCENT > 0x09010001 IDLE 0.000000 0.000 > 0x0A010001 UI1 0.001260 100.000 > 0x0A010002 TA1 0.000000 0.000 > 0x0A010003 TA2 0.000000 0.000 > 0x0A010004 TA3 0.000000 0.000 > 0x0A010005 TA4 0.000000 0.000 > 0x0A010006 TA5 0.000000 0.000 > > ----OK bcz idle is by defaul..rest of having 0 exec time..good......But don't know what UI1 is ?????? > > ok then after execution of all the tasks i am having table like that > > ID NAME SECONDS PERCENT > 0x09010001 IDLE 0.000000 0.000 > 0x0A010001 UI1 0.000787 0.024 > 0x0A010002 TA1 2.216917 70.157 > 0x0A010004 TA3 0.001027 0.032 > 0x0A010006 TA5 0.000000 0.000 > > --still made at UI1..what is it? and where TA2 AND TA4 have gone????? > although i tried to solve this problem by defining array of task name and id of size 7 instead of five.I know it is ridiculus to do this...it should have no effect on this problem.any solution? > > > nasim > _______________________________________________ > rtems-users mailing list > rtems-users at rtems.org > http://www.rtems.org/mailman/listinfo/rtems-users > _______________________________________________ > rtems-users mailing list > rtems-users at rtems.org > http://www.rtems.org/mailman/listinfo/rtems-users > From David.Brooke at 3t-ag.com Mon Jul 20 16:33:47 2009 From: David.Brooke at 3t-ag.com (David Brooke) Date: Mon, 20 Jul 2009 17:33:47 +0100 Subject: gen83xx ethernet transmit problem In-Reply-To: <4A2E218D.7050808@embedded-brains.de> References: <20090605103120.GA12444@dbrooke.littleport> <4A2E218D.7050808@embedded-brains.de> Message-ID: <20090720163347.GC2572@dbrooke.littleport> On Tue, Jun 09, 2009 at 10:47:09AM +0200, Thomas D?rfler wrote: [snip] > > Right, this wokrs fine on MPC8349 and MPC8313. We just got U-Boot running on our real hardware, which differs only slightly from the board I was working with, and the Ethernet seems to be working fine. So it looks like the problem was something specific to my initial development platform. Regards, David From Thomas.Doerfler at embedded-brains.de Tue Jul 21 19:05:34 2009 From: Thomas.Doerfler at embedded-brains.de (=?ISO-8859-15?Q?Thomas_D=F6rfler?=) Date: Tue, 21 Jul 2009 21:05:34 +0200 Subject: Ann: RTEMS open class in Munich/Germany Message-ID: <4A66117E.2000706@embedded-brains.de> Hello, due to several requests, we are currently planning another open RTEMS class in Munich/Germany to start on October 6-9 2009. Maybe you or some of your colleagues like to join in? See our updated website http://www.embedded-brains.de/index.php?id=rtems_class&L=1 for more details. The closing date for registrations is September 18 2009. Please note that the number of seats is limited and can only be booked on a first come, first serve base. Please use the website form or send us an email if you and/or your colleagues are interested to attend, so we can reserve seats for you. wkr, Thomas Doerfler. -- -------------------------------------------- embedded brains GmbH Thomas Doerfler Obere Lagerstr. 30 D-82178 Puchheim Germany Tel. : +49-89-18 90 80 79-2 Fax : +49-89-18 90 80 79-9 email: Thomas.Doerfler at embedded-brains.de PGP public key available on request From gxfarmer at gmail.com Wed Jul 22 03:24:29 2009 From: gxfarmer at gmail.com (=?GB2312?B?1tC5+sWpw/E=?=) Date: Wed, 22 Jul 2009 11:24:29 +0800 Subject: about RTEMS Remote Debugger Server Message-ID: <545c8850907212024k744d892dp9f5472737ad5ba35@mail.gmail.com> hi, anyone could give me some tips about the RTEMS Remote Debugger Server on RTEMS 4.92? how to implement the RTEMS Remote Debugger Server? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jszhang3 at gmail.com Thu Jul 23 18:33:46 2009 From: jszhang3 at gmail.com (JiSheng Zhang) Date: Fri, 24 Jul 2009 02:33:46 +0800 Subject: [GSOC]Dynamic object file loading:basic dlsym and dlclose Message-ID: <2df346410907231133u14b21a4cwb6b08ae20c549bc7@mail.gmail.com> Hi all, I have completed the baisc implementation of dlsym and dlclose. Now the four dlXXX functions are all basically completed, although only on x86 now. I have git push the code on github, so for test just do the following: git clone git://github.com/absabs/objdl.git cd objdl make ./demo -l t.o -s get enjoy;) Note:there's a mem leak in dlclose, because the memory of global symbol name allocated by strdup is not freed. But I have to go to bed, this will be fixed tomorrow Thanks, JiSheng From joel.sherrill at OARcorp.com Fri Jul 24 13:38:53 2009 From: joel.sherrill at OARcorp.com (Joel Sherrill) Date: Fri, 24 Jul 2009 08:38:53 -0500 Subject: ITRON API Deprecated for 4.10 Message-ID: <4A69B96D.4060900@oarcorp.com> Hi, The Steering Committee has decided to deprecate the ITRON 3.0 API implementation in RTEMS in 4.10 and plans to remove it in 4.11. It is now disabled by default on the CVS head. Here are the pertinent facts that lead to this decision. + It was implemented as class projects by a graduate real-time class Joel taught in 1999. + It is incomplete. + It is based on ITRON 3.0. Current revision is at least 4.0. + SC didn't recall a PR or question on it. + .h files define common some names so when it is enabled, it can cause surprising conflicts. So it is incomplete, out of date, and may have no users. The primary positive point we saw is that it is another example of using the SuperCore to implement an API. If someone steps forward to update the implementation to the current revision or sponsor that work, then it will be kept alive. Being out of date and incomplete are big negatives. Not having confirmed users is not as much an issue because there are lots of very quiet RTEMS users so we might never know. Even with all that going against it, RTEMS is by nature a conservative project. So it will be there for another release cycle. If you want the ITRON implementation to live on, please contribute. Updating it to the current specification could be a good senior or class project. -- 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 From fgnicodemos at terra.com.br Fri Jul 24 14:10:34 2009 From: fgnicodemos at terra.com.br (Fernando Nicodemos) Date: Fri, 24 Jul 2009 11:10:34 -0300 Subject: Examples Message-ID: Hi, My name is Fernando Nicodemos and I am pretty new in this RTEMS List. I have been working with RTEMS since 2007, but I start to work heavly this year, 2009. I have two simple questions for now. 1- Does anybody have Webserver, HTTP, FTP and implementations using PPP (from Free BSD TCP/IP stack) example sources using RTEMS or anybody know where I can find them, if available at the source tree? 2- How far are this implementations in RTEMS? Are they fully functional? Does anybody tested them? Thanks a lot, Fernando Nicodemos From mprtems at bellsouth.net Fri Jul 24 14:24:02 2009 From: mprtems at bellsouth.net (Mike Panetta) Date: Fri, 24 Jul 2009 07:24:02 -0700 (PDT) Subject: Cortex-M3 support? Message-ID: <830532.41038.qm@web180404.mail.gq1.yahoo.com> I have been looking at CVS head and noticed that there is no cortex-m3 support in RTEMS. Has anyone started work on this? If yes, is the code available somewhere? If no, where would one start a port for this ARM core? It does not seem to quite fit in with the current ARM code in that exception handling is somewhat different... Would one create a cortex-m3 directory under libcpu/arm,libbsp/arm, etc, or just put the code directly in the respective arm dir for this port? I don't think adding CPU support for this core would be such a big deal, its just figuring out where to put it... BSP support on the other hand may be another matter... Any help, suggestions on this would be greatly appreciated! Thanks, Mike From joel.sherrill at OARcorp.com Fri Jul 24 14:31:05 2009 From: joel.sherrill at OARcorp.com (Joel Sherrill) Date: Fri, 24 Jul 2009 09:31:05 -0500 Subject: Examples In-Reply-To: References: Message-ID: <4A69C5A9.10407@oarcorp.com> Fernando Nicodemos wrote: > Hi, > > My name is Fernando Nicodemos and I am pretty new in this RTEMS List. > I have been working with RTEMS since 2007, but I start to work heavly this > year, 2009. > > Hi Fernando. :) > I have two simple questions for now. > > 1- Does anybody have Webserver, HTTP, FTP and implementations using PPP > (from Free BSD TCP/IP stack) example sources using RTEMS or anybody know > where I can find them, if available at the source tree? > > check out network-demos from CVS. This includes ftpd, httpd, and telnetd usage examples. > 2- How far are this implementations in RTEMS? Are they fully functional? > Does anybody tested them? > > There are two httpd implementations in cpukit. All of the various network servers are functional but "fully" is a vague term. They provide basic functionality one would expect from an embedded device. > Thanks a lot, > > Fernando Nicodemos > > > > _______________________________________________ > rtems-users mailing list > rtems-users at rtems.org > http://www.rtems.org/mailman/listinfo/rtems-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 From joel.sherrill at OARcorp.com Fri Jul 24 14:41:21 2009 From: joel.sherrill at OARcorp.com (Joel Sherrill) Date: Fri, 24 Jul 2009 09:41:21 -0500 Subject: Cortex-M3 support? In-Reply-To: <830532.41038.qm@web180404.mail.gq1.yahoo.com> References: <830532.41038.qm@web180404.mail.gq1.yahoo.com> Message-ID: <4A69C811.3000201@oarcorp.com> Mike Panetta wrote: > I have been looking at CVS head and noticed that there is no cortex-m3 support in RTEMS. Has anyone started work on this? If yes, is the code available somewhere? If no, where would one start a port for this ARM core? It does not seem to quite fit in with the current ARM code in that exception handling is somewhat different... Would one create a cortex-m3 directory under libcpu/arm,libbsp/arm, etc, or just put the code directly in the respective arm dir for this port? I don't think adding CPU support for this core would be such a big deal, its just figuring out where to put it... BSP support on the other hand may be another matter... > > Sebastian Huber has been reworking the ARM exception code so make sure you are on today's head and talking to him. In general terms, you want to start with the CPU core and ignore the peripherals. + make sure the multilib variant is in the tools + make sure the multilib variant is properly supported by cpukit/score/arm and the libnetworking cksum routines. If you have a non-RTEMS "no OS" arm-elf toolset which can produce working executables for you, then you are almost ready for a very minimal BSP. + Use the linker script as base with additions for workspace related symbols + Use the crt0.S from it (change call main -> boot_card) + implement a polled console using the libgloss support. + Use the "dummy idle task clock driver" At the moment, I think the avr, m32c, adn m32r BSPs are the closest examples to this minimal point. That gives you enough to run tests with no interrupts. Sebastian will need to step in for exception processing. > Any help, suggestions on this would be greatly appreciated! > > Thanks, > Mike > > _______________________________________________ > rtems-users mailing list > rtems-users at rtems.org > http://www.rtems.org/mailman/listinfo/rtems-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 From fgnicodemos at terra.com.br Fri Jul 24 16:28:48 2009 From: fgnicodemos at terra.com.br (Fernando Nicodemos) Date: Fri, 24 Jul 2009 13:28:48 -0300 Subject: Examples In-Reply-To: <5cbbb9e90907240720mf7bcb58t7d9fc9554c157b72@mail.gmail.com> Message-ID: Hi Andy, Thanks for the answer. So the implementation of Free BSD does not support PPP for rtems 4.8 and 4.9? Fernando On 7/24/09 11:20 AM, "Andrew Sporner" wrote: > Hi > > I am about 30% through on the porting of TCP/IP (7.1 FreeBSD) to Rtems 4.10 > and > this will include PPP. My end goal of August has slipped a little > bit, but thats not > surprising considering I am working already at 140% :-) > > Andy > > Esta mensagem foi verificada pelo E-mail Protegido Terra. > Atualizado em 24/07/2009 > From asporner at googlemail.com Fri Jul 24 18:16:49 2009 From: asporner at googlemail.com (Andrew Sporner) Date: Fri, 24 Jul 2009 20:16:49 +0200 Subject: Examples In-Reply-To: References: <5cbbb9e90907240720mf7bcb58t7d9fc9554c157b72@mail.gmail.com> Message-ID: <5cbbb9e90907241116n4d191fc9j48cb733b044b9dc2@mail.gmail.com> Hi Fernando, I have not tried to use it but it looks like its all there. I am working from an open project on the project list. I have been doing TCP/IP related things for over ten years now and it seemed like a good fit to my background. Now finally I am getting more time to focus on it more. Andy On Fri, Jul 24, 2009 at 6:28 PM, Fernando Nicodemos wrote: > Hi Andy, > > Thanks for the answer. > So the implementation of Free BSD does not support PPP for rtems 4.8 and > 4.9? > > Fernando > > > On 7/24/09 11:20 AM, "Andrew Sporner" wrote: > >> Hi >> >> I am about 30% through on the porting of TCP/IP (7.1 FreeBSD) to Rtems 4.10 >> and >> this will include PPP. ?My end goal of August has slipped a little >> bit, but thats not >> surprising considering I am working already at 140% :-) >> >> Andy >> >> Esta mensagem foi verificada pelo E-mail Protegido Terra. >> Atualizado em 24/07/2009 >> > > > From hiyangxi at gmail.com Sun Jul 26 13:13:26 2009 From: hiyangxi at gmail.com (xi yang) Date: Sun, 26 Jul 2009 23:13:26 +1000 Subject: [GSOC2009] Frame buffer support for PXA255 target of Skyeye simulator Message-ID: <552cfe40907260613x5b0b7884m685762703c0470e8@mail.gmail.com> Hi Joel, please adding "fb.h" and "skyeye_fb.h" to "libbsp/arm/gumstix/fb/fb.h" "libbsp/arm/gumstix/fb/skyeye_fb.h". Enable_lcd.patch is for gcc-testing frambuffer.patch is for RTEMS * Enable LCD option for gumstix of gcc-tesging Index: sim-scripts/gumstix.in =================================================================== RCS file: /usr1/CVS/gcc-testing/sim-scripts/gumstix.in,v retrieving revision 1.4 diff -u -r1.4 gumstix.in --- sim-scripts/gumstix.in 10 Jul 2009 17:07:22 -0000 1.4 +++ sim-scripts/gumstix.in 26 Jul 2009 13:07:18 -0000 @@ -43,6 +43,7 @@ mem_bank: map=I, type=RW, addr=0xB0000000, size=0x100000 mem_bank: map=I, type=RW, addr=0x40000000, size=0x4C000000 shutdown_device: addr=0xb0000000, max_ins=${limit}0000000 +lcd:state=on,type=pxa,mod=gtk EOF if [ ${coverage} = yes ] ; then echo "code_coverage: state=on, filename=${2}.cov, start=0xA0000000, end=0xA4000000" *Frame buffer support for pxa255 target of SKYEYE simulator Index: c/src/lib/libbsp/arm/gumstix/ChangeLog =================================================================== RCS file: /usr1/CVS/rtems/c/src/lib/libbsp/arm/gumstix/ChangeLog,v retrieving revision 1.7 diff -u -r1.7 ChangeLog --- c/src/lib/libbsp/arm/gumstix/ChangeLog 16 Jul 2009 23:18:12 -0000 1.7 +++ c/src/lib/libbsp/arm/gumstix/ChangeLog 26 Jul 2009 13:04:27 -0000 @@ -1,3 +1,9 @@ +2009-07-26 Xi Yang + * Makefile.am: Add fb/fb.c + * preinstall.am: Install skyeye_fb.h + * fb/fb.c, fb/skyeye_fb.h: Framebuffer support for skyeye simulator + * startup/memmap.c: Change the size of Map I/O to 1216M + 2009-07-16 Joel Sherrill * configure.ac: Rename BSP_BOOTCARD_OPTIONS to Index: c/src/lib/libbsp/arm/gumstix/Makefile.am =================================================================== RCS file: /usr1/CVS/rtems/c/src/lib/libbsp/arm/gumstix/Makefile.am,v retrieving revision 1.4 diff -u -r1.4 Makefile.am --- c/src/lib/libbsp/arm/gumstix/Makefile.am 10 Jul 2009 17:06:37 -0000 1.4 +++ c/src/lib/libbsp/arm/gumstix/Makefile.am 26 Jul 2009 13:04:27 -0000 @@ -40,6 +40,8 @@ libbsp_a_SOURCES += console/uarts.c ../../shared/console.c #abort libbsp_a_SOURCES += ../shared/abort/abort.c +#framebuffer +libbsp_a_SOURCES += fb/fb.c libbsp_a_LIBADD = ../../../libcpu/@RTEMS_CPU@/shared/arm920.rel \ ../../../libcpu/@RTEMS_CPU@/@RTEMS_CPU_MODEL@/clock.rel \ Index: c/src/lib/libbsp/arm/gumstix/preinstall.am =================================================================== RCS file: /usr1/CVS/rtems/c/src/lib/libbsp/arm/gumstix/preinstall.am,v retrieving revision 1.1 diff -u -r1.1 preinstall.am --- c/src/lib/libbsp/arm/gumstix/preinstall.am 4 Jun 2009 16:23:11 -0000 1.1 +++ c/src/lib/libbsp/arm/gumstix/preinstall.am 26 Jul 2009 13:04:27 -0000 @@ -41,6 +41,10 @@ $(INSTALL_DATA) $< $(PROJECT_INCLUDE)/bsp.h PREINSTALL_FILES += $(PROJECT_INCLUDE)/bsp.h +$(PROJECT_INCLUDE)/rtems/skyeye_fb.h: fb/skyeye_fb.h $(PROJECT_INCLUDE)/rtems/$(dirstamp) + $(INSTALL_DATA) $< $(PROJECT_INCLUDE)/rtems/skyeye_fb.h +PREINSTALL_FILES += $(PROJECT_INCLUDE)/rtems/skyeye_fb.h + $(PROJECT_INCLUDE)/tm27.h: include/tm27.h $(PROJECT_INCLUDE)/$(dirstamp) $(INSTALL_DATA) $< $(PROJECT_INCLUDE)/tm27.h PREINSTALL_FILES += $(PROJECT_INCLUDE)/tm27.h Index: c/src/lib/libbsp/arm/gumstix/startup/memmap.c =================================================================== RCS file: /usr1/CVS/rtems/c/src/lib/libbsp/arm/gumstix/startup/memmap.c,v retrieving revision 1.1 diff -u -r1.1 memmap.c --- c/src/lib/libbsp/arm/gumstix/startup/memmap.c 4 Jun 2009 16:23:11 -0000 1.1 +++ c/src/lib/libbsp/arm/gumstix/startup/memmap.c 26 Jul 2009 13:04:27 -0000 @@ -12,7 +12,7 @@ mmu_sect_map_t mem_map[] = { /* */ - {0x40000000, 0x40000000, 20, MMU_CACHE_NONE}, /*Map I/O*/ + {0x40000000, 0x40000000, 1216, MMU_CACHE_NONE}, /*Map I/O*/ {0xA0000000, 0x00000000, 1, MMU_CACHE_NONE}, /*sram*/ {0xA0000000, 0xA0000000, 64, MMU_CACHE_WBACK}, /* SDRAM */ {0x00000000, 0x00000000, 0, 0} /* The end */ Index: c/src/lib/libcpu/arm/ChangeLog =================================================================== RCS file: /usr1/CVS/rtems/c/src/lib/libcpu/arm/ChangeLog,v retrieving revision 1.61 diff -u -r1.61 ChangeLog --- c/src/lib/libcpu/arm/ChangeLog 17 Jul 2009 13:52:16 -0000 1.61 +++ c/src/lib/libcpu/arm/ChangeLog 26 Jul 2009 13:04:28 -0000 @@ -1,3 +1,6 @@ +2009-07-26 Xi Yang + * pxa255/include/pxa255.h: Add LCD related registers + 2009-07-15 Sebastian Huber * Makefile.am: Removed references to deleted file Index: c/src/lib/libcpu/arm/pxa255/include/pxa255.h =================================================================== RCS file: /usr1/CVS/rtems/c/src/lib/libcpu/arm/pxa255/include/pxa255.h,v retrieving revision 1.3 diff -u -r1.3 pxa255.h --- c/src/lib/libcpu/arm/pxa255/include/pxa255.h 10 Jul 2009 15:34:12 -0000 1.3 +++ c/src/lib/libcpu/arm/pxa255/include/pxa255.h 26 Jul 2009 13:04:28 -0000 @@ -106,4 +106,24 @@ #define PMC_PMNC_CCD (0x01 << 3) #define PMC_PMNC_PCD (0x01 << 4) +/*LCD*/ +#define LCCR0 (*(volatile word_t *)(0x44000000)) +#define LCCR1 (*(volatile word_t *)(0x44000004)) +#define LCCR2 (*(volatile word_t *)(0x44000008)) +#define LCCR3 (*(volatile word_t *)(0x4400000C)) + +#define FDADR0 (*(volatile word_t *)(0x44000200)) +#define FSADR0 (*(volatile word_t *)(0x44000204)) +#define FIDR0 (*(volatile word_t *)(0x44000208)) +#define LDCMD0 (*(volatile word_t *)(0x4400020C)) + +#define FDADR1 (*(volatile word_t *)(0x44000210)) +#define FSADR1 (*(volatile word_t *)(0x44000214)) +#define FIDR1 (*(volatile word_t *)(0x44000218)) +#define LDCMD1 (*(volatile word_t *)(0x4400021C)) + +#define LCCR0_ENB 0x00000001 +#define LCCR1_PPL 0x000003FF +#define LCCR2_LPP 0x000003FF +#define LCCR3_BPP 0x07000000 #endif -------------- next part -------------- A non-text attachment was scrubbed... Name: frambuffer.patch Type: text/x-patch Size: 4986 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: enable_lcd.patch Type: text/x-patch Size: 667 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: fb.c Type: text/x-csrc Size: 4408 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: skyeye_fb.h Type: text/x-chdr Size: 1003 bytes Desc: not available URL: From siddons at bnl.gov Sun Jul 26 14:45:00 2009 From: siddons at bnl.gov (D. Peter Siddons) Date: Sun, 26 Jul 2009 10:45:00 -0400 Subject: problem with iostream In-Reply-To: <4A4F87C3.2020903@oarcorp.com> References: <4A4F7C71.70003@bnl.gov> <4A4F87C3.2020903@oarcorp.com> Message-ID: <4A6C6BEC.2050707@bnl.gov> Hi Joel, My linkcmds file is closely similar to that in the uC5282 bsp. Although there are some differences in detail, I think all of the same sections are defined. I confess that linkcmds I find pretty opaque. I have attached it. Do you see any obvious omissions? Pete. Joel Sherrill wrote: > D. Peter Siddons wrote: >> I am upgrading my bsp to rtems-4.9 from 4.7. I took the tool rpms. I >> used alien to make debs and installed them on my Ubuntu Jaunty. I have >> got to the point where everything seems to build OK until it tries to >> link the iostream example. I get the following: >> >> 272/testsuites/samples/iostream' >> m68k-rtems4.9-g++ -B../../../../../uC5272/lib/ -specs bsp_specs >> -qrtems -m5200 -O4 -fomit-frame-pointer -m5200 -o >> cxx_iostream.exe init.o >> /opt/rtems-4.9/lib/gcc/m68k-rtems4.9/4.3.2/../../../../m68k-rtems4.9/bin/ld: >> error: no memory region specified for loadable section >> `.text._ZSt18__throw_bad_typeidv' >> collect2: ld returned 1 exit status >> >> Any suggestions? >> > > error: no memory region specified for loadable section > Compare the linker scripts in /opt with the one for your BSP. > Apparently there is a section not in your linkcmds. >> Pete. >> >> >> > > -- D. Peter Siddons Detector Development Group Leader National Synchrotron Light Source Brookhaven National Laboratory Upton, NY 11973 email: siddons at bnl.gov Phone: (631) 344-2738 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: linkcmds URL: From sebastian.huber at embedded-brains.de Sun Jul 26 15:08:21 2009 From: sebastian.huber at embedded-brains.de (Sebastian Huber) Date: Sun, 26 Jul 2009 17:08:21 +0200 Subject: Cortex-M3 support? In-Reply-To: <4A69C811.3000201@oarcorp.com> References: <830532.41038.qm@web180404.mail.gq1.yahoo.com> <4A69C811.3000201@oarcorp.com> Message-ID: <4A6C7165.5020302@embedded-brains.de> Hi, yes, the exception processing is completely different compared to the ARMv4 or ARMv5 architecture. The current ARM port is located mainly at 'cpukit/score/cpu/arm'. I guess that all assembler files under this directory are worthless for the Cortex. I would add the Cortex specific files to this directory and prefix them with cortex_*. In the general CPU files cpu.c, cpu_asm.S, cpu.h and cpu_asm.h we can use conditional compilation. I don't know if it is possible to write the NVIC support in a BSP independent fashion. CU Joel Sherrill wrote: > Mike Panetta wrote: > >> I have been looking at CVS head and noticed that there is no cortex-m3 support in RTEMS. Has anyone started work on this? If yes, is the code available somewhere? If no, where would one start a port for this ARM core? It does not seem to quite fit in with the current ARM code in that exception handling is somewhat different... Would one create a cortex-m3 directory under libcpu/arm,libbsp/arm, etc, or just put the code directly in the respective arm dir for this port? I don't think adding CPU support for this core would be such a big deal, its just figuring out where to put it... BSP support on the other hand may be another matter... >> >> >> > Sebastian Huber has been reworking the ARM exception code so > make sure you are on today's head and talking to him. > > In general terms, you want to start with the CPU core and > ignore the peripherals. > > + make sure the multilib variant is in the tools > + make sure the multilib variant is properly supported > by cpukit/score/arm and the libnetworking cksum routines. > > If you have a non-RTEMS "no OS" arm-elf toolset which can > produce working executables for you, then you are almost > ready for a very minimal BSP. > > + Use the linker script as base with additions for > workspace related symbols > + Use the crt0.S from it (change call main -> boot_card) > + implement a polled console using the libgloss support. > + Use the "dummy idle task clock driver" > > At the moment, I think the avr, m32c, adn m32r BSPs are the closest > examples to this minimal point. > > That gives you enough to run tests with no interrupts. > > Sebastian will need to step in for exception processing. > > >> Any help, suggestions on this would be greatly appreciated! >> >> Thanks, >> Mike >> >> _______________________________________________ >> rtems-users mailing list >> rtems-users at rtems.org >> http://www.rtems.org/mailman/listinfo/rtems-users >> >> > > > -- 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 at embedded-brains.de PGP : Public key available on request Diese Nachricht ist keine gesch?ftliche Mitteilung im Sinne des EHUG. From siddons at bnl.gov Sun Jul 26 16:10:45 2009 From: siddons at bnl.gov (D. Peter Siddons) Date: Sun, 26 Jul 2009 12:10:45 -0400 Subject: problem with iostream In-Reply-To: <4A6C6BEC.2050707@bnl.gov> References: <4A4F7C71.70003@bnl.gov> <4A4F87C3.2020903@oarcorp.com> <4A6C6BEC.2050707@bnl.gov> Message-ID: <4A6C8005.5030005@bnl.gov> OK, as usual, as soon as I make the post, I find the problem. THere were a bunch of missing trailing *'s in the linkcmds. Sorry to bother you. Pete. D. Peter Siddons wrote: > Hi Joel, > My linkcmds file is closely similar to that in the uC5282 bsp. > Although there are some differences in detail, I think all of the same > sections are defined. I confess that linkcmds I find pretty opaque. I > have attached it. Do you see any obvious omissions? > Pete. > > Joel Sherrill wrote: >> D. Peter Siddons wrote: >>> I am upgrading my bsp to rtems-4.9 from 4.7. I took the tool rpms. I >>> used alien to make debs and installed them on my Ubuntu Jaunty. I >>> have got to the point where everything seems to build OK until it >>> tries to link the iostream example. I get the following: >>> >>> 272/testsuites/samples/iostream' >>> m68k-rtems4.9-g++ -B../../../../../uC5272/lib/ -specs bsp_specs >>> -qrtems -m5200 -O4 -fomit-frame-pointer -m5200 -o >>> cxx_iostream.exe init.o >>> /opt/rtems-4.9/lib/gcc/m68k-rtems4.9/4.3.2/../../../../m68k-rtems4.9/bin/ld: >>> error: no memory region specified for loadable section >>> `.text._ZSt18__throw_bad_typeidv' >>> collect2: ld returned 1 exit status >>> >>> Any suggestions? >>> >> >> error: no memory region specified for loadable section >> Compare the linker scripts in /opt with the one for your BSP. >> Apparently there is a section not in your linkcmds. >>> Pete. >>> >>> >>> >> >> > > > ------------------------------------------------------------------------ > > _______________________________________________ > rtems-users mailing list > rtems-users at rtems.org > http://www.rtems.org/mailman/listinfo/rtems-users -- D. Peter Siddons Detector Development Group Leader National Synchrotron Light Source Brookhaven National Laboratory Upton, NY 11973 email: siddons at bnl.gov Phone: (631) 344-2738 From joel.sherrill at OARcorp.com Mon Jul 27 14:33:16 2009 From: joel.sherrill at OARcorp.com (Joel Sherrill) Date: Mon, 27 Jul 2009 09:33:16 -0500 Subject: [GSOC2009] Frame buffer support for PXA255 target of Skyeye simulator In-Reply-To: <552cfe40907260613x5b0b7884m685762703c0470e8@mail.gmail.com> References: <552cfe40907260613x5b0b7884m685762703c0470e8@mail.gmail.com> Message-ID: <4A6DBAAC.7080900@oarcorp.com> Hi, With Roxana's work on a framebuffer driver interface this raises questions for me. This is the second FB driver in the tree so let's do it right. + This is now going to be a standard type of driver like an RTC, Clock or Console. We should have a CONFIGURE_APPLICATION_NEEDS_FRAME_BUFFER_DRIVER in confdefs.h which means we need a standard framebuffer.h which defines the standard interface to this class of driver for configuration purposes. skyeye_fb.h is actually close to this .h file. + I have a feeling the LCD support in the BSP needs to be conditional on "ENABLE_LCD" and "on skyeye" for the skyeye specific variant. Unless the Skyeye and real hardware match for the LCD output. Then ENABLE_LCD is sufficient. You don't want the graphics memory area mapped unless the hardware is really there. + Does the testing script support enabling the LCD all the time imply that a graphics window always pops up? Most of the time we test automated with no graphics and in batch mode, so this would be bad. I think there needs to be an option to gdb-sim-run.in like -G for graphics enabled. + The csb337 has an ENABLE_LCD option which I think now might need to be ENABLE_GRAPHICS_ADAPTER or something more generic like that. Especially since we should use the same configure variable name across BSPs. Just trying to come up with a standard cross-BSP approach to configuring and enabling the support. Just to be clear, there is nothing really wrong with this patch technically. I am just trying to think very very broad and long term. We want this all to go in right the first time. :) --joel xi yang wrote: > Hi Joel, please adding "fb.h" and "skyeye_fb.h" to > "libbsp/arm/gumstix/fb/fb.h" "libbsp/arm/gumstix/fb/skyeye_fb.h". > Enable_lcd.patch is for gcc-testing > frambuffer.patch is for RTEMS > > * Enable LCD option for gumstix of gcc-tesging > > Index: sim-scripts/gumstix.in > =================================================================== > RCS file: /usr1/CVS/gcc-testing/sim-scripts/gumstix.in,v > retrieving revision 1.4 > diff -u -r1.4 gumstix.in > --- sim-scripts/gumstix.in 10 Jul 2009 17:07:22 -0000 1.4 > +++ sim-scripts/gumstix.in 26 Jul 2009 13:07:18 -0000 > @@ -43,6 +43,7 @@ > mem_bank: map=I, type=RW, addr=0xB0000000, size=0x100000 > mem_bank: map=I, type=RW, addr=0x40000000, size=0x4C000000 > shutdown_device: addr=0xb0000000, max_ins=${limit}0000000 > +lcd:state=on,type=pxa,mod=gtk > EOF > if [ ${coverage} = yes ] ; then > echo "code_coverage: state=on, filename=${2}.cov, start=0xA0000000, > end=0xA4000000" > > > > *Frame buffer support for pxa255 target of SKYEYE simulator > > Index: c/src/lib/libbsp/arm/gumstix/ChangeLog > =================================================================== > RCS file: /usr1/CVS/rtems/c/src/lib/libbsp/arm/gumstix/ChangeLog,v > retrieving revision 1.7 > diff -u -r1.7 ChangeLog > --- c/src/lib/libbsp/arm/gumstix/ChangeLog 16 Jul 2009 23:18:12 -0000 1.7 > +++ c/src/lib/libbsp/arm/gumstix/ChangeLog 26 Jul 2009 13:04:27 -0000 > @@ -1,3 +1,9 @@ > +2009-07-26 Xi Yang > + * Makefile.am: Add fb/fb.c > + * preinstall.am: Install skyeye_fb.h > + * fb/fb.c, fb/skyeye_fb.h: Framebuffer support for skyeye simulator > + * startup/memmap.c: Change the size of Map I/O to 1216M > + > 2009-07-16 Joel Sherrill > > * configure.ac: Rename BSP_BOOTCARD_OPTIONS to > Index: c/src/lib/libbsp/arm/gumstix/Makefile.am > =================================================================== > RCS file: /usr1/CVS/rtems/c/src/lib/libbsp/arm/gumstix/Makefile.am,v > retrieving revision 1.4 > diff -u -r1.4 Makefile.am > --- c/src/lib/libbsp/arm/gumstix/Makefile.am 10 Jul 2009 17:06:37 -0000 1.4 > +++ c/src/lib/libbsp/arm/gumstix/Makefile.am 26 Jul 2009 13:04:27 -0000 > @@ -40,6 +40,8 @@ > libbsp_a_SOURCES += console/uarts.c ../../shared/console.c > #abort > libbsp_a_SOURCES += ../shared/abort/abort.c > +#framebuffer > +libbsp_a_SOURCES += fb/fb.c > > libbsp_a_LIBADD = ../../../libcpu/@RTEMS_CPU@/shared/arm920.rel \ > ../../../libcpu/@RTEMS_CPU@/@RTEMS_CPU_MODEL@/clock.rel \ > Index: c/src/lib/libbsp/arm/gumstix/preinstall.am > =================================================================== > RCS file: /usr1/CVS/rtems/c/src/lib/libbsp/arm/gumstix/preinstall.am,v > retrieving revision 1.1 > diff -u -r1.1 preinstall.am > --- c/src/lib/libbsp/arm/gumstix/preinstall.am 4 Jun 2009 16:23:11 -0000 1.1 > +++ c/src/lib/libbsp/arm/gumstix/preinstall.am 26 Jul 2009 13:04:27 -0000 > @@ -41,6 +41,10 @@ > $(INSTALL_DATA) $< $(PROJECT_INCLUDE)/bsp.h > PREINSTALL_FILES += $(PROJECT_INCLUDE)/bsp.h > > +$(PROJECT_INCLUDE)/rtems/skyeye_fb.h: fb/skyeye_fb.h > $(PROJECT_INCLUDE)/rtems/$(dirstamp) > + $(INSTALL_DATA) $< $(PROJECT_INCLUDE)/rtems/skyeye_fb.h > +PREINSTALL_FILES += $(PROJECT_INCLUDE)/rtems/skyeye_fb.h > + > $(PROJECT_INCLUDE)/tm27.h: include/tm27.h $(PROJECT_INCLUDE)/$(dirstamp) > $(INSTALL_DATA) $< $(PROJECT_INCLUDE)/tm27.h > PREINSTALL_FILES += $(PROJECT_INCLUDE)/tm27.h > Index: c/src/lib/libbsp/arm/gumstix/startup/memmap.c > =================================================================== > RCS file: /usr1/CVS/rtems/c/src/lib/libbsp/arm/gumstix/startup/memmap.c,v > retrieving revision 1.1 > diff -u -r1.1 memmap.c > --- c/src/lib/libbsp/arm/gumstix/startup/memmap.c 4 Jun 2009 16:23:11 -0000 1.1 > +++ c/src/lib/libbsp/arm/gumstix/startup/memmap.c 26 Jul 2009 13:04:27 -0000 > @@ -12,7 +12,7 @@ > > mmu_sect_map_t mem_map[] = { > /* */ > - {0x40000000, 0x40000000, 20, MMU_CACHE_NONE}, /*Map I/O*/ > + {0x40000000, 0x40000000, 1216, MMU_CACHE_NONE}, /*Map I/O*/ > {0xA0000000, 0x00000000, 1, MMU_CACHE_NONE}, /*sram*/ > {0xA0000000, 0xA0000000, 64, MMU_CACHE_WBACK}, /* SDRAM */ > {0x00000000, 0x00000000, 0, 0} /* The end */ > Index: c/src/lib/libcpu/arm/ChangeLog > =================================================================== > RCS file: /usr1/CVS/rtems/c/src/lib/libcpu/arm/ChangeLog,v > retrieving revision 1.61 > diff -u -r1.61 ChangeLog > --- c/src/lib/libcpu/arm/ChangeLog 17 Jul 2009 13:52:16 -0000 1.61 > +++ c/src/lib/libcpu/arm/ChangeLog 26 Jul 2009 13:04:28 -0000 > @@ -1,3 +1,6 @@ > +2009-07-26 Xi Yang > + * pxa255/include/pxa255.h: Add LCD related registers > + > 2009-07-15 Sebastian Huber > > * Makefile.am: Removed references to deleted file > Index: c/src/lib/libcpu/arm/pxa255/include/pxa255.h > =================================================================== > RCS file: /usr1/CVS/rtems/c/src/lib/libcpu/arm/pxa255/include/pxa255.h,v > retrieving revision 1.3 > diff -u -r1.3 pxa255.h > --- c/src/lib/libcpu/arm/pxa255/include/pxa255.h 10 Jul 2009 15:34:12 -0000 1.3 > +++ c/src/lib/libcpu/arm/pxa255/include/pxa255.h 26 Jul 2009 13:04:28 -0000 > @@ -106,4 +106,24 @@ > #define PMC_PMNC_CCD (0x01 << 3) > #define PMC_PMNC_PCD (0x01 << 4) > > +/*LCD*/ > +#define LCCR0 (*(volatile word_t *)(0x44000000)) > +#define LCCR1 (*(volatile word_t *)(0x44000004)) > +#define LCCR2 (*(volatile word_t *)(0x44000008)) > +#define LCCR3 (*(volatile word_t *)(0x4400000C)) > + > +#define FDADR0 (*(volatile word_t *)(0x44000200)) > +#define FSADR0 (*(volatile word_t *)(0x44000204)) > +#define FIDR0 (*(volatile word_t *)(0x44000208)) > +#define LDCMD0 (*(volatile word_t *)(0x4400020C)) > + > +#define FDADR1 (*(volatile word_t *)(0x44000210)) > +#define FSADR1 (*(volatile word_t *)(0x44000214)) > +#define FIDR1 (*(volatile word_t *)(0x44000218)) > +#define LDCMD1 (*(volatile word_t *)(0x4400021C)) > + > +#define LCCR0_ENB 0x00000001 > +#define LCCR1_PPL 0x000003FF > +#define LCCR2_LPP 0x000003FF > +#define LCCR3_BPP 0x07000000 > #endif > -- 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 From hiyangxi at gmail.com Mon Jul 27 23:41:31 2009 From: hiyangxi at gmail.com (xi yang) Date: Tue, 28 Jul 2009 09:41:31 +1000 Subject: [GSOC2009] Frame buffer support for PXA255 target of Skyeye simulator In-Reply-To: <4A6DBAAC.7080900@oarcorp.com> References: <552cfe40907260613x5b0b7884m685762703c0470e8@mail.gmail.com> <4A6DBAAC.7080900@oarcorp.com> Message-ID: <552cfe40907271641w5c3c75aagfc9fab7d979962ce@mail.gmail.com> 2009/7/28 Joel Sherrill : > Hi, > > With Roxana's work on a framebuffer driver interface this raises > questions for me. This is the second FB driver in the tree so > let's do it right. > > + This is now going to be a standard type of driver like > an RTC, Clock or Console. We should have a > CONFIGURE_APPLICATION_NEEDS_FRAME_BUFFER_DRIVER > in confdefs.h which means we need a standard > framebuffer.h which defines the standard interface to > this class of driver for configuration purposes. > skyeye_fb.h is actually close to this .h file. Yeah. Otherwise, we have to add drivers to driver table manually. > > + I have a feeling the LCD support in the BSP needs to > be conditional on "ENABLE_LCD" and "on skyeye" for the > skyeye specific variant. Unless the Skyeye and real hardware > match for the LCD output. Then ENABLE_LCD is sufficient. > You don't want the graphics memory area mapped unless the > hardware is really there. > > + Does the testing script support enabling the LCD all the > time imply that a graphics window always pops up? > Most of the time we test automated with no graphics and > in batch mode, so this would be bad. I think there needs > to be an option to gdb-sim-run.in like -G for graphics enabled. Graphics windows pops up only when we write enable register for LCD. So, for other tests, it runs as without LCD. > > + The csb337 has an ENABLE_LCD option which I think now > might need to be ENABLE_GRAPHICS_ADAPTER or something > more generic like that. Especially since we should use the > same configure variable name across BSPs. > > Just trying to come up with a standard cross-BSP approach to > configuring and enabling the support. > > Just to be clear, there is nothing really wrong with this patch > technically. I am just trying to think very very broad and long > term. We want this all to go in right the first time. :) yeah, it is better have a cross-bsp framework. > > --joel > > xi yang wrote: >> Hi Joel, please adding "fb.h" and "skyeye_fb.h" to >> "libbsp/arm/gumstix/fb/fb.h" "libbsp/arm/gumstix/fb/skyeye_fb.h". >> Enable_lcd.patch is for gcc-testing >> frambuffer.patch is for RTEMS >> >> * Enable LCD option for gumstix of gcc-tesging >> >> Index: sim-scripts/gumstix.in >> =================================================================== >> RCS file: /usr1/CVS/gcc-testing/sim-scripts/gumstix.in,v >> retrieving revision 1.4 >> diff -u -r1.4 gumstix.in >> --- sim-scripts/gumstix.in ? ?10 Jul 2009 17:07:22 -0000 ? ? ?1.4 >> +++ sim-scripts/gumstix.in ? ?26 Jul 2009 13:07:18 -0000 >> @@ -43,6 +43,7 @@ >> ?mem_bank: map=I, type=RW, addr=0xB0000000, size=0x100000 >> ?mem_bank: map=I, type=RW, addr=0x40000000, size=0x4C000000 >> ?shutdown_device: addr=0xb0000000, max_ins=${limit}0000000 >> +lcd:state=on,type=pxa,mod=gtk >> ?EOF >> ?if [ ${coverage} = yes ] ; then >> ? ?echo "code_coverage: state=on, filename=${2}.cov, start=0xA0000000, >> end=0xA4000000" >> >> >> >> *Frame buffer support for pxa255 target of SKYEYE simulator >> >> Index: c/src/lib/libbsp/arm/gumstix/ChangeLog >> =================================================================== >> RCS file: /usr1/CVS/rtems/c/src/lib/libbsp/arm/gumstix/ChangeLog,v >> retrieving revision 1.7 >> diff -u -r1.7 ChangeLog >> --- c/src/lib/libbsp/arm/gumstix/ChangeLog ? ?16 Jul 2009 23:18:12 -0000 ? ? ?1.7 >> +++ c/src/lib/libbsp/arm/gumstix/ChangeLog ? ?26 Jul 2009 13:04:27 -0000 >> @@ -1,3 +1,9 @@ >> +2009-07-26 ? Xi Yang >> + ? ? * Makefile.am: Add fb/fb.c >> + ? ? * preinstall.am: Install skyeye_fb.h >> + ? ? * fb/fb.c, fb/skyeye_fb.h: Framebuffer support for skyeye simulator >> + ? ? * startup/memmap.c: Change the size of Map I/O to 1216M >> + >> ?2009-07-16 ? Joel Sherrill >> >> ? ? ? * configure.ac: Rename BSP_BOOTCARD_OPTIONS to >> Index: c/src/lib/libbsp/arm/gumstix/Makefile.am >> =================================================================== >> RCS file: /usr1/CVS/rtems/c/src/lib/libbsp/arm/gumstix/Makefile.am,v >> retrieving revision 1.4 >> diff -u -r1.4 Makefile.am >> --- c/src/lib/libbsp/arm/gumstix/Makefile.am ?10 Jul 2009 17:06:37 -0000 ? ? ?1.4 >> +++ c/src/lib/libbsp/arm/gumstix/Makefile.am ?26 Jul 2009 13:04:27 -0000 >> @@ -40,6 +40,8 @@ >> ?libbsp_a_SOURCES += console/uarts.c ../../shared/console.c >> ?#abort >> ?libbsp_a_SOURCES += ../shared/abort/abort.c >> +#framebuffer >> +libbsp_a_SOURCES += fb/fb.c >> >> ?libbsp_a_LIBADD = ../../../libcpu/@RTEMS_CPU@/shared/arm920.rel \ >> ? ? ?../../../libcpu/@RTEMS_CPU@/@RTEMS_CPU_MODEL@/clock.rel \ >> Index: c/src/lib/libbsp/arm/gumstix/preinstall.am >> =================================================================== >> RCS file: /usr1/CVS/rtems/c/src/lib/libbsp/arm/gumstix/preinstall.am,v >> retrieving revision 1.1 >> diff -u -r1.1 preinstall.am >> --- c/src/lib/libbsp/arm/gumstix/preinstall.am ? ? ? ?4 Jun 2009 16:23:11 -0000 ? ? ? 1.1 >> +++ c/src/lib/libbsp/arm/gumstix/preinstall.am ? ? ? ?26 Jul 2009 13:04:27 -0000 >> @@ -41,6 +41,10 @@ >> ? ? ? $(INSTALL_DATA) $< $(PROJECT_INCLUDE)/bsp.h >> ?PREINSTALL_FILES += $(PROJECT_INCLUDE)/bsp.h >> >> +$(PROJECT_INCLUDE)/rtems/skyeye_fb.h: fb/skyeye_fb.h >> $(PROJECT_INCLUDE)/rtems/$(dirstamp) >> + ? ? $(INSTALL_DATA) $< $(PROJECT_INCLUDE)/rtems/skyeye_fb.h >> +PREINSTALL_FILES += $(PROJECT_INCLUDE)/rtems/skyeye_fb.h >> + >> ?$(PROJECT_INCLUDE)/tm27.h: include/tm27.h $(PROJECT_INCLUDE)/$(dirstamp) >> ? ? ? $(INSTALL_DATA) $< $(PROJECT_INCLUDE)/tm27.h >> ?PREINSTALL_FILES += $(PROJECT_INCLUDE)/tm27.h >> Index: c/src/lib/libbsp/arm/gumstix/startup/memmap.c >> =================================================================== >> RCS file: /usr1/CVS/rtems/c/src/lib/libbsp/arm/gumstix/startup/memmap.c,v >> retrieving revision 1.1 >> diff -u -r1.1 memmap.c >> --- c/src/lib/libbsp/arm/gumstix/startup/memmap.c ? ? 4 Jun 2009 16:23:11 -0000 ? ? ? 1.1 >> +++ c/src/lib/libbsp/arm/gumstix/startup/memmap.c ? ? 26 Jul 2009 13:04:27 -0000 >> @@ -12,7 +12,7 @@ >> >> ?mmu_sect_map_t mem_map[] = { >> ?/* ? ? */ >> - ?{0x40000000, 0x40000000, ?20, ? MMU_CACHE_NONE}, ?/*Map I/O*/ >> + ?{0x40000000, 0x40000000, ?1216, ? MMU_CACHE_NONE}, ?/*Map I/O*/ >> ? ?{0xA0000000, 0x00000000, ? 1, ? MMU_CACHE_NONE}, ?/*sram*/ >> ? ?{0xA0000000, 0xA0000000, ?64, ? MMU_CACHE_WBACK}, /* SDRAM */ >> ? ?{0x00000000, 0x00000000, ? 0, ? 0} ? ? ? ? ? ? ? ?/* The end */ >> Index: c/src/lib/libcpu/arm/ChangeLog >> =================================================================== >> RCS file: /usr1/CVS/rtems/c/src/lib/libcpu/arm/ChangeLog,v >> retrieving revision 1.61 >> diff -u -r1.61 ChangeLog >> --- c/src/lib/libcpu/arm/ChangeLog ? ?17 Jul 2009 13:52:16 -0000 ? ? ?1.61 >> +++ c/src/lib/libcpu/arm/ChangeLog ? ?26 Jul 2009 13:04:28 -0000 >> @@ -1,3 +1,6 @@ >> +2009-07-26 ? Xi Yang >> + ? ? * pxa255/include/pxa255.h: Add LCD related registers >> + >> ?2009-07-15 ? Sebastian Huber >> >> ? ? ? * Makefile.am: Removed references to deleted file >> Index: c/src/lib/libcpu/arm/pxa255/include/pxa255.h >> =================================================================== >> RCS file: /usr1/CVS/rtems/c/src/lib/libcpu/arm/pxa255/include/pxa255.h,v >> retrieving revision 1.3 >> diff -u -r1.3 pxa255.h >> --- c/src/lib/libcpu/arm/pxa255/include/pxa255.h ? ? ?10 Jul 2009 15:34:12 -0000 ? ? ?1.3 >> +++ c/src/lib/libcpu/arm/pxa255/include/pxa255.h ? ? ?26 Jul 2009 13:04:28 -0000 >> @@ -106,4 +106,24 @@ >> ?#define PMC_PMNC_CCD (0x01 << 3) >> ?#define PMC_PMNC_PCD (0x01 << 4) >> >> +/*LCD*/ >> +#define LCCR0 ?(*(volatile word_t *)(0x44000000)) >> +#define LCCR1 ?(*(volatile word_t *)(0x44000004)) >> +#define LCCR2 ?(*(volatile word_t *)(0x44000008)) >> +#define LCCR3 ?(*(volatile word_t *)(0x4400000C)) >> + >> +#define FDADR0 ?(*(volatile word_t *)(0x44000200)) >> +#define FSADR0 ?(*(volatile word_t *)(0x44000204)) >> +#define FIDR0 ? (*(volatile word_t *)(0x44000208)) >> +#define LDCMD0 ?(*(volatile word_t *)(0x4400020C)) >> + >> +#define FDADR1 ?(*(volatile word_t *)(0x44000210)) >> +#define FSADR1 ?(*(volatile word_t *)(0x44000214)) >> +#define FIDR1 ? (*(volatile word_t *)(0x44000218)) >> +#define LDCMD1 ?(*(volatile word_t *)(0x4400021C)) >> + >> +#define LCCR0_ENB ? ? ? 0x00000001 >> +#define LCCR1_PPL ? ? ? 0x000003FF >> +#define LCCR2_LPP ? ? ? 0x000003FF >> +#define LCCR3_BPP ? ? ? 0x07000000 >> ?#endif >> > > > -- > 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 > > > From hiyangxi at gmail.com Tue Jul 28 01:19:52 2009 From: hiyangxi at gmail.com (xi yang) Date: Tue, 28 Jul 2009 11:19:52 +1000 Subject: shut down device support for edb7312 Message-ID: <552cfe40907271819k161f7de0iebac73b0ba6404f1@mail.gmail.com> Hi joel, shutdown_edb7312 is for gcc-testing. The other is for RTEMS. For gcc-testing: Index: sim-scripts/edb7312.in =================================================================== RCS file: /usr1/CVS/gcc-testing/sim-scripts/edb7312.in,v retrieving revision 1.5 diff -u -r1.5 edb7312.in --- sim-scripts/edb7312.in 20 Mar 2009 19:41:25 -0000 1.5 +++ sim-scripts/edb7312.in 28 Jul 2009 01:09:52 -0000 @@ -5,7 +5,7 @@ # ##INSERT SKYEYE SUPPORT HERE - +bspSimTrustedToExit="yes" runARGS() { echo "-c ${bspTreeFile} -e ${1}" @@ -29,6 +29,7 @@ mem_bank: map=I,type=RW, addr=0x80000000, size=0x00100000 mem_bank: map=M, type=RW, addr=0x00000000, size=0x1000000 uart: mod=pipe, desc_in=/dev/null, desc_out=/dev/stdout +shutdown_device: addr=0xb0000000, max_ins=${limit}0000000 EOF if [ ${coverage} = yes ] ; then This is for RTEMS: Index: c/src/lib/libbsp/arm/edb7312/ChangeLog =================================================================== RCS file: /usr1/CVS/rtems/c/src/lib/libbsp/arm/edb7312/ChangeLog,v retrieving revision 1.100 diff -u -r1.100 ChangeLog --- c/src/lib/libbsp/arm/edb7312/ChangeLog 17 Jul 2009 13:53:04 -0000 1.100 +++ c/src/lib/libbsp/arm/edb7312/ChangeLog 28 Jul 2009 01:13:23 -0000 @@ -1,3 +1,7 @@ +2009-07-28 Xi Yang + * configure.ac: undefine BSP_PREE_KEY_FOR_RESET + * startup/bspreset.c, include/ep7312.h: Support skyeye shutdown device + 2009-07-16 Joel Sherrill * configure.ac: Rename BSP_BOOTCARD_OPTIONS to Index: c/src/lib/libbsp/arm/edb7312/configure.ac =================================================================== RCS file: /usr1/CVS/rtems/c/src/lib/libbsp/arm/edb7312/configure.ac,v retrieving revision 1.18 diff -u -r1.18 configure.ac --- c/src/lib/libbsp/arm/edb7312/configure.ac 16 Jul 2009 23:18:09 -0000 1.18 +++ c/src/lib/libbsp/arm/edb7312/configure.ac 28 Jul 2009 01:13:23 -0000 @@ -26,7 +26,7 @@ the wall time required to execute the RTEMS test suites.]) RTEMS_BSP_BOOTCARD_OPTIONS -RTEMS_BSP_CLEANUP_OPTIONS(1, 1) +RTEMS_BSP_CLEANUP_OPTIONS(0, 1) # Explicitly list all Makefiles here AC_CONFIG_FILES([Makefile]) Index: c/src/lib/libbsp/arm/edb7312/include/ep7312.h =================================================================== RCS file: /usr1/CVS/rtems/c/src/lib/libbsp/arm/edb7312/include/ep7312.h,v retrieving revision 1.4 diff -u -r1.4 ep7312.h --- c/src/lib/libbsp/arm/edb7312/include/ep7312.h 21 Apr 2004 10:42:43 -0000 1.4 +++ c/src/lib/libbsp/arm/edb7312/include/ep7312.h 28 Jul 2009 01:13:23 -0000 @@ -153,4 +153,7 @@ /* INTR3 (Interrupt 3) mask/status register bits */ #define EP7312_INTR2_DAIINT 0x00000001 +/*Write to SKYEYE_MAGIC_ADDRESS to make SKYEYE exit*/ + +#define SKYEYE_MAGIC_ADDRESS (*(volatile unsigned int *)(0xb0000000)) #endif /* __EP7312_H__ */ Index: c/src/lib/libbsp/arm/edb7312/startup/bspreset.c =================================================================== RCS file: /usr1/CVS/rtems/c/src/lib/libbsp/arm/edb7312/startup/bspreset.c,v retrieving revision 1.2 diff -u -r1.2 bspreset.c --- c/src/lib/libbsp/arm/edb7312/startup/bspreset.c 12 Jul 2009 13:59:09 -0000 1.2 +++ c/src/lib/libbsp/arm/edb7312/startup/bspreset.c 28 Jul 2009 01:13:23 -0000 @@ -9,12 +9,13 @@ */ #include +#include void bsp_reset(void) { - #if ON_SKYEYE - /* TBD use Skyeye reset device */ - #else - asm volatile ("b _start"); - #endif +#if ON_SKYEYE == 1 + SKYEYE_MAGIC_ADDRESS = 0xff; +#else + asm volatile ("b _start"); +#endif } -------------- next part -------------- A non-text attachment was scrubbed... Name: shutdown_edb7312.patch Type: text/x-patch Size: 740 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: support_skyeye_shutdown_edb7312.patch Type: text/x-patch Size: 2682 bytes Desc: not available URL: From W.M.Grim at sron.nl Tue Jul 28 07:12:54 2009 From: W.M.Grim at sron.nl (Martin Grim) Date: Tue, 28 Jul 2009 09:12:54 +0200 Subject: C compiler cannot create executables Message-ID: <4A6EC116020000960000C2B2@pluto.sron.nl> Hi folks, I ran into the "C compiler cannot create executables" error. I did follow the remark on the wiki to fix my c compiler with the "apt-get install libc-dev". However, the problem remains. Does anybode have an other lead which I could follow to solve this? Regards, Martin -- ir. W.M. Grim SRON Netherlands Institute for Space Research Sorbonnelaan 2 3584 CA Utrecht, The Netherlands www.sron.nl From Thomas.Doerfler at embedded-brains.de Tue Jul 28 07:23:13 2009 From: Thomas.Doerfler at embedded-brains.de (Thomas Doerfler) Date: Tue, 28 Jul 2009 09:23:13 +0200 Subject: C compiler cannot create executables In-Reply-To: <4A6EC116020000960000C2B2@pluto.sron.nl> References: <4A6EC116020000960000C2B2@pluto.sron.nl> Message-ID: <4A6EA761.20305@embedded-brains.de> Martin, can you give us more information? Specifically: - which host OS / host CPU class (32 bit/64 bit) - which RTEMS tool versions - which autoconf/automake version - which target (I assume LEON?) - which PATH have you when trying to build the compiler - how did you configure the compiler? - did you already install the proper binutils first? Thank you, Thomas. Martin Grim wrote: > Hi folks, > > I ran into the "C compiler cannot create executables" error. I did follow the remark on the wiki to fix my c compiler with the "apt-get install libc-dev". However, the problem remains. Does anybode have an other lead which I could follow to solve this? > > Regards, > > Martin > > -- -------------------------------------------- Embedded Brains GmbH Thomas Doerfler Obere Lagerstrasse 30 D-82178 Puchheim Germany email: Thomas.Doerfler at embedded-brains.de Phone: +49-89-18908079-2 Fax: +49-89-18908079-9 From dirk.heinrichs at online.de Tue Jul 28 08:53:20 2009 From: dirk.heinrichs at online.de (Dirk Heinrichs) Date: Tue, 28 Jul 2009 10:53:20 +0200 Subject: C compiler cannot create executables In-Reply-To: <4A6EC116020000960000C2B2@pluto.sron.nl> References: <4A6EC116020000960000C2B2@pluto.sron.nl> Message-ID: <200907281053.26746.dirk.heinrichs@online.de> Am Dienstag 28 Juli 2009 09:12:54 schrieb Martin Grim: > I ran into the "C compiler cannot create executables" error. I did follow > the remark on the wiki to fix my c compiler with the "apt-get install > libc-dev". However, the problem remains. Does anybode have an other lead > which I could follow to solve this? What is the command you run when the error occurs? What's its output? Bye... Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From W.M.Grim at sron.nl Tue Jul 28 11:11:59 2009 From: W.M.Grim at sron.nl (Martin Grim) Date: Tue, 28 Jul 2009 13:11:59 +0200 Subject: C compiler cannot create executables In-Reply-To: <4A6EA761.20305@embedded-brains.de> References: <4A6EC116020000960000C2B2@pluto.sron.nl> <4A6EA761.20305@embedded-brains.de> Message-ID: <4A6EF91F020000960000C2C7@pluto.sron.nl> Hi, > - did you already install the proper binutils first? This seemed to be the problem: the binutils, etc. where installed after the configure was run. Now that I've changed the order, everything build oke.' Thanks for the hint. Martin -- ir. W.M. Grim SRON Netherlands Institute for Space Research Sorbonnelaan 2 3584 CA Utrecht, The Netherlands www.sron.nl From joel.sherrill at OARcorp.com Tue Jul 28 19:42:46 2009 From: joel.sherrill at OARcorp.com (Joel Sherrill) Date: Tue, 28 Jul 2009 14:42:46 -0500 Subject: Virtex PPC440 Message-ID: <4A6F54B6.7020301@oarcorp.com> Hi, Does anyone out there have a BSP for this or is working on it? -- 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 From mprtems at bellsouth.net Wed Jul 29 01:54:02 2009 From: mprtems at bellsouth.net (Mike Panetta) Date: Tue, 28 Jul 2009 18:54:02 -0700 (PDT) Subject: Cortex-M3 support? In-Reply-To: <4A69C811.3000201@oarcorp.com> References: <830532.41038.qm@web180404.mail.gq1.yahoo.com> <4A69C811.3000201@oarcorp.com> Message-ID: <394292.68170.qm@web180415.mail.gq1.yahoo.com> ----- Original Message ---- > From: Joel Sherrill > To: Mike Panetta ; "rtems-users at rtems.org" > Sent: Friday, July 24, 2009 10:41:21 AM > Subject: Re: Cortex-M3 support? > > Sebastian Huber has been reworking the ARM exception code so > make sure you are on today's head and talking to him. I don't have his email address, should it be in the list archives? He has not posted recently in reply to this message, so I am not quite sure how to contact him. > > In general terms, you want to start with the CPU core and > ignore the peripherals. > > + make sure the multilib variant is in the tools > + make sure the multilib variant is properly supported > by cpukit/score/arm and the libnetworking cksum routines. Its in the tools, but the score code seems to be dependent on non thumb ASM so it will not compile for the Cortex-M3. Specifically the context switching code is explicitly in ARM mode. > > If you have a non-RTEMS "no OS" arm-elf toolset which can > produce working executables for you, then you are almost > ready for a very minimal BSP. > > + Use the linker script as base with additions for > workspace related symbols > + Use the crt0.S from it (change call main -> boot_card) > + implement a polled console using the libgloss support. > + Use the "dummy idle task clock driver" As soon as I can figure the best way to get the score code to compile that will be my next step, using the rtems supplied tools. :) > > At the moment, I think the avr, m32c, adn m32r BSPs are the closest > examples to this minimal point. > > That gives you enough to run tests with no interrupts. > > Sebastian will need to step in for exception processing. Waiting to hear from him. > Thanks again, Mike > > -- 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 From rayx.cn at gmail.com Wed Jul 29 03:25:41 2009 From: rayx.cn at gmail.com (xu ray) Date: Wed, 29 Jul 2009 11:25:41 +0800 Subject: Cortex-M3 support? In-Reply-To: <394292.68170.qm@web180415.mail.gq1.yahoo.com> References: <830532.41038.qm@web180404.mail.gq1.yahoo.com> <4A69C811.3000201@oarcorp.com> <394292.68170.qm@web180415.mail.gq1.yahoo.com> Message-ID: <454f44fc0907282025u2dba421n5843cec170ba5495@mail.gmail.com> 2009/7/29 Mike Panetta > > > > > > ----- Original Message ---- > > From: Joel Sherrill > > To: Mike Panetta ; "rtems-users at rtems.org" < > rtems-users at rtems.org> > > Sent: Friday, July 24, 2009 10:41:21 AM > > Subject: Re: Cortex-M3 support? > > > > Sebastian Huber has been reworking the ARM exception code so > > make sure you are on today's head and talking to him. > > I don't have his email address, should it be in the list archives? > He has not posted recently in reply to this message, so I am > not quite sure how to contact him. > Add Sebastian Huber in the loop. He might be busy with LPC porting now. > > > > > In general terms, you want to start with the CPU core and > > ignore the peripherals. > > > > + make sure the multilib variant is in the tools > > + make sure the multilib variant is properly supported > > by cpukit/score/arm and the libnetworking cksum routines. > > Its in the tools, but the score code seems to be dependent on > non thumb ASM so it will not compile for the Cortex-M3. > > Specifically the context switching code is explicitly in ARM mode. > You can refer to make/custom/rtl22xx_t.cfg and rtl22xx_t BSP. This is a Thumb BSP. Try the "-mcpu=cortex-m3 -mthumb" flag for cortext-m3. I think no one have ever tried the cortex-m3 flag with rtems tool chain yet, hoping it works for you. Btw, minimum code size for rtl22xx_t is about 16K with 2K .bss/.data space, and the binary removed the filesystem and libc overhead. What is your requirement for RAM and ROM space? For the assembly code. The cortex family does not need to change to ARM mode when run the privilege instructions. So you can change the mode switch macro like align. Furthermore, cortex adds some registers like basepri, psp which is critical to the thread switch. You will have to add code to handle these. > > > > > If you have a non-RTEMS "no OS" arm-elf toolset which can > > produce working executables for you, then you are almost > > ready for a very minimal BSP. > > > > + Use the linker script as base with additions for > > workspace related symbols > > + Use the crt0.S from it (change call main -> boot_card) > > + implement a polled console using the libgloss support. > > + Use the "dummy idle task clock driver" > > As soon as I can figure the best way to get the score code to > compile that will be my next step, using the rtems supplied tools. :) > > > > > At the moment, I think the avr, m32c, adn m32r BSPs are the closest > > examples to this minimal point. > > > > That gives you enough to run tests with no interrupts. > > > > Sebastian will need to step in for exception processing. > > Waiting to hear from him. > > > > > Thanks again, > Mike > > > > > -- 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 > > _______________________________________________ > rtems-users mailing list > rtems-users at rtems.org > http://www.rtems.org/mailman/listinfo/rtems-users > -- Thanks & Best Regards! Ray, Xu PEP Technology -------------- next part -------------- An HTML attachment was scrubbed... URL: From sebastian.huber at embedded-brains.de Wed Jul 29 07:44:40 2009 From: sebastian.huber at embedded-brains.de (Sebastian Huber) Date: Wed, 29 Jul 2009 09:44:40 +0200 Subject: Automake question Message-ID: <4A6FFDE8.7060603@embedded-brains.de> Hi, for a BSP I need to compile one module with non standard CFLAGS. How can I do this? Unfortunately this will not work: noinst_PROGRAMS = starthooks.rel starthooks_rel_SOURCES = startup/bspstarthooks.c starthooks_rel_CFLAGS = $(NON_STANDARD_CFLAGS) libbsp_a_LIBADD = starthooks.rel Automake still uses the $(CFLAGS) which contains all the $(CPU_CFLAGS). 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 at embedded-brains.de PGP : Public key available on request Diese Nachricht ist keine gesch?ftliche Mitteilung im Sinne des EHUG. From ralf.corsepius at rtems.org Wed Jul 29 07:59:02 2009 From: ralf.corsepius at rtems.org (Ralf Corsepius) Date: Wed, 29 Jul 2009 09:59:02 +0200 Subject: Automake question In-Reply-To: <4A6FFDE8.7060603@embedded-brains.de> References: <4A6FFDE8.7060603@embedded-brains.de> Message-ID: <4A700146.9030403@rtems.org> On 07/29/2009 09:44 AM, Sebastian Huber wrote: > Hi, > > for a BSP I need to compile one module with non standard CFLAGS. Why? Under normal circumstances, you don't want to do this. In almost 100% of all cases, doing so is a bug. Ralf From sebastian.huber at embedded-brains.de Wed Jul 29 08:04:50 2009 From: sebastian.huber at embedded-brains.de (Sebastian Huber) Date: Wed, 29 Jul 2009 10:04:50 +0200 Subject: Automake question In-Reply-To: <4A700146.9030403@rtems.org> References: <4A6FFDE8.7060603@embedded-brains.de> <4A700146.9030403@rtems.org> Message-ID: <4A7002A2.7060400@embedded-brains.de> Ralf Corsepius wrote: > On 07/29/2009 09:44 AM, Sebastian Huber wrote: >> Hi, >> >> for a BSP I need to compile one module with non standard CFLAGS. > Why? Under normal circumstances, you don't want to do this. > In almost 100% of all cases, doing so is a bug. > > Ralf On the ARMv4 architecture you have two instruction sets: ARM and THUMB. I have to compile one module with ARM instructions only (because some low level stuff requires ARM mode): CPU_FLAGS without -mthumb. The rest of the BSP will use THUMB instructions: CPU_FLAGS with -mthumb. -- 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 at embedded-brains.de PGP : Public key available on request Diese Nachricht ist keine gesch?ftliche Mitteilung im Sinne des EHUG. From ralf.corsepius at rtems.org Wed Jul 29 11:09:57 2009 From: ralf.corsepius at rtems.org (Ralf Corsepius) Date: Wed, 29 Jul 2009 13:09:57 +0200 Subject: Automake question In-Reply-To: <4A7002A2.7060400@embedded-brains.de> References: <4A6FFDE8.7060603@embedded-brains.de> <4A700146.9030403@rtems.org> <4A7002A2.7060400@embedded-brains.de> Message-ID: <4A702E05.9020504@rtems.org> On 07/29/2009 10:04 AM, Sebastian Huber wrote: > Ralf Corsepius wrote: >> On 07/29/2009 09:44 AM, Sebastian Huber wrote: >>> Hi, >>> >>> for a BSP I need to compile one module with non standard CFLAGS. >> Why? Under normal circumstances, you don't want to do this. >> In almost 100% of all cases, doing so is a bug. >> >> Ralf > > On the ARMv4 architecture you have two instruction sets: ARM and THUMB. I have > to compile one module with ARM instructions only (because some low level stuff > requires ARM mode): CPU_FLAGS without -mthumb. The rest of the BSP will use > THUMB instructions: CPU_FLAGS with -mthumb. That's your bug. Arm and thumb are different architectures, which must not be mixed. Ralf From sebastian.huber at embedded-brains.de Wed Jul 29 11:39:20 2009 From: sebastian.huber at embedded-brains.de (Sebastian Huber) Date: Wed, 29 Jul 2009 13:39:20 +0200 Subject: Automake question In-Reply-To: <4A702E05.9020504@rtems.org> References: <4A6FFDE8.7060603@embedded-brains.de> <4A700146.9030403@rtems.org> <4A7002A2.7060400@embedded-brains.de> <4A702E05.9020504@rtems.org> Message-ID: <4A7034E8.8080102@embedded-brains.de> Ralf Corsepius wrote: > On 07/29/2009 10:04 AM, Sebastian Huber wrote: >> Ralf Corsepius wrote: >>> On 07/29/2009 09:44 AM, Sebastian Huber wrote: >>>> Hi, >>>> >>>> for a BSP I need to compile one module with non standard CFLAGS. >>> Why? Under normal circumstances, you don't want to do this. >>> In almost 100% of all cases, doing so is a bug. >>> >>> Ralf >> On the ARMv4 architecture you have two instruction sets: ARM and THUMB. I have >> to compile one module with ARM instructions only (because some low level stuff >> requires ARM mode): CPU_FLAGS without -mthumb. The rest of the BSP will use >> THUMB instructions: CPU_FLAGS with -mthumb. > > That's your bug. Arm and thumb are different architectures, which must > not be mixed. This is definitely not a bug. The exception processing for example starts in ARM mode. It is also possible to mix THUMB and ARM functions. This is called interworking. If you need position independent code you have to use ARM. -- 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 at embedded-brains.de PGP : Public key available on request Diese Nachricht ist keine gesch?ftliche Mitteilung im Sinne des EHUG. From Thomas.Doerfler at embedded-brains.de Wed Jul 29 12:16:43 2009 From: Thomas.Doerfler at embedded-brains.de (Thomas Doerfler) Date: Wed, 29 Jul 2009 14:16:43 +0200 Subject: Automake question In-Reply-To: <4A702E05.9020504@rtems.org> References: <4A6FFDE8.7060603@embedded-brains.de> <4A700146.9030403@rtems.org> <4A7002A2.7060400@embedded-brains.de> <4A702E05.9020504@rtems.org> Message-ID: <4A703DAB.3020106@embedded-brains.de> Ralf, Ralf Corsepius wrote: > On 07/29/2009 10:04 AM, Sebastian Huber wrote: >> Ralf Corsepius wrote: >>> On 07/29/2009 09:44 AM, Sebastian Huber wrote: >>>> Hi, >>>> >>>> for a BSP I need to compile one module with non standard CFLAGS. >>> Why? Under normal circumstances, you don't want to do this. >>> In almost 100% of all cases, doing so is a bug. >>> >>> Ralf >> On the ARMv4 architecture you have two instruction sets: ARM and THUMB. I have >> to compile one module with ARM instructions only (because some low level stuff >> requires ARM mode): CPU_FLAGS without -mthumb. The rest of the BSP will use >> THUMB instructions: CPU_FLAGS with -mthumb. > > That's your bug. Arm and thumb are different architectures, which must > not be mixed. >From ARM7TDMIvE.pdf, chapter 3.9.1: "If the processor is in THUMB state when an exception occurs, it will automatically switch into ARM state when the PC is loaded with the exception vector address." We have a ARM7 system with a 16 bit external memory bus. Using Thumb mode here gives us substantially more performance, b ut the exception entry MUST be coded as ARM code. So we really have to intermix both instruction sets (which is a "normal" way to work). So it would really help to pass special CFLAGs to certain modules. I understand, that usage of such a mechanism should be limited, though, to avoid to get the whole tree unmaintainable. wkr, Thomas. > > Ralf > > > > _______________________________________________ > rtems-users mailing list > rtems-users at rtems.org > http://www.rtems.org/mailman/listinfo/rtems-users -- -------------------------------------------- Embedded Brains GmbH Thomas Doerfler Obere Lagerstrasse 30 D-82178 Puchheim Germany email: Thomas.Doerfler at embedded-brains.de Phone: +49-89-18908079-2 Fax: +49-89-18908079-9 From ralf.corsepius at rtems.org Wed Jul 29 13:49:10 2009 From: ralf.corsepius at rtems.org (Ralf Corsepius) Date: Wed, 29 Jul 2009 15:49:10 +0200 Subject: Automake question In-Reply-To: <4A7034E8.8080102@embedded-brains.de> References: <4A6FFDE8.7060603@embedded-brains.de> <4A700146.9030403@rtems.org> <4A7002A2.7060400@embedded-brains.de> <4A702E05.9020504@rtems.org> <4A7034E8.8080102@embedded-brains.de> Message-ID: <4A705356.2040601@rtems.org> On 07/29/2009 01:39 PM, Sebastian Huber wrote: > The exception processing for example starts in > ARM mode. It is also possible to mix THUMB and ARM functions. This is called > interworking. That's not how GCC works. For it, thumb-interworking is yet another architectural variant (multilib) of the arm (unsupported in rtems). Ralf From sebastian.huber at embedded-brains.de Wed Jul 29 14:20:55 2009 From: sebastian.huber at embedded-brains.de (Sebastian Huber) Date: Wed, 29 Jul 2009 16:20:55 +0200 Subject: Automake question In-Reply-To: <4A6FFDE8.7060603@embedded-brains.de> References: <4A6FFDE8.7060603@embedded-brains.de> Message-ID: <4A705AC7.2010509@embedded-brains.de> Sebastian Huber wrote: > Hi, > > for a BSP I need to compile one module with non standard CFLAGS. How can I do > this? Unfortunately this will not work: > > noinst_PROGRAMS = starthooks.rel > > starthooks_rel_SOURCES = startup/bspstarthooks.c > starthooks_rel_CFLAGS = $(NON_STANDARD_CFLAGS) > > libbsp_a_LIBADD = starthooks.rel > > Automake still uses the $(CFLAGS) which contains all the $(CPU_CFLAGS). > > Have a nice day! This works and is quite ugly: libbsp_a_SOURCES += startup/bspstarthooks.c bspstarthooks.o: startup/bspstarthooks.c $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) \ $(AM_CPPFLAGS)$(CPPFLAGS) $(AM_CFLAGS) $(LPC24XX_CFLAGS) \ -MT bspstarthooks.o -MD -MP -MF $(DEPDIR)/bspstarthooks.Tpo \ -c -o bspstarthooks.o \ `test -f 'startup/bspstarthooks.c' || echo \ '$(srcdir)/'`startup/bspstarthooks.c -- 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 at embedded-brains.de PGP : Public key available on request Diese Nachricht ist keine gesch?ftliche Mitteilung im Sinne des EHUG. From feng1 at bnl.gov Fri Jul 31 15:49:52 2009 From: feng1 at bnl.gov (Kate Feng) Date: Fri, 31 Jul 2009 11:49:52 -0400 Subject: 64 bit DMA on RTEMS Message-ID: <4A7312A0.5000401@bnl.gov> Hi, Does RTEMS compiler truly support "64 bit DMA operation" if the H/W (e.g. processor & data bus) supports 64 bit data ? What I meant is that the compiler will not chop down the 64 bit data into two of 32 bit ones. Please confirm. Regards, Kate From leonp at plris.com Fri Jul 31 18:00:13 2009 From: leonp at plris.com (Leon Pollak) Date: Fri, 31 Jul 2009 21:00:13 +0300 Subject: 64 bit DMA on RTEMS In-Reply-To: <4A7312A0.5000401@bnl.gov> References: <4A7312A0.5000401@bnl.gov> Message-ID: <200907312100.14043.leonp@plris.com> On Friday July 31 2009, Kate Feng wrote: > Hi, > > Does RTEMS compiler truly support "64 bit DMA operation" > if the H/W (e.g. processor & data bus) supports 64 bit data ? > What I meant is that the compiler will not chop down the > 64 bit data into two of 32 bit ones. Please confirm. Kate, i am not sure what you mean... In my case, I have MPC8260 like CPU which has 64bit bus for RAM and DMA transfers. This is done by CPU automatically. AFAIK, DMA is done without CPU intervention and compiler can not influence on that. May be you mean 64bit machines such as AMD or INTEL Pentium Dual core etc.? -- Leon From funnyvoice at tlabs.ac.za Wed Jul 1 11:13:09 2009 From: funnyvoice at tlabs.ac.za (lee) Date: Wed, 01 Jul 2009 13:13:09 +0200 Subject: i386-gdb-stub compile error And rtems_shell _init error Message-ID: <1246446789.6918.10.camel@lee.tlabs.ac.za> Hi... Excuse all the questions all two of them... 1.) When I try to start the rtems shell with: rtems_shell_init("SHLL",RTEMS_MINIMUM_STACK_SIZE * 4,100,"/dev/console",0,1); the compiler gives me this warning: test.c:195: error: too few arguments to function 'rtems_shell_init' I've checked rtems/shell.h for the correct usage, and this is from a exact example again... not sure what the problem is... clearly compiling is using something else as rtems_shell_init or not? 2.) When I try to compile the gdb debugging example given in i386/shared/comm/GDB-HOWTO , the compiler gives me this error : opt/rtems-4.10/i386-rtems4.10/pc386/lib/librtemsbsp.a(i386-stub.o): In function `debug_error': /opt/rtems/c/src/lib/libbsp/i386/pc386/../../i386/shared/comm/i386-stub.c:575: undefined reference to `remote_debug' /opt/rtems-4.10/i386-rtems4.10/pc386/lib/librtemsbsp.a(i386-stub.o): In function `getpacket': /opt/rtems/c/src/lib/libbsp/i386/pc386/../../i386/shared/comm/i386-stub.c:504: undefined reference to `remote_debug' /opt/rtems/c/src/lib/libbsp/i386/pc386/../../i386/shared/comm/i386-stub.c:504: undefined reference to `remote_debug' /opt/rtems-4.10/i386-rtems4.10/pc386/lib/librtemsbsp.a(i386-stub.o): In function `handle_exception': /opt/rtems/c/src/lib/libbsp/i386/pc386/../../i386/shared/comm/i386-stub.c:758: undefined reference to `remote_debug' /opt/rtems/c/src/lib/libbsp/i386/pc386/../../i386/shared/comm/i386-stub.c:808: undefined reference to `remote_debug' Im busy figuring out what this means... not having much luck... anyone got any ideas... "extern int remote_debug"?? what is the use for this variable.... Kind Regards Much Love Lee From joel.sherrill at OARcorp.com Wed Jul 1 12:00:59 2009 From: joel.sherrill at OARcorp.com (Joel Sherrill) Date: Wed, 1 Jul 2009 07:00:59 -0500 Subject: i386-gdb-stub compile error And rtems_shell _init error In-Reply-To: <1246446789.6918.10.camel@lee.tlabs.ac.za> References: <1246446789.6918.10.camel@lee.tlabs.ac.za> Message-ID: <4A4B4FFB.9030706@oarcorp.com> lee wrote: > Hi... > > Excuse all the questions all two of them... > > 1.) When I try to start the rtems shell with: > > rtems_shell_init("SHLL",RTEMS_MINIMUM_STACK_SIZE * > 4,100,"/dev/console",0,1); > > the compiler gives me this warning: > > test.c:195: error: too few arguments to function 'rtems_shell_init' > > I've checked rtems/shell.h for the correct usage, and this is from a > exact example again... not sure what the problem is... clearly compiling > is using something else as rtems_shell_init or not? > > The calling sequence changed in the past few months on the CVS head. If you are looking at the telnetd example for the call, you will need to update your tree. testsuites/samples/fileio also calls it. > 2.) When I try to compile the gdb debugging example given in > i386/shared/comm/GDB-HOWTO , the compiler gives me this error : > > opt/rtems-4.10/i386-rtems4.10/pc386/lib/librtemsbsp.a(i386-stub.o): In > function `debug_error': > /opt/rtems/c/src/lib/libbsp/i386/pc386/../../i386/shared/comm/i386-stub.c:575: undefined reference to `remote_debug' > /opt/rtems-4.10/i386-rtems4.10/pc386/lib/librtemsbsp.a(i386-stub.o): In > function `getpacket': > /opt/rtems/c/src/lib/libbsp/i386/pc386/../../i386/shared/comm/i386-stub.c:504: undefined reference to `remote_debug' > /opt/rtems/c/src/lib/libbsp/i386/pc386/../../i386/shared/comm/i386-stub.c:504: undefined reference to `remote_debug' > /opt/rtems-4.10/i386-rtems4.10/pc386/lib/librtemsbsp.a(i386-stub.o): In > function `handle_exception': > /opt/rtems/c/src/lib/libbsp/i386/pc386/../../i386/shared/comm/i386-stub.c:758: undefined reference to `remote_debug' > /opt/rtems/c/src/lib/libbsp/i386/pc386/../../i386/shared/comm/i386-stub.c:808: undefined reference to `remote_debug' > > extern int remote_debug; /* debug > 0 prints ill-formed commands in valid packets & checksum errors */ You will have to declare this in your program somewhere so you can set the initial gdb protocol debug level. > Im busy figuring out what this means... not having much luck... anyone > got any ideas... "extern int remote_debug"?? what is the use for this > variable.... > > > Kind Regards Much Love > Lee > > _______________________________________________ > rtems-users mailing list > rtems-users at rtems.org > http://www.rtems.org/mailman/listinfo/rtems-users > --joel From chrisj at rtems.org Wed Jul 1 12:01:44 2009 From: chrisj at rtems.org (Chris Johns) Date: Wed, 01 Jul 2009 22:01:44 +1000 Subject: i386-gdb-stub compile error And rtems_shell _init error In-Reply-To: <1246446789.6918.10.camel@lee.tlabs.ac.za> References: <1246446789.6918.10.camel@lee.tlabs.ac.za> Message-ID: <4A4B5028.20506@rtems.org> lee wrote: > Hi... > > Excuse all the questions all two of them... > > 1.) When I try to start the rtems shell with: > > rtems_shell_init("SHLL",RTEMS_MINIMUM_STACK_SIZE * > 4,100,"/dev/console",0,1); > > the compiler gives me this warning: > > test.c:195: error: too few arguments to function 'rtems_shell_init' > > I've checked rtems/shell.h for the correct usage, and this is from a > exact example again... not sure what the problem is... clearly compiling > is using something else as rtems_shell_init or not? > I use: /** * Start the RTEMS Shell. */ void shell_start () { rtems_status_code sc; printf ("Starting shell....\n\n"); sc = rtems_shell_init ("fstst", 60 * 1024, 150, "/dev/console", 0, 1, NULL); if (sc != RTEMS_SUCCESSFUL) printf ("error: starting shell: %s (%d)\n", rtems_status_text (sc), sc); } I suspect something has changed and the documentation is not up to date. > > 2.) When I try to compile the gdb debugging example given in > i386/shared/comm/GDB-HOWTO , the compiler gives me this error : > > opt/rtems-4.10/i386-rtems4.10/pc386/lib/librtemsbsp.a(i386-stub.o): In > function `debug_error': > /opt/rtems/c/src/lib/libbsp/i386/pc386/../../i386/shared/comm/i386-stub.c:575: undefined reference to `remote_debug' > /opt/rtems-4.10/i386-rtems4.10/pc386/lib/librtemsbsp.a(i386-stub.o): In > function `getpacket': > /opt/rtems/c/src/lib/libbsp/i386/pc386/../../i386/shared/comm/i386-stub.c:504: undefined reference to `remote_debug' > /opt/rtems/c/src/lib/libbsp/i386/pc386/../../i386/shared/comm/i386-stub.c:504: undefined reference to `remote_debug' > /opt/rtems-4.10/i386-rtems4.10/pc386/lib/librtemsbsp.a(i386-stub.o): In > function `handle_exception': > /opt/rtems/c/src/lib/libbsp/i386/pc386/../../i386/shared/comm/i386-stub.c:758: undefined reference to `remote_debug' > /opt/rtems/c/src/lib/libbsp/i386/pc386/../../i386/shared/comm/i386-stub.c:808: undefined reference to `remote_debug' > > Im busy figuring out what this means... not having much luck... anyone > got any ideas... "extern int remote_debug"?? what is the use for this > variable.... > Not sure. I attach the file I use with this code in main: #if pc586 int arg; for (arg = 1; arg < argc; arg++) if (strcmp (argv[arg], "--gdb") == 0) pc386_gdb_init (); #endif This from the file system test code you can find here: http://www.rtems.org/ftp/pub/rtems/people/chrisj/file-system/rfs-20090612.tar.gz Regards Chris -------------- next part -------------- A non-text attachment was scrubbed... Name: pc386-gdb.c Type: text/x-csrc Size: 558 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pc386-gdb.h Type: text/x-chdr Size: 228 bytes Desc: not available URL: From fabricio at dea.inpe.br Wed Jul 1 13:02:50 2009 From: fabricio at dea.inpe.br (=?iso-8859-1?Q?Fabr=EDcio_de_Novaes_Kucinskis?=) Date: Wed, 1 Jul 2009 10:02:50 -0300 Subject: Possible error in the C User's Guide Message-ID: <20090701132637.A297F128A47@satelite.dea.inpe.br> Hello, In the C User?s Guide for RTEMS 4.9.2, at the botton of page 157 (REGION_GET_SEGMENT), the description for RTEMS_WAIT woudn't be "task will wait for a segment" instead of a ?wait for a semaphore?? Regards, Fabr?cio. -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel at gaisler.com Wed Jul 1 13:08:39 2009 From: daniel at gaisler.com (Daniel Hellstrom) Date: Wed, 01 Jul 2009 15:08:39 +0200 Subject: Multiprocessor problems In-Reply-To: <4A3A5C62.5080504@oarcorp.com> References: <22282CD520B39B4AB380985121DF4B0E0FFFF4CA68@MAIL03.ug.kth.se> <4A16C4D7.9020800@oarcorp.com> <4A3A0170.7060906@gaisler.com> <4A3A5C62.5080504@oarcorp.com> Message-ID: <4A4B5FD7.7060701@gaisler.com> Hi Joel, I have attached a patch which introduces a new "early" MP initialization routine. This works for SPARC/LEON3 MP. Daniel Joel Sherrill wrote: > Can you provide a patch Daniel? > > Daniel Hellstrom wrote: > >> Hi, >> >> The problem seems to be the initialization of _Objects_Local_node in >> multiprocessor enabled kernels. Since the _MPCI_Initialization() >> initializes _Objects_Local_node later than the first semaphores and >> tasks are created, this makes the IDs assigned to created objects >> incorrect. >> >> In single processor systems the _Objects_Local_node is a constant set >> to 1, but in multiprocessor systems it is initially set to zero and >> then initialized by _MPCI_Initialization(). >> >> The problem you experience is probably the same problem I ran into >> this week when running on a dual core SPARC/LEON3 system. Two tasks >> are created before the node number is setup correctly. See below >> print out from GRMON after breaking at Init(): >> >> grmon> thread info >> >> Name | Type | Id | Prio | Time (h:m:s) | Entry >> point | PC | State >> --------------------------------------------------------------------------------------------------------------------------------------- >> >> Int. | internal | 0x09000001 | 255 | 0.000000 | >> ?? | 0x0 | READY >> --------------------------------------------------------------------------------------------------------------------------------------- >> >> Int. | classic | 0x09000002 | 0 | 0.000000 | ?? >> | 0x0 | Wsem >> --------------------------------------------------------------------------------------------------------------------------------------- >> >> * UI1 | classic | 0x0a010001 | 1 | 0.000000 | >> RAM_END | 0x40001368 Init + >> 0x4 | READY >> --------------------------------------------------------------------------------------------------------------------------------------- >> >> >> As you can see the node number is 0 rather than 1 or 2 in the ID field. >> >> The bug appears when the first MPCI packet is received on the target >> node, the ISR calls _MCPI_Announce which tries to release a >> semaphore, the blocked thread are thought to be global and the system >> crashes. The function deciding if it is a global or local object >> simply checks if they are of the same node, not if the node number is >> zero. >> >> RTEMS_INLINE_ROUTINE bool _Objects_Is_local_node( >> uint32_t node >> ) >> { >> return ( node == _Objects_Local_node ); >> } >> >> To test that this theory holds I changed the declaration of >> _Objects_Local_node to extern instead of SCORE_EXTERN, and declared >> it in my project initialy initialized to the node number. The LEON3 >> dual core system now works and I have successfully managed to get >> semaphores and tasks interacting between the two nodes. >> >> uint16_t _Objects_Local_node = CONFIGURE_MP_NODE_NUMBER; >> >> >> >> I suggest that the initialization of _Objects_Local_node is moved to >> be initialized earlier. >> >> Regards, >> Daniel Hellstrom >> >> >> >> Joel Sherrill wrote: >> >> >> >>> Roger Dahlkvist wrote: >>> >>> >>> >>> >>>> Hi, >>>> >>>> I'm using a timer ISR polling method checking for new messages from >>>> other nodes. Unfortunately the system crashes as soon as >>>> rtems_multiprocessing_announce is called. >>>> >>>> >>>> >>> >>> There are no interrupts enabled until the initialization task is >>> switched >>> in. >>> >>> I have wondered if it wouldn't make sense to have the MP initialization >>> sycnhronization done either explicitly by the application (like >>> initialization >>> of TCP/IP) or implicitly by the init thread like C++ global >>> constructors. >>> >>> You can try moving this code from exinit.c to threadhandler.c where and >>> protect it somehow from being executed more than once. >>> >>> #if defined(RTEMS_MULTIPROCESSING) >>> if ( _System_state_Is_multiprocessing ) { >>> _MPCI_Initialization(); >>> _MPCI_Internal_packets_Send_process_packet( >>> MPCI_PACKETS_SYSTEM_VERIFY >>> ); >>> } >>> #endif >>> >>> Then you will at least be able to get your interrupts and call MP >>> announce >>> to complete system initialization. >>> >>> >>> >>> >>>> However, rtems_multiprocessing_announce works just fine if it's >>>> called just after the initialization phase, before the >>>> initinitialization task is started. That's really strange. >>>> >>>> So for example, if I make one node get initialized and started >>>> faster than the other node (using less drivers etc), I'll be able >>>> to create global objects. and as long as the other node has not >>>> started the initialization task, the message is received and the >>>> global objects table is updated, so it can be identified later on. >>>> But I can't use them since furter calls to >>>> rtems_multiprocessing_announce will fail. >>>> >>>> At this point I feel like I have tested just about everything, with >>>> no luck. It's urgent that I get MP to work properly. I'm using Nios >>>> II processors and I have defined my own MPCI routines. I'm >>>> confident that they work properly and I have verified that the >>>> system crashes before they are even invoked. >>>> >>>> Is there anyone with MP experience who might have a clue of what's >>>> causing my problems? Any help is MUCH appreciated. >>>> >>>> //Roger >>>> >>>> _______________________________________________ >>>> rtems-users mailing list >>>> rtems-users at rtems.org >>>> http://www.rtems.org/mailman/listinfo/rtems-users >>>> >>>> >>>> >>> >>> >>> >>> >> >> >> > > > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Object_Local_node.patch URL: From daniel at gaisler.com Wed Jul 1 13:14:03 2009 From: daniel at gaisler.com (Daniel Hellstrom) Date: Wed, 01 Jul 2009 15:14:03 +0200 Subject: Multiprocessor problems In-Reply-To: <4A3A5CA8.7010807@oarcorp.com> References: <22282CD520B39B4AB380985121DF4B0E0FFFF4CA68@MAIL03.ug.kth.se> <4A16C4D7.9020800@oarcorp.com> <4A3A0170.7060906@gaisler.com> <4A3A2F8A.4030206@gaisler.com> <4A3A5CA8.7010807@oarcorp.com> Message-ID: <4A4B611B.6060808@gaisler.com> Hello, The init task name is defined by confdef.h, it is possible to set the init task name to a custom name using the CONFIGURE_INIT_TASK_NAME define, for example: #define CONFIGURE_INIT_TASK_NAME rtems_build_name('U', 'I', '0'+CONFIGURE_MP_NODE_NUMBER, ' ') Perhaps a patch is not needed in this case? Daniel Joel Sherrill wrote: > Provide a patch and I will merge it. :) > > --joel > > Daniel Hellstrom wrote: > >> Hi, >> >> On a similar MP topic, all Init tasks have the same name "UI1" >> regardless of CPU node. I have seen in the mptests that the >> CONFIGURE_INIT_TASK_ATTRIBUTES is set to RTEMS_GLOBAL, this means >> that the rtems_ident_task() can not be used to look up the ID of the >> remote node's Init task. Perhaps the Init task name could be >> {'U','I','0'+nodeid,'\0'} instead? >> >> >> GRMON thread info output from the two LEON3 CPUs, CPU0 >> [0x40000000-0x43FFFFFF0] and CPU1 [0x44000000-0x47FFFFFF0]: >> >> grlib> sym rtems-mp1 >> read 1456 symbols >> entry point: 0x40000000 >> grlib> thread info >> >> Name | Type | Id | Prio | Time (h:m:s) | Entry >> point | PC | State >> --------------------------------------------------------------------------------------------------------------------------------------- >> >> Int. | internal | 0x09010001 | 255 | 0.000000 | >> _BSP_Thread_Idle_body | 0x400030a4 _BSP_Thread_Idle_body + >> 0x0 | READY >> --------------------------------------------------------------------------------------------------------------------------------------- >> >> Int. | classic | 0x09010002 | 0 | 0.005648 | >> _MPCI_Receive_server | 0x4000c66c _Thread_Dispatch + >> 0xd8 | Wsem >> --------------------------------------------------------------------------------------------------------------------------------------- >> >> * UI1 | classic | 0x0a010001 | 1 | 0.000000 | >> Init | 0x40001368 Init + >> 0x4 | READY >> --------------------------------------------------------------------------------------------------------------------------------------- >> >> >> grlib> sym rtems-mp2 >> read 1456 symbols >> entry point: 0x44000000 >> grlib> thread info >> >> Name | Type | Id | Prio | Time (h:m:s) | Entry >> point | PC | State >> --------------------------------------------------------------------------------------------------------------------------------------- >> >> Int. | internal | 0x09020001 | 255 | 0.000000 | >> _BSP_Thread_Idle_body | 0x440030a4 _BSP_Thread_Idle_body + >> 0x0 | READY >> --------------------------------------------------------------------------------------------------------------------------------------- >> >> Int. | classic | 0x09020002 | 0 | 0.005661 | >> _MPCI_Receive_server | 0x4400c66c _Thread_Dispatch + >> 0xd8 | Wsem >> --------------------------------------------------------------------------------------------------------------------------------------- >> >> * UI1 | classic | 0x0a020001 | 1 | 0.000000 | >> Init | 0x40001368 _RAM_SIZE + >> 0x3c00136c | READY >> --------------------------------------------------------------------------------------------------------------------------------------- >> >> >> >> Daniel >> >> >> >> Daniel Hellstrom wrote: >> >> >> >>> Hi, >>> >>> The problem seems to be the initialization of _Objects_Local_node in >>> multiprocessor enabled kernels. Since the _MPCI_Initialization() >>> initializes _Objects_Local_node later than the first semaphores and >>> tasks are created, this makes the IDs assigned to created objects >>> incorrect. >>> >>> In single processor systems the _Objects_Local_node is a constant >>> set to 1, but in multiprocessor systems it is initially set to zero >>> and then initialized by _MPCI_Initialization(). >>> >>> The problem you experience is probably the same problem I ran into >>> this week when running on a dual core SPARC/LEON3 system. Two tasks >>> are created before the node number is setup correctly. See below >>> print out >> >> >from GRMON after breaking at Init(): >> >> >>> grmon> thread info >>> >>> Name | Type | Id | Prio | Time (h:m:s) | Entry >>> point | PC | >>> State >>> --------------------------------------------------------------------------------------------------------------------------------------- >>> >>> Int. | internal | 0x09000001 | 255 | 0.000000 | >>> ?? | 0x0 | READY >>> --------------------------------------------------------------------------------------------------------------------------------------- >>> >>> Int. | classic | 0x09000002 | 0 | 0.000000 | ?? >>> | 0x0 | Wsem >>> --------------------------------------------------------------------------------------------------------------------------------------- >>> >>> * UI1 | classic | 0x0a010001 | 1 | 0.000000 | >>> RAM_END | 0x40001368 Init + >>> 0x4 | READY >>> --------------------------------------------------------------------------------------------------------------------------------------- >>> >>> >>> As you can see the node number is 0 rather than 1 or 2 in the ID field. >>> >>> The bug appears when the first MPCI packet is received on the target >>> node, the ISR calls _MCPI_Announce which tries to release a >>> semaphore, the blocked thread are thought to be global and the >>> system crashes. The function deciding if it is a global or local >>> object simply checks if they are of the same node, not if the node >>> number is zero. >>> >>> RTEMS_INLINE_ROUTINE bool _Objects_Is_local_node( >>> uint32_t node >>> ) >>> { >>> return ( node == _Objects_Local_node ); >>> } >>> >>> To test that this theory holds I changed the declaration of >>> _Objects_Local_node to extern instead of SCORE_EXTERN, and declared >>> it in my project initialy initialized to the node number. The LEON3 >>> dual core system now works and I have successfully managed to get >>> semaphores and tasks interacting between the two nodes. >>> >>> uint16_t _Objects_Local_node = CONFIGURE_MP_NODE_NUMBER; >>> >>> >>> >>> I suggest that the initialization of _Objects_Local_node is moved to >>> be initialized earlier. >>> >>> Regards, >>> Daniel Hellstrom >>> >>> >>> >>> Joel Sherrill wrote: >>> >>> >>> >>> >>> >>>> Roger Dahlkvist wrote: >>>> >>>> >>>> >>>> >>>> >>>>> Hi, >>>>> >>>>> I'm using a timer ISR polling method checking for new messages >>>>> from other nodes. Unfortunately the system crashes as soon as >>>>> rtems_multiprocessing_announce is called. >>>>> >>>>> >>>>> >>>>> >>>> >>>> There are no interrupts enabled until the initialization task is >>>> switched >>>> in. >>>> >>>> I have wondered if it wouldn't make sense to have the MP >>>> initialization >>>> sycnhronization done either explicitly by the application (like >>>> initialization >>>> of TCP/IP) or implicitly by the init thread like C++ global >>>> constructors. >>>> >>>> You can try moving this code from exinit.c to threadhandler.c where >>>> and >>>> protect it somehow from being executed more than once. >>>> >>>> #if defined(RTEMS_MULTIPROCESSING) >>>> if ( _System_state_Is_multiprocessing ) { >>>> _MPCI_Initialization(); >>>> _MPCI_Internal_packets_Send_process_packet( >>>> MPCI_PACKETS_SYSTEM_VERIFY >>>> ); >>>> } >>>> #endif >>>> >>>> Then you will at least be able to get your interrupts and call MP >>>> announce >>>> to complete system initialization. >>>> >>>> >>>> >>>> >>>> >>>>> However, rtems_multiprocessing_announce works just fine if it's >>>>> called just after the initialization phase, before the >>>>> initinitialization task is started. That's really strange. >>>>> >>>>> So for example, if I make one node get initialized and started >>>>> faster than the other node (using less drivers etc), I'll be able >>>>> to create global objects. and as long as the other node has not >>>>> started the initialization task, the message is received and the >>>>> global objects table is updated, so it can be identified later on. >>>>> But I can't use them since furter calls to >>>>> rtems_multiprocessing_announce will fail. >>>>> >>>>> At this point I feel like I have tested just about everything, >>>>> with no luck. It's urgent that I get MP to work properly. I'm >>>>> using Nios II processors and I have defined my own MPCI routines. >>>>> I'm confident that they work properly and I have verified that the >>>>> system crashes before they are even invoked. >>>>> >>>>> Is there anyone with MP experience who might have a clue of what's >>>>> causing my problems? Any help is MUCH appreciated. >>>>> >>>>> //Roger >>>>> >>>>> _______________________________________________ >>>>> rtems-users mailing list >>>>> rtems-users at rtems.org >>>>> http://www.rtems.org/mailman/listinfo/rtems-users >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> _______________________________________________ >>> rtems-users mailing list >>> rtems-users at rtems.org >>> http://www.rtems.org/mailman/listinfo/rtems-users >>> >>> >>> >>> >>> >> >> >> > > > From joel.sherrill at OARcorp.com Wed Jul 1 13:46:15 2009 From: joel.sherrill at OARcorp.com (Joel Sherrill) Date: Wed, 1 Jul 2009 08:46:15 -0500 Subject: RTEMS schedualing example In-Reply-To: References: Message-ID: <4A4B68A7.3000008@oarcorp.com> Nasim Zehra wrote: > dear users, > can any one post any example showing schedualing of two or more than two tasks using rate monotonic directives?This example should be other than that described in RTEMS c user guide manual ans should be in running condition.I am having a bit confusion using these directives.Will be very thankful to you. > > testsuites/libtests/rtmonuse has 5 tasks. > regards > -------- > nasim zahra > _______________________________________________ > rtems-users mailing list > rtems-users at rtems.org > http://www.rtems.org/mailman/listinfo/rtems-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 From funnyvoice at tlabs.ac.za Wed Jul 1 13:59:12 2009 From: funnyvoice at tlabs.ac.za (lee) Date: Wed, 01 Jul 2009 15:59:12 +0200 Subject: Exception ?? Message-ID: <1246456752.6918.19.camel@lee.tlabs.ac.za> Hi All again.... Im running a very simple test program, called hello.exe... So I got the shell working.. thanx again... then tried the gdb... got gdb compiled works fine.... but when I run the target after compiling it i get 0x0a10003 thread 3 exception error? The name of this thread is "UI1"... but cant seem to find this anywhere in source... I grepped just about the entire source tree.... any idea what this could be...??? This happens when I invoke : set_debug_traps(); Here is the startup: i386_stub_glue_init(BSP_UART_COM1); /* Init GDB stub itself */ //set_debug_traps(); /* * Init GDB break in capability, * has to be called after * set_debug_traps */ i386_stub_glue_init_breakin(); I've put a breakpoint somewhere in the source.... anyone have similar problem... Kind Regards Lee From daron.chabot at gmail.com Wed Jul 1 15:29:25 2009 From: daron.chabot at gmail.com (Daron Chabot) Date: Wed, 1 Jul 2009 11:29:25 -0400 Subject: Exception ?? In-Reply-To: <1246456752.6918.19.camel@lee.tlabs.ac.za> References: <1246456752.6918.19.camel@lee.tlabs.ac.za> Message-ID: <50cc54100907010829g5d57d049g71f4aeecbe9bd2da@mail.gmail.com> Exception 3 is a breakpoint exception on the i386 :-) "UI1"... That sounds like the "Init" thread. You are generating a breakpoint from Init... FYI, I have used these commands to initialize the remote-debugging stub and stop program execution, waiting for the host gdb session to connect (over rs-232): init_remote_gdb(); rtems_task_wake_after(25); /* 1 tick == 10 ms */ breakpoint(); -- dc On Wed, Jul 1, 2009 at 9:59 AM, lee wrote: > Hi All again.... > > Im running a very simple test program, called hello.exe... > > So I got the shell working.. thanx again... then tried the gdb... got > gdb compiled works fine.... but when I run the target after compiling it > i get 0x0a10003 thread 3 exception error? The name of this thread is > "UI1"... but cant seem to find this anywhere in source... I grepped just > about the entire source tree.... any idea what this could be...??? > > This happens when I invoke : > > set_debug_traps(); > > Here is the startup: > > > > ?i386_stub_glue_init(BSP_UART_COM1); > > > ?/* Init GDB stub itself */ > ?//set_debug_traps(); > > ?/* > ? * Init GDB break in capability, > ? * has to be called after > ? * set_debug_traps > ? */ > ?i386_stub_glue_init_breakin(); > > > I've put a breakpoint somewhere in the source.... anyone have similar > problem... > > Kind Regards > Lee > > _______________________________________________ > rtems-users mailing list > rtems-users at rtems.org > http://www.rtems.org/mailman/listinfo/rtems-users > From funnyvoice at tlabs.ac.za Thu Jul 2 12:36:07 2009 From: funnyvoice at tlabs.ac.za (lee) Date: Thu, 02 Jul 2009 14:36:07 +0200 Subject: Rtems VME.h VMEDMA.h example of using these API's ? Message-ID: <1246538167.6918.22.camel@lee.tlabs.ac.za> Hi... Does anyone have an example of using just these 2 API's for the vme universe driver? Kind Regards Lee From strauman at slac.stanford.edu Thu Jul 2 14:26:19 2009 From: strauman at slac.stanford.edu (Till Straumann) Date: Thu, 02 Jul 2009 09:26:19 -0500 Subject: Rtems VME.h VMEDMA.h example of using these API's ? In-Reply-To: <1246538167.6918.22.camel@lee.tlabs.ac.za> References: <1246538167.6918.22.camel@lee.tlabs.ac.za> Message-ID: <4A4CC38B.1070801@slac.stanford.edu> lee wrote: > Hi... > > > Does anyone have an example of using just these 2 API's for the vme > universe driver? > > Kind Regards > Lee > > _______________________________________________ > rtems-users mailing list > rtems-users at rtems.org > http://www.rtems.org/mailman/listinfo/rtems-users > I'll send you two example off-line... T. From joel.sherrill at OARcorp.com Fri Jul 3 15:16:59 2009 From: joel.sherrill at OARcorp.com (Joel Sherrill) Date: Fri, 3 Jul 2009 10:16:59 -0500 Subject: Multiprocessor problems In-Reply-To: <4A4B5FD7.7060701@gaisler.com> References: <22282CD520B39B4AB380985121DF4B0E0FFFF4CA68@MAIL03.ug.kth.se> <4A16C4D7.9020800@oarcorp.com> <4A3A0170.7060906@gaisler.com> <4A3A5C62.5080504@oarcorp.com> <4A4B5FD7.7060701@gaisler.com> Message-ID: <4A4E20EB.6020807@oarcorp.com> Daniel Hellstrom wrote: > Hi Joel, > > I have attached a patch which introduces a new "early" MP initialization > routine. This works for SPARC/LEON3 MP. > > Committed to the head. Does this also need to go on the 4.9 branch? What were you testing with? --joel > Daniel > > > Joel Sherrill wrote: > > >> Can you provide a patch Daniel? >> >> Daniel Hellstrom wrote: >> >> >>> Hi, >>> >>> The problem seems to be the initialization of _Objects_Local_node in >>> multiprocessor enabled kernels. Since the _MPCI_Initialization() >>> initializes _Objects_Local_node later than the first semaphores and >>> tasks are created, this makes the IDs assigned to created objects >>> incorrect. >>> >>> In single processor systems the _Objects_Local_node is a constant set >>> to 1, but in multiprocessor systems it is initially set to zero and >>> then initialized by _MPCI_Initialization(). >>> >>> The problem you experience is probably the same problem I ran into >>> this week when running on a dual core SPARC/LEON3 system. Two tasks >>> are created before the node number is setup correctly. See below >>> print out from GRMON after breaking at Init(): >>> >>> grmon> thread info >>> >>> Name | Type | Id | Prio | Time (h:m:s) | Entry >>> point | PC | State >>> --------------------------------------------------------------------------------------------------------------------------------------- >>> >>> Int. | internal | 0x09000001 | 255 | 0.000000 | >>> ?? | 0x0 | READY >>> --------------------------------------------------------------------------------------------------------------------------------------- >>> >>> Int. | classic | 0x09000002 | 0 | 0.000000 | ?? >>> | 0x0 | Wsem >>> --------------------------------------------------------------------------------------------------------------------------------------- >>> >>> * UI1 | classic | 0x0a010001 | 1 | 0.000000 | >>> RAM_END | 0x40001368 Init + >>> 0x4 | READY >>> --------------------------------------------------------------------------------------------------------------------------------------- >>> >>> >>> As you can see the node number is 0 rather than 1 or 2 in the ID field. >>> >>> The bug appears when the first MPCI packet is received on the target >>> node, the ISR calls _MCPI_Announce which tries to release a >>> semaphore, the blocked thread are thought to be global and the system >>> crashes. The function deciding if it is a global or local object >>> simply checks if they are of the same node, not if the node number is >>> zero. >>> >>> RTEMS_INLINE_ROUTINE bool _Objects_Is_local_node( >>> uint32_t node >>> ) >>> { >>> return ( node == _Objects_Local_node ); >>> } >>> >>> To test that this theory holds I changed the declaration of >>> _Objects_Local_node to extern instead of SCORE_EXTERN, and declared >>> it in my project initialy initialized to the node number. The LEON3 >>> dual core system now works and I have successfully managed to get >>> semaphores and tasks interacting between the two nodes. >>> >>> uint16_t _Objects_Local_node = CONFIGURE_MP_NODE_NUMBER; >>> >>> >>> >>> I suggest that the initialization of _Objects_Local_node is moved to >>> be initialized earlier. >>> >>> Regards, >>> Daniel Hellstrom >>> >>> >>> >>> Joel Sherrill wrote: >>> >>> >>> >>> >>>> Roger Dahlkvist wrote: >>>> >>>> >>>> >>>> >>>> >>>>> Hi, >>>>> >>>>> I'm using a timer ISR polling method checking for new messages from >>>>> other nodes. Unfortunately the system crashes as soon as >>>>> rtems_multiprocessing_announce is called. >>>>> >>>>> >>>>> >>>>> >>>> There are no interrupts enabled until the initialization task is >>>> switched >>>> in. >>>> >>>> I have wondered if it wouldn't make sense to have the MP initialization >>>> sycnhronization done either explicitly by the application (like >>>> initialization >>>> of TCP/IP) or implicitly by the init thread like C++ global >>>> constructors. >>>> >>>> You can try moving this code from exinit.c to threadhandler.c where and >>>> protect it somehow from being executed more than once. >>>> >>>> #if defined(RTEMS_MULTIPROCESSING) >>>> if ( _System_state_Is_multiprocessing ) { >>>> _MPCI_Initialization(); >>>> _MPCI_Internal_packets_Send_process_packet( >>>> MPCI_PACKETS_SYSTEM_VERIFY >>>> ); >>>> } >>>> #endif >>>> >>>> Then you will at least be able to get your interrupts and call MP >>>> announce >>>> to complete system initialization. >>>> >>>> >>>> >>>> >>>> >>>>> However, rtems_multiprocessing_announce works just fine if it's >>>>> called just after the initialization phase, before the >>>>> initinitialization task is started. That's really strange. >>>>> >>>>> So for example, if I make one node get initialized and started >>>>> faster than the other node (using less drivers etc), I'll be able >>>>> to create global objects. and as long as the other node has not >>>>> started the initialization task, the message is received and the >>>>> global objects table is updated, so it can be identified later on. >>>>> But I can't use them since furter calls to >>>>> rtems_multiprocessing_announce will fail. >>>>> >>>>> At this point I feel like I have tested just about everything, with >>>>> no luck. It's urgent that I get MP to work properly. I'm using Nios >>>>> II processors and I have defined my own MPCI routines. I'm >>>>> confident that they work properly and I have verified that the >>>>> system crashes before they are even invoked. >>>>> >>>>> Is there anyone with MP experience who might have a clue of what's >>>>> causing my problems? Any help is MUCH appreciated. >>>>> >>>>> //Roger >>>>> >>>>> _______________________________________________ >>>>> rtems-users mailing list >>>>> rtems-users at rtems.org >>>>> http://www.rtems.org/mailman/listinfo/rtems-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 From joel.sherrill at OARcorp.com Fri Jul 3 20:37:22 2009 From: joel.sherrill at OARcorp.com (Joel Sherrill) Date: Fri, 3 Jul 2009 15:37:22 -0500 Subject: Was RTEMS user in Fermilabs Discovery? Message-ID: <4A4E6C02.1090009@oarcorp.com> Hi, I saw that Fermilab?s announced the discovery of a new particle, the Omega-sub-b (?_b ), and wondered if RTEMS and EPICS played a role in this. -- 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 From asporner at googlemail.com Fri Jul 3 20:44:55 2009 From: asporner at googlemail.com (Andrew Sporner) Date: Fri, 3 Jul 2009 22:44:55 +0200 Subject: Was RTEMS user in Fermilabs Discovery? In-Reply-To: <4A4E6C02.1090009@oarcorp.com> References: <4A4E6C02.1090009@oarcorp.com> Message-ID: <5cbbb9e90907031344m6f83c678h5bbc24ca837777d1@mail.gmail.com> Years ago when I was an intern at feynman computer center it was mostly big-Os stuff. I do recall Risc/Os being used for the 68K based stuff and even the ACP/Maps which at the time was the biggest supercomputer, but that was some time ago. Andy On Fri, Jul 3, 2009 at 10:37 PM, Joel Sherrill wrote: > Hi, > > I saw that Fermilab?s announced the discovery > of a new particle, the Omega-sub-b (?_b ), and > wondered if RTEMS and EPICS played a role in > this. > > -- > 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 > > > _______________________________________________ > rtems-users mailing list > rtems-users at rtems.org > http://www.rtems.org/mailman/listinfo/rtems-users > From asporner at googlemail.com Fri Jul 3 20:45:44 2009 From: asporner at googlemail.com (Andrew Sporner) Date: Fri, 3 Jul 2009 22:45:44 +0200 Subject: Was RTEMS user in Fermilabs Discovery? In-Reply-To: <5cbbb9e90907031344m6f83c678h5bbc24ca837777d1@mail.gmail.com> References: <4A4E6C02.1090009@oarcorp.com> <5cbbb9e90907031344m6f83c678h5bbc24ca837777d1@mail.gmail.com> Message-ID: <5cbbb9e90907031345h26b9bd45ud7ddd799d1d70994@mail.gmail.com> Just realized I goofed that, it was the I860 stuff. 2009/7/3 Andrew Sporner : > Years ago when I was an intern at feynman computer center it was mostly > big-Os stuff. ?I do recall Risc/Os being used for the 68K based stuff and even > the ACP/Maps which at the time was the biggest supercomputer, but that was > some time ago. > > Andy > > On Fri, Jul 3, 2009 at 10:37 PM, Joel Sherrill wrote: >> Hi, >> >> I saw that Fermilab?s announced the discovery >> of a new particle, the Omega-sub-b (?_b ), and >> wondered if RTEMS and EPICS played a role in >> this. >> >> -- >> 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 >> >> >> _______________________________________________ >> rtems-users mailing list >> rtems-users at rtems.org >> http://www.rtems.org/mailman/listinfo/rtems-users >> > From joel.sherrill at OARcorp.com Fri Jul 3 20:49:41 2009 From: joel.sherrill at OARcorp.com (Joel Sherrill) Date: Fri, 3 Jul 2009 15:49:41 -0500 Subject: Was RTEMS user in Fermilabs Discovery? In-Reply-To: <5cbbb9e90907031345h26b9bd45ud7ddd799d1d70994@mail.gmail.com> References: <4A4E6C02.1090009@oarcorp.com> <5cbbb9e90907031344m6f83c678h5bbc24ca837777d1@mail.gmail.com> <5cbbb9e90907031345h26b9bd45ud7ddd799d1d70994@mail.gmail.com> Message-ID: <4A4E6EE5.6030003@oarcorp.com> Andrew Sporner wrote: > Just realized I goofed that, it was the I860 stuff. > > 2009/7/3 Andrew Sporner : > >> Years ago when I was an intern at feynman computer center it was mostly >> big-Os stuff. I do recall Risc/Os being used for the 68K based stuff and even >> the ACP/Maps which at the time was the biggest supercomputer, but that was >> some time ago. >> I found some requirement docs on the web from there that indicates that they do use RTEMS on at least some control equipment. Just curious if it made the lab stuff for this discovery. --joel >> Andy >> >> On Fri, Jul 3, 2009 at 10:37 PM, Joel Sherrill wrote: >> >>> Hi, >>> >>> I saw that Fermilab?s announced the discovery >>> of a new particle, the Omega-sub-b (?_b ), and >>> wondered if RTEMS and EPICS played a role in >>> this. >>> >>> -- >>> 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 >>> >>> >>> _______________________________________________ >>> rtems-users mailing list >>> rtems-users at rtems.org >>> http://www.rtems.org/mailman/listinfo/rtems-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 From siddons at bnl.gov Fri Jul 3 21:30:00 2009 From: siddons at bnl.gov (D. Peter Siddons) Date: Fri, 03 Jul 2009 17:30:00 -0400 Subject: Was RTEMS user in Fermilabs Discovery? In-Reply-To: <4A4E6C02.1090009@oarcorp.com> References: <4A4E6C02.1090009@oarcorp.com> Message-ID: <4A4E7858.1080400@bnl.gov> Hi Joel, According to the FNAL web site, both D0 and CDF use EPICS as part of their control system, but I couldn't find any reference to RTEMS. The new particle came from CDF. The D0 page has info about VxWorks. That said, many EPICS folks are looking hard at RTEMS as it becomes more visible in projects like Stanford's LCLS. Pete. Joel Sherrill wrote: > Hi, > > I saw that Fermilab?s announced the discovery > of a new particle, the Omega-sub-b (?_b ), and > wondered if RTEMS and EPICS played a role in > this. > -- D. Peter Siddons Detector Development Group Leader National Synchrotron Light Source Brookhaven National Laboratory Upton, NY 11973 email: siddons at bnl.gov Phone: (631) 344-2738 From jszhang3 at gmail.com Fri Jul 3 23:12:22 2009 From: jszhang3 at gmail.com (JiSheng Zhang) Date: Sat, 4 Jul 2009 07:12:22 +0800 Subject: [GSOC] Dynamic object file loading status Message-ID: <2df346410907031612j6cafcd0o6c80adfdd16b8147@mail.gmail.com> Hi all, My coding started on 15 June. It's too late. I hope I can catch up with other students. As for the project status: I have implemented a loader under Linux. The code is based on bionic(android libc) linker, but the object file loading and symbol resolving and ?relocation will be rewritten. It seems ?that object file loading and parsing, symbol resolving and relocation works fine. But the object is entirely readed into memory, ?we only need to load sections such as .text .data .symtab etc. So I rewrite some code of the loader, now the resolving and relocation doesn't work! (Segmentation fault). The reason is that before call update_symbols I need to update the section table first. This will be fixed this week. All the code is attached. Limitation:only support x86 now, need to implement relocation on other arch. Some Q&A: Why I choose implement a loader under Linux? Because the debug is easy, once the loader under Linux completed, it can be easily ported to rtems. Why git? I often have no internet access. So code.google.com is not an idea project hosting place. I choose github. Comments are welcomed. Thanks, JiSheng -------------- next part -------------- A non-text attachment was scrubbed... Name: linker.tar.bz2 Type: application/x-bzip2 Size: 9760 bytes Desc: not available URL: From joel.sherrill at OARcorp.com Sat Jul 4 14:46:07 2009 From: joel.sherrill at OARcorp.com (Joel Sherrill) Date: Sat, 4 Jul 2009 09:46:07 -0500 Subject: Was RTEMS user in Fermilabs Discovery? In-Reply-To: <4A4E7858.1080400@bnl.gov> References: <4A4E6C02.1090009@oarcorp.com> <4A4E7858.1080400@bnl.gov> Message-ID: <4A4F6B2F.4070102@oarcorp.com> D. Peter Siddons wrote: > Hi Joel, > According to the FNAL web site, both D0 and CDF use EPICS as part of > their control system, but I couldn't find any reference to RTEMS. The > new particle came from CDF. The D0 page has info about VxWorks. That > said, many EPICS folks are looking hard at RTEMS as it becomes more > visible in projects like Stanford's LCLS. > I found this document online which is recent and does mention RTEMS with no hint to me as to whether it is really used or in what. http://docdb.fnal.gov/ILC/DocDB/0003/000325/015/NML_ControlsRequirements.doc Hard to know anything. --joel > Pete. > > > Joel Sherrill wrote: > >> Hi, >> >> I saw that Fermilab?s announced the discovery >> of a new particle, the Omega-sub-b (?_b ), and >> wondered if RTEMS and EPICS played a role in >> this. >> >> > > From joel.sherrill at OARcorp.com Sat Jul 4 14:59:58 2009 From: joel.sherrill at OARcorp.com (Joel Sherrill) Date: Sat, 4 Jul 2009 09:59:58 -0500 Subject: [GSOC] Dynamic object file loading status In-Reply-To: <2df346410907031612j6cafcd0o6c80adfdd16b8147@mail.gmail.com> References: <2df346410907031612j6cafcd0o6c80adfdd16b8147@mail.gmail.com> Message-ID: <4A4F6E6E.3090004@oarcorp.com> JiSheng Zhang wrote: > Hi all, > > My coding started on 15 June. It's too late. I hope I can catch up > with other students. > > If you are debugging code, then you are probably on track. :) > As for the project status: > I have implemented a loader under Linux. The code is based on > bionic(android libc) linker, but the object file loading and symbol > resolving and relocation will be rewritten. It seems that object > file loading and parsing, symbol resolving and relocation works fine. > But the object is entirely readed into memory, we only need to load > sections such as .text .data .symtab etc. So I rewrite some code of > the loader, now the resolving and relocation doesn't work! > (Segmentation fault). The reason is that before call update_symbols I > need to update the section table first. This will be fixed this week. > All the code is attached. > Holiday weekend in the States. Hopefully I will get to try it next week when it works. > Limitation:only support x86 now, need to implement relocation on other arch. > > Random comments: + What is the license for Android libc? I recall BSD. Is this right? + What version did you use? Isolate RTEMS specific changes and try to get them as ifdef's into their code base. Document procedure for getting their source and updating it. Getting updates from third party source like this is a fact of life and you need to ensure that it is easy to do so in the future. + The procedure for users creating and loading their own modules must be very clearly documented. > Some Q&A: > Why I choose implement a loader under Linux? Because the debug is > easy, once the loader under Linux completed, it can be easily ported > to rtems. > I think many of us have done the same thing. Many of the posix tests I wrote for RTEMS were developed under Linux first. :) > Why git? I often have no internet access. So code.google.com is not an > idea project hosting place. I choose github. > > code.google.com doesn't have to be your source code control site. But you have to drop code their in the end to get Google to pay you. So putting the intermediate and final drops on their is a good thing. > Comments are welcomed. > > Thanks, > JiSheng > From joel.sherrill at OARcorp.com Sat Jul 4 15:04:13 2009 From: joel.sherrill at OARcorp.com (Joel Sherrill) Date: Sat, 4 Jul 2009 10:04:13 -0500 Subject: Summer of Code Students/Mentors Announcement Message-ID: <4A4F6F6D.8030600@oarcorp.com> Hi, We are at mid-term. Mentors will be doing reviews next week so a payment can be made to you. Students should be submitting progress reports anyway but I would really appreciate a mid-term report to the user's list. I want to collect them and put out an overall mid-term report. --joel From daniel at gaisler.com Sat Jul 4 14:58:38 2009 From: daniel at gaisler.com (Daniel Hellstrom) Date: Sat, 04 Jul 2009 16:58:38 +0200 Subject: Multiprocessor problems In-Reply-To: <4A4E20EB.6020807@oarcorp.com> References: <22282CD520B39B4AB380985121DF4B0E0FFFF4CA68@MAIL03.ug.kth.se> <4A16C4D7.9020800@oarcorp.com> <4A3A0170.7060906@gaisler.com> <4A3A5C62.5080504@oarcorp.com> <4A4B5FD7.7060701@gaisler.com> <4A4E20EB.6020807@oarcorp.com> Message-ID: <4A4F6E1E.9090908@gaisler.com> Joel Sherrill wrote: > Daniel Hellstrom wrote: > >> Hi Joel, >> >> I have attached a patch which introduces a new "early" MP >> initialization routine. This works for SPARC/LEON3 MP. >> >> > > Committed to the head. Does this also need to go on the 4.9 branch? Have not investigated this, am on my summer holidays now until 1:st aug. > > What were you testing with? SPARC/LEON3 Dual Core, 256MB SDRAM, 5 Timers, 2 UARTs, PCI and Ethernet. Booting from RAM using GRMON, and from FLASH using mkprom. Daniel > > --joel > >> Daniel >> >> >> Joel Sherrill wrote: >> >> >> >>> Can you provide a patch Daniel? >>> >>> Daniel Hellstrom wrote: >>> >>> >>> >>>> Hi, >>>> >>>> The problem seems to be the initialization of _Objects_Local_node >>>> in multiprocessor enabled kernels. Since the _MPCI_Initialization() >>>> initializes _Objects_Local_node later than the first semaphores and >>>> tasks are created, this makes the IDs assigned to created objects >>>> incorrect. >>>> >>>> In single processor systems the _Objects_Local_node is a constant >>>> set to 1, but in multiprocessor systems it is initially set to zero >>>> and then initialized by _MPCI_Initialization(). >>>> >>>> The problem you experience is probably the same problem I ran into >>>> this week when running on a dual core SPARC/LEON3 system. Two tasks >>>> are created before the node number is setup correctly. See below >>>> print out from GRMON after breaking at Init(): >>>> >>>> grmon> thread info >>>> >>>> Name | Type | Id | Prio | Time (h:m:s) | Entry >>>> point | PC | >>>> State >>>> --------------------------------------------------------------------------------------------------------------------------------------- >>>> >>>> Int. | internal | 0x09000001 | 255 | 0.000000 | >>>> ?? | 0x0 | READY >>>> --------------------------------------------------------------------------------------------------------------------------------------- >>>> >>>> Int. | classic | 0x09000002 | 0 | 0.000000 | ?? >>>> | 0x0 | Wsem >>>> --------------------------------------------------------------------------------------------------------------------------------------- >>>> >>>> * UI1 | classic | 0x0a010001 | 1 | 0.000000 | >>>> RAM_END | 0x40001368 Init + >>>> 0x4 | READY >>>> --------------------------------------------------------------------------------------------------------------------------------------- >>>> >>>> >>>> As you can see the node number is 0 rather than 1 or 2 in the ID >>>> field. >>>> >>>> The bug appears when the first MPCI packet is received on the >>>> target node, the ISR calls _MCPI_Announce which tries to release a >>>> semaphore, the blocked thread are thought to be global and the >>>> system crashes. The function deciding if it is a global or local >>>> object simply checks if they are of the same node, not if the node >>>> number is zero. >>>> >>>> RTEMS_INLINE_ROUTINE bool _Objects_Is_local_node( >>>> uint32_t node >>>> ) >>>> { >>>> return ( node == _Objects_Local_node ); >>>> } >>>> >>>> To test that this theory holds I changed the declaration of >>>> _Objects_Local_node to extern instead of SCORE_EXTERN, and declared >>>> it in my project initialy initialized to the node number. The LEON3 >>>> dual core system now works and I have successfully managed to get >>>> semaphores and tasks interacting between the two nodes. >>>> >>>> uint16_t _Objects_Local_node = CONFIGURE_MP_NODE_NUMBER; >>>> >>>> >>>> >>>> I suggest that the initialization of _Objects_Local_node is moved >>>> to be initialized earlier. >>>> >>>> Regards, >>>> Daniel Hellstrom >>>> >>>> >>>> >>>> Joel Sherrill wrote: >>>> >>>> >>>> >>>> >>>> >>>>> Roger Dahlkvist wrote: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> Hi, >>>>>> >>>>>> I'm using a timer ISR polling method checking for new messages >>>>>> from other nodes. Unfortunately the system crashes as soon as >>>>>> rtems_multiprocessing_announce is called. >>>>>> >>>>>> >>>>> >>>>> There are no interrupts enabled until the initialization task is >>>>> switched >>>>> in. >>>>> >>>>> I have wondered if it wouldn't make sense to have the MP >>>>> initialization >>>>> sycnhronization done either explicitly by the application (like >>>>> initialization >>>>> of TCP/IP) or implicitly by the init thread like C++ global >>>>> constructors. >>>>> >>>>> You can try moving this code from exinit.c to threadhandler.c >>>>> where and >>>>> protect it somehow from being executed more than once. >>>>> >>>>> #if defined(RTEMS_MULTIPROCESSING) >>>>> if ( _System_state_Is_multiprocessing ) { >>>>> _MPCI_Initialization(); >>>>> _MPCI_Internal_packets_Send_process_packet( >>>>> MPCI_PACKETS_SYSTEM_VERIFY >>>>> ); >>>>> } >>>>> #endif >>>>> >>>>> Then you will at least be able to get your interrupts and call MP >>>>> announce >>>>> to complete system initialization. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> However, rtems_multiprocessing_announce works just fine if it's >>>>>> called just after the initialization phase, before the >>>>>> initinitialization task is started. That's really strange. >>>>>> >>>>>> So for example, if I make one node get initialized and started >>>>>> faster than the other node (using less drivers etc), I'll be able >>>>>> to create global objects. and as long as the other node has not >>>>>> started the initialization task, the message is received and the >>>>>> global objects table is updated, so it can be identified later >>>>>> on. But I can't use them since furter calls to >>>>>> rtems_multiprocessing_announce will fail. >>>>>> >>>>>> At this point I feel like I have tested just about everything, >>>>>> with no luck. It's urgent that I get MP to work properly. I'm >>>>>> using Nios II processors and I have defined my own MPCI routines. >>>>>> I'm confident that they work properly and I have verified that >>>>>> the system crashes before they are even invoked. >>>>>> >>>>>> Is there anyone with MP experience who might have a clue of >>>>>> what's causing my problems? Any help is MUCH appreciated. >>>>>> >>>>>> //Roger >>>>>> >>>>>> _______________________________________________ >>>>>> rtems-users mailing list >>>>>> rtems-users at rtems.org >>>>>> http://www.rtems.org/mailman/listinfo/rtems-users >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >>> >> >> >> > > > From siddons at bnl.gov Sat Jul 4 15:59:45 2009 From: siddons at bnl.gov (D. Peter Siddons) Date: Sat, 04 Jul 2009 11:59:45 -0400 Subject: problem with iostream Message-ID: <4A4F7C71.70003@bnl.gov> I am upgrading my bsp to rtems-4.9 from 4.7. I took the tool rpms. I used alien to make debs and installed them on my Ubuntu Jaunty. I have got to the point where everything seems to build OK until it tries to link the iostream example. I get the following: 272/testsuites/samples/iostream' m68k-rtems4.9-g++ -B../../../../../uC5272/lib/ -specs bsp_specs -qrtems -m5200 -O4 -fomit-frame-pointer -m5200 -o cxx_iostream.exe init.o /opt/rtems-4.9/lib/gcc/m68k-rtems4.9/4.3.2/../../../../m68k-rtems4.9/bin/ld: error: no memory region specified for loadable section `.text._ZSt18__throw_bad_typeidv' collect2: ld returned 1 exit status Any suggestions? Pete. -- D. Peter Siddons Detector Development Group Leader National Synchrotron Light Source Brookhaven National Laboratory Upton, NY 11973 email: siddons at bnl.gov Phone: (631) 344-2738 From joel.sherrill at OARcorp.com Sat Jul 4 16:48:03 2009 From: joel.sherrill at OARcorp.com (Joel Sherrill) Date: Sat, 4 Jul 2009 11:48:03 -0500 Subject: problem with iostream In-Reply-To: <4A4F7C71.70003@bnl.gov> References: <4A4F7C71.70003@bnl.gov> Message-ID: <4A4F87C3.2020903@oarcorp.com> D. Peter Siddons wrote: > I am upgrading my bsp to rtems-4.9 from 4.7. I took the tool rpms. I > used alien to make debs and installed them on my Ubuntu Jaunty. I have > got to the point where everything seems to build OK until it tries to > link the iostream example. I get the following: > > 272/testsuites/samples/iostream' > m68k-rtems4.9-g++ -B../../../../../uC5272/lib/ -specs bsp_specs -qrtems > -m5200 -O4 -fomit-frame-pointer -m5200 -o cxx_iostream.exe init.o > /opt/rtems-4.9/lib/gcc/m68k-rtems4.9/4.3.2/../../../../m68k-rtems4.9/bin/ld: > error: no memory region specified for loadable section > `.text._ZSt18__throw_bad_typeidv' > collect2: ld returned 1 exit status > > Any suggestions? > error: no memory region specified for loadable section Compare the linker scripts in /opt with the one for your BSP. Apparently there is a section not in your linkcmds. > Pete. > > > From strauman at slac.stanford.edu Sun Jul 5 14:35:10 2009 From: strauman at slac.stanford.edu (Till Straumann) Date: Sun, 05 Jul 2009 09:35:10 -0500 Subject: support for PTHREAD_MUTEX_RECURSIVE ? Message-ID: <4A50BA1E.7020303@slac.stanford.edu> It seems that rtems-4.9.2 already implements support for recursive pthread mutexes under the hood and yet there is no static initializer nor pthread_mutexattr_settype()/pthread_mutexattr_gettype(). Wouldn't it be easy and worthwhile to add these? WKR -- Till From joel.sherrill at OARcorp.com Sun Jul 5 15:09:13 2009 From: joel.sherrill at OARcorp.com (Joel Sherrill) Date: Sun, 5 Jul 2009 10:09:13 -0500 Subject: support for PTHREAD_MUTEX_RECURSIVE ? In-Reply-To: <4A50BA1E.7020303@slac.stanford.edu> References: <4A50BA1E.7020303@slac.stanford.edu> Message-ID: <4A50C219.4080807@oarcorp.com> Till Straumann wrote: > It seems that rtems-4.9.2 already implements > support for recursive pthread mutexes under > the hood and yet there is no static initializer > nor pthread_mutexattr_settype()/pthread_mutexattr_gettype(). > Wouldn't it be easy and worthwhile to add these? > > Yes. It has been on the todo list but hasn't made the top. I don't think it would be difficult to implement but it would take a bit of time and require adding a test. The test coverage of the cpukit directories score, sapi, posix and rtems is ~98.5% and we don't want any new features to negatively impact that. --joel > WKR > -- Till > > _______________________________________________ > rtems-users mailing list > rtems-users at rtems.org > http://www.rtems.org/mailman/listinfo/rtems-users > From joel.sherrill at OARcorp.com Mon Jul 6 14:53:27 2009 From: joel.sherrill at OARcorp.com (Joel Sherrill) Date: Mon, 6 Jul 2009 09:53:27 -0500 Subject: support for PTHREAD_MUTEX_RECURSIVE ? In-Reply-To: <4A50BA1E.7020303@slac.stanford.edu> References: <4A50BA1E.7020303@slac.stanford.edu> Message-ID: <4A520FE7.2020007@oarcorp.com> Till Straumann wrote: > It seems that rtems-4.9.2 already implements > support for recursive pthread mutexes under > the hood and yet there is no static initializer > nor pthread_mutexattr_settype()/pthread_mutexattr_gettype(). > Wouldn't it be easy and worthwhile to add these? > > Till I added the basics for supporting these to posix/src along with a switch in pthread_mutex_init. Now it is up to you to translate the types into supercore attributes and provide a test. :-D > WKR > -- Till > > _______________________________________________ > rtems-users mailing list > rtems-users at rtems.org > http://www.rtems.org/mailman/listinfo/rtems-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 From joel.sherrill at OARcorp.com Mon Jul 6 15:17:30 2009 From: joel.sherrill at OARcorp.com (Joel Sherrill) Date: Mon, 6 Jul 2009 10:17:30 -0500 Subject: Summer of Code Mid-Term Report Invite Message-ID: <4A52158A.8060001@oarcorp.com> Hi, I think I just sent all students and mentors an invitation to edit a Google doc for the mid-term report. If you are a SoC student or mentor and didn't get one, I apologize. Please ping me and I will invite you. I was trying to add 14 people from memory. -- 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 From joel.sherrill at OARcorp.com Mon Jul 6 20:20:40 2009 From: joel.sherrill at OARcorp.com (Joel Sherrill) Date: Mon, 6 Jul 2009 15:20:40 -0500 Subject: ALERT GSoC Mid-Term Mentors and Students Message-ID: <4A525C98.8060207@oarcorp.com> Hi, Please visit http://socghop.appspot.com, go to the bottom on the left hand side where the list of things to click on is. Fill out whatever there is to fill out. Mentors and students.. if you have any issues with the webapp or each other or me, just let me know. If the student gets "passed" at the bottom, they get paid. Don't let them down. -- 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 From manuel.coutinho at edisoft.pt Tue Jul 7 08:53:44 2009 From: manuel.coutinho at edisoft.pt (Manuel Coutinho) Date: Tue, 7 Jul 2009 09:53:44 +0100 Subject: Semaphore release - not owner of resource return In-Reply-To: <4A1C8038.9000504@oarcorp.com> References: <000601c9de1a$4f2599b0$680aa8c0@ecmcoutinho> <4A1C8038.9000504@oarcorp.com> Message-ID: <000901c9fee0$6ef15950$680aa8c0@ecmcoutinho> By the way, is there a special reason why locked binary semaphores cannot be deleted and simple binary semaphores can? (just came across this section of the code...) I am thinking of this problem because of PR788 (Priority inheritance mechanism may activate a deleted task). If locked simple binary semaphores and locked binary semaphores are impossible to be deleted, then this bug may be fixed easily (since only these two types of semaphores can have priority inheritance protocol). Thanks Kind regards Manuel Coutinho > -----Original Message----- > From: Joel Sherrill [mailto:joel.sherrill at oarcorp.com] > Sent: Wednesday, May 27, 2009 12:50 AM > To: Manuel Coutinho > Cc: rtems-users at rtems.com > Subject: Re: Semaphore release - not owner of resource return > > Manuel Coutinho wrote: > > > > Hi > > > > > > > > Was checking some RTEMS code and stumbled upon the error > > RTEMS_NOT_OWNER_OF_RESOURCE when we do a semaphore release -> threadA > > obtains a semaphore and threadB releases it. > > > > From what I understood, this error can only happen with a binary > > semaphore with priority inherence or ceiling. > > > > > > > > > > > > extract of the rtems_semaphore_create directive: > > > > > > > > if ( _Attributes_Is_*binary*_semaphore( attribute_set ) ) { > > > > the_mutex_attributes.lock_nesting_behavior = > > CORE_MUTEX_NESTING_ACQUIRES; > > > > > > > > switch ( the_mutex_attributes.discipline ) { > > > > case CORE_MUTEX_DISCIPLINES_FIFO: > > > > case CORE_MUTEX_DISCIPLINES_PRIORITY: > > > > the_mutex_attributes.only_owner_release = FALSE; > > > > break; > > > > case CORE_MUTEX_DISCIPLINES_PRIORITY_CEILING: > > > > case CORE_MUTEX_DISCIPLINES_PRIORITY_INHERIT: > > > > the_mutex_attributes.only_owner_release = TRUE; > > > > break; > > > > } > > > > } > > > > > > > > My question is: why does this give an error with binary and not with > > simple binaries? > > > > > > > > From what I understand about this functionality, a use for this could > > be when the thread (threadA) is taking a long time or is in error and > > another thread (threadB) tries to release all the semaphores that > > threadA obtained and afterwards wants to delete threadA (or something > > of the sort). So this, in principle, could be valid for both binary > > and simple binary semaphores, no? > > > > > > > > Is there an implementation issue as to why this is not possible to do > > with binary semaphores (am just guessing, but if this is possible with > > simple binary.why not with binary)? > > > Simple binary are used by applications to do condition synchronization. > This > means the sem is created locked, taskA blocks waiting for signal > (unlock) and > an isr or taskB unlocks it to unblock taskA. By design and intention, the > task that locks is NEVER the unlocking task. > > In contrast RTEMS binary semaphores (e.g. mutexes) are used for critical > sections (a.k.a. mutual exclusion) and are always locked/unlocked by the > same thread. > > > > > > > > Thanks > > > > Kind Regards > > > > Manuel Coutinho > > From joel.sherrill at OARcorp.com Tue Jul 7 12:03:26 2009 From: joel.sherrill at OARcorp.com (Joel Sherrill) Date: Tue, 7 Jul 2009 07:03:26 -0500 Subject: Semaphore release - not owner of resource return In-Reply-To: <000901c9fee0$6ef15950$680aa8c0@ecmcoutinho> References: <000601c9de1a$4f2599b0$680aa8c0@ecmcoutinho> <4A1C8038.9000504@oarcorp.com> <000901c9fee0$6ef15950$680aa8c0@ecmcoutinho> Message-ID: <4A53398E.3070708@oarcorp.com> Manuel Coutinho wrote: > By the way, is there a special reason why locked binary semaphores cannot be > deleted and simple binary semaphores can? (just came across this section of > the code...) > The general thinking is that when locked they indicate some task is in a critical section. If you delete them, then you are potentially negatively impacting that critical section. There may also have been some discussion of how do you deal with any inherited priority. In general it avoids dealing with complicated side-effects of cleaning up. Simple binary semaphores are used for condition synchronization --not critical sections. They are locked when a task is waiting on someone to announce a condition (e.g. often an ISR occurred). The task waiting will naturally wake up with RTEMS_OBJECT_WAS_DELETED. So this one takes care of itself in a natural and clean way. > I am thinking of this problem because of PR788 (Priority inheritance > mechanism may activate a deleted task). > > If locked simple binary semaphores and locked binary semaphores are > impossible to be deleted, then this bug may be fixed easily (since only > these two types of semaphores can have priority inheritance protocol). > > Simple binary can't have inheritance or ceiling. Only true binary. But go on... explain your idea. > Thanks > Kind regards > Manuel Coutinho > > >> -----Original Message----- >> From: Joel Sherrill [mailto:joel.sherrill at oarcorp.com] >> Sent: Wednesday, May 27, 2009 12:50 AM >> To: Manuel Coutinho >> Cc: rtems-users at rtems.com >> Subject: Re: Semaphore release - not owner of resource return >> >> Manuel Coutinho wrote: >> >>> Hi >>> >>> >>> >>> Was checking some RTEMS code and stumbled upon the error >>> RTEMS_NOT_OWNER_OF_RESOURCE when we do a semaphore release -> threadA >>> obtains a semaphore and threadB releases it. >>> >>> From what I understood, this error can only happen with a binary >>> semaphore with priority inherence or ceiling. >>> >>> >>> >>> >>> >>> extract of the rtems_semaphore_create directive: >>> >>> >>> >>> if ( _Attributes_Is_*binary*_semaphore( attribute_set ) ) { >>> >>> the_mutex_attributes.lock_nesting_behavior = >>> CORE_MUTEX_NESTING_ACQUIRES; >>> >>> >>> >>> switch ( the_mutex_attributes.discipline ) { >>> >>> case CORE_MUTEX_DISCIPLINES_FIFO: >>> >>> case CORE_MUTEX_DISCIPLINES_PRIORITY: >>> >>> the_mutex_attributes.only_owner_release = FALSE; >>> >>> break; >>> >>> case CORE_MUTEX_DISCIPLINES_PRIORITY_CEILING: >>> >>> case CORE_MUTEX_DISCIPLINES_PRIORITY_INHERIT: >>> >>> the_mutex_attributes.only_owner_release = TRUE; >>> >>> break; >>> >>> } >>> >>> } >>> >>> >>> >>> My question is: why does this give an error with binary and not with >>> simple binaries? >>> >>> >>> >>> From what I understand about this functionality, a use for this could >>> be when the thread (threadA) is taking a long time or is in error and >>> another thread (threadB) tries to release all the semaphores that >>> threadA obtained and afterwards wants to delete threadA (or something >>> of the sort). So this, in principle, could be valid for both binary >>> and simple binary semaphores, no? >>> >>> >>> >>> Is there an implementation issue as to why this is not possible to do >>> with binary semaphores (am just guessing, but if this is possible with >>> simple binary.why not with binary)? >>> >>> >> Simple binary are used by applications to do condition synchronization. >> This >> means the sem is created locked, taskA blocks waiting for signal >> (unlock) and >> an isr or taskB unlocks it to unblock taskA. By design and intention, the >> task that locks is NEVER the unlocking task. >> >> In contrast RTEMS binary semaphores (e.g. mutexes) are used for critical >> sections (a.k.a. mutual exclusion) and are always locked/unlocked by the >> same thread. >> >>> >>> Thanks >>> >>> Kind Regards >>> >>> Manuel Coutinho >>> >>> > > > From manuel.coutinho at edisoft.pt Tue Jul 7 16:11:54 2009 From: manuel.coutinho at edisoft.pt (Manuel Coutinho) Date: Tue, 7 Jul 2009 17:11:54 +0100 Subject: Semaphore release - not owner of resource return In-Reply-To: <4A53398E.3070708@oarcorp.com> References: <000601c9de1a$4f2599b0$680aa8c0@ecmcoutinho> <4A1C8038.9000504@oarcorp.com> <000901c9fee0$6ef15950$680aa8c0@ecmcoutinho> <4A53398E.3070708@oarcorp.com> Message-ID: <000d01c9ff1d$a5141120$680aa8c0@ecmcoutinho> Ok :) Now I understand: Simple binary semaphores cannot have priority inheritance or ceiling. But RTEMS is currently allowing this. A simple binary semaphore can be created with one of priority protocols and the holder threads priority is increased/decreased accordingly. Suppose this is a bug of RTEMS then: do not allow creation of simple binary semaphores with priority ceiling or priority inheritance protocols. Regarding bug PR788, forget my previous suggestion. My mind was not good at the time! However, had another "solution": When a thread is deleted, all the semaphores it holds are set free. This is actually the same behavior as specified in ARINC 653. Of course, some modifications have to be performed to accomplish this. But is there any special reason not to implement this behavior (apart from the O(n) complexity issue)? Kind regards Manuel Coutinho > -----Original Message----- > From: Joel Sherrill [mailto:joel.sherrill at oarcorp.com] > Sent: Tuesday, July 07, 2009 1:03 PM > To: Manuel Coutinho > Cc: rtems-users at rtems.com > Subject: Re: Semaphore release - not owner of resource return > > Manuel Coutinho wrote: > > By the way, is there a special reason why locked binary semaphores > cannot be > > deleted and simple binary semaphores can? (just came across this section > of > > the code...) > > > > The general thinking is that when locked they indicate > some task is in a critical section. If you delete them, then > you are potentially negatively impacting that critical > section. > > There may also have been some discussion of how do you > deal with any inherited priority. > > In general it avoids dealing with complicated side-effects > of cleaning up. > > Simple binary semaphores are used for condition > synchronization --not critical sections. They are locked > when a task is waiting on someone to announce a > condition (e.g. often an ISR occurred). The task waiting will > naturally wake up with RTEMS_OBJECT_WAS_DELETED. > So this one takes care of itself in a natural and clean way. > > I am thinking of this problem because of PR788 (Priority inheritance > > mechanism may activate a deleted task). > > > > If locked simple binary semaphores and locked binary semaphores are > > impossible to be deleted, then this bug may be fixed easily (since only > > these two types of semaphores can have priority inheritance protocol). > > > > > Simple binary can't have inheritance or ceiling. Only > true binary. > > But go on... explain your idea. > > Thanks > > Kind regards > > Manuel Coutinho > > > > > >> -----Original Message----- > >> From: Joel Sherrill [mailto:joel.sherrill at oarcorp.com] > >> Sent: Wednesday, May 27, 2009 12:50 AM > >> To: Manuel Coutinho > >> Cc: rtems-users at rtems.com > >> Subject: Re: Semaphore release - not owner of resource return > >> > >> Manuel Coutinho wrote: > >> > >>> Hi > >>> > >>> > >>> > >>> Was checking some RTEMS code and stumbled upon the error > >>> RTEMS_NOT_OWNER_OF_RESOURCE when we do a semaphore release -> threadA > >>> obtains a semaphore and threadB releases it. > >>> > >>> From what I understood, this error can only happen with a binary > >>> semaphore with priority inherence or ceiling. > >>> > >>> > >>> > >>> > >>> > >>> extract of the rtems_semaphore_create directive: > >>> > >>> > >>> > >>> if ( _Attributes_Is_*binary*_semaphore( attribute_set ) ) { > >>> > >>> the_mutex_attributes.lock_nesting_behavior = > >>> CORE_MUTEX_NESTING_ACQUIRES; > >>> > >>> > >>> > >>> switch ( the_mutex_attributes.discipline ) { > >>> > >>> case CORE_MUTEX_DISCIPLINES_FIFO: > >>> > >>> case CORE_MUTEX_DISCIPLINES_PRIORITY: > >>> > >>> the_mutex_attributes.only_owner_release = FALSE; > >>> > >>> break; > >>> > >>> case CORE_MUTEX_DISCIPLINES_PRIORITY_CEILING: > >>> > >>> case CORE_MUTEX_DISCIPLINES_PRIORITY_INHERIT: > >>> > >>> the_mutex_attributes.only_owner_release = TRUE; > >>> > >>> break; > >>> > >>> } > >>> > >>> } > >>> > >>> > >>> > >>> My question is: why does this give an error with binary and not with > >>> simple binaries? > >>> > >>> > >>> > >>> From what I understand about this functionality, a use for this could > >>> be when the thread (threadA) is taking a long time or is in error and > >>> another thread (threadB) tries to release all the semaphores that > >>> threadA obtained and afterwards wants to delete threadA (or something > >>> of the sort). So this, in principle, could be valid for both binary > >>> and simple binary semaphores, no? > >>> > >>> > >>> > >>> Is there an implementation issue as to why this is not possible to do > >>> with binary semaphores (am just guessing, but if this is possible with > >>> simple binary.why not with binary)? > >>> > >>> > >> Simple binary are used by applications to do condition synchronization. > >> This > >> means the sem is created locked, taskA blocks waiting for signal > >> (unlock) and > >> an isr or taskB unlocks it to unblock taskA. By design and intention, > the > >> task that locks is NEVER the unlocking task. > >> > >> In contrast RTEMS binary semaphores (e.g. mutexes) are used for > critical > >> sections (a.k.a. mutual exclusion) and are always locked/unlocked by > the > >> same thread. > >> > >>> > >>> Thanks > >>> > >>> Kind Regards > >>> > >>> Manuel Coutinho > >>> > >>> > > > > > > From roxana.leontie at gmail.com Thu Jul 9 16:47:44 2009 From: roxana.leontie at gmail.com (Roxana Leontie) Date: Thu, 9 Jul 2009 12:47:44 -0400 Subject: anybody is using fb_vga? Message-ID: Hi, For those of you who don't know me I an the student working on the Nano-X project. I want to know if anyone (or an application that you are aware of - except Nano-X) that is using fb_vga? I want to make sure I am not breaking any interface with my changes. Roxana -------------- next part -------------- An HTML attachment was scrubbed... URL: From jszhang3 at gmail.com Thu Jul 9 19:34:48 2009 From: jszhang3 at gmail.com (JiSheng Zhang) Date: Fri, 10 Jul 2009 03:34:48 +0800 Subject: [GSOC]Dynamic object file loading:basic working version Message-ID: <2df346410907091234p446e6af1q50ec9dfe4228e305@mail.gmail.com> Hi all, Now basic symbol resolving and relocation works! The code is attached. For test just make and then ./demo -l ./t.o -s get. If you should see something like "******5******" plus various debug message. Explanation: t.c looks like this: /*****************/ int ttt=5; int get() { return ttt; } /****************/ so t.o should have at least one relocation and two symbols. readelf -S t.o and readelf -s t.o prove this. the dynamic linker load t.o and parsing it, then it loading all needed sections, finally it will do symbol resolving and relocation. For test I just point entry to the start of ".text" that is get function, then call this function via entry, we should get the result:5 TODO next week: 1.lookup external symbol which is exported by demo 2.support symbol resolving exported by object file which is dynamic loaded Regards, JiSheng -------------- next part -------------- A non-text attachment was scrubbed... Name: objdl.tar.gz Type: application/x-gzip Size: 9972 bytes Desc: not available URL: From joel.sherrill at OARcorp.com Thu Jul 9 19:57:17 2009 From: joel.sherrill at OARcorp.com (Joel Sherrill) Date: Thu, 9 Jul 2009 14:57:17 -0500 Subject: [GSOC]Dynamic object file loading:basic working version In-Reply-To: <2df346410907091234p446e6af1q50ec9dfe4228e305@mail.gmail.com> References: <2df346410907091234p446e6af1q50ec9dfe4228e305@mail.gmail.com> Message-ID: <4A564B9D.3090507@oarcorp.com> Good job! Random questions: + unload_library isn't implemented yet in the linker.c + does the loaded library get a call to initialize itself? + will you need some help getting a comparable demo application on RTEMS? + The code uses at least pthread_mutex. This means that it will require POSIX to be enabled in RTEMS. Is this the only thing forcing RTEMS POSIX thread support to be enabled? [NOTE: I don't know if this is a big deal or not. at this point, it is just a requirement on the code.] + Is this really as self-contained as it looks? :-D And can you update the google docs page that has the general SoC Status for all RTEMS projects? If I didn't send you permission, just ping me and I will add you. --joel JiSheng Zhang wrote: > Hi all, > Now basic symbol resolving and relocation works! The code is attached. > For test just make and then ./demo -l ./t.o -s get. If you should see > something like "******5******" plus various debug message. > Explanation: > t.c looks like this: > /*****************/ > int ttt=5; > int get() > { > return ttt; > > } > /****************/ > so t.o should have at least one relocation and two symbols. readelf -S > t.o and readelf -s t.o prove this. > the dynamic linker load t.o and parsing it, then it loading all needed > sections, finally it will do symbol resolving and relocation. > > For test I just point entry to the start of ".text" that is get > function, then call this function via entry, we should get the > result:5 > > TODO next week: > 1.lookup external symbol which is exported by demo > 2.support symbol resolving exported by object file which is dynamic loaded > > Regards, > JiSheng > -- 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 From jszhang3 at gmail.com Fri Jul 10 04:21:36 2009 From: jszhang3 at gmail.com (JiSheng Zhang) Date: Fri, 10 Jul 2009 12:21:36 +0800 Subject: [GSOC]Dynamic object file loading:basic working version In-Reply-To: <4A564B9D.3090507@oarcorp.com> References: <2df346410907091234p446e6af1q50ec9dfe4228e305@mail.gmail.com> <4A564B9D.3090507@oarcorp.com> Message-ID: <2df346410907092121o455b76e7wd0878d67dab7d068@mail.gmail.com> Hi Dr.Joel, 2009/7/10 Joel Sherrill : > Good job! > > Random questions: > > + unload_library isn't implemented yet in the linker.c on TODO list, it's simple;) > + does the loaded library get a call to initialize itself? Do you mean the initialization used for constructor in c++? Will be added in next week. > + will you need some help getting a comparable demo > ?application on RTEMS? Thanks, Once I come across a problem, I will ask on maillist > + The code uses at least pthread_mutex. ?This means that > ?it will require POSIX to be enabled in RTEMS. ?Is this the > ?only thing forcing RTEMS POSIX thread support to be > ?enabled? ?[NOTE: I don't know if this is a big deal or not. > ?at this point, it is just a requirement on the code.] Hmmm, pthread_mutex can be replaced by rtems_semapohore, the real problem is that the code uses open\read\lseek etc. Are these functions included in POSIX? Are there rtems' native functions? > + Is this really as self-contained as it looks? :-D > > And can you update the google docs page that has > the general SoC Status for all RTEMS projects? ?If OK, I will update it tonight or tomorrow > I didn't send you permission, just ping me and I > will add you. > > --joel Regards, JiSheng From sebastian.huber at embedded-brains.de Fri Jul 10 12:04:25 2009 From: sebastian.huber at embedded-brains.de (Sebastian Huber) Date: Fri, 10 Jul 2009 14:04:25 +0200 Subject: RFC: Interrupt Manager Extension changes Message-ID: <4A572E49.4040407@embedded-brains.de> Hi, the Interrupt Manager Extension is documented here: http://www.rtems.com/doxygen/cpukit/html/group__rtems__interrupt__extension.html In order to support the legacy API and FreeBSD interrupt handlers better I would like to change the interrupt handler signature from typedef void (*rtems_interrupt_handler)(rtems_vector_number, void *); to typedef void (*rtems_interrupt_handler)(void *); The current signature was primarily chosen to support the Classic API in the future without overhead. This turned out to be impractical. I would also like to change the return code for requests with an invalid vector number from RTEMS_INVALID_NUMBER to RTEMS_INVALID_ID since the vector number acts like an object ID in this context. I would like to add a new API for interrupt handlers which should be executed within a task context: /** * @brief Initializes the interrupt server task. * * The task will have the priority @a priority, the stack size @a stack_size, * the modes @a modes and the attributes @a attributes. Interrupt handlers can * be installed on the server with rtems_interrupt_server_handler_install() and * removed with rtems_interrupt_server_handler_remove(). In case of an * interrupt the request will be forwarded to the server. The handlers are * executed within the server context. If one handler blocks on something this * may delay the processing of other handlers. * * @note This function may block. * * @return * - On success @c RTEMS_SUCCESSFUL shall be returned. * - If the interrupt server task is already initialized * @c RTEMS_INCORRECT_STATE shall be returned. * - Other error states are BSP specific. */ rtems_status_code rtems_interrupt_server_initialize( rtems_task_priority priority, size_t stack_size, rtems_mode modes, rtems_attribute attributes ); /** * @brief Installs the interrupt handler routine @a handler for the interrupt * vector with number @a vector. * * The handler routine will be executed on the interrupt server task. * * @note This function may block. * * @see rtems_interrupt_handler_install(). * * @return * - On success @c RTEMS_SUCCESSFUL shall be returned. * - If the interrupt handler server is not initialized * @c RTEMS_INCORRECT_STATE shall be returned. * - For other errors see rtems_interrupt_handler_install(). */ rtems_status_code rtems_interrupt_server_handler_install( rtems_vector_number vector, const char *info, rtems_option options, rtems_interrupt_handler handler, void *arg ); /** * @brief Removes the interrupt handler routine @a handler with argument @a arg * for the interrupt vector with number @a vector. * * @note This function may block. * * @see rtems_interrupt_handler_remove(). * * @return * - On success @c RTEMS_SUCCESSFUL shall be returned. * - If the interrupt handler server is not initialized * @c RTEMS_INCORRECT_STATE shall be returned. * - For other errors see rtems_interrupt_handler_remove(). */ rtems_status_code rtems_interrupt_server_handler_remove( rtems_vector_number vector, rtems_interrupt_handler handler, void *arg ); 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 at embedded-brains.de PGP : Public key available on request Diese Nachricht ist keine gesch?ftliche Mitteilung im Sinne des EHUG. From strauman at slac.stanford.edu Fri Jul 10 15:50:40 2009 From: strauman at slac.stanford.edu (Till Straumann) Date: Fri, 10 Jul 2009 10:50:40 -0500 Subject: RFC: Interrupt Manager Extension changes In-Reply-To: <4A572E49.4040407@embedded-brains.de> References: <4A572E49.4040407@embedded-brains.de> Message-ID: <4A576350.3040803@slac.stanford.edu> I like the idea of a facility to let interrupt handlers execute from a task context. However, IMO it would be far more flexible and useful if there was not just one server task (which still could be the default) but if when installing the ISR one could optionally request a new/separate task (with desired priority etc.). -- Till Sebastian Huber wrote: > Hi, > > the Interrupt Manager Extension is documented here: > > http://www.rtems.com/doxygen/cpukit/html/group__rtems__interrupt__extension.html > > In order to support the legacy API and FreeBSD interrupt handlers better I > would like to change the interrupt handler signature from > > typedef void (*rtems_interrupt_handler)(rtems_vector_number, void *); > > to > > typedef void (*rtems_interrupt_handler)(void *); > > The current signature was primarily chosen to support the Classic API in the > future without overhead. This turned out to be impractical. > > I would also like to change the return code for requests with an invalid vector > number from RTEMS_INVALID_NUMBER to RTEMS_INVALID_ID since the vector number > acts like an object ID in this context. > > I would like to add a new API for interrupt handlers which should be executed > within a task context: > > /** > * @brief Initializes the interrupt server task. > * > * The task will have the priority @a priority, the stack size @a stack_size, > * the modes @a modes and the attributes @a attributes. Interrupt handlers can > * be installed on the server with rtems_interrupt_server_handler_install() and > * removed with rtems_interrupt_server_handler_remove(). In case of an > * interrupt the request will be forwarded to the server. The handlers are > * executed within the server context. If one handler blocks on something this > * may delay the processing of other handlers. > * > * @note This function may block. > * > * @return > * - On success @c RTEMS_SUCCESSFUL shall be returned. > * - If the interrupt server task is already initialized > * @c RTEMS_INCORRECT_STATE shall be returned. > * - Other error states are BSP specific. > */ > rtems_status_code rtems_interrupt_server_initialize( > rtems_task_priority priority, > size_t stack_size, > rtems_mode modes, > rtems_attribute attributes > ); > > /** > * @brief Installs the interrupt handler routine @a handler for the interrupt > * vector with number @a vector. > * > * The handler routine will be executed on the interrupt server task. > * > * @note This function may block. > * > * @see rtems_interrupt_handler_install(). > * > * @return > * - On success @c RTEMS_SUCCESSFUL shall be returned. > * - If the interrupt handler server is not initialized > * @c RTEMS_INCORRECT_STATE shall be returned. > * - For other errors see rtems_interrupt_handler_install(). > */ > rtems_status_code rtems_interrupt_server_handler_install( > rtems_vector_number vector, > const char *info, > rtems_option options, > rtems_interrupt_handler handler, > void *arg > ); > > /** > * @brief Removes the interrupt handler routine @a handler with argument @a arg > * for the interrupt vector with number @a vector. > * > * @note This function may block. > * > * @see rtems_interrupt_handler_remove(). > * > * @return > * - On success @c RTEMS_SUCCESSFUL shall be returned. > * - If the interrupt handler server is not initialized > * @c RTEMS_INCORRECT_STATE shall be returned. > * - For other errors see rtems_interrupt_handler_remove(). > */ > rtems_status_code rtems_interrupt_server_handler_remove( > rtems_vector_number vector, > rtems_interrupt_handler handler, > void *arg > ); > > Have a nice day! > > From hiyangxi at gmail.com Sat Jul 11 05:27:34 2009 From: hiyangxi at gmail.com (xi yang) Date: Sat, 11 Jul 2009 15:27:34 +1000 Subject: [GSOC2009] Skyeye shutdown device patch for 1.2.8 branch of SKYEYE Message-ID: <552cfe40907102227kc8f5789jf4579135ddc5750d@mail.gmail.com> Index: device/nandflash/nandflash_smallblock.c =================================================================== --- device/nandflash/nandflash_smallblock.c (revision 691) +++ device/nandflash/nandflash_smallblock.c (working copy) @@ -516,7 +516,7 @@ #endif nf->writebuffer=(u8*)malloc(dev->pagedumpsize); //nf->memsize=528*32*4096; - if ((nf->fdump= open(dev->dump, FILE_FLAG)) < 0) + if ((nf->fdump= open(dev->dump, FILE_FLAG, FILE_MODE)) < 0) { free(nf); printf("error open nandflash dump!\n"); Index: device/nandflash/nandflash_smallblock.h =================================================================== --- device/nandflash/nandflash_smallblock.h (revision 691) +++ device/nandflash/nandflash_smallblock.h (working copy) @@ -27,6 +27,8 @@ #define FILE_FLAG (O_RDWR | O_CREAT) #endif +#define FILE_MODE (0x777) + #if (defined(__MINGW32__) || defined(__BEOS__)) #define POSIX_SHARE_MEMORY_BROKEN #endif Index: memory/ram.c =================================================================== --- memory/ram.c (revision 691) +++ memory/ram.c (working copy) @@ -261,10 +261,10 @@ void * state; switch(size){ case 8: - *(uint8_t *)value = (uint8_t)mem_read_byte (offset); + *value = (uint8_t)mem_read_byte (offset); break; case 16: - *(uint16_t *)value = (uint16_t)mem_read_halfword(offset); + *value = (uint16_t)mem_read_halfword(offset); break; case 32: *value = mem_read_word(offset); Index: arch/arm/common/armemu.c =================================================================== --- arch/arm/common/armemu.c (revision 691) +++ arch/arm/common/armemu.c (working copy) @@ -676,7 +676,15 @@ } io_do_cycle (state); state->NumInstrs++; - + if (skyeye_config.shutdown_device.status){ + if (skyeye_config.shutdown_device.max_ins){ + if (state->NumInstrs >= skyeye_config.shutdown_device.max_ins){ + fprintf(stderr, "Shutdown_device:max_ins expired\n"); + exit(2); + } + } + } + #ifdef MODET /* Provide Thumb instruction decoding. If the processor is in Thumb mode, then we can simply decode the Thumb instruction, and map it @@ -5069,6 +5077,11 @@ MEM_STORE_LOG("WORD"); BUSUSEDINCPCN; + + if(skyeye_config.shutdown_device.status){ + if(address == skyeye_config.shutdown_device.shutdown_addr) + exit(0); + } #ifndef MODE32 if (DESTReg == 15) state->Reg[15] = ECC | ER15INT | R15PC | EMODE; Index: utils/config/skyeye_config.h =================================================================== --- utils/config/skyeye_config.h (revision 691) +++ utils/config/skyeye_config.h (working copy) @@ -100,6 +100,21 @@ } machine_config_t; +/* + * If status of shutdown device is 1, when "shutdown_addr" + * (align on 8bytes) is written, SKYEYE simulator exits. + * If the number of executed instructions by skyeye simulator + * is bigger than "max_instructions", then skyeye return with + * value 2 +*/ +typedef struct shutdown_config +{ + unsigned int status; + u32 shutdown_addr; + unsigned long long max_ins; +}shutdown_config_t; + + #define MAX_BANK 8 #define MAX_STR 1024 @@ -183,6 +198,7 @@ int do_dummy_option (); int do_arch_option (); int do_cpu_option (); +int do_shutdown_option (); int do_mach_option (); int do_mem_bank_option (); int do_net_option (); @@ -248,6 +264,7 @@ //mem_config_t mem; //chy 2003-09-12, now support more io banks // ioaddr_config_t ioaddr; //used for ARMul_notIOaddr funciton + shutdown_config_t shutdown_device; net_config_t net[NET_MAXNICNUM_PER_HOST]; uart_config_t uart; log_config_t log; @@ -280,10 +297,12 @@ {"arch", do_arch_option, 0, 1}, {"cpu", do_cpu_option, 0, 1}, {"mach", do_mach_option, 0, 1}, + {"shutdown_device", do_shutdown_option,0, 1}, /*mem option */ {"mem_bank", do_mem_bank_option, 0, MAX_BANK}, + {"net", do_net_option, 0, 10}, {"energy", do_energy_option, 0, 1}, {"uart", do_uart_option, 0, MAX_UART_DEVICE_NUM}, Index: utils/config/skyeye_options.c =================================================================== --- utils/config/skyeye_options.c (revision 691) +++ utils/config/skyeye_options.c (working copy) @@ -79,6 +79,9 @@ config->uart.count = 0; atexit(skyeye_uart_cleanup); + config->shutdown_device.status = 0; + config->shutdown_device.max_ins = 0; + /*ywc 2005-04-01 */ config->no_dbct = 1; /*default, dbct is off */ //teawater add for new tb manage function 2005.07.10---------------------------- @@ -247,6 +250,44 @@ } int +do_shutdown_option (skyeye_option_t * this_option, int num_params, + const char *params[]) +{ + int ret; + char *value; + shutdown_config_t *shutdown = &(skyeye_config.shutdown_device); + if(ret = strncmp(params[0],"addr=",5)){ + SKYEYE_ERR ("Error, Wrong parameter for shutdown_device\n"); + return -1; + } + value = &(params[0][5]); + if(value[0]=='0' && (value[1] == 'x' || value[1] == 'X')) + shutdown->shutdown_addr = (unsigned int)strtoul(value,NULL,16); + else + shutdown->shutdown_addr = (unsigned int)strtoul(value,NULL,10); + if(shutdown->shutdown_addr & 0x7){ + SKYEYE_ERR ("Error, shutdown address needs align on 8 bytes\n"); + return -1; + } + + if(ret = strncmp(params[1],"max_ins=",8)){ + SKYEYE_ERR ("Error, Wrong parameter for shutdown_device\n"); + return -1; + } + value = &(params[1][8]); + if(value[0]=='0' && (value[1] == 'x' || value[1] == 'X')) + shutdown->max_ins = strtoull(value,NULL,16); + else + shutdown->max_ins = strtoull(value,NULL,10); + + shutdown->status = 1; + + printf("Shutdown addr=%x, max_ins=%x\n",shutdown->shutdown_addr,shutdown->max_ins); + return 1; +} + + +int do_mem_bank_option (skyeye_option_t * this_option, int num_params, const char *params[]) { From sebastian.huber at embedded-brains.de Mon Jul 13 07:55:08 2009 From: sebastian.huber at embedded-brains.de (Sebastian Huber) Date: Mon, 13 Jul 2009 09:55:08 +0200 Subject: RFC: Interrupt Manager Extension changes In-Reply-To: <4A576350.3040803@slac.stanford.edu> References: <4A572E49.4040407@embedded-brains.de> <4A576350.3040803@slac.stanford.edu> Message-ID: <4A5AE85C.1030704@embedded-brains.de> Till Straumann wrote: > I like the idea of a facility to let interrupt handlers execute > from a task context. > > However, IMO it would be far more flexible and useful if there was not > just one server task (which still could be the default) but if > when installing the ISR one could optionally request a new/separate > task (with desired priority etc.). [...] Yes, this is indeed more useful. I added a server identifier, so that you can install the handlers on a particular server. Some problems: Do we want a default server? How do we initialize the default server? How do we refer to the default server? At the moment we have one default server which is identified by RTEMS_ID_NONE. In case of more than one running server it is implementation dependent which one is the default server. A simple implementation may look like: One task, one counting semaphore and one list for each server. The interrupt handler disables the corresponding interrupt vector on the interrupt controller, adds one item to the list and increments the counting semaphore. The server continuously decrements the semaphore and fetches one item at a time. It processes the item and enables the corresponding interrupt vector on the interrupt controller afterwards. If we want so support shared interrupts, we need also a counter for each vector to count the number of shared server handlers per vector. This ensures that we only enable the vector if each handler was processed. /** * @brief Initializes an interrupt server task. * * The task will have the priority @a priority, the stack size @a stack_size, * the modes @a modes and the attributes @a attributes. The identifier of the * server task will be returned in @a server. Interrupt handlers can be * installed on the server with rtems_interrupt_server_handler_install() and * removed with rtems_interrupt_server_handler_remove() using this identifier. * In case of an interrupt the request will be forwarded to the server. The * handlers are executed within the server context. If one handler blocks on * something this may delay the processing of other handlers. * * @note This function may block. * * @return * - On success @c RTEMS_SUCCESSFUL shall be returned. * - If the @a server pointer is @c NULL @c RTEMS_INVALID_ADDRESS shall be * returned. * - Other error states are BSP specific. */ rtems_status_code rtems_interrupt_server_initialize( rtems_task_priority priority, size_t stack_size, rtems_mode modes, rtems_attribute attributes, rtems_id *server ); /** * @brief Installs the interrupt handler routine @a handler for the interrupt * vector with number @a vector on the server @a server. * * The handler routine will be executed on the corresponding interrupt server * task. A server identifier of @c RTEMS_ID_NONE may be used to install the * handler on some available server. * * @note This function may block. * * @see rtems_interrupt_handler_install(). * * @return * - On success @c RTEMS_SUCCESSFUL shall be returned. * - If the interrupt handler server is not initialized * @c RTEMS_INCORRECT_STATE shall be returned. * - For other errors see rtems_interrupt_handler_install(). */ rtems_status_code rtems_interrupt_server_handler_install( rtems_id server, rtems_vector_number vector, const char *info, rtems_option options, rtems_interrupt_handler handler, void *arg ); /** * @brief Removes the interrupt handler routine @a handler with argument @a arg * for the interrupt vector with number @a vector from the server @a server. * * @note This function may block. * * @see rtems_interrupt_handler_remove(). * * @return * - On success @c RTEMS_SUCCESSFUL shall be returned. * - If the interrupt handler server is not initialized * @c RTEMS_INCORRECT_STATE shall be returned. * - For other errors see rtems_interrupt_handler_remove(). */ rtems_status_code rtems_interrupt_server_handler_remove( rtems_id server, rtems_vector_number vector, rtems_interrupt_handler handler, void *arg ); -- 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 at embedded-brains.de PGP : Public key available on request Diese Nachricht ist keine gesch?ftliche Mitteilung im Sinne des EHUG. From sebastian.huber at embedded-brains.de Mon Jul 13 07:58:57 2009 From: sebastian.huber at embedded-brains.de (Sebastian Huber) Date: Mon, 13 Jul 2009 09:58:57 +0200 Subject: RFC: Interrupt Manager Extension changes In-Reply-To: <4A5AE85C.1030704@embedded-brains.de> References: <4A572E49.4040407@embedded-brains.de> <4A576350.3040803@slac.stanford.edu> <4A5AE85C.1030704@embedded-brains.de> Message-ID: <4A5AE941.7@embedded-brains.de> Sebastian Huber wrote: > Till Straumann wrote: >> I like the idea of a facility to let interrupt handlers execute >> from a task context. >> >> However, IMO it would be far more flexible and useful if there was not >> just one server task (which still could be the default) but if >> when installing the ISR one could optionally request a new/separate >> task (with desired priority etc.). > [...] > > Yes, this is indeed more useful. I added a server identifier, so that you can > install the handlers on a particular server. Some problems: > > Do we want a default server? > How do we initialize the default server? > How do we refer to the default server? Maybe we can use the NULL pointer for @a server in rtems_interrupt_server_initialize() for the default server initialization. -- 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 at embedded-brains.de PGP : Public key available on request Diese Nachricht ist keine gesch?ftliche Mitteilung im Sinne des EHUG. From kenneth.j.peters at jpl.nasa.gov Mon Jul 13 15:16:30 2009 From: kenneth.j.peters at jpl.nasa.gov (Peters, Kenneth J) Date: Mon, 13 Jul 2009 08:16:30 -0700 Subject: New floating point Wiki page Message-ID: The issue where building the RTEMS kernel with "-msoft-float" removes all floating-point context handling from RTEMS seems to rise up periodically. It seems to result from many BSPs (the sparc ones are examples) setting CPU_HARDWARE_FP FALSE as a result of using -msoft-float to compile the kernel, so that kernel FP support is defined out. Since the only explanations of this are scattered around the mailing list archives, I have written a Wiki page titled "Floating Point Support" (under "How To's") to try to provide a complete explanation. Please take a look and correct my mistakes. Ken Peters From peter.o.mueller at gmx.de Mon Jul 13 16:06:29 2009 From: peter.o.mueller at gmx.de (Peter Mueller) Date: Mon, 13 Jul 2009 18:06:29 +0200 Subject: C-Code generator from UML state charts - new version 1.6.2 Message-ID: Hello list readers, SinelaboreRT is a console application that generates C-code from UML state charts. The UML state charts can be designed with Cadifra UML editor, Enterprise Architect, UModel or Magic Draw. The generation process can be widely adjusted to your needs and produces code that can even run in an ISR. SinelaboreRT was built especially for embedded real-time/low-power systems: - Generates human readable C-code - No run-time environment needed - Fits well in different system designs (foreground/background, RTOS- based ...) - No gap anymore between design and code - Simple integration in different development environments - Low cost - Support for automatic test-case generation - Simulation in interactive or batch mode. - Interactive and remote controlled visual mode! - Optionally generating trace code - Creation of state tables from UML state charts If you want to give it a try please visit www.sinelabore.com and take a look in the manual. There is a demo versions available. With best regards, Peter Mueller -- Peter Mueller pmueller at sinelabore.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.corsepius at rtems.org Mon Jul 13 16:16:05 2009 From: ralf.corsepius at rtems.org (Ralf Corsepius) Date: Mon, 13 Jul 2009 18:16:05 +0200 Subject: SPAM: Re: C-Code generator from UML state charts - new version 1.6.2 In-Reply-To: References: Message-ID: <4A5B5DC5.8010705@rtems.org> Peter Mueller wrote: > Hello list readers, Please stop abusing this list for advertisments of closed source products which are not even related to rtems. I consider this posing of yours to be simply SPAM. Ralf From leonp at plris.com Mon Jul 13 16:36:31 2009 From: leonp at plris.com (Leon Pollak) Date: Mon, 13 Jul 2009 19:36:31 +0300 Subject: SPAM: Re: C-Code generator from UML state charts - new version 1.6.2 In-Reply-To: <4A5B5DC5.8010705@rtems.org> References: <4A5B5DC5.8010705@rtems.org> Message-ID: <200907131936.31576.leonp@plris.com> On Monday July 13 2009, Ralf Corsepius wrote: > Peter Mueller wrote: > > Hello list readers, > > Please stop abusing this list for advertisments of closed source > products which are not even related to rtems. > > I consider this posting of yours to be simply SPAM. > You are absolutely right. As for me, I promise that I will NEVER even look into the direction of Sinelabore, not to mention their products. And call everybody to do the same. -- Dr.Leon M.Pollak Director PLR Information Systems Ltd. From roxana.leontie at gmail.com Mon Jul 13 23:15:02 2009 From: roxana.leontie at gmail.com (Roxana Leontie) Date: Mon, 13 Jul 2009 19:15:02 -0400 Subject: QEMU and RTEMS problem on Ubuntu Message-ID: Hi all, I have been trying to set up a new development environment, because my previous one (I was working on a VM that had fedora 10 in it) was getting kind-of slow. I choose ubuntu just because I already had it as a dual boot on my PC. So here it is my problem: I am using - kernel: Linux 2.6.28-13-generic - qemu version: 0.10 or 0.9.1 (both of them create the same problem on ubuntu) - grub version: GNU GRUB version 1.96 When running an rtems example (say hello - from pc386) i am seeing a 1-2 minutes delay before the grub> prompt appears ( since I am seeing "Welcome to GRUB!" until i see the "GNU GRUB version 1.96" and the grub> prompt) Had anyone else encountered this problem before? Any solutions/suggestions? Roxana -------------- next part -------------- An HTML attachment was scrubbed... URL: From jszhang3 at gmail.com Tue Jul 14 04:50:15 2009 From: jszhang3 at gmail.com (JiSheng Zhang) Date: Tue, 14 Jul 2009 12:50:15 +0800 Subject: QEMU and RTEMS problem on Ubuntu In-Reply-To: References: Message-ID: <2df346410907132150s4e97a231qe139802a96011837@mail.gmail.com> I used grub 1.96+ qemu+ rtems two years ago, there is no such problem. how do you make the disk image?and how install grub into its mbr? Maybe there is some problem there Jisheng From ralf.corsepius at rtems.org Tue Jul 14 05:05:17 2009 From: ralf.corsepius at rtems.org (Ralf Corsepius) Date: Tue, 14 Jul 2009 07:05:17 +0200 Subject: QEMU and RTEMS problem on Ubuntu In-Reply-To: References: Message-ID: <4A5C120D.1050408@rtems.org> Roxana Leontie wrote: > Hi all, > > I have been trying to set up a new development environment, because my > previous one (I was working on a VM that had fedora 10 in it) was getting > kind-of slow. I choose ubuntu just because I already had it as a dual boot > on my PC. > > So here it is my problem: > I am using > - kernel: Linux 2.6.28-13-generic > - qemu version: 0.10 or 0.9.1 (both of them create the same problem on > ubuntu) > - grub version: GNU GRUB version 1.96 > When running an rtems example (say hello - from pc386) i am seeing a 1-2 > minutes delay before the grub> prompt appears ( since I am seeing "Welcome > to GRUB!" until i see the "GNU GRUB version 1.96" and the grub> prompt) > > Had anyone else encountered this problem before? Any solutions/suggestions? AFAICT, the major difference between Ubuntu and most other linux distros is Ubuntu using grub2 (c.f. above: grub-1.96) instead of grub[1] (e.g.: Fedora 11: grub-0.97). So, I am inclined to think you might either have tripped over a bug in grub2 or a grub/grub2 incompatibility. Ralf From jszhang3 at gmail.com Tue Jul 14 05:10:26 2009 From: jszhang3 at gmail.com (JiSheng Zhang) Date: Tue, 14 Jul 2009 13:10:26 +0800 Subject: QEMU and RTEMS problem on Ubuntu In-Reply-To: <4A5C120D.1050408@rtems.org> References: <4A5C120D.1050408@rtems.org> Message-ID: <2df346410907132210k35a9392foaf22c5aae170aa1@mail.gmail.com> 2009/7/14 Ralf Corsepius : > AFAICT, the major difference between Ubuntu and most other linux distros > is Ubuntu using grub2 (c.f. above: grub-1.96) instead of grub[1] > (e.g.: Fedora 11: grub-0.97). > > So, I am inclined to think you might either have tripped over a bug in > grub2 or a grub/grub2 incompatibility. > > Ralf > hmmm, ubuntu 9.10 will use grub2(grub 1.96). I tried grub2 and qemu two years ago, there's no problem. May be related with how Roxana make the disk image Jisheng From roxana.leontie at gmail.com Tue Jul 14 17:01:07 2009 From: roxana.leontie at gmail.com (Roxana Leontie) Date: Tue, 14 Jul 2009 13:01:07 -0400 Subject: QEMU and RTEMS problem on Ubuntu In-Reply-To: <4A5C120D.1050408@rtems.org> References: <4A5C120D.1050408@rtems.org> Message-ID: Ralf the difference between Ubuntu and Fedora (grub2 vs grub[1]) is not something that I have to worry about. I am using a rtems-boot.img from Chris Johns that has the grub version 1.96 on it and can read the ext2 file system. This is what I have tried so far: 1.- removed all hdd's except the vfat partition as hda(then as hdb) - same result 2.- booted from a linux image ( the qemu small image ),then copied rtems-grub.cfg to the root of the filesystem. After that I booted again from the rtems floppy, hoping it will find the rtems-grub.cfg there. (no result) 3. - booted with hda as the linux image( a valid image - rather our fake zero-ed image) and hdb as the fat local directory. Still the same delay. 4. - booted from the linux small image and mounted the hdb vfat partition. All was good. Except ls listed the rtems-grub.cfg as rtems-gr.cfg. Might this be the cause ? Any other toughts? Thanks, Roxana On Tue, Jul 14, 2009 at 1:05 AM, Ralf Corsepius wrote: > Roxana Leontie wrote: > >> Hi all, >> >> I have been trying to set up a new development environment, because my >> previous one (I was working on a VM that had fedora 10 in it) was getting >> kind-of slow. I choose ubuntu just because I already had it as a dual boot >> on my PC. >> >> So here it is my problem: >> I am using >> - kernel: Linux 2.6.28-13-generic >> - qemu version: 0.10 or 0.9.1 (both of them create the same problem on >> ubuntu) >> - grub version: GNU GRUB version 1.96 >> When running an rtems example (say hello - from pc386) i am seeing a 1-2 >> minutes delay before the grub> prompt appears ( since I am seeing >> "Welcome >> to GRUB!" until i see the "GNU GRUB version 1.96" and the grub> prompt) >> >> Had anyone else encountered this problem before? Any >> solutions/suggestions? >> > AFAICT, the major difference between Ubuntu and most other linux distros is > Ubuntu using grub2 (c.f. above: grub-1.96) instead of grub[1] > (e.g.: Fedora 11: grub-0.97). > > So, I am inclined to think you might either have tripped over a bug in > grub2 or a grub/grub2 incompatibility. > > Ralf > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jszhang3 at gmail.com Tue Jul 14 17:13:47 2009 From: jszhang3 at gmail.com (JiSheng Zhang) Date: Wed, 15 Jul 2009 01:13:47 +0800 Subject: QEMU and RTEMS problem on Ubuntu In-Reply-To: References: <4A5C120D.1050408@rtems.org> Message-ID: <2df346410907141013k18781d07j25f52656e26fd914@mail.gmail.com> I have tried to build floppy image myself as I did two years ago but failed, this is the error message which grub-setup prints: grub-setup: info: the size of fd0 is 2880 grub-setup: info: the size of fd0 is 2880 grub-setup: info: the size of fd0 is 2880 grub-setup: info: the size of fd0 is 2880 grub-setup: info: the size of fd0 is 2880 grub-setup: info: the size of fd0 is 2880 grub-setup: info: getting the size of /tmp/loop/boot/grub/boot.img grub-setup: info: reading /tmp/loop/boot/grub/boot.img grub-setup: info: getting the size of /tmp/loop/boot/grub/boot.img grub-setup: info: getting the size of /tmp/loop/boot/grub/core.img grub-setup: info: reading /tmp/loop/boot/grub/core.img grub-setup: info: getting the size of /tmp/loop/boot/grub/core.img grub-setup: info: the size of fd0 is 2880 grub-setup: info: the size of fd0 is 2880 grub-setup: info: setting the root device to `fd0' grub-setup: info: dos partition is -1, bsd partition is -1 grub-setup: warn: Your embedding area is unusually small. core.img won't fit in it. grub-setup: warn: Embedding is not possible. GRUB can only be installed in this setup by using blocklists. However, blocklists are UNRELIABLE and its use is discouraged. grub-setup: info: attempting to read the core image `/tmp/loop/boot/grub/core.img' from GRUB grub-setup: info: the size of fd0 is 2880 grub-setup: info: the size of fd0 is 2880 grub-setup: info: couldn't open the core image grub-setup: info: error message = file not found grub-setup: info: attempting to read the core image `/grub/core.img' from GRUB again grub-setup: info: the size of fd0 is 2880 grub-setup: info: the size of fd0 is 2880 grub-setup: info: couldn't open the core image grub-setup: info: error message = file not found grub-setup: info: attempting to read the core image `/grub/core.img' from GRUB again grub-setup: info: the size of fd0 is 2880 grub-setup: info: the size of fd0 is 2880 grub-setup: info: couldn't open the core image grub-setup: info: error message = file not found grub-setup: info: attempting to read the core image `/grub/core.img' from GRUB again grub-setup: info: the size of fd0 is 2880 grub-setup: info: the size of fd0 is 2880 grub-setup: info: couldn't open the core image grub-setup: info: error message = file not found grub-setup: info: attempting to read the core image `/grub/core.img' from GRUB again grub-setup: info: the size of fd0 is 2880 grub-setup: info: the size of fd0 is 2880 grub-setup: info: couldn't open the core image grub-setup: info: error message = file not found grub-setup: error: Cannot read `/grub/core.img' correctly IMHO, there's a lot of bugs in grub2 now. So it's better to use grub, it is OK 2009/7/15 Roxana Leontie : > Ralf the difference between Ubuntu and Fedora (grub2 vs grub[1]) is not > something that I have to worry about. I am using a rtems-boot.img from Chris > Johns that has the grub version 1.96 on it and can read the ext2 file > system. I got the same results when using the img form Chris Johns JiSheng From chrisj at rtems.org Wed Jul 15 00:08:56 2009 From: chrisj at rtems.org (Chris Johns) Date: Wed, 15 Jul 2009 10:08:56 +1000 Subject: QEMU and RTEMS problem on Ubuntu In-Reply-To: <2df346410907141013k18781d07j25f52656e26fd914@mail.gmail.com> References: <4A5C120D.1050408@rtems.org> <2df346410907141013k18781d07j25f52656e26fd914@mail.gmail.com> Message-ID: <4A5D1E18.7090009@rtems.org> JiSheng Zhang wrote: > > IMHO, there's a lot of bugs in grub2 now. So it's better to use grub, it is OK > I build grub2 and use it without any problems on Fedora. The only issue I have had is the ata.o module. Do not use this one. > > 2009/7/15 Roxana Leontie : >> Ralf the difference between Ubuntu and Fedora (grub2 vs grub[1]) is not >> something that I have to worry about. I am using a rtems-boot.img from Chris >> Johns that has the grub version 1.96 on it and can read the ext2 file >> system. > I got the same results when using the img form Chris Johns Interesting. I have not followed what host you are using. Is it Ubuntu ? Do you have a working grub image that Roxana can use ? Regards Chris From jszhang3 at gmail.com Wed Jul 15 02:53:14 2009 From: jszhang3 at gmail.com (JiSheng Zhang) Date: Wed, 15 Jul 2009 10:53:14 +0800 Subject: QEMU and RTEMS problem on Ubuntu In-Reply-To: <4A5D1E18.7090009@rtems.org> References: <4A5C120D.1050408@rtems.org> <2df346410907141013k18781d07j25f52656e26fd914@mail.gmail.com> <4A5D1E18.7090009@rtems.org> Message-ID: <2df346410907141953k4583ab50g4b4d2fe11f134a8b@mail.gmail.com> 2009/7/15 Chris Johns : > JiSheng Zhang wrote: >> >> IMHO, there's a lot of bugs in grub2 now. So it's better to use grub, it >> is OK >> > > I build grub2 and use it without any problems on Fedora. The only issue I > have had is the ata.o module. Do not use this one. > >> >> 2009/7/15 Roxana Leontie : >>> >>> Ralf the difference between Ubuntu and Fedora (grub2 vs grub[1]) is not >>> something that I have to worry about. I am using a rtems-boot.img from >>> Chris >>> Johns that has the grub version 1.96 on it and can read the ext2 file >>> system. >> >> I got the same results when using the img form Chris Johns > > Interesting. I have not followed what host you are using. Is it Ubuntu ? I'm using debian unstable > > Do you have a working grub image that Roxana can use ? > I don't know how to make grub2 image(there's filesystem on it). I just make a grub floppy image which filesystem is ext2. But how can I send the image to Roxana? I have no pub ftp\http etc. If we don't need make filesystem on floppy image, there's no problem with grub2(just dd if=boot.img etc.) > Regards > Chris > Thanks, Jisheng From jszhang3 at gmail.com Wed Jul 15 03:17:55 2009 From: jszhang3 at gmail.com (JiSheng Zhang) Date: Wed, 15 Jul 2009 11:17:55 +0800 Subject: QEMU and RTEMS problem on Ubuntu In-Reply-To: <2df346410907141953k4583ab50g4b4d2fe11f134a8b@mail.gmail.com> References: <4A5C120D.1050408@rtems.org> <2df346410907141013k18781d07j25f52656e26fd914@mail.gmail.com> <4A5D1E18.7090009@rtems.org> <2df346410907141953k4583ab50g4b4d2fe11f134a8b@mail.gmail.com> Message-ID: <2df346410907142017uf5df3d8o3da6739275d3a846@mail.gmail.com> OK I have send the floppy image to her Any idea about how to make an grub2 floppy image? Jisheng 2009/7/15 JiSheng Zhang : > 2009/7/15 Chris Johns : >> JiSheng Zhang wrote: >>> >>> IMHO, there's a lot of bugs in grub2 now. So it's better to use grub, it >>> is OK >>> >> >> I build grub2 and use it without any problems on Fedora. The only issue I >> have had is the ata.o module. Do not use this one. >> >>> >>> 2009/7/15 Roxana Leontie : >>>> >>>> Ralf the difference between Ubuntu and Fedora (grub2 vs grub[1]) is not >>>> something that I have to worry about. I am using a rtems-boot.img from >>>> Chris >>>> Johns that has the grub version 1.96 on it and can read the ext2 file >>>> system. >>> >>> I got the same results when using the img form Chris Johns >> >> Interesting. I have not followed what host you are using. Is it Ubuntu ? > I'm using debian unstable >> >> Do you have a working grub image that Roxana can use ? >> > I don't know how to make grub2 image(there's filesystem on it). I just > make a grub floppy image which filesystem is ext2. But how can I send > the image to Roxana? I have no pub ftp\http etc. > > If we don't need make filesystem on floppy image, there's no problem > with grub2(just dd if=boot.img etc.) >> Regards >> Chris >> > Thanks, > Jisheng > From roxana.leontie at gmail.com Wed Jul 15 23:56:50 2009 From: roxana.leontie at gmail.com (Roxana Leontie) Date: Wed, 15 Jul 2009 19:56:50 -0400 Subject: QEMU and RTEMS problem on Ubuntu Message-ID: > > OK I have send the floppy image to her Thanks I got the email and I tested the image and it worked. I will try to improve the floppy.img you sent and post an update for future references. > Any idea about how to make an grub2 floppy image? > > > Jisheng Roxana -------------- next part -------------- An HTML attachment was scrubbed... URL: From chrisj at rtems.org Thu Jul 16 23:47:33 2009 From: chrisj at rtems.org (Chris Johns) Date: Fri, 17 Jul 2009 09:47:33 +1000 Subject: QEMU and RTEMS problem on Ubuntu In-Reply-To: <2df346410907142017uf5df3d8o3da6739275d3a846@mail.gmail.com> References: <4A5C120D.1050408@rtems.org> <2df346410907141013k18781d07j25f52656e26fd914@mail.gmail.com> <4A5D1E18.7090009@rtems.org> <2df346410907141953k4583ab50g4b4d2fe11f134a8b@mail.gmail.com> <2df346410907142017uf5df3d8o3da6739275d3a846@mail.gmail.com> Message-ID: <4A5FBC15.6010503@rtems.org> JiSheng Zhang wrote: > OK I have send the floppy image to her > > Any idea about how to make an grub2 floppy image? > The script I use is here: http://www.rtems.org/ftp/pub/rtems/people/chrisj/grub/g2-rtems-floppy.sh Regards Chris From daron.chabot at gmail.com Fri Jul 17 01:25:07 2009 From: daron.chabot at gmail.com (Daron Chabot) Date: Thu, 16 Jul 2009 21:25:07 -0400 Subject: mvme6100 support Message-ID: <50cc54100907161825p5cac46a0m66be86ebc544b646@mail.gmail.com> Just looking at the cvs HEAD, it seems as though the mvme5500 bsp may also support the mvme6100 board. Is this correct ? Or should I instead be inquiring about the "beatnik" bsp for 6100 support ? Thanks. -- dc From feng at bnl.gov Fri Jul 17 01:51:34 2009 From: feng at bnl.gov (Feng, Kate) Date: Thu, 16 Jul 2009 21:51:34 -0400 Subject: mvme6100 support References: <50cc54100907161825p5cac46a0m66be86ebc544b646@mail.gmail.com> Message-ID: I wrote and upgraded the mvme5500 BSP to disco BSP to support the mvme6100 board. At that time, the performance of the network on the mvme6100 board was not important, but the decision for the choice of H/W for my project was urgent. Thus, the code for the network is not really ready for a formal release yet. It seems that the network code for beatnik BSP needs to be optimized or rewritten as well based on the version I obtained from Till Straumann a while ago. I do not know if he had any chance to improve the netowrk performance ever since then. At this point, I have at least two other higher priority tasks to be completed before I have a chance to finish rewriting the network code for the mvme6100 board to boost up its performance, although it could be a fun project. Cheers, Kate ________________________________ From: rtems-users-bounces at rtems.org on behalf of Daron Chabot Sent: Thu 7/16/2009 9:25 PM To: RTEMS Subject: mvme6100 support Just looking at the cvs HEAD, it seems as though the mvme5500 bsp may also support the mvme6100 board. Is this correct ? Or should I instead be inquiring about the "beatnik" bsp for 6100 support ? Thanks. -- dc _______________________________________________ rtems-users mailing list rtems-users at rtems.org http://www.rtems.org/mailman/listinfo/rtems-users From joel.sherrill at OARcorp.com Fri Jul 17 02:19:36 2009 From: joel.sherrill at OARcorp.com (Joel Sherrill) Date: Thu, 16 Jul 2009 21:19:36 -0500 Subject: mvme6100 support In-Reply-To: References: <50cc54100907161825p5cac46a0m66be86ebc544b646@mail.gmail.com> Message-ID: <4A5FDFB8.6050500@oarcorp.com> Feng, Kate wrote: > I wrote and upgraded the mvme5500 BSP to disco BSP to support the > mvme6100 board. At that time, the performance of the network on > the mvme6100 board was not important, but the decision for the > choice of H/W for my project was urgent. Thus, the code for > the network is not really ready for a formal release yet. It seems that the > network code for beatnik BSP needs to be optimized or rewritten as well > based on the version I obtained from Till Straumann a while ago. > I do not know if he had any chance to improve the netowrk > performance ever since then. > So .. it should work to ... a) build for mvme5500 and run on mvme6100? b) add alias to build for mvme6100 and fix x odd issues for mvme6100 Does this mean the network driver works? How bad is "not optimized" really? Just asking because I know you are a perfectionist and wanted to get an accurate description of the status. :) --joel > > At this point, I have at least two other higher priority tasks to be > completed before I have a chance to finish rewriting the network > code for the mvme6100 board to boost up its performance, although it > could be a fun project. > > Cheers, > Kate > > ________________________________ > > From: rtems-users-bounces at rtems.org on behalf of Daron Chabot > Sent: Thu 7/16/2009 9:25 PM > To: RTEMS > Subject: mvme6100 support > > > > Just looking at the cvs HEAD, it seems as though the mvme5500 bsp may > also support the mvme6100 board. Is this correct ? > > Or should I instead be inquiring about the "beatnik" bsp for 6100 support ? > > Thanks. > > > -- dc > _______________________________________________ > rtems-users mailing list > rtems-users at rtems.org > http://www.rtems.org/mailman/listinfo/rtems-users > > > _______________________________________________ > rtems-users mailing list > rtems-users at rtems.org > http://www.rtems.org/mailman/listinfo/rtems-users > From nasimz at lums.edu.pk Fri Jul 17 04:42:44 2009 From: nasimz at lums.edu.pk (Nasim Zehra) Date: Fri, 17 Jul 2009 10:42:44 +0600 Subject: Dynamic scheduling Message-ID: Does rtems support dynamic scheduling??if yes what managers are useful for this purpose? nasim From Thomas.Doerfler at embedded-brains.de Fri Jul 17 06:49:20 2009 From: Thomas.Doerfler at embedded-brains.de (Thomas Doerfler) Date: Fri, 17 Jul 2009 08:49:20 +0200 Subject: Dynamic scheduling In-Reply-To: References: Message-ID: <4A601EF0.1050907@embedded-brains.de> Hi, what exactly do you call "dynamic scheduling"? The term seems a bit "open" to me, but maybe I am simpy ignorant :-) wkr, Thomas. Nasim Zehra wrote: > Does rtems support dynamic scheduling??if yes what managers are useful for this purpose? > > nasim > _______________________________________________ > rtems-users mailing list > rtems-users at rtems.org > http://www.rtems.org/mailman/listinfo/rtems-users -- -------------------------------------------- Embedded Brains GmbH Thomas Doerfler Obere Lagerstrasse 30 D-82178 Puchheim Germany email: Thomas.Doerfler at embedded-brains.de Phone: +49-89-18908079-2 Fax: +49-89-18908079-9 From nasimz at lums.edu.pk Fri Jul 17 06:57:32 2009 From: nasimz at lums.edu.pk (Nasim Zehra) Date: Fri, 17 Jul 2009 12:57:32 +0600 Subject: Dynamic scheduling In-Reply-To: <4A601EF0.1050907@embedded-brains.de> References: , <4A601EF0.1050907@embedded-brains.de> Message-ID: like EDF, Minimum Laxity first.Actually i m having observation that rtems has only rate monotonic .static scheduling scheme, manager.May be it does not support dynamic one?I guess timer or clock directives are helpful in this regard, but i am having problem using timer directive..that what should be written in place of *user_data when timer is fired.Moreover whether should we create timer directive in main "init" function or should we create and delete then like rate monotonic periods inside the task ,mentioned in the example of rate monotonic manager. nasim ________________________________________ From: Thomas Doerfler [Thomas.Doerfler at embedded-brains.de] Sent: Friday, July 17, 2009 12:49 PM To: Nasim Zehra Cc: rtems-users at rtems.org Subject: Re: Dynamic scheduling Hi, what exactly do you call "dynamic scheduling"? The term seems a bit "open" to me, but maybe I am simpy ignorant :-) wkr, Thomas. Nasim Zehra wrote: > Does rtems support dynamic scheduling??if yes what managers are useful for this purpose? > > nasim > _______________________________________________ > rtems-users mailing list > rtems-users at rtems.org > http://www.rtems.org/mailman/listinfo/rtems-users -- -------------------------------------------- Embedded Brains GmbH Thomas Doerfler Obere Lagerstrasse 30 D-82178 Puchheim Germany email: Thomas.Doerfler at embedded-brains.de Phone: +49-89-18908079-2 Fax: +49-89-18908079-9 From nasimz at lums.edu.pk Fri Jul 17 07:03:41 2009 From: nasimz at lums.edu.pk (Nasim Zehra) Date: Fri, 17 Jul 2009 13:03:41 +0600 Subject: CPU_USAGE_REPORT() Problem Message-ID: Hi, i am having five tasks and i want cpu usage report table. just after five tasks creation ,i am having table like that ID NAME SECONDS PERCENT 0x09010001 IDLE 0.000000 0.000 0x0A010001 UI1 0.001260 100.000 0x0A010002 TA1 0.000000 0.000 0x0A010003 TA2 0.000000 0.000 0x0A010004 TA3 0.000000 0.000 0x0A010005 TA4 0.000000 0.000 0x0A010006 TA5 0.000000 0.000 ----OK bcz idle is by defaul..rest of having 0 exec time..good......But don't know what UI1 is ?????? ok then after execution of all the tasks i am having table like that ID NAME SECONDS PERCENT 0x09010001 IDLE 0.000000 0.000 0x0A010001 UI1 0.000787 0.024 0x0A010002 TA1 2.216917 70.157 0x0A010004 TA3 0.001027 0.032 0x0A010006 TA5 0.000000 0.000 --still made at UI1..what is it? and where TA2 AND TA4 have gone????? although i tried to solve this problem by defining array of task name and id of size 7 instead of five.I know it is ridiculus to do this...it should have no effect on this problem.any solution? nasim From nasimz at lums.edu.pk Fri Jul 17 07:09:25 2009 From: nasimz at lums.edu.pk (Nasim Zehra) Date: Fri, 17 Jul 2009 13:09:25 +0600 Subject: CPU_USAGE_REPORT() Problem In-Reply-To: References: Message-ID: moreover it does not give info. like Ticks since last reset = 1600 Total Units = 1608 mentioned in c user guide of rtem. I am using rtems 4.8. rtems newer than 4.7 use seconds approach instead of ticks ?in rtems 4.8 ,using cpu_usage_report(),can i get ticks info instead of seconds? nasim ________________________________________ From: rtems-users-bounces at rtems.org [rtems-users-bounces at rtems.org] On Behalf Of Nasim Zehra [nasimz at lums.edu.pk] Sent: Friday, July 17, 2009 1:03 PM To: rtems-users at rtems.org Subject: CPU_USAGE_REPORT() Problem Hi, i am having five tasks and i want cpu usage report table. just after five tasks creation ,i am having table like that ID NAME SECONDS PERCENT 0x09010001 IDLE 0.000000 0.000 0x0A010001 UI1 0.001260 100.000 0x0A010002 TA1 0.000000 0.000 0x0A010003 TA2 0.000000 0.000 0x0A010004 TA3 0.000000 0.000 0x0A010005 TA4 0.000000 0.000 0x0A010006 TA5 0.000000 0.000 ----OK bcz idle is by defaul..rest of having 0 exec time..good......But don't know what UI1 is ?????? ok then after execution of all the tasks i am having table like that ID NAME SECONDS PERCENT 0x09010001 IDLE 0.000000 0.000 0x0A010001 UI1 0.000787 0.024 0x0A010002 TA1 2.216917 70.157 0x0A010004 TA3 0.001027 0.032 0x0A010006 TA5 0.000000 0.000 --still made at UI1..what is it? and where TA2 AND TA4 have gone????? although i tried to solve this problem by defining array of task name and id of size 7 instead of five.I know it is ridiculus to do this...it should have no effect on this problem.any solution? nasim _______________________________________________ rtems-users mailing list rtems-users at rtems.org http://www.rtems.org/mailman/listinfo/rtems-users From manuel.coutinho at edisoft.pt Fri Jul 17 08:15:13 2009 From: manuel.coutinho at edisoft.pt (Manuel Coutinho) Date: Fri, 17 Jul 2009 09:15:13 +0100 Subject: CPU_USAGE_REPORT() Problem In-Reply-To: References: Message-ID: <000001ca06b6$b5f49500$680aa8c0@ecmcoutinho> Hi The UI1 is your "Init" task. You can change the name (and entry point and other parameters) using the confdefs.h options. RTEMS counts the percentage through the number of clock ticks that occur during the execution of each task. As to the other problems, have no response to them (don't know your system that well). Regards Manuel Coutinho > -----Original Message----- > From: rtems-users-bounces at rtems.org [mailto:rtems-users-bounces at rtems.org] > On Behalf Of Nasim Zehra > Sent: Friday, July 17, 2009 8:09 AM > To: Nasim Zehra > Cc: rtems-users at rtems.org > Subject: RE: CPU_USAGE_REPORT() Problem > > moreover it does not give info. like > > Ticks since last reset = 1600 > Total Units = 1608 > mentioned in c user guide of rtem. > I am using rtems 4.8. rtems newer than 4.7 use seconds approach instead of > ticks ?in rtems 4.8 ,using cpu_usage_report(),can i get ticks info instead > of seconds? > > nasim > ________________________________________ > From: rtems-users-bounces at rtems.org [rtems-users-bounces at rtems.org] On > Behalf Of Nasim Zehra [nasimz at lums.edu.pk] > Sent: Friday, July 17, 2009 1:03 PM > To: rtems-users at rtems.org > Subject: CPU_USAGE_REPORT() Problem > > Hi, > i am having five tasks and i want cpu usage report table. > just after five tasks creation ,i am having table like that > ID NAME SECONDS PERCENT > 0x09010001 IDLE 0.000000 0.000 > 0x0A010001 UI1 0.001260 100.000 > 0x0A010002 TA1 0.000000 0.000 > 0x0A010003 TA2 0.000000 0.000 > 0x0A010004 TA3 0.000000 0.000 > 0x0A010005 TA4 0.000000 0.000 > 0x0A010006 TA5 0.000000 0.000 > > ----OK bcz idle is by defaul..rest of having 0 exec time..good......But > don't know what UI1 is ?????? > > ok then after execution of all the tasks i am having table like that > > ID NAME SECONDS PERCENT > 0x09010001 IDLE 0.000000 0.000 > 0x0A010001 UI1 0.000787 0.024 > 0x0A010002 TA1 2.216917 70.157 > 0x0A010004 TA3 0.001027 0.032 > 0x0A010006 TA5 0.000000 0.000 > > --still made at UI1..what is it? and where TA2 AND TA4 have gone????? > although i tried to solve this problem by defining array of task name and > id of size 7 instead of five.I know it is ridiculus to do this...it should > have no effect on this problem.any solution? > > > nasim > _______________________________________________ > rtems-users mailing list > rtems-users at rtems.org > http://www.rtems.org/mailman/listinfo/rtems-users > _______________________________________________ > rtems-users mailing list > rtems-users at rtems.org > http://www.rtems.org/mailman/listinfo/rtems-users From manuel.coutinho at edisoft.pt Fri Jul 17 08:20:38 2009 From: manuel.coutinho at edisoft.pt (Manuel Coutinho) Date: Fri, 17 Jul 2009 09:20:38 +0100 Subject: Dynamic scheduling In-Reply-To: References: , <4A601EF0.1050907@embedded-brains.de> Message-ID: <000101ca06b7$7768d020$680aa8c0@ecmcoutinho> RTEMS has fixed-priority scheduling. RTEMS does not support dynamic scheduling. Actually, the rate monotonic that is referred only makes tasks to be periodic. It does not implement the Rate Monotonic Scheduler. The application must correctly assign the tasks priorities in order for the Rate Monotonic Scheduler to work. Note that is good that RTEMS does this because other scheduler variants can be easily implemented (e.g Deadline Monotonic). Also, there are system models, for example, non-preemptive or in which the task releases are well defined, in which the Rate Monotonic Scheduler is NOT the optimal scheduler. Hope this helps Regards Manuel Coutinho > -----Original Message----- > From: rtems-users-bounces at rtems.org [mailto:rtems-users-bounces at rtems.org] > On Behalf Of Nasim Zehra > Sent: Friday, July 17, 2009 7:58 AM > To: Thomas Doerfler > Cc: rtems-users at rtems.org > Subject: RE: Dynamic scheduling > > like EDF, Minimum Laxity first.Actually i m having observation that rtems > has only rate monotonic .static scheduling scheme, manager.May be it does > not support dynamic one?I guess timer or clock directives are helpful in > this regard, but i am having problem using timer directive..that what > should be written in place of *user_data when timer is fired.Moreover > whether should we create timer directive in main "init" function or should > we create and delete then like rate monotonic periods inside the task > ,mentioned in the example of rate monotonic manager. > > nasim > ________________________________________ > From: Thomas Doerfler [Thomas.Doerfler at embedded-brains.de] > Sent: Friday, July 17, 2009 12:49 PM > To: Nasim Zehra > Cc: rtems-users at rtems.org > Subject: Re: Dynamic scheduling > > Hi, > > what exactly do you call "dynamic scheduling"? The term seems a bit > "open" to me, but maybe I am simpy ignorant :-) > > wkr, > Thomas. > > Nasim Zehra wrote: > > Does rtems support dynamic scheduling??if yes what managers are useful > for this purpose? > > > > nasim > > _______________________________________________ > > rtems-users mailing list > > rtems-users at rtems.org > > http://www.rtems.org/mailman/listinfo/rtems-users > > > -- > > -------------------------------------------- > Embedded Brains GmbH > Thomas Doerfler Obere Lagerstrasse 30 > D-82178 Puchheim Germany > email: Thomas.Doerfler at embedded-brains.de > Phone: +49-89-18908079-2 > Fax: +49-89-18908079-9 > _______________________________________________ > rtems-users mailing list > rtems-users at rtems.org > http://www.rtems.org/mailman/listinfo/rtems-users From nasimz at lums.edu.pk Fri Jul 17 09:07:33 2009 From: nasimz at lums.edu.pk (Nasim Zehra) Date: Fri, 17 Jul 2009 15:07:33 +0600 Subject: CPU_USAGE_REPORT() Problem In-Reply-To: <000001ca06b6$b5f49500$680aa8c0@ecmcoutinho> References: , <000001ca06b6$b5f49500$680aa8c0@ecmcoutinho> Message-ID: if this is init function ,should it not have maximum execution seconds than any other of the tasks?becuase it is suspended and then is resumed after completion of all the tasks.Answers for other problems still are required. nasim ________________________________________ From: Manuel Coutinho [manuel.coutinho at edisoft.pt] Sent: Friday, July 17, 2009 2:15 PM To: Nasim Zehra Cc: rtems-users at rtems.org Subject: RE: CPU_USAGE_REPORT() Problem Hi The UI1 is your "Init" task. You can change the name (and entry point and other parameters) using the confdefs.h options. RTEMS counts the percentage through the number of clock ticks that occur during the execution of each task. As to the other problems, have no response to them (don't know your system that well). Regards Manuel Coutinho > -----Original Message----- > From: rtems-users-bounces at rtems.org [mailto:rtems-users-bounces at rtems.org] > On Behalf Of Nasim Zehra > Sent: Friday, July 17, 2009 8:09 AM > To: Nasim Zehra > Cc: rtems-users at rtems.org > Subject: RE: CPU_USAGE_REPORT() Problem > > moreover it does not give info. like > > Ticks since last reset = 1600 > Total Units = 1608 > mentioned in c user guide of rtem. > I am using rtems 4.8. rtems newer than 4.7 use seconds approach instead of > ticks ?in rtems 4.8 ,using cpu_usage_report(),can i get ticks info instead > of seconds? > > nasim > ________________________________________ > From: rtems-users-bounces at rtems.org [rtems-users-bounces at rtems.org] On > Behalf Of Nasim Zehra [nasimz at lums.edu.pk] > Sent: Friday, July 17, 2009 1:03 PM > To: rtems-users at rtems.org > Subject: CPU_USAGE_REPORT() Problem > > Hi, > i am having five tasks and i want cpu usage report table. > just after five tasks creation ,i am having table like that > ID NAME SECONDS PERCENT > 0x09010001 IDLE 0.000000 0.000 > 0x0A010001 UI1 0.001260 100.000 > 0x0A010002 TA1 0.000000 0.000 > 0x0A010003 TA2 0.000000 0.000 > 0x0A010004 TA3 0.000000 0.000 > 0x0A010005 TA4 0.000000 0.000 > 0x0A010006 TA5 0.000000 0.000 > > ----OK bcz idle is by defaul..rest of having 0 exec time..good......But > don't know what UI1 is ?????? > > ok then after execution of all the tasks i am having table like that > > ID NAME SECONDS PERCENT > 0x09010001 IDLE 0.000000 0.000 > 0x0A010001 UI1 0.000787 0.024 > 0x0A010002 TA1 2.216917 70.157 > 0x0A010004 TA3 0.001027 0.032 > 0x0A010006 TA5 0.000000 0.000 > > --still made at UI1..what is it? and where TA2 AND TA4 have gone????? > although i tried to solve this problem by defining array of task name and > id of size 7 instead of five.I know it is ridiculus to do this...it should > have no effect on this problem.any solution? > > > nasim > _______________________________________________ > rtems-users mailing list > rtems-users at rtems.org > http://www.rtems.org/mailman/listinfo/rtems-users > _______________________________________________ > rtems-users mailing list > rtems-users at rtems.org > http://www.rtems.org/mailman/listinfo/rtems-users From feng1 at bnl.gov Fri Jul 17 11:06:25 2009 From: feng1 at bnl.gov (Kate Feng) Date: Fri, 17 Jul 2009 07:06:25 -0400 Subject: mvme6100 support In-Reply-To: <4A5FDFB8.6050500@oarcorp.com> References: <50cc54100907161825p5cac46a0m66be86ebc544b646@mail.gmail.com> <4A5FDFB8.6050500@oarcorp.com> Message-ID: <4A605B31.3020005@bnl.gov> Joel Sherrill wrote: > Feng, Kate wrote: >> I wrote and upgraded the mvme5500 BSP to disco BSP to support the >> mvme6100 board. At that time, the performance of the network on >> the mvme6100 board was not important, but the decision for the >> choice of H/W for my project was urgent. Thus, the code for >> the network is not really ready for a formal release yet. It seems >> that the >> network code for beatnik BSP needs to be optimized or rewritten as >> well >> based on the version I obtained from Till Straumann a while ago. I >> do not know if he had any chance to improve the netowrk >> performance ever since then. > So .. it should work to ... > > a) build for mvme5500 and run on mvme6100? Not the mvme5500 BSP in the current RTEMS release. I could rename "disco" BSP back to "mvme5500" BSP for the RTEMS release, except the network driver was/is really not ready for the open release yet. > b) add alias to build for mvme6100 and fix x odd > issues for mvme6100 > > Does this mean the network driver works? How > bad is "not optimized" really? Yes, the network driver for the mvme6100 works, at least for the one project I tested, but a workaround that have degraded the actual performance of the H/W by my estimation of at least two. It was not written for the real-time performance because there were somethings missing. I had to quickly move on to a different H/W platform because the DDR memory date rate is too slow for my project, not because of the network driver. I actually started to rewrite the driver to meet the requirement of the real-time programming. However, it kept getting interrupted by my other higher priority projects that I could not get this project completed. It should be fun to get it finished, but it is more important to get my other projects done at this point. Regards, Kate > > Just asking because I know you are a perfectionist and > wanted to get an accurate description of the status. :) > > --joel >> >> At this point, I have at least two other higher priority tasks to be >> completed before I have a chance to finish rewriting the network >> code for the mvme6100 board to boost up its performance, although it >> could be a fun project. >> >> Cheers, >> Kate >> >> ________________________________ >> >> From: rtems-users-bounces at rtems.org on behalf of Daron Chabot >> Sent: Thu 7/16/2009 9:25 PM >> To: RTEMS >> Subject: mvme6100 support >> >> >> >> Just looking at the cvs HEAD, it seems as though the mvme5500 bsp may >> also support the mvme6100 board. Is this correct ? >> >> Or should I instead be inquiring about the "beatnik" bsp for 6100 >> support ? >> >> Thanks. >> >> >> -- dc >> _______________________________________________ >> rtems-users mailing list >> rtems-users at rtems.org >> http://www.rtems.org/mailman/listinfo/rtems-users >> >> >> _______________________________________________ >> rtems-users mailing list >> rtems-users at rtems.org >> http://www.rtems.org/mailman/listinfo/rtems-users >> > From daron.chabot at gmail.com Fri Jul 17 11:37:24 2009 From: daron.chabot at gmail.com (Daron Chabot) Date: Fri, 17 Jul 2009 07:37:24 -0400 Subject: mvme6100 support In-Reply-To: <4A605B31.3020005@bnl.gov> References: <50cc54100907161825p5cac46a0m66be86ebc544b646@mail.gmail.com> <4A5FDFB8.6050500@oarcorp.com> <4A605B31.3020005@bnl.gov> Message-ID: <50cc54100907170437t57d47200weef29be47251f403@mail.gmail.com> On Fri, Jul 17, 2009 at 7:06 AM, Kate Feng wrote: > Joel Sherrill wrote: >> >> Feng, Kate wrote: >>> >>> I wrote and upgraded the mvme5500 BSP to disco BSP to support the >>> mvme6100 board. ?At that time, the performance of the network on >>> the mvme6100 board was not important, but the decision for the >>> choice of H/W for my project was urgent. ?Thus, the code for >>> the network is not really ready for a formal release yet. ?It seems that >>> the >>> network code for beatnik BSP needs to be ?optimized or rewritten ?as well >>> based on the version I obtained from Till Straumann a while ago. ?I do >>> not know if he had any chance to improve the netowrk >>> performance ever since then. >> >> So .. it should work to ... >> >> a) build for mvme5500 and run on mvme6100? > > Not the mvme5500 BSP ?in the current RTEMS release. As in my original posting, I am not referring to the current (4.9.2) release, but to the mvme5500 BSP as it stands in the cvs HEAD version. This enum from mvme5500/include/bsp.h seems to imply run-time detection of board type: /* Board type */ typedef enum { undefined = 0, MVME5500, MVME6100 } BSP_BoardTypes; So, as Joel asked, with the version on cvs HEAD, is it possible to build for the 5500 and _run_ on the 6100 ? BTW -- Kate, I am now working at BNL with the NSLS2 controls group :-) so, I may be able to help with the mvme6100 bsp issues. -- dc > I could rename "disco" BSP ?back to "mvme5500" BSP > for the RTEMS release, except the network driver was/is > really not ready for the open release yet. >> >> b) add alias to build for mvme6100 and fix x odd >> ? ?issues for mvme6100 >> >> Does this mean the network driver works? ?How >> bad is "not optimized" really? > > Yes, the network driver for the mvme6100 works, at > least for the one project I tested, but a workaround that > have degraded the actual performance of the H/W by my > estimation of at least two. > It was not written for the real-time performance because > there were somethings missing. ?I had to quickly move on > to a different H/W platform because the DDR memory > date rate is too slow for my project, not because of the > network driver. ?I actually started to rewrite the driver to > meet the requirement of the real-time programming. > However, it kept getting interrupted by my other higher > priority projects that I could not get this project > completed. ?It should be fun to get it finished, but > it is more important to get my other projects done at > this point. > > Regards, > Kate >> >> Just asking because I know you are a perfectionist and >> wanted to get an accurate description of the status. :) >> >> --joel >>> >>> ?At this point, I have at least two other higher priority tasks to be >>> completed before I have a chance to ?finish rewriting the network >>> code for the mvme6100 board to boost up its performance, although it >>> could be a fun project. >>> ?Cheers, >>> Kate >>> >>> ________________________________ >>> >>> From: rtems-users-bounces at rtems.org on behalf of Daron Chabot >>> Sent: Thu 7/16/2009 9:25 PM >>> To: RTEMS >>> Subject: mvme6100 support >>> >>> >>> >>> Just looking at the cvs HEAD, it seems as though the mvme5500 bsp may >>> also support the mvme6100 board. Is this correct ? >>> >>> Or should I instead be inquiring about the "beatnik" bsp for 6100 support >>> ? >>> >>> Thanks. >>> >>> >>> -- dc >>> _______________________________________________ >>> rtems-users mailing list >>> rtems-users at rtems.org >>> http://www.rtems.org/mailman/listinfo/rtems-users >>> >>> >>> _______________________________________________ >>> rtems-users mailing list >>> rtems-users at rtems.org >>> http://www.rtems.org/mailman/listinfo/rtems-users >>> >> > > From feng1 at bnl.gov Fri Jul 17 12:23:19 2009 From: feng1 at bnl.gov (Kate Feng) Date: Fri, 17 Jul 2009 08:23:19 -0400 Subject: mvme6100 support for CVS head In-Reply-To: <50cc54100907170437t57d47200weef29be47251f403@mail.gmail.com> References: <50cc54100907161825p5cac46a0m66be86ebc544b646@mail.gmail.com> <4A5FDFB8.6050500@oarcorp.com> <4A605B31.3020005@bnl.gov> <50cc54100907170437t57d47200weef29be47251f403@mail.gmail.com> Message-ID: <4A606D37.1030204@bnl.gov> Daron Chabot wrote: > On Fri, Jul 17, 2009 at 7:06 AM, Kate Feng wrote: > >> Joel Sherrill wrote: >> >>> Feng, Kate wrote: >>> >>>> I wrote and upgraded the mvme5500 BSP to disco BSP to support the >>>> mvme6100 board. At that time, the performance of the network on >>>> the mvme6100 board was not important, but the decision for the >>>> choice of H/W for my project was urgent. Thus, the code for >>>> the network is not really ready for a formal release yet. It seems that >>>> the >>>> network code for beatnik BSP needs to be optimized or rewritten as well >>>> based on the version I obtained from Till Straumann a while ago. I do >>>> not know if he had any chance to improve the netowrk >>>> performance ever since then. >>>> >>> So .. it should work to ... >>> >>> a) build for mvme5500 and run on mvme6100? >>> >> Not the mvme5500 BSP in the current RTEMS release. >> > > As in my original posting, I am not referring to the current (4.9.2) > release, but to the mvme5500 BSP as it stands > in the cvs HEAD version. > > This enum from mvme5500/include/bsp.h seems to imply run-time > detection of board type: > /* Board type */ > typedef enum { > undefined = 0, > MVME5500, > MVME6100 > } BSP_BoardTypes; > > So, as Joel asked, with the version on cvs HEAD, is it possible to > build for the 5500 and _run_ on the 6100 ? > I will have to submit the network driver for the mvme6100. I just wish one to be aware that the current driver is not written in the typical RTEMS real-time fashion, and its performance could be boosted -up to at least an estimated factor of two. Thus, one should not use that as a template for other network driver. Speaking of the CVS head, back in April, I had to modify some shared files to solve the issue with the RTEMS work space and C program heap before I submitted the updated code for mvme5500 BSP. I did not send the patch for the shared files back then because I only had it tested for the case when rtems_unified_work_area is false. Joel, is the code updated ? The code should be updated before mvme5500, mvme6100, and I think any other PPC can work. Did I miss something ? Kate > BTW -- Kate, I am now working at BNL with the NSLS2 controls group :-) > so, I may be able to help with the mvme6100 bsp issues. > > > -- dc > > >> I could rename "disco" BSP back to "mvme5500" BSP >> for the RTEMS release, except the network driver was/is >> really not ready for the open release yet. >> >>> b) add alias to build for mvme6100 and fix x odd >>> issues for mvme6100 >>> >>> Does this mean the network driver works? How >>> bad is "not optimized" really? >>> >> Yes, the network driver for the mvme6100 works, at >> least for the one project I tested, but a workaround that >> have degraded the actual performance of the H/W by my >> estimation of at least two. >> It was not written for the real-time performance because >> there were somethings missing. I had to quickly move on >> to a different H/W platform because the DDR memory >> date rate is too slow for my project, not because of the >> network driver. I actually started to rewrite the driver to >> meet the requirement of the real-time programming. >> However, it kept getting interrupted by my other higher >> priority projects that I could not get this project >> completed. It should be fun to get it finished, but >> it is more important to get my other projects done at >> this point. >> >> Regards, >> Kate >> >>> Just asking because I know you are a perfectionist and >>> wanted to get an accurate description of the status. :) >>> >>> --joel >>> >>>> At this point, I have at least two other higher priority tasks to be >>>> completed before I have a chance to finish rewriting the network >>>> code for the mvme6100 board to boost up its performance, although it >>>> could be a fun project. >>>> Cheers, >>>> Kate >>>> >>>> ________________________________ >>>> >>>> From: rtems-users-bounces at rtems.org on behalf of Daron Chabot >>>> Sent: Thu 7/16/2009 9:25 PM >>>> To: RTEMS >>>> Subject: mvme6100 support >>>> >>>> >>>> >>>> Just looking at the cvs HEAD, it seems as though the mvme5500 bsp may >>>> also support the mvme6100 board. Is this correct ? >>>> >>>> Or should I instead be inquiring about the "beatnik" bsp for 6100 support >>>> ? >>>> >>>> Thanks. >>>> >>>> >>>> -- dc >>>> _______________________________________________ >>>> rtems-users mailing list >>>> rtems-users at rtems.org >>>> http://www.rtems.org/mailman/listinfo/rtems-users >>>> >>>> >>>> _______________________________________________ >>>> rtems-users mailing list >>>> rtems-users at rtems.org >>>> http://www.rtems.org/mailman/listinfo/rtems-users >>>> >>>> >> From joel.sherrill at OARcorp.com Fri Jul 17 12:36:19 2009 From: joel.sherrill at OARcorp.com (Joel Sherrill) Date: Fri, 17 Jul 2009 07:36:19 -0500 Subject: CPU_USAGE_REPORT() Problem In-Reply-To: References: Message-ID: <4A607043.6020007@oarcorp.com> Nasim Zehra wrote: > Hi, > i am having five tasks and i want cpu usage report table. > just after five tasks creation ,i am having table like that > ID NAME SECONDS PERCENT > 0x09010001 IDLE 0.000000 0.000 > 0x0A010001 UI1 0.001260 100.000 > 0x0A010002 TA1 0.000000 0.000 > 0x0A010003 TA2 0.000000 0.000 > 0x0A010004 TA3 0.000000 0.000 > 0x0A010005 TA4 0.000000 0.000 > 0x0A010006 TA5 0.000000 0.000 > > ----OK bcz idle is by defaul..rest of having 0 exec time..good......But don't know what UI1 is ?????? > > ok then after execution of all the tasks i am having table like that > > ID NAME SECONDS PERCENT > 0x09010001 IDLE 0.000000 0.000 > 0x0A010001 UI1 0.000787 0.024 > 0x0A010002 TA1 2.216917 70.157 > 0x0A010004 TA3 0.001027 0.032 > 0x0A010006 TA5 0.000000 0.000 > > --still made at UI1..what is it? and where TA2 AND TA4 have gone????? > UI1 is the default name of the user initialization task. Tasks missing indicates that they have exited or been deleted. The percentage doesn't get close to 100% because the report wasn't reset after they were deleted. With no source code, this is an educated guess on TA2 and TA4 > although i tried to solve this problem by defining array of task name and id of size 7 instead of five.I know it is ridiculus to do this...it should have no effect on this problem.any solution? > > Array is just used by the tests. Name is stored internal to TCB, > nasim > _______________________________________________ > rtems-users mailing list > rtems-users at rtems.org > http://www.rtems.org/mailman/listinfo/rtems-users > From joel.sherrill at OARcorp.com Fri Jul 17 12:37:29 2009 From: joel.sherrill at OARcorp.com (Joel Sherrill) Date: Fri, 17 Jul 2009 07:37:29 -0500 Subject: CPU_USAGE_REPORT() Problem In-Reply-To: References: Message-ID: <4A607089.5050504@oarcorp.com> Nasim Zehra wrote: > moreover it does not give info. like > > Ticks since last reset = 1600 > Total Units = 1608 > mentioned in c user guide of rtem. > I am using rtems 4.8. rtems newer than 4.7 use seconds approach instead of ticks ?in rtems 4.8 ,using cpu_usage_report(),can i get ticks info instead of seconds? > > Are you running on a sparc on sis or tsim? I have noticed that the last few lines of output do not always get flushed through RTEMS and the simulator as you are shutting down on those. --joel > nasim > ________________________________________ > From: rtems-users-bounces at rtems.org [rtems-users-bounces at rtems.org] On Behalf Of Nasim Zehra [nasimz at lums.edu.pk] > Sent: Friday, July 17, 2009 1:03 PM > To: rtems-users at rtems.org > Subject: CPU_USAGE_REPORT() Problem > > Hi, > i am having five tasks and i want cpu usage report table. > just after five tasks creation ,i am having table like that > ID NAME SECONDS PERCENT > 0x09010001 IDLE 0.000000 0.000 > 0x0A010001 UI1 0.001260 100.000 > 0x0A010002 TA1 0.000000 0.000 > 0x0A010003 TA2 0.000000 0.000 > 0x0A010004 TA3 0.000000 0.000 > 0x0A010005 TA4 0.000000 0.000 > 0x0A010006 TA5 0.000000 0.000 > > ----OK bcz idle is by defaul..rest of having 0 exec time..good......But don't know what UI1 is ?????? > > ok then after execution of all the tasks i am having table like that > > ID NAME SECONDS PERCENT > 0x09010001 IDLE 0.000000 0.000 > 0x0A010001 UI1 0.000787 0.024 > 0x0A010002 TA1 2.216917 70.157 > 0x0A010004 TA3 0.001027 0.032 > 0x0A010006 TA5 0.000000 0.000 > > --still made at UI1..what is it? and where TA2 AND TA4 have gone????? > although i tried to solve this problem by defining array of task name and id of size 7 instead of five.I know it is ridiculus to do this...it should have no effect on this problem.any solution? > > > nasim > _______________________________________________ > rtems-users mailing list > rtems-users at rtems.org > http://www.rtems.org/mailman/listinfo/rtems-users > _______________________________________________ > rtems-users mailing list > rtems-users at rtems.org > http://www.rtems.org/mailman/listinfo/rtems-users > From joel.sherrill at OARcorp.com Fri Jul 17 14:01:43 2009 From: joel.sherrill at OARcorp.com (Joel Sherrill) Date: Fri, 17 Jul 2009 09:01:43 -0500 Subject: Dynamic scheduling In-Reply-To: <000101ca06b7$7768d020$680aa8c0@ecmcoutinho> References: , <4A601EF0.1050907@embedded-brains.de> <000101ca06b7$7768d020$680aa8c0@ecmcoutinho> Message-ID: <4A608447.80803@oarcorp.com> Manuel Coutinho wrote: > RTEMS has fixed-priority scheduling. RTEMS does not support dynamic > scheduling. > > Actually, the rate monotonic that is referred only makes tasks to be > periodic. It does not implement the Rate Monotonic Scheduler. The > application must correctly assign the tasks priorities in order for the Rate > Monotonic Scheduler to work. > http://en.wikipedia.org/wiki/Rate-monotonic_scheduling is a pretty good article. I have never seen any claim that the RMS priority assignment rule must be done by the operating system. In the original Lui/Layland paper which defined RMS and two analysis algorithms, the only requirement laid on the OS was that it support priority based scheduling with preemption. As defined there, RMS and RMA are fundamentally offline algorithms to place guarantees on task set schedulability if you follow the priority assignment rule and perform analysis. With that said, I know there are software schedulers out there which use the period information to schedule tasks. This is not a requirement. > Note that is good that RTEMS does this because other scheduler variants can > be easily implemented (e.g Deadline Monotonic). Also, there are system > models, for example, non-preemptive or in which the task releases are well > defined, in which the Rate Monotonic Scheduler is NOT the optimal scheduler. > > Hope this helps > Regards > Manuel Coutinho > > >> -----Original Message----- >> From: rtems-users-bounces at rtems.org [mailto:rtems-users-bounces at rtems.org] >> On Behalf Of Nasim Zehra >> Sent: Friday, July 17, 2009 7:58 AM >> To: Thomas Doerfler >> Cc: rtems-users at rtems.org >> Subject: RE: Dynamic scheduling >> >> like EDF, Minimum Laxity first.Actually i m having observation that rtems >> has only rate monotonic .static scheduling scheme, manager.May be it does >> not support dynamic one?I guess timer or clock directives are helpful in >> this regard, but i am having problem using timer directive..that what >> should be written in place of *user_data when timer is fired.Moreover >> whether should we create timer directive in main "init" function or should >> we create and delete then like rate monotonic periods inside the task >> ,mentioned in the example of rate monotonic manager. >> >> nasim >> ________________________________________ >> From: Thomas Doerfler [Thomas.Doerfler at embedded-brains.de] >> Sent: Friday, July 17, 2009 12:49 PM >> To: Nasim Zehra >> Cc: rtems-users at rtems.org >> Subject: Re: Dynamic scheduling >> >> Hi, >> >> what exactly do you call "dynamic scheduling"? The term seems a bit >> "open" to me, but maybe I am simpy ignorant :-) >> >> wkr, >> Thomas. >> >> Nasim Zehra wrote: >> >>> Does rtems support dynamic scheduling??if yes what managers are useful >>> >> for this purpose? >> >>> nasim >>> _______________________________________________ >>> rtems-users mailing list >>> rtems-users at rtems.org >>> http://www.rtems.org/mailman/listinfo/rtems-users >>> >> -- >> >> -------------------------------------------- >> Embedded Brains GmbH >> Thomas Doerfler Obere Lagerstrasse 30 >> D-82178 Puchheim Germany >> email: Thomas.Doerfler at embedded-brains.de >> Phone: +49-89-18908079-2 >> Fax: +49-89-18908079-9 >> _______________________________________________ >> rtems-users mailing list >> rtems-users at rtems.org >> http://www.rtems.org/mailman/listinfo/rtems-users >> > > _______________________________________________ > rtems-users mailing list > rtems-users at rtems.org > http://www.rtems.org/mailman/listinfo/rtems-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 From joel.sherrill at OARcorp.com Fri Jul 17 14:12:31 2009 From: joel.sherrill at OARcorp.com (Joel Sherrill) Date: Fri, 17 Jul 2009 09:12:31 -0500 Subject: mvme6100 support for CVS head In-Reply-To: <4A606D37.1030204@bnl.gov> References: <50cc54100907161825p5cac46a0m66be86ebc544b646@mail.gmail.com> <4A5FDFB8.6050500@oarcorp.com> <4A605B31.3020005@bnl.gov> <50cc54100907170437t57d47200weef29be47251f403@mail.gmail.com> <4A606D37.1030204@bnl.gov> Message-ID: <4A6086CF.6000507@oarcorp.com> Kate Feng wrote: > Daron Chabot wrote: > >> On Fri, Jul 17, 2009 at 7:06 AM, Kate Feng wrote: >> >> >>> Joel Sherrill wrote: >>> >>> >>>> Feng, Kate wrote: >>>> >>>> >>>>> I wrote and upgraded the mvme5500 BSP to disco BSP to support the >>>>> mvme6100 board. At that time, the performance of the network on >>>>> the mvme6100 board was not important, but the decision for the >>>>> choice of H/W for my project was urgent. Thus, the code for >>>>> the network is not really ready for a formal release yet. It seems that >>>>> the >>>>> network code for beatnik BSP needs to be optimized or rewritten as well >>>>> based on the version I obtained from Till Straumann a while ago. I do >>>>> not know if he had any chance to improve the netowrk >>>>> performance ever since then. >>>>> >>>>> >>>> So .. it should work to ... >>>> >>>> a) build for mvme5500 and run on mvme6100? >>>> >>>> >>> Not the mvme5500 BSP in the current RTEMS release. >>> >>> >> As in my original posting, I am not referring to the current (4.9.2) >> release, but to the mvme5500 BSP as it stands >> in the cvs HEAD version. >> >> This enum from mvme5500/include/bsp.h seems to imply run-time >> detection of board type: >> /* Board type */ >> typedef enum { >> undefined = 0, >> MVME5500, >> MVME6100 >> } BSP_BoardTypes; >> >> So, as Joel asked, with the version on cvs HEAD, is it possible to >> build for the 5500 and _run_ on the 6100 ? >> >> > I will have to submit the network driver for the mvme6100. I just wish > one to be aware that the current driver is not written in the typical RTEMS > real-time fashion, and its performance could be boosted -up to at least > an estimated factor of two. Thus, one should not use that as a template > for other network driver. > > Speaking of the CVS head, back in April, I had to modify some shared files > to solve the issue with the RTEMS work space and C program heap > before I submitted the updated code for mvme5500 BSP. I did not send > the patch for the shared files back then because I only had it tested > for the case > when rtems_unified_work_area is false. Joel, is the code updated ? > The code should be updated before mvme5500, mvme6100, and I think > any other PPC can work. Did I miss something ? > > I have no idea what the problem you are referring to is. :) Give me a description or half-baked old patch and I will look at it. --joel > Kate > > >> BTW -- Kate, I am now working at BNL with the NSLS2 controls group :-) >> so, I may be able to help with the mvme6100 bsp issues. >> >> >> -- dc >> >> >> >>> I could rename "disco" BSP back to "mvme5500" BSP >>> for the RTEMS release, except the network driver was/is >>> really not ready for the open release yet. >>> >>> >>>> b) add alias to build for mvme6100 and fix x odd >>>> issues for mvme6100 >>>> >>>> Does this mean the network driver works? How >>>> bad is "not optimized" really? >>>> >>>> >>> Yes, the network driver for the mvme6100 works, at >>> least for the one project I tested, but a workaround that >>> have degraded the actual performance of the H/W by my >>> estimation of at least two. >>> It was not written for the real-time performance because >>> there were somethings missing. I had to quickly move on >>> to a different H/W platform because the DDR memory >>> date rate is too slow for my project, not because of the >>> network driver. I actually started to rewrite the driver to >>> meet the requirement of the real-time programming. >>> However, it kept getting interrupted by my other higher >>> priority projects that I could not get this project >>> completed. It should be fun to get it finished, but >>> it is more important to get my other projects done at >>> this point. >>> >>> Regards, >>> Kate >>> >>> >>>> Just asking because I know you are a perfectionist and >>>> wanted to get an accurate description of the status. :) >>>> >>>> --joel >>>> >>>> >>>>> At this point, I have at least two other higher priority tasks to be >>>>> completed before I have a chance to finish rewriting the network >>>>> code for the mvme6100 board to boost up its performance, although it >>>>> could be a fun project. >>>>> Cheers, >>>>> Kate >>>>> >>>>> ________________________________ >>>>> >>>>> From: rtems-users-bounces at rtems.org on behalf of Daron Chabot >>>>> Sent: Thu 7/16/2009 9:25 PM >>>>> To: RTEMS >>>>> Subject: mvme6100 support >>>>> >>>>> >>>>> >>>>> Just looking at the cvs HEAD, it seems as though the mvme5500 bsp may >>>>> also support the mvme6100 board. Is this correct ? >>>>> >>>>> Or should I instead be inquiring about the "beatnik" bsp for 6100 support >>>>> ? >>>>> >>>>> Thanks. >>>>> >>>>> >>>>> -- dc >>>>> _______________________________________________ >>>>> rtems-users mailing list >>>>> rtems-users at rtems.org >>>>> http://www.rtems.org/mailman/listinfo/rtems-users >>>>> >>>>> >>>>> _______________________________________________ >>>>> rtems-users mailing list >>>>> rtems-users at rtems.org >>>>> http://www.rtems.org/mailman/listinfo/rtems-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 From jszhang3 at gmail.com Fri Jul 17 16:28:06 2009 From: jszhang3 at gmail.com (JiSheng Zhang) Date: Sat, 18 Jul 2009 00:28:06 +0800 Subject: QEMU and RTEMS problem on Ubuntu In-Reply-To: <4A5FBC15.6010503@rtems.org> References: <4A5C120D.1050408@rtems.org> <2df346410907141013k18781d07j25f52656e26fd914@mail.gmail.com> <4A5D1E18.7090009@rtems.org> <2df346410907141953k4583ab50g4b4d2fe11f134a8b@mail.gmail.com> <2df346410907142017uf5df3d8o3da6739275d3a846@mail.gmail.com> <4A5FBC15.6010503@rtems.org> Message-ID: <2df346410907170928l3d4dc4d9v9ac710f23ff5e51c@mail.gmail.com> 2009/7/17 Chris Johns : > JiSheng Zhang wrote: >> >> OK I have send the floppy image to her >> >> Any idea about how to make an grub2 floppy image? >> > > The script I use is here: > > http://www.rtems.org/ftp/pub/rtems/people/chrisj/grub/g2-rtems-floppy.sh the last step "grub-setup" will failed now. Fortunately, it seems that someone in #haiku is one of the developers of grub2 and he helped me to make a ext2 floppy image with grub2 installed. It works. Regards, Jisheng From feng1 at bnl.gov Fri Jul 17 18:31:06 2009 From: feng1 at bnl.gov (Kate Feng) Date: Fri, 17 Jul 2009 14:31:06 -0400 Subject: mvme6100 support for CVS head In-Reply-To: <4A6086CF.6000507@oarcorp.com> References: <50cc54100907161825p5cac46a0m66be86ebc544b646@mail.gmail.com> <4A5FDFB8.6050500@oarcorp.com> <4A605B31.3020005@bnl.gov> <50cc54100907170437t57d47200weef29be47251f403@mail.gmail.com> <4A606D37.1030204@bnl.gov> <4A6086CF.6000507@oarcorp.com> Message-ID: <4A60C36A.8010709@bnl.gov> Joel Sherrill wrote: > Kate Feng wrote: >> Daron Chabot wrote: >> >>> On Fri, Jul 17, 2009 at 7:06 AM, Kate Feng wrote: >>> >>>> Joel Sherrill wrote: >>>> >>>>> Feng, Kate wrote: >>>>> >>>>>> I wrote and upgraded the mvme5500 BSP to disco BSP to support the >>>>>> mvme6100 board. At that time, the performance of the network on >>>>>> the mvme6100 board was not important, but the decision for the >>>>>> choice of H/W for my project was urgent. Thus, the code for >>>>>> the network is not really ready for a formal release yet. It >>>>>> seems that >>>>>> the >>>>>> network code for beatnik BSP needs to be optimized or rewritten >>>>>> as well >>>>>> based on the version I obtained from Till Straumann a while ago. >>>>>> I do >>>>>> not know if he had any chance to improve the netowrk >>>>>> performance ever since then. >>>>>> >>>>> So .. it should work to ... >>>>> >>>>> a) build for mvme5500 and run on mvme6100? >>>>> >>>> Not the mvme5500 BSP in the current RTEMS release. >>>> >>> As in my original posting, I am not referring to the current (4.9.2) >>> release, but to the mvme5500 BSP as it stands >>> in the cvs HEAD version. >>> >>> This enum from mvme5500/include/bsp.h seems to imply run-time >>> detection of board type: >>> /* Board type */ >>> typedef enum { >>> undefined = 0, >>> MVME5500, >>> MVME6100 >>> } BSP_BoardTypes; >>> >>> So, as Joel asked, with the version on cvs HEAD, is it possible to >>> build for the 5500 and _run_ on the 6100 ? >>> >> I will have to submit the network driver for the mvme6100. I just wish >> one to be aware that the current driver is not written in the typical >> RTEMS >> real-time fashion, and its performance could be boosted -up to at least >> an estimated factor of two. Thus, one should not use that as a template >> for other network driver. >> >> Speaking of the CVS head, back in April, I had to modify some >> shared files >> to solve the issue with the RTEMS work space and C program heap >> before I submitted the updated code for mvme5500 BSP. I did not send >> the patch for the shared files back then because I only had it tested >> for the case >> when rtems_unified_work_area is false. Joel, is the code updated ? >> The code should be updated before mvme5500, mvme6100, and I think >> any other PPC can work. Did I miss something ? >> >> > I have no idea what the problem you are referring to is. :) > > Give me a description or half-baked old patch and I will look > at it. > - The attached is the half-baked patch for the CVS head, which I only tested it with mvme5500 BSP briefly. Regarding the network driver for the mvme6100, it was ported quickly from the beatnik BSP, which was written by Till Straumann. Thus, the performance would be similar to that of the beatnik BSP. If both Joel and Till does not mind that I release a work-around version in the CVS head, I will find time to package it, if that helps. However, I only used the driver to boot up the BSP so that I could test my project. Perhaps, has one rewritten it to improve its performance since the mvme6100 boards are heavily used for others' projects ? Please advise. Sincerely, Kate -------------- next part -------------- A non-text attachment was scrubbed... Name: CVS-RTEMS4.10-libbsp.diff Type: text/x-patch Size: 4463 bytes Desc: not available URL: From chrisj at rtems.org Fri Jul 17 21:38:51 2009 From: chrisj at rtems.org (Chris Johns) Date: Sat, 18 Jul 2009 07:38:51 +1000 Subject: QEMU and RTEMS problem on Ubuntu In-Reply-To: <2df346410907170928l3d4dc4d9v9ac710f23ff5e51c@mail.gmail.com> References: <4A5C120D.1050408@rtems.org> <2df346410907141013k18781d07j25f52656e26fd914@mail.gmail.com> <4A5D1E18.7090009@rtems.org> <2df346410907141953k4583ab50g4b4d2fe11f134a8b@mail.gmail.com> <2df346410907142017uf5df3d8o3da6739275d3a846@mail.gmail.com> <4A5FBC15.6010503@rtems.org> <2df346410907170928l3d4dc4d9v9ac710f23ff5e51c@mail.gmail.com> Message-ID: <4A60EF6B.1040109@rtems.org> JiSheng Zhang wrote: > 2009/7/17 Chris Johns : >> JiSheng Zhang wrote: >>> OK I have send the floppy image to her >>> >>> Any idea about how to make an grub2 floppy image? >>> >> The script I use is here: >> >> http://www.rtems.org/ftp/pub/rtems/people/chrisj/grub/g2-rtems-floppy.sh > > the last step "grub-setup" will failed now. Fortunately, it seems that > someone in #haiku is one of the developers of grub2 and he helped me > to make a ext2 floppy image with grub2 installed. It works. > Was this a problem with the script or some thing else ? Regards Chris From nasimz at lums.edu.pk Mon Jul 20 03:43:08 2009 From: nasimz at lums.edu.pk (Nasim Zehra) Date: Mon, 20 Jul 2009 09:43:08 +0600 Subject: CPU_USAGE_REPORT() Problem In-Reply-To: <4A607089.5050504@oarcorp.com> References: , <4A607089.5050504@oarcorp.com> Message-ID: hi I am using rtems 4.8 for sparc and loen for compilation and link purpose.And then simulating its binary file through TSIM simulator.I am not shutting down on those.Moreover i am resetting too. using rtems_cpu_usage_report( ); rtems_cpu_usage_reset( ); both. and i m doing this when init task is resumed after execution of all the tasks. nasim ________________________________________ From: Joel Sherrill [joel.sherrill at oarcorp.com] Sent: Friday, July 17, 2009 6:37 PM To: Nasim Zehra Cc: rtems-users at rtems.org Subject: Re: CPU_USAGE_REPORT() Problem Nasim Zehra wrote: > moreover it does not give info. like > > Ticks since last reset = 1600 > Total Units = 1608 > mentioned in c user guide of rtem. > I am using rtems 4.8. rtems newer than 4.7 use seconds approach instead of ticks ?in rtems 4.8 ,using cpu_usage_report(),can i get ticks info instead of seconds? > > Are you running on a sparc on sis or tsim? I have noticed that the last few lines of output do not always get flushed through RTEMS and the simulator as you are shutting down on those. --joel > nasim > ________________________________________ > From: rtems-users-bounces at rtems.org [rtems-users-bounces at rtems.org] On Behalf Of Nasim Zehra [nasimz at lums.edu.pk] > Sent: Friday, July 17, 2009 1:03 PM > To: rtems-users at rtems.org > Subject: CPU_USAGE_REPORT() Problem > > Hi, > i am having five tasks and i want cpu usage report table. > just after five tasks creation ,i am having table like that > ID NAME SECONDS PERCENT > 0x09010001 IDLE 0.000000 0.000 > 0x0A010001 UI1 0.001260 100.000 > 0x0A010002 TA1 0.000000 0.000 > 0x0A010003 TA2 0.000000 0.000 > 0x0A010004 TA3 0.000000 0.000 > 0x0A010005 TA4 0.000000 0.000 > 0x0A010006 TA5 0.000000 0.000 > > ----OK bcz idle is by defaul..rest of having 0 exec time..good......But don't know what UI1 is ?????? > > ok then after execution of all the tasks i am having table like that > > ID NAME SECONDS PERCENT > 0x09010001 IDLE 0.000000 0.000 > 0x0A010001 UI1 0.000787 0.024 > 0x0A010002 TA1 2.216917 70.157 > 0x0A010004 TA3 0.001027 0.032 > 0x0A010006 TA5 0.000000 0.000 > > --still made at UI1..what is it? and where TA2 AND TA4 have gone????? > although i tried to solve this problem by defining array of task name and id of size 7 instead of five.I know it is ridiculus to do this...it should have no effect on this problem.any solution? > > > nasim > _______________________________________________ > rtems-users mailing list > rtems-users at rtems.org > http://www.rtems.org/mailman/listinfo/rtems-users > _______________________________________________ > rtems-users mailing list > rtems-users at rtems.org > http://www.rtems.org/mailman/listinfo/rtems-users > From David.Brooke at 3t-ag.com Mon Jul 20 16:33:47 2009 From: David.Brooke at 3t-ag.com (David Brooke) Date: Mon, 20 Jul 2009 17:33:47 +0100 Subject: gen83xx ethernet transmit problem In-Reply-To: <4A2E218D.7050808@embedded-brains.de> References: <20090605103120.GA12444@dbrooke.littleport> <4A2E218D.7050808@embedded-brains.de> Message-ID: <20090720163347.GC2572@dbrooke.littleport> On Tue, Jun 09, 2009 at 10:47:09AM +0200, Thomas D?rfler wrote: [snip] > > Right, this wokrs fine on MPC8349 and MPC8313. We just got U-Boot running on our real hardware, which differs only slightly from the board I was working with, and the Ethernet seems to be working fine. So it looks like the problem was something specific to my initial development platform. Regards, David From Thomas.Doerfler at embedded-brains.de Tue Jul 21 19:05:34 2009 From: Thomas.Doerfler at embedded-brains.de (=?ISO-8859-15?Q?Thomas_D=F6rfler?=) Date: Tue, 21 Jul 2009 21:05:34 +0200 Subject: Ann: RTEMS open class in Munich/Germany Message-ID: <4A66117E.2000706@embedded-brains.de> Hello, due to several requests, we are currently planning another open RTEMS class in Munich/Germany to start on October 6-9 2009. Maybe you or some of your colleagues like to join in? See our updated website http://www.embedded-brains.de/index.php?id=rtems_class&L=1 for more details. The closing date for registrations is September 18 2009. Please note that the number of seats is limited and can only be booked on a first come, first serve base. Please use the website form or send us an email if you and/or your colleagues are interested to attend, so we can reserve seats for you. wkr, Thomas Doerfler. -- -------------------------------------------- embedded brains GmbH Thomas Doerfler Obere Lagerstr. 30 D-82178 Puchheim Germany Tel. : +49-89-18 90 80 79-2 Fax : +49-89-18 90 80 79-9 email: Thomas.Doerfler at embedded-brains.de PGP public key available on request From gxfarmer at gmail.com Wed Jul 22 03:24:29 2009 From: gxfarmer at gmail.com (=?GB2312?B?1tC5+sWpw/E=?=) Date: Wed, 22 Jul 2009 11:24:29 +0800 Subject: about RTEMS Remote Debugger Server Message-ID: <545c8850907212024k744d892dp9f5472737ad5ba35@mail.gmail.com> hi, anyone could give me some tips about the RTEMS Remote Debugger Server on RTEMS 4.92? how to implement the RTEMS Remote Debugger Server? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jszhang3 at gmail.com Thu Jul 23 18:33:46 2009 From: jszhang3 at gmail.com (JiSheng Zhang) Date: Fri, 24 Jul 2009 02:33:46 +0800 Subject: [GSOC]Dynamic object file loading:basic dlsym and dlclose Message-ID: <2df346410907231133u14b21a4cwb6b08ae20c549bc7@mail.gmail.com> Hi all, I have completed the baisc implementation of dlsym and dlclose. Now the four dlXXX functions are all basically completed, although only on x86 now. I have git push the code on github, so for test just do the following: git clone git://github.com/absabs/objdl.git cd objdl make ./demo -l t.o -s get enjoy;) Note:there's a mem leak in dlclose, because the memory of global symbol name allocated by strdup is not freed. But I have to go to bed, this will be fixed tomorrow Thanks, JiSheng From joel.sherrill at OARcorp.com Fri Jul 24 13:38:53 2009 From: joel.sherrill at OARcorp.com (Joel Sherrill) Date: Fri, 24 Jul 2009 08:38:53 -0500 Subject: ITRON API Deprecated for 4.10 Message-ID: <4A69B96D.4060900@oarcorp.com> Hi, The Steering Committee has decided to deprecate the ITRON 3.0 API implementation in RTEMS in 4.10 and plans to remove it in 4.11. It is now disabled by default on the CVS head. Here are the pertinent facts that lead to this decision. + It was implemented as class projects by a graduate real-time class Joel taught in 1999. + It is incomplete. + It is based on ITRON 3.0. Current revision is at least 4.0. + SC didn't recall a PR or question on it. + .h files define common some names so when it is enabled, it can cause surprising conflicts. So it is incomplete, out of date, and may have no users. The primary positive point we saw is that it is another example of using the SuperCore to implement an API. If someone steps forward to update the implementation to the current revision or sponsor that work, then it will be kept alive. Being out of date and incomplete are big negatives. Not having confirmed users is not as much an issue because there are lots of very quiet RTEMS users so we might never know. Even with all that going against it, RTEMS is by nature a conservative project. So it will be there for another release cycle. If you want the ITRON implementation to live on, please contribute. Updating it to the current specification could be a good senior or class project. -- 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 From fgnicodemos at terra.com.br Fri Jul 24 14:10:34 2009 From: fgnicodemos at terra.com.br (Fernando Nicodemos) Date: Fri, 24 Jul 2009 11:10:34 -0300 Subject: Examples Message-ID: Hi, My name is Fernando Nicodemos and I am pretty new in this RTEMS List. I have been working with RTEMS since 2007, but I start to work heavly this year, 2009. I have two simple questions for now. 1- Does anybody have Webserver, HTTP, FTP and implementations using PPP (from Free BSD TCP/IP stack) example sources using RTEMS or anybody know where I can find them, if available at the source tree? 2- How far are this implementations in RTEMS? Are they fully functional? Does anybody tested them? Thanks a lot, Fernando Nicodemos From mprtems at bellsouth.net Fri Jul 24 14:24:02 2009 From: mprtems at bellsouth.net (Mike Panetta) Date: Fri, 24 Jul 2009 07:24:02 -0700 (PDT) Subject: Cortex-M3 support? Message-ID: <830532.41038.qm@web180404.mail.gq1.yahoo.com> I have been looking at CVS head and noticed that there is no cortex-m3 support in RTEMS. Has anyone started work on this? If yes, is the code available somewhere? If no, where would one start a port for this ARM core? It does not seem to quite fit in with the current ARM code in that exception handling is somewhat different... Would one create a cortex-m3 directory under libcpu/arm,libbsp/arm, etc, or just put the code directly in the respective arm dir for this port? I don't think adding CPU support for this core would be such a big deal, its just figuring out where to put it... BSP support on the other hand may be another matter... Any help, suggestions on this would be greatly appreciated! Thanks, Mike From joel.sherrill at OARcorp.com Fri Jul 24 14:31:05 2009 From: joel.sherrill at OARcorp.com (Joel Sherrill) Date: Fri, 24 Jul 2009 09:31:05 -0500 Subject: Examples In-Reply-To: References: Message-ID: <4A69C5A9.10407@oarcorp.com> Fernando Nicodemos wrote: > Hi, > > My name is Fernando Nicodemos and I am pretty new in this RTEMS List. > I have been working with RTEMS since 2007, but I start to work heavly this > year, 2009. > > Hi Fernando. :) > I have two simple questions for now. > > 1- Does anybody have Webserver, HTTP, FTP and implementations using PPP > (from Free BSD TCP/IP stack) example sources using RTEMS or anybody know > where I can find them, if available at the source tree? > > check out network-demos from CVS. This includes ftpd, httpd, and telnetd usage examples. > 2- How far are this implementations in RTEMS? Are they fully functional? > Does anybody tested them? > > There are two httpd implementations in cpukit. All of the various network servers are functional but "fully" is a vague term. They provide basic functionality one would expect from an embedded device. > Thanks a lot, > > Fernando Nicodemos > > > > _______________________________________________ > rtems-users mailing list > rtems-users at rtems.org > http://www.rtems.org/mailman/listinfo/rtems-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 From joel.sherrill at OARcorp.com Fri Jul 24 14:41:21 2009 From: joel.sherrill at OARcorp.com (Joel Sherrill) Date: Fri, 24 Jul 2009 09:41:21 -0500 Subject: Cortex-M3 support? In-Reply-To: <830532.41038.qm@web180404.mail.gq1.yahoo.com> References: <830532.41038.qm@web180404.mail.gq1.yahoo.com> Message-ID: <4A69C811.3000201@oarcorp.com> Mike Panetta wrote: > I have been looking at CVS head and noticed that there is no cortex-m3 support in RTEMS. Has anyone started work on this? If yes, is the code available somewhere? If no, where would one start a port for this ARM core? It does not seem to quite fit in with the current ARM code in that exception handling is somewhat different... Would one create a cortex-m3 directory under libcpu/arm,libbsp/arm, etc, or just put the code directly in the respective arm dir for this port? I don't think adding CPU support for this core would be such a big deal, its just figuring out where to put it... BSP support on the other hand may be another matter... > > Sebastian Huber has been reworking the ARM exception code so make sure you are on today's head and talking to him. In general terms, you want to start with the CPU core and ignore the peripherals. + make sure the multilib variant is in the tools + make sure the multilib variant is properly supported by cpukit/score/arm and the libnetworking cksum routines. If you have a non-RTEMS "no OS" arm-elf toolset which can produce working executables for you, then you are almost ready for a very minimal BSP. + Use the linker script as base with additions for workspace related symbols + Use the crt0.S from it (change call main -> boot_card) + implement a polled console using the libgloss support. + Use the "dummy idle task clock driver" At the moment, I think the avr, m32c, adn m32r BSPs are the closest examples to this minimal point. That gives you enough to run tests with no interrupts. Sebastian will need to step in for exception processing. > Any help, suggestions on this would be greatly appreciated! > > Thanks, > Mike > > _______________________________________________ > rtems-users mailing list > rtems-users at rtems.org > http://www.rtems.org/mailman/listinfo/rtems-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 From fgnicodemos at terra.com.br Fri Jul 24 16:28:48 2009 From: fgnicodemos at terra.com.br (Fernando Nicodemos) Date: Fri, 24 Jul 2009 13:28:48 -0300 Subject: Examples In-Reply-To: <5cbbb9e90907240720mf7bcb58t7d9fc9554c157b72@mail.gmail.com> Message-ID: Hi Andy, Thanks for the answer. So the implementation of Free BSD does not support PPP for rtems 4.8 and 4.9? Fernando On 7/24/09 11:20 AM, "Andrew Sporner" wrote: > Hi > > I am about 30% through on the porting of TCP/IP (7.1 FreeBSD) to Rtems 4.10 > and > this will include PPP. My end goal of August has slipped a little > bit, but thats not > surprising considering I am working already at 140% :-) > > Andy > > Esta mensagem foi verificada pelo E-mail Protegido Terra. > Atualizado em 24/07/2009 > From asporner at googlemail.com Fri Jul 24 18:16:49 2009 From: asporner at googlemail.com (Andrew Sporner) Date: Fri, 24 Jul 2009 20:16:49 +0200 Subject: Examples In-Reply-To: References: <5cbbb9e90907240720mf7bcb58t7d9fc9554c157b72@mail.gmail.com> Message-ID: <5cbbb9e90907241116n4d191fc9j48cb733b044b9dc2@mail.gmail.com> Hi Fernando, I have not tried to use it but it looks like its all there. I am working from an open project on the project list. I have been doing TCP/IP related things for over ten years now and it seemed like a good fit to my background. Now finally I am getting more time to focus on it more. Andy On Fri, Jul 24, 2009 at 6:28 PM, Fernando Nicodemos wrote: > Hi Andy, > > Thanks for the answer. > So the implementation of Free BSD does not support PPP for rtems 4.8 and > 4.9? > > Fernando > > > On 7/24/09 11:20 AM, "Andrew Sporner" wrote: > >> Hi >> >> I am about 30% through on the porting of TCP/IP (7.1 FreeBSD) to Rtems 4.10 >> and >> this will include PPP. ?My end goal of August has slipped a little >> bit, but thats not >> surprising considering I am working already at 140% :-) >> >> Andy >> >> Esta mensagem foi verificada pelo E-mail Protegido Terra. >> Atualizado em 24/07/2009 >> > > > From hiyangxi at gmail.com Sun Jul 26 13:13:26 2009 From: hiyangxi at gmail.com (xi yang) Date: Sun, 26 Jul 2009 23:13:26 +1000 Subject: [GSOC2009] Frame buffer support for PXA255 target of Skyeye simulator Message-ID: <552cfe40907260613x5b0b7884m685762703c0470e8@mail.gmail.com> Hi Joel, please adding "fb.h" and "skyeye_fb.h" to "libbsp/arm/gumstix/fb/fb.h" "libbsp/arm/gumstix/fb/skyeye_fb.h". Enable_lcd.patch is for gcc-testing frambuffer.patch is for RTEMS * Enable LCD option for gumstix of gcc-tesging Index: sim-scripts/gumstix.in =================================================================== RCS file: /usr1/CVS/gcc-testing/sim-scripts/gumstix.in,v retrieving revision 1.4 diff -u -r1.4 gumstix.in --- sim-scripts/gumstix.in 10 Jul 2009 17:07:22 -0000 1.4 +++ sim-scripts/gumstix.in 26 Jul 2009 13:07:18 -0000 @@ -43,6 +43,7 @@ mem_bank: map=I, type=RW, addr=0xB0000000, size=0x100000 mem_bank: map=I, type=RW, addr=0x40000000, size=0x4C000000 shutdown_device: addr=0xb0000000, max_ins=${limit}0000000 +lcd:state=on,type=pxa,mod=gtk EOF if [ ${coverage} = yes ] ; then echo "code_coverage: state=on, filename=${2}.cov, start=0xA0000000, end=0xA4000000" *Frame buffer support for pxa255 target of SKYEYE simulator Index: c/src/lib/libbsp/arm/gumstix/ChangeLog =================================================================== RCS file: /usr1/CVS/rtems/c/src/lib/libbsp/arm/gumstix/ChangeLog,v retrieving revision 1.7 diff -u -r1.7 ChangeLog --- c/src/lib/libbsp/arm/gumstix/ChangeLog 16 Jul 2009 23:18:12 -0000 1.7 +++ c/src/lib/libbsp/arm/gumstix/ChangeLog 26 Jul 2009 13:04:27 -0000 @@ -1,3 +1,9 @@ +2009-07-26 Xi Yang + * Makefile.am: Add fb/fb.c + * preinstall.am: Install skyeye_fb.h + * fb/fb.c, fb/skyeye_fb.h: Framebuffer support for skyeye simulator + * startup/memmap.c: Change the size of Map I/O to 1216M + 2009-07-16 Joel Sherrill * configure.ac: Rename BSP_BOOTCARD_OPTIONS to Index: c/src/lib/libbsp/arm/gumstix/Makefile.am =================================================================== RCS file: /usr1/CVS/rtems/c/src/lib/libbsp/arm/gumstix/Makefile.am,v retrieving revision 1.4 diff -u -r1.4 Makefile.am --- c/src/lib/libbsp/arm/gumstix/Makefile.am 10 Jul 2009 17:06:37 -0000 1.4 +++ c/src/lib/libbsp/arm/gumstix/Makefile.am 26 Jul 2009 13:04:27 -0000 @@ -40,6 +40,8 @@ libbsp_a_SOURCES += console/uarts.c ../../shared/console.c #abort libbsp_a_SOURCES += ../shared/abort/abort.c +#framebuffer +libbsp_a_SOURCES += fb/fb.c libbsp_a_LIBADD = ../../../libcpu/@RTEMS_CPU@/shared/arm920.rel \ ../../../libcpu/@RTEMS_CPU@/@RTEMS_CPU_MODEL@/clock.rel \ Index: c/src/lib/libbsp/arm/gumstix/preinstall.am =================================================================== RCS file: /usr1/CVS/rtems/c/src/lib/libbsp/arm/gumstix/preinstall.am,v retrieving revision 1.1 diff -u -r1.1 preinstall.am --- c/src/lib/libbsp/arm/gumstix/preinstall.am 4 Jun 2009 16:23:11 -0000 1.1 +++ c/src/lib/libbsp/arm/gumstix/preinstall.am 26 Jul 2009 13:04:27 -0000 @@ -41,6 +41,10 @@ $(INSTALL_DATA) $< $(PROJECT_INCLUDE)/bsp.h PREINSTALL_FILES += $(PROJECT_INCLUDE)/bsp.h +$(PROJECT_INCLUDE)/rtems/skyeye_fb.h: fb/skyeye_fb.h $(PROJECT_INCLUDE)/rtems/$(dirstamp) + $(INSTALL_DATA) $< $(PROJECT_INCLUDE)/rtems/skyeye_fb.h +PREINSTALL_FILES += $(PROJECT_INCLUDE)/rtems/skyeye_fb.h + $(PROJECT_INCLUDE)/tm27.h: include/tm27.h $(PROJECT_INCLUDE)/$(dirstamp) $(INSTALL_DATA) $< $(PROJECT_INCLUDE)/tm27.h PREINSTALL_FILES += $(PROJECT_INCLUDE)/tm27.h Index: c/src/lib/libbsp/arm/gumstix/startup/memmap.c =================================================================== RCS file: /usr1/CVS/rtems/c/src/lib/libbsp/arm/gumstix/startup/memmap.c,v retrieving revision 1.1 diff -u -r1.1 memmap.c --- c/src/lib/libbsp/arm/gumstix/startup/memmap.c 4 Jun 2009 16:23:11 -0000 1.1 +++ c/src/lib/libbsp/arm/gumstix/startup/memmap.c 26 Jul 2009 13:04:27 -0000 @@ -12,7 +12,7 @@ mmu_sect_map_t mem_map[] = { /* */ - {0x40000000, 0x40000000, 20, MMU_CACHE_NONE}, /*Map I/O*/ + {0x40000000, 0x40000000, 1216, MMU_CACHE_NONE}, /*Map I/O*/ {0xA0000000, 0x00000000, 1, MMU_CACHE_NONE}, /*sram*/ {0xA0000000, 0xA0000000, 64, MMU_CACHE_WBACK}, /* SDRAM */ {0x00000000, 0x00000000, 0, 0} /* The end */ Index: c/src/lib/libcpu/arm/ChangeLog =================================================================== RCS file: /usr1/CVS/rtems/c/src/lib/libcpu/arm/ChangeLog,v retrieving revision 1.61 diff -u -r1.61 ChangeLog --- c/src/lib/libcpu/arm/ChangeLog 17 Jul 2009 13:52:16 -0000 1.61 +++ c/src/lib/libcpu/arm/ChangeLog 26 Jul 2009 13:04:28 -0000 @@ -1,3 +1,6 @@ +2009-07-26 Xi Yang + * pxa255/include/pxa255.h: Add LCD related registers + 2009-07-15 Sebastian Huber * Makefile.am: Removed references to deleted file Index: c/src/lib/libcpu/arm/pxa255/include/pxa255.h =================================================================== RCS file: /usr1/CVS/rtems/c/src/lib/libcpu/arm/pxa255/include/pxa255.h,v retrieving revision 1.3 diff -u -r1.3 pxa255.h --- c/src/lib/libcpu/arm/pxa255/include/pxa255.h 10 Jul 2009 15:34:12 -0000 1.3 +++ c/src/lib/libcpu/arm/pxa255/include/pxa255.h 26 Jul 2009 13:04:28 -0000 @@ -106,4 +106,24 @@ #define PMC_PMNC_CCD (0x01 << 3) #define PMC_PMNC_PCD (0x01 << 4) +/*LCD*/ +#define LCCR0 (*(volatile word_t *)(0x44000000)) +#define LCCR1 (*(volatile word_t *)(0x44000004)) +#define LCCR2 (*(volatile word_t *)(0x44000008)) +#define LCCR3 (*(volatile word_t *)(0x4400000C)) + +#define FDADR0 (*(volatile word_t *)(0x44000200)) +#define FSADR0 (*(volatile word_t *)(0x44000204)) +#define FIDR0 (*(volatile word_t *)(0x44000208)) +#define LDCMD0 (*(volatile word_t *)(0x4400020C)) + +#define FDADR1 (*(volatile word_t *)(0x44000210)) +#define FSADR1 (*(volatile word_t *)(0x44000214)) +#define FIDR1 (*(volatile word_t *)(0x44000218)) +#define LDCMD1 (*(volatile word_t *)(0x4400021C)) + +#define LCCR0_ENB 0x00000001 +#define LCCR1_PPL 0x000003FF +#define LCCR2_LPP 0x000003FF +#define LCCR3_BPP 0x07000000 #endif -------------- next part -------------- A non-text attachment was scrubbed... Name: frambuffer.patch Type: text/x-patch Size: 4986 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: enable_lcd.patch Type: text/x-patch Size: 667 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: fb.c Type: text/x-csrc Size: 4408 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: skyeye_fb.h Type: text/x-chdr Size: 1003 bytes Desc: not available URL: From siddons at bnl.gov Sun Jul 26 14:45:00 2009 From: siddons at bnl.gov (D. Peter Siddons) Date: Sun, 26 Jul 2009 10:45:00 -0400 Subject: problem with iostream In-Reply-To: <4A4F87C3.2020903@oarcorp.com> References: <4A4F7C71.70003@bnl.gov> <4A4F87C3.2020903@oarcorp.com> Message-ID: <4A6C6BEC.2050707@bnl.gov> Hi Joel, My linkcmds file is closely similar to that in the uC5282 bsp. Although there are some differences in detail, I think all of the same sections are defined. I confess that linkcmds I find pretty opaque. I have attached it. Do you see any obvious omissions? Pete. Joel Sherrill wrote: > D. Peter Siddons wrote: >> I am upgrading my bsp to rtems-4.9 from 4.7. I took the tool rpms. I >> used alien to make debs and installed them on my Ubuntu Jaunty. I have >> got to the point where everything seems to build OK until it tries to >> link the iostream example. I get the following: >> >> 272/testsuites/samples/iostream' >> m68k-rtems4.9-g++ -B../../../../../uC5272/lib/ -specs bsp_specs >> -qrtems -m5200 -O4 -fomit-frame-pointer -m5200 -o >> cxx_iostream.exe init.o >> /opt/rtems-4.9/lib/gcc/m68k-rtems4.9/4.3.2/../../../../m68k-rtems4.9/bin/ld: >> error: no memory region specified for loadable section >> `.text._ZSt18__throw_bad_typeidv' >> collect2: ld returned 1 exit status >> >> Any suggestions? >> > > error: no memory region specified for loadable section > Compare the linker scripts in /opt with the one for your BSP. > Apparently there is a section not in your linkcmds. >> Pete. >> >> >> > > -- D. Peter Siddons Detector Development Group Leader National Synchrotron Light Source Brookhaven National Laboratory Upton, NY 11973 email: siddons at bnl.gov Phone: (631) 344-2738 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: linkcmds URL: From sebastian.huber at embedded-brains.de Sun Jul 26 15:08:21 2009 From: sebastian.huber at embedded-brains.de (Sebastian Huber) Date: Sun, 26 Jul 2009 17:08:21 +0200 Subject: Cortex-M3 support? In-Reply-To: <4A69C811.3000201@oarcorp.com> References: <830532.41038.qm@web180404.mail.gq1.yahoo.com> <4A69C811.3000201@oarcorp.com> Message-ID: <4A6C7165.5020302@embedded-brains.de> Hi, yes, the exception processing is completely different compared to the ARMv4 or ARMv5 architecture. The current ARM port is located mainly at 'cpukit/score/cpu/arm'. I guess that all assembler files under this directory are worthless for the Cortex. I would add the Cortex specific files to this directory and prefix them with cortex_*. In the general CPU files cpu.c, cpu_asm.S, cpu.h and cpu_asm.h we can use conditional compilation. I don't know if it is possible to write the NVIC support in a BSP independent fashion. CU Joel Sherrill wrote: > Mike Panetta wrote: > >> I have been looking at CVS head and noticed that there is no cortex-m3 support in RTEMS. Has anyone started work on this? If yes, is the code available somewhere? If no, where would one start a port for this ARM core? It does not seem to quite fit in with the current ARM code in that exception handling is somewhat different... Would one create a cortex-m3 directory under libcpu/arm,libbsp/arm, etc, or just put the code directly in the respective arm dir for this port? I don't think adding CPU support for this core would be such a big deal, its just figuring out where to put it... BSP support on the other hand may be another matter... >> >> >> > Sebastian Huber has been reworking the ARM exception code so > make sure you are on today's head and talking to him. > > In general terms, you want to start with the CPU core and > ignore the peripherals. > > + make sure the multilib variant is in the tools > + make sure the multilib variant is properly supported > by cpukit/score/arm and the libnetworking cksum routines. > > If you have a non-RTEMS "no OS" arm-elf toolset which can > produce working executables for you, then you are almost > ready for a very minimal BSP. > > + Use the linker script as base with additions for > workspace related symbols > + Use the crt0.S from it (change call main -> boot_card) > + implement a polled console using the libgloss support. > + Use the "dummy idle task clock driver" > > At the moment, I think the avr, m32c, adn m32r BSPs are the closest > examples to this minimal point. > > That gives you enough to run tests with no interrupts. > > Sebastian will need to step in for exception processing. > > >> Any help, suggestions on this would be greatly appreciated! >> >> Thanks, >> Mike >> >> _______________________________________________ >> rtems-users mailing list >> rtems-users at rtems.org >> http://www.rtems.org/mailman/listinfo/rtems-users >> >> > > > -- 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 at embedded-brains.de PGP : Public key available on request Diese Nachricht ist keine gesch?ftliche Mitteilung im Sinne des EHUG. From siddons at bnl.gov Sun Jul 26 16:10:45 2009 From: siddons at bnl.gov (D. Peter Siddons) Date: Sun, 26 Jul 2009 12:10:45 -0400 Subject: problem with iostream In-Reply-To: <4A6C6BEC.2050707@bnl.gov> References: <4A4F7C71.70003@bnl.gov> <4A4F87C3.2020903@oarcorp.com> <4A6C6BEC.2050707@bnl.gov> Message-ID: <4A6C8005.5030005@bnl.gov> OK, as usual, as soon as I make the post, I find the problem. THere were a bunch of missing trailing *'s in the linkcmds. Sorry to bother you. Pete. D. Peter Siddons wrote: > Hi Joel, > My linkcmds file is closely similar to that in the uC5282 bsp. > Although there are some differences in detail, I think all of the same > sections are defined. I confess that linkcmds I find pretty opaque. I > have attached it. Do you see any obvious omissions? > Pete. > > Joel Sherrill wrote: >> D. Peter Siddons wrote: >>> I am upgrading my bsp to rtems-4.9 from 4.7. I took the tool rpms. I >>> used alien to make debs and installed them on my Ubuntu Jaunty. I >>> have got to the point where everything seems to build OK until it >>> tries to link the iostream example. I get the following: >>> >>> 272/testsuites/samples/iostream' >>> m68k-rtems4.9-g++ -B../../../../../uC5272/lib/ -specs bsp_specs >>> -qrtems -m5200 -O4 -fomit-frame-pointer -m5200 -o >>> cxx_iostream.exe init.o >>> /opt/rtems-4.9/lib/gcc/m68k-rtems4.9/4.3.2/../../../../m68k-rtems4.9/bin/ld: >>> error: no memory region specified for loadable section >>> `.text._ZSt18__throw_bad_typeidv' >>> collect2: ld returned 1 exit status >>> >>> Any suggestions? >>> >> >> error: no memory region specified for loadable section >> Compare the linker scripts in /opt with the one for your BSP. >> Apparently there is a section not in your linkcmds. >>> Pete. >>> >>> >>> >> >> > > > ------------------------------------------------------------------------ > > _______________________________________________ > rtems-users mailing list > rtems-users at rtems.org > http://www.rtems.org/mailman/listinfo/rtems-users -- D. Peter Siddons Detector Development Group Leader National Synchrotron Light Source Brookhaven National Laboratory Upton, NY 11973 email: siddons at bnl.gov Phone: (631) 344-2738 From joel.sherrill at OARcorp.com Mon Jul 27 14:33:16 2009 From: joel.sherrill at OARcorp.com (Joel Sherrill) Date: Mon, 27 Jul 2009 09:33:16 -0500 Subject: [GSOC2009] Frame buffer support for PXA255 target of Skyeye simulator In-Reply-To: <552cfe40907260613x5b0b7884m685762703c0470e8@mail.gmail.com> References: <552cfe40907260613x5b0b7884m685762703c0470e8@mail.gmail.com> Message-ID: <4A6DBAAC.7080900@oarcorp.com> Hi, With Roxana's work on a framebuffer driver interface this raises questions for me. This is the second FB driver in the tree so let's do it right. + This is now going to be a standard type of driver like an RTC, Clock or Console. We should have a CONFIGURE_APPLICATION_NEEDS_FRAME_BUFFER_DRIVER in confdefs.h which means we need a standard framebuffer.h which defines the standard interface to this class of driver for configuration purposes. skyeye_fb.h is actually close to this .h file. + I have a feeling the LCD support in the BSP needs to be conditional on "ENABLE_LCD" and "on skyeye" for the skyeye specific variant. Unless the Skyeye and real hardware match for the LCD output. Then ENABLE_LCD is sufficient. You don't want the graphics memory area mapped unless the hardware is really there. + Does the testing script support enabling the LCD all the time imply that a graphics window always pops up? Most of the time we test automated with no graphics and in batch mode, so this would be bad. I think there needs to be an option to gdb-sim-run.in like -G for graphics enabled. + The csb337 has an ENABLE_LCD option which I think now might need to be ENABLE_GRAPHICS_ADAPTER or something more generic like that. Especially since we should use the same configure variable name across BSPs. Just trying to come up with a standard cross-BSP approach to configuring and enabling the support. Just to be clear, there is nothing really wrong with this patch technically. I am just trying to think very very broad and long term. We want this all to go in right the first time. :) --joel xi yang wrote: > Hi Joel, please adding "fb.h" and "skyeye_fb.h" to > "libbsp/arm/gumstix/fb/fb.h" "libbsp/arm/gumstix/fb/skyeye_fb.h". > Enable_lcd.patch is for gcc-testing > frambuffer.patch is for RTEMS > > * Enable LCD option for gumstix of gcc-tesging > > Index: sim-scripts/gumstix.in > =================================================================== > RCS file: /usr1/CVS/gcc-testing/sim-scripts/gumstix.in,v > retrieving revision 1.4 > diff -u -r1.4 gumstix.in > --- sim-scripts/gumstix.in 10 Jul 2009 17:07:22 -0000 1.4 > +++ sim-scripts/gumstix.in 26 Jul 2009 13:07:18 -0000 > @@ -43,6 +43,7 @@ > mem_bank: map=I, type=RW, addr=0xB0000000, size=0x100000 > mem_bank: map=I, type=RW, addr=0x40000000, size=0x4C000000 > shutdown_device: addr=0xb0000000, max_ins=${limit}0000000 > +lcd:state=on,type=pxa,mod=gtk > EOF > if [ ${coverage} = yes ] ; then > echo "code_coverage: state=on, filename=${2}.cov, start=0xA0000000, > end=0xA4000000" > > > > *Frame buffer support for pxa255 target of SKYEYE simulator > > Index: c/src/lib/libbsp/arm/gumstix/ChangeLog > =================================================================== > RCS file: /usr1/CVS/rtems/c/src/lib/libbsp/arm/gumstix/ChangeLog,v > retrieving revision 1.7 > diff -u -r1.7 ChangeLog > --- c/src/lib/libbsp/arm/gumstix/ChangeLog 16 Jul 2009 23:18:12 -0000 1.7 > +++ c/src/lib/libbsp/arm/gumstix/ChangeLog 26 Jul 2009 13:04:27 -0000 > @@ -1,3 +1,9 @@ > +2009-07-26 Xi Yang > + * Makefile.am: Add fb/fb.c > + * preinstall.am: Install skyeye_fb.h > + * fb/fb.c, fb/skyeye_fb.h: Framebuffer support for skyeye simulator > + * startup/memmap.c: Change the size of Map I/O to 1216M > + > 2009-07-16 Joel Sherrill > > * configure.ac: Rename BSP_BOOTCARD_OPTIONS to > Index: c/src/lib/libbsp/arm/gumstix/Makefile.am > =================================================================== > RCS file: /usr1/CVS/rtems/c/src/lib/libbsp/arm/gumstix/Makefile.am,v > retrieving revision 1.4 > diff -u -r1.4 Makefile.am > --- c/src/lib/libbsp/arm/gumstix/Makefile.am 10 Jul 2009 17:06:37 -0000 1.4 > +++ c/src/lib/libbsp/arm/gumstix/Makefile.am 26 Jul 2009 13:04:27 -0000 > @@ -40,6 +40,8 @@ > libbsp_a_SOURCES += console/uarts.c ../../shared/console.c > #abort > libbsp_a_SOURCES += ../shared/abort/abort.c > +#framebuffer > +libbsp_a_SOURCES += fb/fb.c > > libbsp_a_LIBADD = ../../../libcpu/@RTEMS_CPU@/shared/arm920.rel \ > ../../../libcpu/@RTEMS_CPU@/@RTEMS_CPU_MODEL@/clock.rel \ > Index: c/src/lib/libbsp/arm/gumstix/preinstall.am > =================================================================== > RCS file: /usr1/CVS/rtems/c/src/lib/libbsp/arm/gumstix/preinstall.am,v > retrieving revision 1.1 > diff -u -r1.1 preinstall.am > --- c/src/lib/libbsp/arm/gumstix/preinstall.am 4 Jun 2009 16:23:11 -0000 1.1 > +++ c/src/lib/libbsp/arm/gumstix/preinstall.am 26 Jul 2009 13:04:27 -0000 > @@ -41,6 +41,10 @@ > $(INSTALL_DATA) $< $(PROJECT_INCLUDE)/bsp.h > PREINSTALL_FILES += $(PROJECT_INCLUDE)/bsp.h > > +$(PROJECT_INCLUDE)/rtems/skyeye_fb.h: fb/skyeye_fb.h > $(PROJECT_INCLUDE)/rtems/$(dirstamp) > + $(INSTALL_DATA) $< $(PROJECT_INCLUDE)/rtems/skyeye_fb.h > +PREINSTALL_FILES += $(PROJECT_INCLUDE)/rtems/skyeye_fb.h > + > $(PROJECT_INCLUDE)/tm27.h: include/tm27.h $(PROJECT_INCLUDE)/$(dirstamp) > $(INSTALL_DATA) $< $(PROJECT_INCLUDE)/tm27.h > PREINSTALL_FILES += $(PROJECT_INCLUDE)/tm27.h > Index: c/src/lib/libbsp/arm/gumstix/startup/memmap.c > =================================================================== > RCS file: /usr1/CVS/rtems/c/src/lib/libbsp/arm/gumstix/startup/memmap.c,v > retrieving revision 1.1 > diff -u -r1.1 memmap.c > --- c/src/lib/libbsp/arm/gumstix/startup/memmap.c 4 Jun 2009 16:23:11 -0000 1.1 > +++ c/src/lib/libbsp/arm/gumstix/startup/memmap.c 26 Jul 2009 13:04:27 -0000 > @@ -12,7 +12,7 @@ > > mmu_sect_map_t mem_map[] = { > /* */ > - {0x40000000, 0x40000000, 20, MMU_CACHE_NONE}, /*Map I/O*/ > + {0x40000000, 0x40000000, 1216, MMU_CACHE_NONE}, /*Map I/O*/ > {0xA0000000, 0x00000000, 1, MMU_CACHE_NONE}, /*sram*/ > {0xA0000000, 0xA0000000, 64, MMU_CACHE_WBACK}, /* SDRAM */ > {0x00000000, 0x00000000, 0, 0} /* The end */ > Index: c/src/lib/libcpu/arm/ChangeLog > =================================================================== > RCS file: /usr1/CVS/rtems/c/src/lib/libcpu/arm/ChangeLog,v > retrieving revision 1.61 > diff -u -r1.61 ChangeLog > --- c/src/lib/libcpu/arm/ChangeLog 17 Jul 2009 13:52:16 -0000 1.61 > +++ c/src/lib/libcpu/arm/ChangeLog 26 Jul 2009 13:04:28 -0000 > @@ -1,3 +1,6 @@ > +2009-07-26 Xi Yang > + * pxa255/include/pxa255.h: Add LCD related registers > + > 2009-07-15 Sebastian Huber > > * Makefile.am: Removed references to deleted file > Index: c/src/lib/libcpu/arm/pxa255/include/pxa255.h > =================================================================== > RCS file: /usr1/CVS/rtems/c/src/lib/libcpu/arm/pxa255/include/pxa255.h,v > retrieving revision 1.3 > diff -u -r1.3 pxa255.h > --- c/src/lib/libcpu/arm/pxa255/include/pxa255.h 10 Jul 2009 15:34:12 -0000 1.3 > +++ c/src/lib/libcpu/arm/pxa255/include/pxa255.h 26 Jul 2009 13:04:28 -0000 > @@ -106,4 +106,24 @@ > #define PMC_PMNC_CCD (0x01 << 3) > #define PMC_PMNC_PCD (0x01 << 4) > > +/*LCD*/ > +#define LCCR0 (*(volatile word_t *)(0x44000000)) > +#define LCCR1 (*(volatile word_t *)(0x44000004)) > +#define LCCR2 (*(volatile word_t *)(0x44000008)) > +#define LCCR3 (*(volatile word_t *)(0x4400000C)) > + > +#define FDADR0 (*(volatile word_t *)(0x44000200)) > +#define FSADR0 (*(volatile word_t *)(0x44000204)) > +#define FIDR0 (*(volatile word_t *)(0x44000208)) > +#define LDCMD0 (*(volatile word_t *)(0x4400020C)) > + > +#define FDADR1 (*(volatile word_t *)(0x44000210)) > +#define FSADR1 (*(volatile word_t *)(0x44000214)) > +#define FIDR1 (*(volatile word_t *)(0x44000218)) > +#define LDCMD1 (*(volatile word_t *)(0x4400021C)) > + > +#define LCCR0_ENB 0x00000001 > +#define LCCR1_PPL 0x000003FF > +#define LCCR2_LPP 0x000003FF > +#define LCCR3_BPP 0x07000000 > #endif > -- 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 From hiyangxi at gmail.com Mon Jul 27 23:41:31 2009 From: hiyangxi at gmail.com (xi yang) Date: Tue, 28 Jul 2009 09:41:31 +1000 Subject: [GSOC2009] Frame buffer support for PXA255 target of Skyeye simulator In-Reply-To: <4A6DBAAC.7080900@oarcorp.com> References: <552cfe40907260613x5b0b7884m685762703c0470e8@mail.gmail.com> <4A6DBAAC.7080900@oarcorp.com> Message-ID: <552cfe40907271641w5c3c75aagfc9fab7d979962ce@mail.gmail.com> 2009/7/28 Joel Sherrill : > Hi, > > With Roxana's work on a framebuffer driver interface this raises > questions for me. This is the second FB driver in the tree so > let's do it right. > > + This is now going to be a standard type of driver like > an RTC, Clock or Console. We should have a > CONFIGURE_APPLICATION_NEEDS_FRAME_BUFFER_DRIVER > in confdefs.h which means we need a standard > framebuffer.h which defines the standard interface to > this class of driver for configuration purposes. > skyeye_fb.h is actually close to this .h file. Yeah. Otherwise, we have to add drivers to driver table manually. > > + I have a feeling the LCD support in the BSP needs to > be conditional on "ENABLE_LCD" and "on skyeye" for the > skyeye specific variant. Unless the Skyeye and real hardware > match for the LCD output. Then ENABLE_LCD is sufficient. > You don't want the graphics memory area mapped unless the > hardware is really there. > > + Does the testing script support enabling the LCD all the > time imply that a graphics window always pops up? > Most of the time we test automated with no graphics and > in batch mode, so this would be bad. I think there needs > to be an option to gdb-sim-run.in like -G for graphics enabled. Graphics windows pops up only when we write enable register for LCD. So, for other tests, it runs as without LCD. > > + The csb337 has an ENABLE_LCD option which I think now > might need to be ENABLE_GRAPHICS_ADAPTER or something > more generic like that. Especially since we should use the > same configure variable name across BSPs. > > Just trying to come up with a standard cross-BSP approach to > configuring and enabling the support. > > Just to be clear, there is nothing really wrong with this patch > technically. I am just trying to think very very broad and long > term. We want this all to go in right the first time. :) yeah, it is better have a cross-bsp framework. > > --joel > > xi yang wrote: >> Hi Joel, please adding "fb.h" and "skyeye_fb.h" to >> "libbsp/arm/gumstix/fb/fb.h" "libbsp/arm/gumstix/fb/skyeye_fb.h". >> Enable_lcd.patch is for gcc-testing >> frambuffer.patch is for RTEMS >> >> * Enable LCD option for gumstix of gcc-tesging >> >> Index: sim-scripts/gumstix.in >> =================================================================== >> RCS file: /usr1/CVS/gcc-testing/sim-scripts/gumstix.in,v >> retrieving revision 1.4 >> diff -u -r1.4 gumstix.in >> --- sim-scripts/gumstix.in ? ?10 Jul 2009 17:07:22 -0000 ? ? ?1.4 >> +++ sim-scripts/gumstix.in ? ?26 Jul 2009 13:07:18 -0000 >> @@ -43,6 +43,7 @@ >> ?mem_bank: map=I, type=RW, addr=0xB0000000, size=0x100000 >> ?mem_bank: map=I, type=RW, addr=0x40000000, size=0x4C000000 >> ?shutdown_device: addr=0xb0000000, max_ins=${limit}0000000 >> +lcd:state=on,type=pxa,mod=gtk >> ?EOF >> ?if [ ${coverage} = yes ] ; then >> ? ?echo "code_coverage: state=on, filename=${2}.cov, start=0xA0000000, >> end=0xA4000000" >> >> >> >> *Frame buffer support for pxa255 target of SKYEYE simulator >> >> Index: c/src/lib/libbsp/arm/gumstix/ChangeLog >> =================================================================== >> RCS file: /usr1/CVS/rtems/c/src/lib/libbsp/arm/gumstix/ChangeLog,v >> retrieving revision 1.7 >> diff -u -r1.7 ChangeLog >> --- c/src/lib/libbsp/arm/gumstix/ChangeLog ? ?16 Jul 2009 23:18:12 -0000 ? ? ?1.7 >> +++ c/src/lib/libbsp/arm/gumstix/ChangeLog ? ?26 Jul 2009 13:04:27 -0000 >> @@ -1,3 +1,9 @@ >> +2009-07-26 ? Xi Yang >> + ? ? * Makefile.am: Add fb/fb.c >> + ? ? * preinstall.am: Install skyeye_fb.h >> + ? ? * fb/fb.c, fb/skyeye_fb.h: Framebuffer support for skyeye simulator >> + ? ? * startup/memmap.c: Change the size of Map I/O to 1216M >> + >> ?2009-07-16 ? Joel Sherrill >> >> ? ? ? * configure.ac: Rename BSP_BOOTCARD_OPTIONS to >> Index: c/src/lib/libbsp/arm/gumstix/Makefile.am >> =================================================================== >> RCS file: /usr1/CVS/rtems/c/src/lib/libbsp/arm/gumstix/Makefile.am,v >> retrieving revision 1.4 >> diff -u -r1.4 Makefile.am >> --- c/src/lib/libbsp/arm/gumstix/Makefile.am ?10 Jul 2009 17:06:37 -0000 ? ? ?1.4 >> +++ c/src/lib/libbsp/arm/gumstix/Makefile.am ?26 Jul 2009 13:04:27 -0000 >> @@ -40,6 +40,8 @@ >> ?libbsp_a_SOURCES += console/uarts.c ../../shared/console.c >> ?#abort >> ?libbsp_a_SOURCES += ../shared/abort/abort.c >> +#framebuffer >> +libbsp_a_SOURCES += fb/fb.c >> >> ?libbsp_a_LIBADD = ../../../libcpu/@RTEMS_CPU@/shared/arm920.rel \ >> ? ? ?../../../libcpu/@RTEMS_CPU@/@RTEMS_CPU_MODEL@/clock.rel \ >> Index: c/src/lib/libbsp/arm/gumstix/preinstall.am >> =================================================================== >> RCS file: /usr1/CVS/rtems/c/src/lib/libbsp/arm/gumstix/preinstall.am,v >> retrieving revision 1.1 >> diff -u -r1.1 preinstall.am >> --- c/src/lib/libbsp/arm/gumstix/preinstall.am ? ? ? ?4 Jun 2009 16:23:11 -0000 ? ? ? 1.1 >> +++ c/src/lib/libbsp/arm/gumstix/preinstall.am ? ? ? ?26 Jul 2009 13:04:27 -0000 >> @@ -41,6 +41,10 @@ >> ? ? ? $(INSTALL_DATA) $< $(PROJECT_INCLUDE)/bsp.h >> ?PREINSTALL_FILES += $(PROJECT_INCLUDE)/bsp.h >> >> +$(PROJECT_INCLUDE)/rtems/skyeye_fb.h: fb/skyeye_fb.h >> $(PROJECT_INCLUDE)/rtems/$(dirstamp) >> + ? ? $(INSTALL_DATA) $< $(PROJECT_INCLUDE)/rtems/skyeye_fb.h >> +PREINSTALL_FILES += $(PROJECT_INCLUDE)/rtems/skyeye_fb.h >> + >> ?$(PROJECT_INCLUDE)/tm27.h: include/tm27.h $(PROJECT_INCLUDE)/$(dirstamp) >> ? ? ? $(INSTALL_DATA) $< $(PROJECT_INCLUDE)/tm27.h >> ?PREINSTALL_FILES += $(PROJECT_INCLUDE)/tm27.h >> Index: c/src/lib/libbsp/arm/gumstix/startup/memmap.c >> =================================================================== >> RCS file: /usr1/CVS/rtems/c/src/lib/libbsp/arm/gumstix/startup/memmap.c,v >> retrieving revision 1.1 >> diff -u -r1.1 memmap.c >> --- c/src/lib/libbsp/arm/gumstix/startup/memmap.c ? ? 4 Jun 2009 16:23:11 -0000 ? ? ? 1.1 >> +++ c/src/lib/libbsp/arm/gumstix/startup/memmap.c ? ? 26 Jul 2009 13:04:27 -0000 >> @@ -12,7 +12,7 @@ >> >> ?mmu_sect_map_t mem_map[] = { >> ?/* ? ? */ >> - ?{0x40000000, 0x40000000, ?20, ? MMU_CACHE_NONE}, ?/*Map I/O*/ >> + ?{0x40000000, 0x40000000, ?1216, ? MMU_CACHE_NONE}, ?/*Map I/O*/ >> ? ?{0xA0000000, 0x00000000, ? 1, ? MMU_CACHE_NONE}, ?/*sram*/ >> ? ?{0xA0000000, 0xA0000000, ?64, ? MMU_CACHE_WBACK}, /* SDRAM */ >> ? ?{0x00000000, 0x00000000, ? 0, ? 0} ? ? ? ? ? ? ? ?/* The end */ >> Index: c/src/lib/libcpu/arm/ChangeLog >> =================================================================== >> RCS file: /usr1/CVS/rtems/c/src/lib/libcpu/arm/ChangeLog,v >> retrieving revision 1.61 >> diff -u -r1.61 ChangeLog >> --- c/src/lib/libcpu/arm/ChangeLog ? ?17 Jul 2009 13:52:16 -0000 ? ? ?1.61 >> +++ c/src/lib/libcpu/arm/ChangeLog ? ?26 Jul 2009 13:04:28 -0000 >> @@ -1,3 +1,6 @@ >> +2009-07-26 ? Xi Yang >> + ? ? * pxa255/include/pxa255.h: Add LCD related registers >> + >> ?2009-07-15 ? Sebastian Huber >> >> ? ? ? * Makefile.am: Removed references to deleted file >> Index: c/src/lib/libcpu/arm/pxa255/include/pxa255.h >> =================================================================== >> RCS file: /usr1/CVS/rtems/c/src/lib/libcpu/arm/pxa255/include/pxa255.h,v >> retrieving revision 1.3 >> diff -u -r1.3 pxa255.h >> --- c/src/lib/libcpu/arm/pxa255/include/pxa255.h ? ? ?10 Jul 2009 15:34:12 -0000 ? ? ?1.3 >> +++ c/src/lib/libcpu/arm/pxa255/include/pxa255.h ? ? ?26 Jul 2009 13:04:28 -0000 >> @@ -106,4 +106,24 @@ >> ?#define PMC_PMNC_CCD (0x01 << 3) >> ?#define PMC_PMNC_PCD (0x01 << 4) >> >> +/*LCD*/ >> +#define LCCR0 ?(*(volatile word_t *)(0x44000000)) >> +#define LCCR1 ?(*(volatile word_t *)(0x44000004)) >> +#define LCCR2 ?(*(volatile word_t *)(0x44000008)) >> +#define LCCR3 ?(*(volatile word_t *)(0x4400000C)) >> + >> +#define FDADR0 ?(*(volatile word_t *)(0x44000200)) >> +#define FSADR0 ?(*(volatile word_t *)(0x44000204)) >> +#define FIDR0 ? (*(volatile word_t *)(0x44000208)) >> +#define LDCMD0 ?(*(volatile word_t *)(0x4400020C)) >> + >> +#define FDADR1 ?(*(volatile word_t *)(0x44000210)) >> +#define FSADR1 ?(*(volatile word_t *)(0x44000214)) >> +#define FIDR1 ? (*(volatile word_t *)(0x44000218)) >> +#define LDCMD1 ?(*(volatile word_t *)(0x4400021C)) >> + >> +#define LCCR0_ENB ? ? ? 0x00000001 >> +#define LCCR1_PPL ? ? ? 0x000003FF >> +#define LCCR2_LPP ? ? ? 0x000003FF >> +#define LCCR3_BPP ? ? ? 0x07000000 >> ?#endif >> > > > -- > 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 > > > From hiyangxi at gmail.com Tue Jul 28 01:19:52 2009 From: hiyangxi at gmail.com (xi yang) Date: Tue, 28 Jul 2009 11:19:52 +1000 Subject: shut down device support for edb7312 Message-ID: <552cfe40907271819k161f7de0iebac73b0ba6404f1@mail.gmail.com> Hi joel, shutdown_edb7312 is for gcc-testing. The other is for RTEMS. For gcc-testing: Index: sim-scripts/edb7312.in =================================================================== RCS file: /usr1/CVS/gcc-testing/sim-scripts/edb7312.in,v retrieving revision 1.5 diff -u -r1.5 edb7312.in --- sim-scripts/edb7312.in 20 Mar 2009 19:41:25 -0000 1.5 +++ sim-scripts/edb7312.in 28 Jul 2009 01:09:52 -0000 @@ -5,7 +5,7 @@ # ##INSERT SKYEYE SUPPORT HERE - +bspSimTrustedToExit="yes" runARGS() { echo "-c ${bspTreeFile} -e ${1}" @@ -29,6 +29,7 @@ mem_bank: map=I,type=RW, addr=0x80000000, size=0x00100000 mem_bank: map=M, type=RW, addr=0x00000000, size=0x1000000 uart: mod=pipe, desc_in=/dev/null, desc_out=/dev/stdout +shutdown_device: addr=0xb0000000, max_ins=${limit}0000000 EOF if [ ${coverage} = yes ] ; then This is for RTEMS: Index: c/src/lib/libbsp/arm/edb7312/ChangeLog =================================================================== RCS file: /usr1/CVS/rtems/c/src/lib/libbsp/arm/edb7312/ChangeLog,v retrieving revision 1.100 diff -u -r1.100 ChangeLog --- c/src/lib/libbsp/arm/edb7312/ChangeLog 17 Jul 2009 13:53:04 -0000 1.100 +++ c/src/lib/libbsp/arm/edb7312/ChangeLog 28 Jul 2009 01:13:23 -0000 @@ -1,3 +1,7 @@ +2009-07-28 Xi Yang + * configure.ac: undefine BSP_PREE_KEY_FOR_RESET + * startup/bspreset.c, include/ep7312.h: Support skyeye shutdown device + 2009-07-16 Joel Sherrill * configure.ac: Rename BSP_BOOTCARD_OPTIONS to Index: c/src/lib/libbsp/arm/edb7312/configure.ac =================================================================== RCS file: /usr1/CVS/rtems/c/src/lib/libbsp/arm/edb7312/configure.ac,v retrieving revision 1.18 diff -u -r1.18 configure.ac --- c/src/lib/libbsp/arm/edb7312/configure.ac 16 Jul 2009 23:18:09 -0000 1.18 +++ c/src/lib/libbsp/arm/edb7312/configure.ac 28 Jul 2009 01:13:23 -0000 @@ -26,7 +26,7 @@ the wall time required to execute the RTEMS test suites.]) RTEMS_BSP_BOOTCARD_OPTIONS -RTEMS_BSP_CLEANUP_OPTIONS(1, 1) +RTEMS_BSP_CLEANUP_OPTIONS(0, 1) # Explicitly list all Makefiles here AC_CONFIG_FILES([Makefile]) Index: c/src/lib/libbsp/arm/edb7312/include/ep7312.h =================================================================== RCS file: /usr1/CVS/rtems/c/src/lib/libbsp/arm/edb7312/include/ep7312.h,v retrieving revision 1.4 diff -u -r1.4 ep7312.h --- c/src/lib/libbsp/arm/edb7312/include/ep7312.h 21 Apr 2004 10:42:43 -0000 1.4 +++ c/src/lib/libbsp/arm/edb7312/include/ep7312.h 28 Jul 2009 01:13:23 -0000 @@ -153,4 +153,7 @@ /* INTR3 (Interrupt 3) mask/status register bits */ #define EP7312_INTR2_DAIINT 0x00000001 +/*Write to SKYEYE_MAGIC_ADDRESS to make SKYEYE exit*/ + +#define SKYEYE_MAGIC_ADDRESS (*(volatile unsigned int *)(0xb0000000)) #endif /* __EP7312_H__ */ Index: c/src/lib/libbsp/arm/edb7312/startup/bspreset.c =================================================================== RCS file: /usr1/CVS/rtems/c/src/lib/libbsp/arm/edb7312/startup/bspreset.c,v retrieving revision 1.2 diff -u -r1.2 bspreset.c --- c/src/lib/libbsp/arm/edb7312/startup/bspreset.c 12 Jul 2009 13:59:09 -0000 1.2 +++ c/src/lib/libbsp/arm/edb7312/startup/bspreset.c 28 Jul 2009 01:13:23 -0000 @@ -9,12 +9,13 @@ */ #include +#include void bsp_reset(void) { - #if ON_SKYEYE - /* TBD use Skyeye reset device */ - #else - asm volatile ("b _start"); - #endif +#if ON_SKYEYE == 1 + SKYEYE_MAGIC_ADDRESS = 0xff; +#else + asm volatile ("b _start"); +#endif } -------------- next part -------------- A non-text attachment was scrubbed... Name: shutdown_edb7312.patch Type: text/x-patch Size: 740 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: support_skyeye_shutdown_edb7312.patch Type: text/x-patch Size: 2682 bytes Desc: not available URL: From W.M.Grim at sron.nl Tue Jul 28 07:12:54 2009 From: W.M.Grim at sron.nl (Martin Grim) Date: Tue, 28 Jul 2009 09:12:54 +0200 Subject: C compiler cannot create executables Message-ID: <4A6EC116020000960000C2B2@pluto.sron.nl> Hi folks, I ran into the "C compiler cannot create executables" error. I did follow the remark on the wiki to fix my c compiler with the "apt-get install libc-dev". However, the problem remains. Does anybode have an other lead which I could follow to solve this? Regards, Martin -- ir. W.M. Grim SRON Netherlands Institute for Space Research Sorbonnelaan 2 3584 CA Utrecht, The Netherlands www.sron.nl From Thomas.Doerfler at embedded-brains.de Tue Jul 28 07:23:13 2009 From: Thomas.Doerfler at embedded-brains.de (Thomas Doerfler) Date: Tue, 28 Jul 2009 09:23:13 +0200 Subject: C compiler cannot create executables In-Reply-To: <4A6EC116020000960000C2B2@pluto.sron.nl> References: <4A6EC116020000960000C2B2@pluto.sron.nl> Message-ID: <4A6EA761.20305@embedded-brains.de> Martin, can you give us more information? Specifically: - which host OS / host CPU class (32 bit/64 bit) - which RTEMS tool versions - which autoconf/automake version - which target (I assume LEON?) - which PATH have you when trying to build the compiler - how did you configure the compiler? - did you already install the proper binutils first? Thank you, Thomas. Martin Grim wrote: > Hi folks, > > I ran into the "C compiler cannot create executables" error. I did follow the remark on the wiki to fix my c compiler with the "apt-get install libc-dev". However, the problem remains. Does anybode have an other lead which I could follow to solve this? > > Regards, > > Martin > > -- -------------------------------------------- Embedded Brains GmbH Thomas Doerfler Obere Lagerstrasse 30 D-82178 Puchheim Germany email: Thomas.Doerfler at embedded-brains.de Phone: +49-89-18908079-2 Fax: +49-89-18908079-9 From dirk.heinrichs at online.de Tue Jul 28 08:53:20 2009 From: dirk.heinrichs at online.de (Dirk Heinrichs) Date: Tue, 28 Jul 2009 10:53:20 +0200 Subject: C compiler cannot create executables In-Reply-To: <4A6EC116020000960000C2B2@pluto.sron.nl> References: <4A6EC116020000960000C2B2@pluto.sron.nl> Message-ID: <200907281053.26746.dirk.heinrichs@online.de> Am Dienstag 28 Juli 2009 09:12:54 schrieb Martin Grim: > I ran into the "C compiler cannot create executables" error. I did follow > the remark on the wiki to fix my c compiler with the "apt-get install > libc-dev". However, the problem remains. Does anybode have an other lead > which I could follow to solve this? What is the command you run when the error occurs? What's its output? Bye... Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From W.M.Grim at sron.nl Tue Jul 28 11:11:59 2009 From: W.M.Grim at sron.nl (Martin Grim) Date: Tue, 28 Jul 2009 13:11:59 +0200 Subject: C compiler cannot create executables In-Reply-To: <4A6EA761.20305@embedded-brains.de> References: <4A6EC116020000960000C2B2@pluto.sron.nl> <4A6EA761.20305@embedded-brains.de> Message-ID: <4A6EF91F020000960000C2C7@pluto.sron.nl> Hi, > - did you already install the proper binutils first? This seemed to be the problem: the binutils, etc. where installed after the configure was run. Now that I've changed the order, everything build oke.' Thanks for the hint. Martin -- ir. W.M. Grim SRON Netherlands Institute for Space Research Sorbonnelaan 2 3584 CA Utrecht, The Netherlands www.sron.nl From joel.sherrill at OARcorp.com Tue Jul 28 19:42:46 2009 From: joel.sherrill at OARcorp.com (Joel Sherrill) Date: Tue, 28 Jul 2009 14:42:46 -0500 Subject: Virtex PPC440 Message-ID: <4A6F54B6.7020301@oarcorp.com> Hi, Does anyone out there have a BSP for this or is working on it? -- 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 From mprtems at bellsouth.net Wed Jul 29 01:54:02 2009 From: mprtems at bellsouth.net (Mike Panetta) Date: Tue, 28 Jul 2009 18:54:02 -0700 (PDT) Subject: Cortex-M3 support? In-Reply-To: <4A69C811.3000201@oarcorp.com> References: <830532.41038.qm@web180404.mail.gq1.yahoo.com> <4A69C811.3000201@oarcorp.com> Message-ID: <394292.68170.qm@web180415.mail.gq1.yahoo.com> ----- Original Message ---- > From: Joel Sherrill > To: Mike Panetta ; "rtems-users at rtems.org" > Sent: Friday, July 24, 2009 10:41:21 AM > Subject: Re: Cortex-M3 support? > > Sebastian Huber has been reworking the ARM exception code so > make sure you are on today's head and talking to him. I don't have his email address, should it be in the list archives? He has not posted recently in reply to this message, so I am not quite sure how to contact him. > > In general terms, you want to start with the CPU core and > ignore the peripherals. > > + make sure the multilib variant is in the tools > + make sure the multilib variant is properly supported > by cpukit/score/arm and the libnetworking cksum routines. Its in the tools, but the score code seems to be dependent on non thumb ASM so it will not compile for the Cortex-M3. Specifically the context switching code is explicitly in ARM mode. > > If you have a non-RTEMS "no OS" arm-elf toolset which can > produce working executables for you, then you are almost > ready for a very minimal BSP. > > + Use the linker script as base with additions for > workspace related symbols > + Use the crt0.S from it (change call main -> boot_card) > + implement a polled console using the libgloss support. > + Use the "dummy idle task clock driver" As soon as I can figure the best way to get the score code to compile that will be my next step, using the rtems supplied tools. :) > > At the moment, I think the avr, m32c, adn m32r BSPs are the closest > examples to this minimal point. > > That gives you enough to run tests with no interrupts. > > Sebastian will need to step in for exception processing. Waiting to hear from him. > Thanks again, Mike > > -- 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 From rayx.cn at gmail.com Wed Jul 29 03:25:41 2009 From: rayx.cn at gmail.com (xu ray) Date: Wed, 29 Jul 2009 11:25:41 +0800 Subject: Cortex-M3 support? In-Reply-To: <394292.68170.qm@web180415.mail.gq1.yahoo.com> References: <830532.41038.qm@web180404.mail.gq1.yahoo.com> <4A69C811.3000201@oarcorp.com> <394292.68170.qm@web180415.mail.gq1.yahoo.com> Message-ID: <454f44fc0907282025u2dba421n5843cec170ba5495@mail.gmail.com> 2009/7/29 Mike Panetta > > > > > > ----- Original Message ---- > > From: Joel Sherrill > > To: Mike Panetta ; "rtems-users at rtems.org" < > rtems-users at rtems.org> > > Sent: Friday, July 24, 2009 10:41:21 AM > > Subject: Re: Cortex-M3 support? > > > > Sebastian Huber has been reworking the ARM exception code so > > make sure you are on today's head and talking to him. > > I don't have his email address, should it be in the list archives? > He has not posted recently in reply to this message, so I am > not quite sure how to contact him. > Add Sebastian Huber in the loop. He might be busy with LPC porting now. > > > > > In general terms, you want to start with the CPU core and > > ignore the peripherals. > > > > + make sure the multilib variant is in the tools > > + make sure the multilib variant is properly supported > > by cpukit/score/arm and the libnetworking cksum routines. > > Its in the tools, but the score code seems to be dependent on > non thumb ASM so it will not compile for the Cortex-M3. > > Specifically the context switching code is explicitly in ARM mode. > You can refer to make/custom/rtl22xx_t.cfg and rtl22xx_t BSP. This is a Thumb BSP. Try the "-mcpu=cortex-m3 -mthumb" flag for cortext-m3. I think no one have ever tried the cortex-m3 flag with rtems tool chain yet, hoping it works for you. Btw, minimum code size for rtl22xx_t is about 16K with 2K .bss/.data space, and the binary removed the filesystem and libc overhead. What is your requirement for RAM and ROM space? For the assembly code. The cortex family does not need to change to ARM mode when run the privilege instructions. So you can change the mode switch macro like align. Furthermore, cortex adds some registers like basepri, psp which is critical to the thread switch. You will have to add code to handle these. > > > > > If you have a non-RTEMS "no OS" arm-elf toolset which can > > produce working executables for you, then you are almost > > ready for a very minimal BSP. > > > > + Use the linker script as base with additions for > > workspace related symbols > > + Use the crt0.S from it (change call main -> boot_card) > > + implement a polled console using the libgloss support. > > + Use the "dummy idle task clock driver" > > As soon as I can figure the best way to get the score code to > compile that will be my next step, using the rtems supplied tools. :) > > > > > At the moment, I think the avr, m32c, adn m32r BSPs are the closest > > examples to this minimal point. > > > > That gives you enough to run tests with no interrupts. > > > > Sebastian will need to step in for exception processing. > > Waiting to hear from him. > > > > > Thanks again, > Mike > > > > > -- 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 > > _______________________________________________ > rtems-users mailing list > rtems-users at rtems.org > http://www.rtems.org/mailman/listinfo/rtems-users > -- Thanks & Best Regards! Ray, Xu PEP Technology -------------- next part -------------- An HTML attachment was scrubbed... URL: From sebastian.huber at embedded-brains.de Wed Jul 29 07:44:40 2009 From: sebastian.huber at embedded-brains.de (Sebastian Huber) Date: Wed, 29 Jul 2009 09:44:40 +0200 Subject: Automake question Message-ID: <4A6FFDE8.7060603@embedded-brains.de> Hi, for a BSP I need to compile one module with non standard CFLAGS. How can I do this? Unfortunately this will not work: noinst_PROGRAMS = starthooks.rel starthooks_rel_SOURCES = startup/bspstarthooks.c starthooks_rel_CFLAGS = $(NON_STANDARD_CFLAGS) libbsp_a_LIBADD = starthooks.rel Automake still uses the $(CFLAGS) which contains all the $(CPU_CFLAGS). 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 at embedded-brains.de PGP : Public key available on request Diese Nachricht ist keine gesch?ftliche Mitteilung im Sinne des EHUG. From ralf.corsepius at rtems.org Wed Jul 29 07:59:02 2009 From: ralf.corsepius at rtems.org (Ralf Corsepius) Date: Wed, 29 Jul 2009 09:59:02 +0200 Subject: Automake question In-Reply-To: <4A6FFDE8.7060603@embedded-brains.de> References: <4A6FFDE8.7060603@embedded-brains.de> Message-ID: <4A700146.9030403@rtems.org> On 07/29/2009 09:44 AM, Sebastian Huber wrote: > Hi, > > for a BSP I need to compile one module with non standard CFLAGS. Why? Under normal circumstances, you don't want to do this. In almost 100% of all cases, doing so is a bug. Ralf From sebastian.huber at embedded-brains.de Wed Jul 29 08:04:50 2009 From: sebastian.huber at embedded-brains.de (Sebastian Huber) Date: Wed, 29 Jul 2009 10:04:50 +0200 Subject: Automake question In-Reply-To: <4A700146.9030403@rtems.org> References: <4A6FFDE8.7060603@embedded-brains.de> <4A700146.9030403@rtems.org> Message-ID: <4A7002A2.7060400@embedded-brains.de> Ralf Corsepius wrote: > On 07/29/2009 09:44 AM, Sebastian Huber wrote: >> Hi, >> >> for a BSP I need to compile one module with non standard CFLAGS. > Why? Under normal circumstances, you don't want to do this. > In almost 100% of all cases, doing so is a bug. > > Ralf On the ARMv4 architecture you have two instruction sets: ARM and THUMB. I have to compile one module with ARM instructions only (because some low level stuff requires ARM mode): CPU_FLAGS without -mthumb. The rest of the BSP will use THUMB instructions: CPU_FLAGS with -mthumb. -- 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 at embedded-brains.de PGP : Public key available on request Diese Nachricht ist keine gesch?ftliche Mitteilung im Sinne des EHUG. From ralf.corsepius at rtems.org Wed Jul 29 11:09:57 2009 From: ralf.corsepius at rtems.org (Ralf Corsepius) Date: Wed, 29 Jul 2009 13:09:57 +0200 Subject: Automake question In-Reply-To: <4A7002A2.7060400@embedded-brains.de> References: <4A6FFDE8.7060603@embedded-brains.de> <4A700146.9030403@rtems.org> <4A7002A2.7060400@embedded-brains.de> Message-ID: <4A702E05.9020504@rtems.org> On 07/29/2009 10:04 AM, Sebastian Huber wrote: > Ralf Corsepius wrote: >> On 07/29/2009 09:44 AM, Sebastian Huber wrote: >>> Hi, >>> >>> for a BSP I need to compile one module with non standard CFLAGS. >> Why? Under normal circumstances, you don't want to do this. >> In almost 100% of all cases, doing so is a bug. >> >> Ralf > > On the ARMv4 architecture you have two instruction sets: ARM and THUMB. I have > to compile one module with ARM instructions only (because some low level stuff > requires ARM mode): CPU_FLAGS without -mthumb. The rest of the BSP will use > THUMB instructions: CPU_FLAGS with -mthumb. That's your bug. Arm and thumb are different architectures, which must not be mixed. Ralf From sebastian.huber at embedded-brains.de Wed Jul 29 11:39:20 2009 From: sebastian.huber at embedded-brains.de (Sebastian Huber) Date: Wed, 29 Jul 2009 13:39:20 +0200 Subject: Automake question In-Reply-To: <4A702E05.9020504@rtems.org> References: <4A6FFDE8.7060603@embedded-brains.de> <4A700146.9030403@rtems.org> <4A7002A2.7060400@embedded-brains.de> <4A702E05.9020504@rtems.org> Message-ID: <4A7034E8.8080102@embedded-brains.de> Ralf Corsepius wrote: > On 07/29/2009 10:04 AM, Sebastian Huber wrote: >> Ralf Corsepius wrote: >>> On 07/29/2009 09:44 AM, Sebastian Huber wrote: >>>> Hi, >>>> >>>> for a BSP I need to compile one module with non standard CFLAGS. >>> Why? Under normal circumstances, you don't want to do this. >>> In almost 100% of all cases, doing so is a bug. >>> >>> Ralf >> On the ARMv4 architecture you have two instruction sets: ARM and THUMB. I have >> to compile one module with ARM instructions only (because some low level stuff >> requires ARM mode): CPU_FLAGS without -mthumb. The rest of the BSP will use >> THUMB instructions: CPU_FLAGS with -mthumb. > > That's your bug. Arm and thumb are different architectures, which must > not be mixed. This is definitely not a bug. The exception processing for example starts in ARM mode. It is also possible to mix THUMB and ARM functions. This is called interworking. If you need position independent code you have to use ARM. -- 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 at embedded-brains.de PGP : Public key available on request Diese Nachricht ist keine gesch?ftliche Mitteilung im Sinne des EHUG. From Thomas.Doerfler at embedded-brains.de Wed Jul 29 12:16:43 2009 From: Thomas.Doerfler at embedded-brains.de (Thomas Doerfler) Date: Wed, 29 Jul 2009 14:16:43 +0200 Subject: Automake question In-Reply-To: <4A702E05.9020504@rtems.org> References: <4A6FFDE8.7060603@embedded-brains.de> <4A700146.9030403@rtems.org> <4A7002A2.7060400@embedded-brains.de> <4A702E05.9020504@rtems.org> Message-ID: <4A703DAB.3020106@embedded-brains.de> Ralf, Ralf Corsepius wrote: > On 07/29/2009 10:04 AM, Sebastian Huber wrote: >> Ralf Corsepius wrote: >>> On 07/29/2009 09:44 AM, Sebastian Huber wrote: >>>> Hi, >>>> >>>> for a BSP I need to compile one module with non standard CFLAGS. >>> Why? Under normal circumstances, you don't want to do this. >>> In almost 100% of all cases, doing so is a bug. >>> >>> Ralf >> On the ARMv4 architecture you have two instruction sets: ARM and THUMB. I have >> to compile one module with ARM instructions only (because some low level stuff >> requires ARM mode): CPU_FLAGS without -mthumb. The rest of the BSP will use >> THUMB instructions: CPU_FLAGS with -mthumb. > > That's your bug. Arm and thumb are different architectures, which must > not be mixed. >From ARM7TDMIvE.pdf, chapter 3.9.1: "If the processor is in THUMB state when an exception occurs, it will automatically switch into ARM state when the PC is loaded with the exception vector address." We have a ARM7 system with a 16 bit external memory bus. Using Thumb mode here gives us substantially more performance, b ut the exception entry MUST be coded as ARM code. So we really have to intermix both instruction sets (which is a "normal" way to work). So it would really help to pass special CFLAGs to certain modules. I understand, that usage of such a mechanism should be limited, though, to avoid to get the whole tree unmaintainable. wkr, Thomas. > > Ralf > > > > _______________________________________________ > rtems-users mailing list > rtems-users at rtems.org > http://www.rtems.org/mailman/listinfo/rtems-users -- -------------------------------------------- Embedded Brains GmbH Thomas Doerfler Obere Lagerstrasse 30 D-82178 Puchheim Germany email: Thomas.Doerfler at embedded-brains.de Phone: +49-89-18908079-2 Fax: +49-89-18908079-9 From ralf.corsepius at rtems.org Wed Jul 29 13:49:10 2009 From: ralf.corsepius at rtems.org (Ralf Corsepius) Date: Wed, 29 Jul 2009 15:49:10 +0200 Subject: Automake question In-Reply-To: <4A7034E8.8080102@embedded-brains.de> References: <4A6FFDE8.7060603@embedded-brains.de> <4A700146.9030403@rtems.org> <4A7002A2.7060400@embedded-brains.de> <4A702E05.9020504@rtems.org> <4A7034E8.8080102@embedded-brains.de> Message-ID: <4A705356.2040601@rtems.org> On 07/29/2009 01:39 PM, Sebastian Huber wrote: > The exception processing for example starts in > ARM mode. It is also possible to mix THUMB and ARM functions. This is called > interworking. That's not how GCC works. For it, thumb-interworking is yet another architectural variant (multilib) of the arm (unsupported in rtems). Ralf From sebastian.huber at embedded-brains.de Wed Jul 29 14:20:55 2009 From: sebastian.huber at embedded-brains.de (Sebastian Huber) Date: Wed, 29 Jul 2009 16:20:55 +0200 Subject: Automake question In-Reply-To: <4A6FFDE8.7060603@embedded-brains.de> References: <4A6FFDE8.7060603@embedded-brains.de> Message-ID: <4A705AC7.2010509@embedded-brains.de> Sebastian Huber wrote: > Hi, > > for a BSP I need to compile one module with non standard CFLAGS. How can I do > this? Unfortunately this will not work: > > noinst_PROGRAMS = starthooks.rel > > starthooks_rel_SOURCES = startup/bspstarthooks.c > starthooks_rel_CFLAGS = $(NON_STANDARD_CFLAGS) > > libbsp_a_LIBADD = starthooks.rel > > Automake still uses the $(CFLAGS) which contains all the $(CPU_CFLAGS). > > Have a nice day! This works and is quite ugly: libbsp_a_SOURCES += startup/bspstarthooks.c bspstarthooks.o: startup/bspstarthooks.c $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) \ $(AM_CPPFLAGS)$(CPPFLAGS) $(AM_CFLAGS) $(LPC24XX_CFLAGS) \ -MT bspstarthooks.o -MD -MP -MF $(DEPDIR)/bspstarthooks.Tpo \ -c -o bspstarthooks.o \ `test -f 'startup/bspstarthooks.c' || echo \ '$(srcdir)/'`startup/bspstarthooks.c -- 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 at embedded-brains.de PGP : Public key available on request Diese Nachricht ist keine gesch?ftliche Mitteilung im Sinne des EHUG. From feng1 at bnl.gov Fri Jul 31 15:49:52 2009 From: feng1 at bnl.gov (Kate Feng) Date: Fri, 31 Jul 2009 11:49:52 -0400 Subject: 64 bit DMA on RTEMS Message-ID: <4A7312A0.5000401@bnl.gov> Hi, Does RTEMS compiler truly support "64 bit DMA operation" if the H/W (e.g. processor & data bus) supports 64 bit data ? What I meant is that the compiler will not chop down the 64 bit data into two of 32 bit ones. Please confirm. Regards, Kate From leonp at plris.com Fri Jul 31 18:00:13 2009 From: leonp at plris.com (Leon Pollak) Date: Fri, 31 Jul 2009 21:00:13 +0300 Subject: 64 bit DMA on RTEMS In-Reply-To: <4A7312A0.5000401@bnl.gov> References: <4A7312A0.5000401@bnl.gov> Message-ID: <200907312100.14043.leonp@plris.com> On Friday July 31 2009, Kate Feng wrote: > Hi, > > Does RTEMS compiler truly support "64 bit DMA operation" > if the H/W (e.g. processor & data bus) supports 64 bit data ? > What I meant is that the compiler will not chop down the > 64 bit data into two of 32 bit ones. Please confirm. Kate, i am not sure what you mean... In my case, I have MPC8260 like CPU which has 64bit bus for RAM and DMA transfers. This is done by CPU automatically. AFAIK, DMA is done without CPU intervention and compiler can not influence on that. May be you mean 64bit machines such as AMD or INTEL Pentium Dual core etc.? -- Leon