[PATCH] doc: Setting Affinity to a Single Processor
---
doc/user/smp.t | 28
1 files changed, 20 insertions(+), 8 deletions(-)
diff --git a/doc/user/smp.t b/doc/user/smp.t
index f710537..3d9cc29 100644
--- a/doc/user/smp.t
+++ b/doc/user/smp.t
@@ -201,20 +201,32 @@ building RTEMS in SMP configuration.
@subsection Setting Affinity to a Single Processor
-In many embedded applications targeting SMP systems, it is common to lock
individual tasks to specific cores. In this way, one can designate a core for
I/O tasks, another for computation, etc.. The following illustrates the code
sequence necessary to assign a task an affinity for processor zero (0).
+On some embedded applications targeting SMP systems, it may be beneficial to
+lock individual tasks to specific processors. In this way, one can designate a
+processor for I/O tasks, another for computation, etc.. The following
+illustrates the code sequence necessary to assign a task an affinity for
+processor with index @code{processor_index}.
@example
-rtems_status_code sc;
-cpu_set_t set;
+@group
+#include
+#include
-CPU_EMPTY( &set );
-CPU_SET( 0, &set );
+void pin_to_processor(rtems_id task_id, int processor_index)
+@{
+ rtems_status_code sc;
+ cpu_set_t cpuset;
-sc = rtems_task_set_affinity(rtems_task_self(), sizeof(set), &set);
-assert(sc == RTEMS_SUCCESSFUL);
+ CPU_ZERO(&cpuset);
+ CPU_SET(processor_index, &cpuset);
+
+ sc = rtems_task_set_affinity(task_id, sizeof(cpuset), &cpuset);
+ assert(sc == RTEMS_SUCCESSFUL);
+@}
+@end group
@end example
-It is important to note that the @code{cpu_set_t} is not validated until the
+It is important to note that the @code{cpuset} is not validated until the
@code{@value{DIRPREFIX}task_set_affinity} call is made. At that point,
it is validated against the current system configuration.
--
1.7.7
___
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
Re: spfatal26 on jmr3904
On 2014-04-17 01:20, Joel Sherrill wrote: Hi The jmr3904 simulator faults before the exception is generated. RTEMS can't catch the exception and generate a fatal error. Any thoughts? *** BEGIN OF TEST SPFATAL 26 *** Breakpoint 4, Init (arg=) at ../../../../../../../rtems/c/src/../../testsuites/sptests/spfatal26/init.c:56 56 provoke_aligment_or_data_access_exception(); (gdb) s provoke_aligment_or_data_access_exception () at ../../../../../../../rtems/c/src/../../testsuites/sptests/spfatal26/init.c:35 35 *(volatile uint64_t *) base; (gdb) si mips-core: 4 byte read to unmapped address 0x4 at 0x880002e8 Program received signal SIGBUS, Bus error. provoke_aligment_or_data_access_exception () at ../../../../../../../rtems/c/src/../../testsuites/sptests/spfatal26/init.c:35 35 *(volatile uint64_t *) base; The simulator lacks support for this exception. On SIS you get for example: *** BEGIN OF TEST SPFATAL 26 *** Memory exception at 8000 (illegal address) Breakpoint 2, _Terminate (the_source=RTEMS_FATAL_SOURCE_EXCEPTION, is_internal=false, the_error=33773240) at /home/sh/rtems-4.11/c/src/../../cpukit/score/src/interr.c:39 39_ISR_Disable_without_giant( level ); (gdb) where #0 _Terminate (the_source=RTEMS_FATAL_SOURCE_EXCEPTION, is_internal=false, the_error=33773240) at /home/sh/rtems-4.11/c/src/../../cpukit/score/src/interr.c:39 #1 0x020051c0 in rtems_fatal (source=RTEMS_FATAL_SOURCE_EXCEPTION, error=33773240) at /home/sh/rtems-4.11/c/src/../../cpukit/sapi/src/fatal2.c:34 #2 0x02002064 in bsp_spurious_handler (trap=265, isf=0x203a6a8) at /home/sh/rtems-4.11/c/src/lib/libbsp/sparc/erc32/startup/spurious.c:131 #3 0x02028370 in dont_fix_pil2 () at /home/sh/rtems-4.11/c/src/lib/libbsp/sparc/erc32/../../sparc/shared/irq_asm.S:464 #4 0x02028370 in dont_fix_pil2 () at /home/sh/rtems-4.11/c/src/lib/libbsp/sparc/erc32/../../sparc/shared/irq_asm.S:464 -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
Re: mips/jmr3904 - sptls01 failing
On 2014-04-17 00:19, Joel Sherrill wrote: Hi What's the missing magic per architecture to get TLS to work? http://rtems.org/onlinedocs/doc-current/share/rtems/html/cpu_supplement/Port-Specific-Information-Thread_002dLocal-Storage.html#Port-Specific-Information-Thread_002dLocal-Storage *** BEGIN OF TEST SPTLS 1 *** ReservedInstruction at PC = 0x880002e8 ReservedInstruction at PC = 0x880002e8 The simulator lacks the instruction used to read/write the thread pointer. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
Re: spintrcricitical20 failure
On 2014-04-16 17:31, Joel Sherrill wrote: On 4/16/2014 3:09 AM, Sebastian Huber wrote: On 2014-04-15 18:40, Joel Sherrill wrote: Hi This has been failing a while. Any ideas? *** BEGIN OF TEST SPINTRCRITICAL 20 *** Support - rtems_timer_create - creating timer 1 ../../../../../../../rtems/c/src/../../testsuites/sptests/spintrcritical20/init.c: 139 ctx->thread_queue_was_null The spintrcritical* tests are timing dependent and sporadically fail. Does it run anywhere for you? Yes, on sis, psim, realview_pbx_a9_qemu, qoriq_p1020rdb, ngmp. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
Re: Raspberry Pi SD card support
On 17/04/2014 12:22 pm, Alan Cudmore wrote: The details of the GPU have been closed, and the linux port has relied on a binary blob for the GPU firmware, but Broadcom recently took a huge step in opening it up: http://www.raspberrypi.org/a-birthday-present-from-broadcom/ Does this mean you could port this code to RTEMS ? Chris ___ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
Re: Raspberry Pi SD card support
On Wed, Apr 16, 2014 at 4:49 PM, Joel Sherrill wrote: > > On 4/16/2014 2:06 PM, Alan Cudmore wrote: > > > > > On Thu, Apr 10, 2014 at 7:11 PM, Andre Marques < > andre.lousa.marq...@gmail.com> wrote: > >> On 04/04/14 20:19, Joel Sherrill wrote: >> >>> On 4/4/2014 1:15 PM, Gedare Bloom wrote: >>> The license looked fine to me. >>> +1 >>> >>> As always, we just need to be careful on a file per file basis just in >>> case >>> something else in rpi-boot has a different license. >>> >> >> All files in rpi-boot use a similar licence, so I will be using some >> code from rpi-boot as a base for this. > > > Great. > > >> >> >> On Thu, Apr 3, 2014 at 10:06 PM, Alan Cudmore wrote: > From my limited research, it looks like the emmc controller in the > Raspberry > Pi BCM2835 may be the way to go. > It looks like it is a high level controller for the SD/MMC card slot > on the > Pi. > > Since this is a custom controller, I don't think there would be an > existing > driver in RTEMS. > > It seems that this emmc controller in the Pi may handle different > types of > cards, and at a higher level than just using the SPI bus to access the > card. > ( This is based on some searches of conversations on the raspberry pi > forums > , not my experience ) > > You would have to write a driver for this emmc controller and provide > the > interface to libblock for the file system interface on RTEMS. The code > you > have linked above for rpi-boot looks like it has a permissive license, > so it > *may* be possible to use this code in the RTEMS driver. There is some > other > potentially useful code in there too. > >> The mailbox access, mmio read and write and the timer code will also be >> usefull, and not only for emmc. This timer code differs from the >> misc/timer.h currently in the raspberrypi BSP, as it waits a certain amount >> of time (until some register gets updated). The misc/timer.h is a benchmark >> timer, so one of them would have to be renamed or reorganized. >> >> > Can an RTEMS timer be used for the mailbox communication? > Also, I don't think the benchmark timer code in the RTEMS Raspberry Pi BSP > is functional. > >Do you mean rtems_timer_XXX or the timer in the BSP? > I mean the rtems_timer_ api. Maybe we can use this, or other RTEMS features to implement the mailbox interface rather than just going directly to the timer hardware like we see in the "bare metal" examples. > > The timer driver in the BSP is strictly for benchmarking -- nothing else. > It is used > by the tmtests and psxtmtests. It should not be used for any other purpose. > > How does the mailbox work? Describe it and we can figure out how to best > address > it. > The mailbox is the interface between the Video Core GPU and the ARM processor on the Pi. Here are some docs: https://github.com/raspberrypi/firmware/wiki/Mailboxes https://github.com/raspberrypi/firmware/wiki/Accessing-mailboxes https://github.com/raspberrypi/firmware/wiki/Mailbox-property-interface The details of the GPU have been closed, and the linux port has relied on a binary blob for the GPU firmware, but Broadcom recently took a huge step in opening it up: http://www.raspberrypi.org/a-birthday-present-from-broadcom/ Hopefully this will help improve the understanding of this interface. I have been contacted by someone who is currently working on a console > driver for the BSP, and has been able to display fonts. We may want to > include him, because I think the graphics code uses mailbox communication > to the GPU. > > It is very interesting that the GPU is running a commercial RTOS, and we > will be communicating to it with RTEMS. > >:) > > > >> My plan was to have at the root of the raspberrypi BSP a folder "emmc" >> for the emmc driver code, and the mailbox, mmio and timer on the misc >> folder, with the headers on the include folder. What do you think? >> >> I have been trying the rpi-boot emmc code for the past week, and I >> modified the hello test to use the emmc driver (an overly simplified >> version of the rpi-boot, just to read the slot info register for now), and >> my compilation process has been: >> >> 1. Add/change files in Raspberrypi BSP >> 2. Update Makefile.am >> 3. Run bootstrap -p and bootstrap from the RaspberryPi BSP folder >> 4. (Re)configure RTEMS >> 5. make and make install RTEMS from the root folder >> >> That is pretty much what I do. Although it might be possible to test > drivers and code in the RKI image, then integrate it into the RTEMS tree > when it is ready. > >--enable-maintainer-mode is supposed to track regenerating the > Makefile.in > and configure files when you modify Makefile.am or configure.ac. > > The current build system has a serious deficiency in that it does **not** > track the dependency of the test executables on any .a or .h file from > RTEMS. > So the best solution f
Re: [PATCH] sapi: Error case for CONFIGURE_UNLIMITED_OBJECTS
On 16/04/2014 5:00 pm, Sebastian Huber wrote: On 2014-04-16 05:55, Chris Johns wrote: On 15/04/2014 9:33 pm, Sebastian Huber wrote: --- cpukit/sapi/include/confdefs.h |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/cpukit/sapi/include/confdefs.h b/cpukit/sapi/include/confdefs.h index c8a9d0e..8b9b3e1 100644 --- a/cpukit/sapi/include/confdefs.h +++ b/cpukit/sapi/include/confdefs.h @@ -1583,6 +1583,12 @@ const rtems_libio_helper rtems_fs_init_helper = * classic or posix objects that have not already been given resource limits. */ #if defined(CONFIGURE_UNLIMITED_OBJECTS) + #if !defined(CONFIGURE_UNIFIED_WORK_AREAS) && \ + !defined(CONFIGURE_EXECUTIVE_RAM_SIZE) && \ + !defined(CONFIGURE_MEMORY_OVERHEAD) + #error "Using CONFIGURE_UNLIMITED_OBJECTS with a pre-calculated work space size makes no sense" + #endif + #if !defined(CONFIGURE_UNLIMITED_ALLOCATION_SIZE) /** * This macro specifies a default allocation size for when auto-extending The use case is (was?) a fixed size or bounded pool of memory that can be used in different ways depending on what is being run depending on how the app is configured. I am not fussed either way what happens here as the unified work areas is a nice feature. Use case for CONFIGURE_UNLIMITED_OBJECTS is to enable the unlimited option for all objects. This makes only sense if we have a work space which has some free space. There are three means to do this as far as I know. Yes this is true. Can the error message please be changed to: "CONFIGURE_UNLIMITED_OBJECTS requires a unified work area, an executive RAM size, or a defined workspace memory overhead" The fact we have an error message implies it does not make sense. I see this patch and discussion as a side effect of requiring confdefs to configure a system. A goal of confdefs is to accurately determine the workspace size given the exact number of resources required however confdefs is not perfect and never will be and users needs to be aware of this, for example stack space allocation in a separate workspace environment cannot be estimated and managed automatically. You could argue not having unified work areas and not defining a memory overhead will cause problems and enforcing it removes the need for this patch. Another larger step is to only support a unified work space removing the need for confdefs to make any memory calculations. You either have the memory or you do not. Chris ___ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
spfatal26 on jmr3904
Hi The jmr3904 simulator faults before the exception is generated. RTEMS can't catch the exception and generate a fatal error. Any thoughts? *** BEGIN OF TEST SPFATAL 26 *** Breakpoint 4, Init (arg=) at ../../../../../../../rtems/c/src/../../testsuites/sptests/spfatal26/init.c:56 56 provoke_aligment_or_data_access_exception(); (gdb) s provoke_aligment_or_data_access_exception () at ../../../../../../../rtems/c/src/../../testsuites/sptests/spfatal26/init.c:35 35 *(volatile uint64_t *) base; (gdb) si mips-core: 4 byte read to unmapped address 0x4 at 0x880002e8 Program received signal SIGBUS, Bus error. provoke_aligment_or_data_access_exception () at ../../../../../../../rtems/c/src/../../testsuites/sptests/spfatal26/init.c:35 35 *(volatile uint64_t *) base; -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985 ___ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
Re: Shell: hexdump command weirdness in fileio
On 4/16/2014 5:36 PM, Chris Johns wrote: > On 17/04/2014 7:31 am, Joel Sherrill wrote: >> Hi >> >> I saw this during the class in Munich but forgot to report it. >> >> RTEMS SHELL (Ver.1.0-FRC):/dev/foobar. Apr 14 2014. 'help' to list commands. >> [/] # hexdump /etc/passwd >> [/] # >> >> Notice that the hexdump command didn't display anything from the file. >> >> Did I do something wrong? Or is something broken? >> > Nothing wrong. I seem to remember a bug in this code somewhere. I need > to take a look. I took a shot at stepping into it and it jumps around like mad. Looks like it calls memset and returns which makes no sense at all. :( > Chris > ___ > rtems-devel mailing list > rtems-devel@rtems.org > http://www.rtems.org/mailman/listinfo/rtems-devel -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985 ___ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
Re: Shell: hexdump command weirdness in fileio
On 17/04/2014 7:31 am, Joel Sherrill wrote: Hi I saw this during the class in Munich but forgot to report it. RTEMS SHELL (Ver.1.0-FRC):/dev/foobar. Apr 14 2014. 'help' to list commands. [/] # hexdump /etc/passwd [/] # Notice that the hexdump command didn't display anything from the file. Did I do something wrong? Or is something broken? Nothing wrong. I seem to remember a bug in this code somewhere. I need to take a look. Chris ___ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
mips/jmr3904 - sptls01 failing
Hi What's the missing magic per architecture to get TLS to work? *** BEGIN OF TEST SPTLS 1 *** ReservedInstruction at PC = 0x880002e8 ReservedInstruction at PC = 0x880002e8 -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985 ___ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
Shell: hexdump command weirdness in fileio
Hi I saw this during the class in Munich but forgot to report it. RTEMS SHELL (Ver.1.0-FRC):/dev/foobar. Apr 14 2014. 'help' to list commands. [/] # hexdump /etc/passwd [/] # Notice that the hexdump command didn't display anything from the file. Did I do something wrong? Or is something broken? -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985 ___ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
Re: Raspberry Pi SD card support
On 4/16/2014 2:06 PM, Alan Cudmore wrote: > > > > On Thu, Apr 10, 2014 at 7:11 PM, Andre Marques > mailto:andre.lousa.marq...@gmail.com>> > wrote: > > On 04/04/14 20:19, Joel Sherrill wrote: > > On 4/4/2014 1:15 PM, Gedare Bloom wrote: > > The license looked fine to me. > > +1 > > As always, we just need to be careful on a file per file basis > just in case > something else in rpi-boot has a different license. > > > All files in rpi-boot use a similar licence, so I will be using > some code from rpi-boot as a base for this. > > > Great. > > > > > On Thu, Apr 3, 2014 at 10:06 PM, Alan Cudmore > mailto:alan.cudm...@gmail.com>> > wrote: > > From my limited research, it looks like the emmc > controller in the Raspberry > Pi BCM2835 may be the way to go. > It looks like it is a high level controller for the > SD/MMC card slot on the > Pi. > > Since this is a custom controller, I don't think there > would be an existing > driver in RTEMS. > > It seems that this emmc controller in the Pi may > handle different types of > cards, and at a higher level than just using the SPI > bus to access the card. > ( This is based on some searches of conversations on > the raspberry pi forums > , not my experience ) > > You would have to write a driver for this emmc > controller and provide the > interface to libblock for the file system interface on > RTEMS. The code you > have linked above for rpi-boot looks like it has a > permissive license, so it > *may* be possible to use this code in the RTEMS > driver. There is some other > potentially useful code in there too. > > > The mailbox access, mmio read and write and the timer code will > also be usefull, and not only for emmc. This timer code differs > from the misc/timer.h currently in the raspberrypi BSP, as it > waits a certain amount of time (until some register gets updated). > The misc/timer.h is a benchmark timer, so one of them would have > to be renamed or reorganized. > > > Can an RTEMS timer be used for the mailbox communication? > Also, I don't think the benchmark timer code in the RTEMS Raspberry Pi > BSP is functional. > Do you mean rtems_timer_XXX or the timer in the BSP? The timer driver in the BSP is strictly for benchmarking -- nothing else. It is used by the tmtests and psxtmtests. It should not be used for any other purpose. How does the mailbox work? Describe it and we can figure out how to best address it. > I have been contacted by someone who is currently working on a console > driver for the BSP, and has been able to display fonts. We may want to > include him, because I think the graphics code uses mailbox > communication to the GPU. > > It is very interesting that the GPU is running a commercial RTOS, and > we will be communicating to it with RTEMS. > :) > > > My plan was to have at the root of the raspberrypi BSP a folder > "emmc" for the emmc driver code, and the mailbox, mmio and timer > on the misc folder, with the headers on the include folder. What > do you think? > > I have been trying the rpi-boot emmc code for the past week, and I > modified the hello test to use the emmc driver (an overly > simplified version of the rpi-boot, just to read the slot info > register for now), and my compilation process has been: > > 1. Add/change files in Raspberrypi BSP > 2. Update Makefile.am > 3. Run bootstrap -p and bootstrap from the RaspberryPi BSP folder > 4. (Re)configure RTEMS > 5. make and make install RTEMS from the root folder > > That is pretty much what I do. Although it might be possible to test > drivers and code in the RKI image, then integrate it into the RTEMS > tree when it is ready. > --enable-maintainer-mode is supposed to track regenerating the Makefile.in and configure files when you modify Makefile.am or configure.ac. The current build system has a serious deficiency in that it does **not** track the dependency of the test executables on any .a or .h file from RTEMS. So the best solution for quick builds is usually to remove the executable you are testing and then run make. Step 3 above is the minimum for a bootstrap. bootstrap -p is only needed when you add/delete/move .h files. > > > I have been using the --enable-maintainer-mode, but I am not sure > about exacly what it simplifies, because I always needed to do > those steps for it to compile and link correctly. > > > I don't know what this does either.. > Just tracks dependencies on generat
Re: Raspberry Pi SD card support
On Thu, Apr 10, 2014 at 7:11 PM, Andre Marques < andre.lousa.marq...@gmail.com> wrote: > On 04/04/14 20:19, Joel Sherrill wrote: > >> On 4/4/2014 1:15 PM, Gedare Bloom wrote: >> >>> The license looked fine to me. >>> >> +1 >> >> As always, we just need to be careful on a file per file basis just in >> case >> something else in rpi-boot has a different license. >> > > All files in rpi-boot use a similar licence, so I will be using some code > from rpi-boot as a base for this. Great. > > > On Thu, Apr 3, 2014 at 10:06 PM, Alan Cudmore >>> wrote: >>> From my limited research, it looks like the emmc controller in the Raspberry Pi BCM2835 may be the way to go. It looks like it is a high level controller for the SD/MMC card slot on the Pi. Since this is a custom controller, I don't think there would be an existing driver in RTEMS. It seems that this emmc controller in the Pi may handle different types of cards, and at a higher level than just using the SPI bus to access the card. ( This is based on some searches of conversations on the raspberry pi forums , not my experience ) You would have to write a driver for this emmc controller and provide the interface to libblock for the file system interface on RTEMS. The code you have linked above for rpi-boot looks like it has a permissive license, so it *may* be possible to use this code in the RTEMS driver. There is some other potentially useful code in there too. >>> > The mailbox access, mmio read and write and the timer code will also be > usefull, and not only for emmc. This timer code differs from the > misc/timer.h currently in the raspberrypi BSP, as it waits a certain amount > of time (until some register gets updated). The misc/timer.h is a benchmark > timer, so one of them would have to be renamed or reorganized. > > Can an RTEMS timer be used for the mailbox communication? Also, I don't think the benchmark timer code in the RTEMS Raspberry Pi BSP is functional. I have been contacted by someone who is currently working on a console driver for the BSP, and has been able to display fonts. We may want to include him, because I think the graphics code uses mailbox communication to the GPU. It is very interesting that the GPU is running a commercial RTOS, and we will be communicating to it with RTEMS. > My plan was to have at the root of the raspberrypi BSP a folder "emmc" for > the emmc driver code, and the mailbox, mmio and timer on the misc folder, > with the headers on the include folder. What do you think? > > I have been trying the rpi-boot emmc code for the past week, and I > modified the hello test to use the emmc driver (an overly simplified > version of the rpi-boot, just to read the slot info register for now), and > my compilation process has been: > > 1. Add/change files in Raspberrypi BSP > 2. Update Makefile.am > 3. Run bootstrap -p and bootstrap from the RaspberryPi BSP folder > 4. (Re)configure RTEMS > 5. make and make install RTEMS from the root folder > > That is pretty much what I do. Although it might be possible to test drivers and code in the RKI image, then integrate it into the RTEMS tree when it is ready. > I have been using the --enable-maintainer-mode, but I am not sure about > exacly what it simplifies, because I always needed to do those steps for it > to compile and link correctly. > I don't know what this does either.. Alan > > --André Marques > > > I'll have to try the serial bootloader, I am also close to ordering an inexpensive JTAG adapter to try loading and debugging through JTAG. uboot is another possibility, using a TFTP server. Alan On Wed, Apr 2, 2014 at 12:02 PM, Andre Marques wrote: > Hello, > > I'm intending to work in the SD card support for the Raspberry Pi BSP, > using the SD mode instead of the SPI mode. > > The references I have gathered so far for this are as follows: > > The Raspberry Pi SOC guide: Broadcom BCM2835 Peripherals Guide > (Chapter 5 > - EMMC) > > The simplified SD standard - > https://www.sdcard.org/downloads/pls/simplified_specs/ > > And the following github code - > https://github.com/jncronin/rpi-boot/blob/master/emmc.c > > There is also the libchip/i2c/spi-sd-card libi2c driver, which can > also be > a reference (even though it uses SPI). > > Now, the questions: > > Should I use the Generic Disk Device driver, as the > libchip/i2c/spi-sd-card ? > > Is there any driver using the SD mode for sd card access, or using an > emmc > interface currently in the RTEMS code base? I haven't found any. > > On a side note, I managed to send RTEMS applications to the RPi though > the > UART interface using the xmodem protocol. > > For that I us
Re: Future of Doc Was: Re: [rtems commit] rtems: Add task get/set scheduler
Hi, good discussion. Maybe it makes sense to define what we want to write into a User's Guide, because the term is used for many different types of documents. I agree with Sebastian that the best place for documenting each API function is doxygen, because it's source is always in sync with the real code (or as close as possible). When it comes to concepts and best practices, when it comes to "Getting stared" or "Write your first RTEMS application", doxygen might not be the best solution. So having an abstract User's Guide that is non-doxygen makes sense to me. It may include: - a Quick Start Guide chapter: "hello embedded world" in 15 minutes - more details: where do I get all the source code, the toolset, the documentation - RTEMS concepts: APIs, OS objects, threads, memory management, Link strategy, Build strategy, configuration - Best practices: Use confdefs.h, code organization, ... - debugging strategies... The User's Guide should then point to doxygen for the fizzy details. What do you think, does that make sense? wkr, Thomas Am 16.04.2014 16:08, schrieb Gedare Bloom: > On Wed, Apr 16, 2014 at 4:08 AM, Sebastian Huber > wrote: >> On 2014-04-15 18:20, Joel Sherrill wrote: >>> >>> >>> On 4/15/2014 11:14 AM, Sebastian Huber wrote: On 04/15/2014 02:48 PM, Sebastian Huber wrote: > > On 2014-04-15 14:36, Joel Sherrill wrote: >> >> You added to the API and added no documentation. > > I added the documentation in Doxygen: > > http://www.rtems.org/pipermail/rtems-devel/2014-March/005901.html > Ok, since we are close to the RTEMS 4.11 release I will add texinfo documentation to all new high-level functions. After the RTEMS 4.11 release we should definitely do something against this copy and paste nightmare. Joel, what is your opinion with respect to the future documentation infrastructure of RTEMS? >>> User Guides should not be in Doxygen. >> >> >> It is possible to write user guides with Doxygen (see @page command). >> > I completely agree that we need to eliminate so much copy-paste. We > need to have a better plan for managing documentation, for user > developers and for kernel developers. I'd like to hear some more > thoughts on the subject and also see some initial requirements. > > Gedare > ___ > rtems-devel mailing list > rtems-devel@rtems.org > http://www.rtems.org/mailman/listinfo/rtems-devel > -- embedded brains GmbH Thomas Doerfler Dornierstr. 4 D-82178 Puchheim Germany email: thomas.doerf...@embedded-brains.de Phone: +49-89-18 94 741-12 Fax: +49-89-18 94 741-09 PGP: Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
Re: spintrcricitical20 failure
On 4/16/2014 3:09 AM, Sebastian Huber wrote: > On 2014-04-15 18:40, Joel Sherrill wrote: >> Hi >> >> This has been failing a while. Any ideas? >> >> *** BEGIN OF TEST SPINTRCRITICAL 20 *** >> Support - rtems_timer_create - creating timer 1 >> ../../../../../../../rtems/c/src/../../testsuites/sptests/spintrcritical20/init.c: >> 139 ctx->thread_queue_was_null >> > The spintrcritical* tests are timing dependent and sporadically fail. Does it run anywhere for you? -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985 ___ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
Re: [rtems commit] rtems: Add task get/set scheduler
On 4/16/2014 3:08 AM, Sebastian Huber wrote: > On 2014-04-15 18:20, Joel Sherrill wrote: >> On 4/15/2014 11:14 AM, Sebastian Huber wrote: >>> On 04/15/2014 02:48 PM, Sebastian Huber wrote: On 2014-04-15 14:36, Joel Sherrill wrote: > You added to the API and added no documentation. I added the documentation in Doxygen: http://www.rtems.org/pipermail/rtems-devel/2014-March/005901.html >>> Ok, since we are close to the RTEMS 4.11 release I will add texinfo >>> documentation to all new high-level functions. After the RTEMS 4.11 >>> release we should definitely do something against this copy and paste >>> nightmare. >>> >>> Joel, what is your opinion with respect to the future documentation >>> infrastructure of RTEMS? >>> >> User Guides should not be in Doxygen. > It is possible to write user guides with Doxygen (see @page command). I have never seen Doxygen produced PDF which is worth consuming. Doxygen is good for code markup and browseable internals/programming documentation. I do not believe it was ever intended for use in producing printed manuals. This discussion is not worth having without Amar or before 4.11 branches. >> But we do have to move to something besides Texinfo for user guides. >> Amar has ideas and proposals once we get past his current goals. >> >> Also some of the current documentation is out of date no matter >> what form it is. This includes readme's, some wiki content, and >> a couple of texinfo manuals. >> >> FWIW I haven't posted yet about this but the life cycle field in >> the TCB didn't get a Doxygen comment. Noticed it teaching last week. > Sorry, should be fixed now. > >> And do you get warnings in Doxygen from RTEMS? Do we have them >> disabled? I can't believe that >> http://www.rtems.org/onlinedocs/doxygen/doxy.log >> doesn't show any. >> > Yes, there should be lots of warnings. > I didn't see any even when I built by hand. -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985 ___ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
Re: SMP: Next steps
On 2014-04-16 16:17, Gedare Bloom wrote: > o support for a priority boost to fix priority inheritance across scheduler >boundaries, > It would also be great if this might fix https://www.rtems.org/bugzilla/show_bug.cgi?id=2124 The bug may apply to SMP scheduling, but I have not thought that hard about it. It is not related to this bug. What I want to address is described in "The limits of priority inheritance", page 125, Björn B. Brandenburg, Scheduling and Locking in Multiprocessor Real-Time Operating Systems, 2011. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
Re: SMP: Next steps
Great, thanks for keeping us all informed. On Wed, Apr 16, 2014 at 4:55 AM, Sebastian Huber wrote: > Hello, > > my next steps are > > o documentation update for the recent high-level API functions introduced > to support clustered/partitioned scheduling, > > o support for a priority boost to fix priority inheritance across scheduler > boundaries, > It would also be great if this might fix https://www.rtems.org/bugzilla/show_bug.cgi?id=2124 The bug may apply to SMP scheduling, but I have not thought that hard about it. > o migration to another scheduler for started threads (forced thread > migration), and > > o support for the MrsP protocol. > > -- > Sebastian Huber, embedded brains GmbH > > Address : Dornierstr. 4, D-82178 Puchheim, Germany > Phone : +49 89 189 47 41-16 > Fax : +49 89 189 47 41-09 > E-Mail : sebastian.hu...@embedded-brains.de > PGP : Public key available on request. > > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. > ___ > rtems-devel mailing list > rtems-devel@rtems.org > http://www.rtems.org/mailman/listinfo/rtems-devel ___ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
Future of Doc Was: Re: [rtems commit] rtems: Add task get/set scheduler
On Wed, Apr 16, 2014 at 4:08 AM, Sebastian Huber wrote: > On 2014-04-15 18:20, Joel Sherrill wrote: >> >> >> On 4/15/2014 11:14 AM, Sebastian Huber wrote: >>> >>> On 04/15/2014 02:48 PM, Sebastian Huber wrote: On 2014-04-15 14:36, Joel Sherrill wrote: > > You added to the API and added no documentation. I added the documentation in Doxygen: http://www.rtems.org/pipermail/rtems-devel/2014-March/005901.html >>> Ok, since we are close to the RTEMS 4.11 release I will add texinfo >>> documentation to all new high-level functions. After the RTEMS 4.11 >>> release we should definitely do something against this copy and paste >>> nightmare. >>> >>> Joel, what is your opinion with respect to the future documentation >>> infrastructure of RTEMS? >>> >> User Guides should not be in Doxygen. > > > It is possible to write user guides with Doxygen (see @page command). > I completely agree that we need to eliminate so much copy-paste. We need to have a better plan for managing documentation, for user developers and for kernel developers. I'd like to hear some more thoughts on the subject and also see some initial requirements. Gedare ___ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
[PATCH 5/8] doc: rtems_scheduler_ident()
---
doc/user/smp.t | 36
1 files changed, 36 insertions(+), 0 deletions(-)
diff --git a/doc/user/smp.t b/doc/user/smp.t
index ced8fdf..ebeb3bb 100644
--- a/doc/user/smp.t
+++ b/doc/user/smp.t
@@ -296,6 +296,42 @@ thread dispatching disabled.
None.
@c
+@c rtems_scheduler_ident
+@c
+@page
+@subsection SCHEDULER_IDENT - Get ID of a scheduler
+
+@subheading CALLING SEQUENCE:
+
+@ifset is-C
+@example
+rtems_status_code rtems_scheduler_ident(
+ rtems_name name,
+ rtems_id *id
+);
+@end example
+@end ifset
+
+@ifset is-Ada
+@end ifset
+
+@subheading DIRECTIVE STATUS CODES:
+
+@code{@value{RPREFIX}SUCCESSFUL} - successful operation@*
+@code{@value{RPREFIX}INVALID_ADDRESS} - @code{id} is NULL@*
+@code{@value{RPREFIX}INVALID_NAME} - invalid scheduler name
+
+@subheading DESCRIPTION:
+
+Identifies a scheduler by its name. The scheduler name is determined by the
+scheduler configuration. @xref{Configuring a System Configuring
+Clustered/Partitioned Schedulers}.
+
+@subheading NOTES:
+
+None.
+
+@c
@c rtems_task_get_affinity
@c
@page
--
1.7.7
___
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
[PATCH 1/8] doc: rtems_get_processor_count()
---
cpukit/rtems/include/rtems/rtems/smp.h | 13 +
doc/user/smp.t | 23 +--
2 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/cpukit/rtems/include/rtems/rtems/smp.h
b/cpukit/rtems/include/rtems/rtems/smp.h
index fa4d5d6..aeb0df6 100644
--- a/cpukit/rtems/include/rtems/rtems/smp.h
+++ b/cpukit/rtems/include/rtems/rtems/smp.h
@@ -31,9 +31,6 @@ extern "C" {
*
* This encapsulates functionality which is useful for SMP applications.
*
- * This API is also available on uni-processor configurations. Here compile
- * time constants are used whenever possible.
- *
* @{
*/
@@ -43,12 +40,12 @@ extern "C" {
* On uni-processor configurations a value of one will be returned.
*
* On SMP configurations this returns the value of a global variable set during
- * system initialization to indicate the count of processors. The processor
- * count depends on the hardware and application configuration. The value will
- * always be less than or equal to the maximum count of application configured
- * processors.
+ * system initialization to indicate the count of utilized processors. The
+ * processor count depends on the physically or virtually available processors
+ * and application configuration. The value will always be less than or equal
+ * to the maximum count of application configured processors.
*
- * @return The count of processors in the system.
+ * @return The count of processors being utilized.
*/
uint32_t rtems_get_processor_count(void);
diff --git a/doc/user/smp.t b/doc/user/smp.t
index 449987a..b0d1189 100644
--- a/doc/user/smp.t
+++ b/doc/user/smp.t
@@ -223,36 +223,39 @@ is dedicated to each of these services and describes the
calling sequence,
related constants, usage, and status codes.
@c
-@c rtems_smp_get_processor_count
+@c rtems_get_processor_count
@c
@page
-@subsection rtems_smp_get_processor_count - Obtain Number of CPUs
+@subsection GET_PROCESSOR_COUNT - Get processor count
@subheading CALLING SEQUENCE:
@ifset is-C
@example
-#include
-
-int rtems_smp_get_processor_count(void);
+uint32_t rtems_get_processor_count(void);
@end example
@end ifset
@ifset is-Ada
@end ifset
-@subheading STATUS CODES:
+@subheading DIRECTIVE STATUS CODES:
-Returns the number of processors being utilized.
+The count of processors in the system.
@subheading DESCRIPTION:
-The @code{rtems_smp_get_processor_count} routine is used to obtain the
-number of processor cores being utilized.
+On uni-processor configurations a value of one will be returned.
+
+On SMP configurations this returns the value of a global variable set during
+system initialization to indicate the count of utilized processors. The
+processor count depends on the physically or virtually available processors and
+application configuration. The value will always be less than or equal to the
+maximum count of application configured processors.
@subheading NOTES:
-NONE
+None.
@c
@c rtems_task_get_affinity
--
1.7.7
___
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
[PATCH 3/8] doc: rtems_task_get_affinity()
---
doc/user/smp.t | 37 ++---
1 files changed, 14 insertions(+), 23 deletions(-)
diff --git a/doc/user/smp.t b/doc/user/smp.t
index 3d565ef..649aaf1 100644
--- a/doc/user/smp.t
+++ b/doc/user/smp.t
@@ -299,18 +299,16 @@ None.
@c rtems_task_get_affinity
@c
@page
-@subsection rtems_task_get_affinity - Obtain Task Affinity
+@subsection TASK_GET_AFFINITY - Get task processor affinity
@subheading CALLING SEQUENCE:
@ifset is-C
@example
-#include
-
rtems_status_code rtems_task_get_affinity(
- rtems_id id,
- size_t cpusetsize,
- cpu_set_t *cpuset
+ rtems_id id,
+ size_t cpusetsize,
+ cpu_set_t *cpuset
);
@end example
@end ifset
@@ -318,30 +316,23 @@ rtems_status_code rtems_task_get_affinity(
@ifset is-Ada
@end ifset
-@subheading STATUS CODES:
-
-@table @b
-@item RTEMS_UNSATISFIED
-The @code{cpuset} pointer argument is invalid.
-
-@item RTEMS_UNSATISFIED
-The @code{cpusetsize} does not match the value of @code{affinitysetsize}
-field in the thread attribute object.
-
-@item RTEMS_INVALID_ID
-The @code{id} is invalid.
+@subheading DIRECTIVE STATUS CODES:
-@end table
+@code{@value{RPREFIX}SUCCESSFUL} - successful operation@*
+@code{@value{RPREFIX}INVALID_ADDRESS} - @code{cpuset} is NULL@*
+@code{@value{RPREFIX}INVALID_ID} - invalid task id@*
+@code{@value{RPREFIX}INVALID_NUMBER} - the affinity set buffer is too small for
+the current processor affinity set of the task
@subheading DESCRIPTION:
-The @code{rtems_task_get_affinity} routine is used to obtain the
-@code{affinityset} field from the thread object @code{id}.
-The value of this field is returned in @code{cpuset}
+Returns the current processor affinity set of the task in @code{cpuset}. A set
+bit in the affinity set means that the task can execute on this processor and a
+cleared bit means the opposite.
@subheading NOTES:
-NONE
+None.
@c
@c rtems_task_set_affinity
--
1.7.7
___
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
[PATCH 8/8] doc: rtems_task_set_scheduler()
---
cpukit/rtems/include/rtems/rtems/tasks.h |3 +
doc/user/smp.t | 76 ++
2 files changed, 79 insertions(+), 0 deletions(-)
diff --git a/cpukit/rtems/include/rtems/rtems/tasks.h
b/cpukit/rtems/include/rtems/rtems/tasks.h
index 72eb553..a9016ce 100644
--- a/cpukit/rtems/include/rtems/rtems/tasks.h
+++ b/cpukit/rtems/include/rtems/rtems/tasks.h
@@ -560,6 +560,9 @@ rtems_status_code rtems_task_get_scheduler(
/**
* @brief Sets the scheduler of a task.
*
+ * The scheduler of a task is initialized to the scheduler of the task that
+ * created it.
+ *
* @param[in] id Identifier of the task. Use @ref RTEMS_SELF to select the
* executing task.
* @param[in] scheduler_id Identifier of the scheduler.
diff --git a/doc/user/smp.t b/doc/user/smp.t
index 9703c14..f998539 100644
--- a/doc/user/smp.t
+++ b/doc/user/smp.t
@@ -405,6 +405,82 @@ Returns the scheduler identifier of a task in
@code{scheduler_id}.
None.
@c
+@c rtems_task_set_scheduler
+@c
+@page
+@subsection TASK_SET_SCHEDULER - Set scheduler of a task
+
+@subheading CALLING SEQUENCE:
+
+@ifset is-C
+@example
+rtems_status_code rtems_task_set_scheduler(
+ rtems_id id,
+ rtems_id scheduler_id
+);
+@end example
+@end ifset
+
+@ifset is-Ada
+@end ifset
+
+@subheading DIRECTIVE STATUS CODES:
+
+@code{@value{RPREFIX}SUCCESSFUL} - successful operation@*
+@code{@value{RPREFIX}INVALID_ID} - invalid task or scheduler id@*
+@code{@value{RPREFIX}INCORRECT_STATE} - the task is in the wrong state to
+perform a scheduler change
+
+@subheading DESCRIPTION:
+
+Sets the scheduler of a task specified by @code{scheduler_id}. The scheduler
+of a task is initialized to the scheduler of the task that created it.
+
+@subheading NOTES:
+
+None.
+
+@subheading EXAMPLE:
+
+@example
+@group
+#include
+#include
+
+void task(rtems_task_argument arg);
+
+void example(void)
+@{
+ rtems_status_code sc;
+ rtems_id task_id;
+ rtems_id scheduler_id;
+ rtems_namescheduler_name;
+
+ scheduler_name = rtems_build_name('W', 'O', 'R', 'K');
+
+ sc = rtems_scheduler_ident(scheduler_name, &scheduler_id);
+ assert(sc == RTEMS_SUCCESSFUL);
+
+ sc = rtems_task_create(
+rtems_build_name('T', 'A', 'S', 'K'),
+1,
+RTEMS_MINIMUM_STACK_SIZE,
+RTEMS_DEFAULT_MODES,
+RTEMS_DEFAULT_ATTRIBUTES,
+&task_id
+ );
+ assert(sc == RTEMS_SUCCESSFUL);
+
+ sc = rtems_task_set_scheduler(task_id, scheduler_id);
+ assert(sc == RTEMS_SUCCESSFUL);
+
+ sc = rtems_task_start(task_id, task, 0);
+ assert(sc == RTEMS_SUCCESSFUL);
+@}
+@end group
+@end example
+
+@c
@c rtems_task_get_affinity
@c
@page
--
1.7.7
___
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
[PATCH 7/8] doc: rtems_task_get_scheduler()
---
doc/user/smp.t | 34 ++
1 files changed, 34 insertions(+), 0 deletions(-)
diff --git a/doc/user/smp.t b/doc/user/smp.t
index 4ed2735..9703c14 100644
--- a/doc/user/smp.t
+++ b/doc/user/smp.t
@@ -371,6 +371,40 @@ cleared bit means the opposite.
None.
@c
+@c rtems_task_get_scheduler
+@c
+@page
+@subsection TASK_GET_SCHEDULER - Get scheduler of a task
+
+@subheading CALLING SEQUENCE:
+
+@ifset is-C
+@example
+rtems_status_code rtems_task_get_scheduler(
+ rtems_id id,
+ rtems_id *scheduler_id
+);
+@end example
+@end ifset
+
+@ifset is-Ada
+@end ifset
+
+@subheading DIRECTIVE STATUS CODES:
+
+@code{@value{RPREFIX}SUCCESSFUL} - successful operation@*
+@code{@value{RPREFIX}INVALID_ADDRESS} - @code{scheduler_id} is NULL@*
+@code{@value{RPREFIX}INVALID_ID} - invalid task id
+
+@subheading DESCRIPTION:
+
+Returns the scheduler identifier of a task in @code{scheduler_id}.
+
+@subheading NOTES:
+
+None.
+
+@c
@c rtems_task_get_affinity
@c
@page
--
1.7.7
___
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
[PATCH 6/8] doc: rtems_scheduler_get_processor_set()
---
doc/user/smp.t | 39 +++
1 files changed, 39 insertions(+), 0 deletions(-)
diff --git a/doc/user/smp.t b/doc/user/smp.t
index ebeb3bb..4ed2735 100644
--- a/doc/user/smp.t
+++ b/doc/user/smp.t
@@ -332,6 +332,45 @@ Clustered/Partitioned Schedulers}.
None.
@c
+@c rtems_scheduler_get_processor_set
+@c
+@page
+@subsection SCHEDULER_GET_PROCESSOR_SET - Get processor set of a scheduler
+
+@subheading CALLING SEQUENCE:
+
+@ifset is-C
+@example
+rtems_status_code rtems_scheduler_get_processor_set(
+ rtems_id scheduler_id,
+ size_t cpusetsize,
+ cpu_set_t *cpuset
+);
+@end example
+@end ifset
+
+@ifset is-Ada
+@end ifset
+
+@subheading DIRECTIVE STATUS CODES:
+
+@code{@value{RPREFIX}SUCCESSFUL} - successful operation@*
+@code{@value{RPREFIX}INVALID_ADDRESS} - @code{cpuset} is NULL@*
+@code{@value{RPREFIX}INVALID_ID} - invalid scheduler id@*
+@code{@value{RPREFIX}INVALID_NUMBER} - the affinity set buffer is too small for
+set of processors owned by the scheduler
+
+@subheading DESCRIPTION:
+
+Returns the processor set owned by the scheduler in @code{cpuset}. A set bit
+in the processor set means that this processor is owned by the scheduler and a
+cleared bit means the opposite.
+
+@subheading NOTES:
+
+None.
+
+@c
@c rtems_task_get_affinity
@c
@page
--
1.7.7
___
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
[PATCH 4/8] doc: rtems_task_set_affinity()
---
doc/user/Makefile.am |2 +-
doc/user/smp.t | 43 +--
2 files changed, 14 insertions(+), 31 deletions(-)
diff --git a/doc/user/Makefile.am b/doc/user/Makefile.am
index 03f776d..ef91a41 100644
--- a/doc/user/Makefile.am
+++ b/doc/user/Makefile.am
@@ -169,7 +169,7 @@ smp.texi: smp.t
-n "Stack Bounds Checker" < $< > $@
stackchk.texi: stackchk.t
- $(BMENU2) -p "Symmetric Multiprocessing Services
rtems_task_set_affinity - Set Task Affinity" \
+ $(BMENU2) -p "Symmetric Multiprocessing Services TASK_SET_AFFINITY -
Set task processor affinity" \
-u "Top" \
-n "CPU Usage Statistics" < $< > $@
diff --git a/doc/user/smp.t b/doc/user/smp.t
index 649aaf1..ced8fdf 100644
--- a/doc/user/smp.t
+++ b/doc/user/smp.t
@@ -338,18 +338,16 @@ None.
@c rtems_task_set_affinity
@c
@page
-@subsection rtems_task_set_affinity - Set Task Affinity
+@subsection TASK_SET_AFFINITY - Set task processor affinity
@subheading CALLING SEQUENCE:
@ifset is-C
@example
-#include
-
rtems_status_code rtems_task_set_affinity(
- rtems_id id,
- size_t cpusetsize,
- cpu_set_t *cpuset
+ rtems_id id,
+ size_t cpusetsize,
+ const cpu_set_t *cpuset
);
@end example
@end ifset
@@ -357,34 +355,19 @@ rtems_status_code rtems_task_set_affinity(
@ifset is-Ada
@end ifset
-@subheading STATUS CODES:
-
-@table @b
-@item RTEMS_UNSATISFIED
-The @code{cpuset} pointer argument is invalid.
-
-@item RTEMS_UNSATISFIED
-The @code{cpusetsize} does not match the value of @code{affinitysetsize}
-field in the thread attribute object.
-
-@item RTEMS_UNSATISFIED
-The @code{cpuset} did not select a valid cpu.
-
-@item RTEMS_UNSATISFIED
-The @code{cpuset} selected a cpu that was invalid.
-
-@item RTEMS_INVALID_ID
-The @code{id} is invalid.
+@subheading DIRECTIVE STATUS CODES:
-@end table
+@code{@value{RPREFIX}SUCCESSFUL} - successful operation@*
+@code{@value{RPREFIX}INVALID_ADDRESS} - @code{cpuset} is NULL@*
+@code{@value{RPREFIX}INVALID_ID} - invalid task id@*
+@code{@value{RPREFIX}INVALID_NUMBER} - invalid processor affinity set
@subheading DESCRIPTION:
-The @code{rtems_task_set_affinity} routine is used to set the
-@code{affinity.set} field of the thread control object associated
-with @code{id}. This value controls the @code{cpuset} that the task can
-execute on.
+Sets the processor affinity set for the task specified by @code{cpuset}. A set
+bit in the affinity set means that the task can execute on this processor and a
+cleared bit means the opposite.
@subheading NOTES:
-NONE
+None.
--
1.7.7
___
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
[PATCH 2/8] doc: rtems_get_current_processor()
--- doc/user/smp.t | 38 ++ 1 files changed, 38 insertions(+), 0 deletions(-) diff --git a/doc/user/smp.t b/doc/user/smp.t index b0d1189..3d565ef 100644 --- a/doc/user/smp.t +++ b/doc/user/smp.t @@ -258,6 +258,44 @@ maximum count of application configured processors. None. @c +@c rtems_get_current_processor +@c +@page +@subsection GET_CURRENT_PROCESSOR - Get current processor index + +@subheading CALLING SEQUENCE: + +@ifset is-C +@example +uint32_t rtems_get_current_processor(void); +@end example +@end ifset + +@ifset is-Ada +@end ifset + +@subheading DIRECTIVE STATUS CODES: + +The index of the current processor. + +@subheading DESCRIPTION: + +On uni-processor configurations a value of zero will be returned. + +On SMP configurations an architecture specific method is used to obtain the +index of the current processor in the system. The set of processor indices is +the range of integers starting with zero up to the processor count minus one. + +Outside of sections with disabled thread dispatching the current processor +index may change after every instruction since the thread may migrate from one +processor to another. Sections with disabled interrupts are sections with +thread dispatching disabled. + +@subheading NOTES: + +None. + +@c @c rtems_task_get_affinity @c @page -- 1.7.7 ___ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
Re: SMP Implementation Status
Hello Jeff, I updated the status subsections in the implementation section. On 2014-04-15 18:15, Jeff Mayes wrote: Hi all, I’m trying to create a table on the RTEMS Wiki to monitor the SMP implementation efforts. See http://www.rtems.org/wiki/index.php/SMP. For anyone working in this area, would you please share the status of your efforts? Not looking for deep details, just high level comments about any ongoing and future implementation. Thanks Jeff ___ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
SMP: Next steps
Hello, my next steps are o documentation update for the recent high-level API functions introduced to support clustered/partitioned scheduling, o support for a priority boost to fix priority inheritance across scheduler boundaries, o migration to another scheduler for started threads (forced thread migration), and o support for the MrsP protocol. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
Re: [rtems commit] rtems: Add task get/set scheduler
On 2014-04-15 18:20, Joel Sherrill wrote: On 4/15/2014 11:14 AM, Sebastian Huber wrote: On 04/15/2014 02:48 PM, Sebastian Huber wrote: On 2014-04-15 14:36, Joel Sherrill wrote: You added to the API and added no documentation. I added the documentation in Doxygen: http://www.rtems.org/pipermail/rtems-devel/2014-March/005901.html Ok, since we are close to the RTEMS 4.11 release I will add texinfo documentation to all new high-level functions. After the RTEMS 4.11 release we should definitely do something against this copy and paste nightmare. Joel, what is your opinion with respect to the future documentation infrastructure of RTEMS? User Guides should not be in Doxygen. It is possible to write user guides with Doxygen (see @page command). But we do have to move to something besides Texinfo for user guides. Amar has ideas and proposals once we get past his current goals. Also some of the current documentation is out of date no matter what form it is. This includes readme's, some wiki content, and a couple of texinfo manuals. FWIW I haven't posted yet about this but the life cycle field in the TCB didn't get a Doxygen comment. Noticed it teaching last week. Sorry, should be fixed now. And do you get warnings in Doxygen from RTEMS? Do we have them disabled? I can't believe that http://www.rtems.org/onlinedocs/doxygen/doxy.log doesn't show any. Yes, there should be lots of warnings. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
Re: spintrcricitical20 failure
On 2014-04-15 18:40, Joel Sherrill wrote: Hi This has been failing a while. Any ideas? *** BEGIN OF TEST SPINTRCRITICAL 20 *** Support - rtems_timer_create - creating timer 1 ../../../../../../../rtems/c/src/../../testsuites/sptests/spintrcritical20/init.c: 139 ctx->thread_queue_was_null The spintrcritical* tests are timing dependent and sporadically fail. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
Re: heapwalk failing on sis
On 2014-04-15 18:41, Joel Sherrill wrote: Hi Again.. failing for a while https://www.rtems.org/bugzilla/show_bug.cgi?id=2177 -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
Important notice for SMP users
Hello, all SMP users of RTEMS should update to the latest Git master version or at least back port the following patches: http://git.rtems.org/rtems/commit/?id=33d0666d02832f63dfd035c7ac9890b4397a1fdc http://git.rtems.org/rtems/commit/?id=91e7b0c5ae837c055fd67d77d8db26bfb648261b Without these fixes unpredictable run-time behaviour can occur. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
Re: [PATCH] sapi: Error case for CONFIGURE_UNLIMITED_OBJECTS
On 2014-04-16 05:55, Chris Johns wrote: On 15/04/2014 9:33 pm, Sebastian Huber wrote: --- cpukit/sapi/include/confdefs.h |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/cpukit/sapi/include/confdefs.h b/cpukit/sapi/include/confdefs.h index c8a9d0e..8b9b3e1 100644 --- a/cpukit/sapi/include/confdefs.h +++ b/cpukit/sapi/include/confdefs.h @@ -1583,6 +1583,12 @@ const rtems_libio_helper rtems_fs_init_helper = * classic or posix objects that have not already been given resource limits. */ #if defined(CONFIGURE_UNLIMITED_OBJECTS) + #if !defined(CONFIGURE_UNIFIED_WORK_AREAS) && \ + !defined(CONFIGURE_EXECUTIVE_RAM_SIZE) && \ + !defined(CONFIGURE_MEMORY_OVERHEAD) + #error "Using CONFIGURE_UNLIMITED_OBJECTS with a pre-calculated work space size makes no sense" + #endif + #if !defined(CONFIGURE_UNLIMITED_ALLOCATION_SIZE) /** * This macro specifies a default allocation size for when auto-extending The use case is (was?) a fixed size or bounded pool of memory that can be used in different ways depending on what is being run depending on how the app is configured. I am not fussed either way what happens here as the unified work areas is a nice feature. Use case for CONFIGURE_UNLIMITED_OBJECTS is to enable the unlimited option for all objects. This makes only sense if we have a work space which has some free space. There are three means to do this as far as I know. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
