Re: New source layout.
On Thu, Mar 12, 2015 at 9:21 AM, Amar Takhar wrote: > On 2015-03-12 14:19 +0100, Sebastian Huber wrote: >> >> >> On 12/03/15 14:13, Amar Takhar wrote: >> > On 2015-03-12 14:10 +0100, Sebastian Huber wrote: >> >> >> >>> #include >> >>> #include >> >> This will not work. We have sparc, arm, powerpc etc. and they must not >> >> be visible at the same time. >> > What do you mean by 'visible'? >> >> If I build for arm, then I need the arm and not the >> one for sparc or powerpc. > > I wasn't clear. Wherever you include 'percpu.h' you would include the correct > cpu.h above it and remove the #include <...cpu.h> from percpu.h. > This doesn't work in supposedly CPU-independent source code files. Let's take percpu.h as an example. We need to include it in -- the main header for thread scheduling that is included by virtually every source file in the supercore. We can't include the CPU-dependent headers here, unless we use the CPP #if-elif cascase as mentioned by Sebastian. Gedare > > Amar. > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: New source layout.
On Thu, Mar 12, 2015 at 9:51 AM, Amar Takhar wrote: > On 2015-03-12 09:45 -0400, Gedare Bloom wrote: >> This doesn't work in supposedly CPU-independent source code files. >> >> Let's take percpu.h as an example. We need to include it in >> -- the main header for thread scheduling that >> is included by virtually every source file in the supercore. We can't >> include the CPU-dependent headers here, unless we use the CPP #if-elif >> cascase as mentioned by Sebastian. > > The eventual goal is everything would be distilled to a single header per arch > that would have to be included in your application source. Right now that is > not possible and we do use the if-elif solution right now in the waf build as > a > stopgap. > Relying on the application to provide the header means coupling the RTEMS build to the application build. This is an as-yet-undiscussed direction that should be elaborated in a separate thread. I might be happy with some CPP magic to hide the if-elif cascade if that is plausible. RTEMS_INCLUDE_CPU_SPECIFIC(cpu.h) or some such. > I've asked Chris to better explain this he understands the issues from an > RTEMS > perspective better than I do. He also knows what the eventual goal of the > header move is. > OK. > To be clear: the intermediary period is already solved in the waf build > nothing > will have to change. As we change / 'unwind' the headers we'll modify the > source. This is going to be a drawn out process. The nice thing is any > changes > we make in this regard is verifiable by using hashes of the resulting objects. > > > Amar. > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 2/2] posix: Return error code if mmap is used
Thanks.
On Thu, Mar 12, 2015 at 4:04 AM, Daniel Cederman wrote:
> ---
> cpukit/posix/src/mmap.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/cpukit/posix/src/mmap.c b/cpukit/posix/src/mmap.c
> index 3ebb2f4..90c6d0a 100644
> --- a/cpukit/posix/src/mmap.c
> +++ b/cpukit/posix/src/mmap.c
> @@ -26,5 +26,5 @@ void *mmap(
>off_t off
> )
> {
> - return NULL;
> + return MAP_FAILED;
> }
> --
> 2.2.1
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: New source layout.
On Thu, Mar 12, 2015 at 10:08 AM, Joel Sherrill wrote: > > > On March 12, 2015 8:56:36 AM CDT, Gedare Bloom wrote: >>On Thu, Mar 12, 2015 at 9:51 AM, Amar Takhar wrote: >>> On 2015-03-12 09:45 -0400, Gedare Bloom wrote: >>>> This doesn't work in supposedly CPU-independent source code files. >>>> >>>> Let's take percpu.h as an example. We need to include it in >>>> -- the main header for thread scheduling that >>>> is included by virtually every source file in the supercore. We >>can't >>>> include the CPU-dependent headers here, unless we use the CPP >>#if-elif >>>> cascase as mentioned by Sebastian. >>> >>> The eventual goal is everything would be distilled to a single header >>per arch >>> that would have to be included in your application source. Right now >>that is >>> not possible and we do use the if-elif solution right now in the waf >>build as a >>> stopgap. >>> >>Relying on the application to provide the header means coupling the >>RTEMS build to the application build. This is an as-yet-undiscussed >>direction that should be elaborated in a separate thread. > > I am opposed to anything that works against modularity and increases > cohesion. Some of the architecture .h files may be able to be combined but > they all should not be. > > I am also strongly opposed to making architecture visible to the application > source code. We have worked hard to prevent this. > >>I might be happy with some CPP magic to hide the if-elif cascade if >>that is plausible. >>RTEMS_INCLUDE_CPU_SPECIFIC(cpu.h) >>or some such. > > This is ok for port files but may be unworkable for bsp related ones. It > would at least take a two level cascade to be managable for per bsp files. > There shouldn't be any BSP includes in target-independent code. Do you know of some? > The user visible level view should not change. > Agreed. > >>> I've asked Chris to better explain this he understands the issues >>from an RTEMS >>> perspective better than I do. He also knows what the eventual goal >>of the >>> header move is. >>> >>OK. >> >>> To be clear: the intermediary period is already solved in the waf >>build nothing >>> will have to change. As we change / 'unwind' the headers we'll >>modify the >>> source. This is going to be a drawn out process. The nice thing is >>any changes >>> we make in this regard is verifiable by using hashes of the resulting >>objects. >>> >>> >>> Amar. >>> ___ >>> devel mailing list >>> devel@rtems.org >>> http://lists.rtems.org/mailman/listinfo/devel >>___ >>devel mailing list >>devel@rtems.org >>http://lists.rtems.org/mailman/listinfo/devel > > --joel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Detecting Tests Which Don't Have Enough Workspace
On Thu, Mar 12, 2015 at 1:41 PM, Joel Sherrill
wrote:
> Hi
>
> Many BSPs can link a test but don't actually have enough memory
> to run the test. They will fail in the first few lines when the requested
> memory for the RTEMS work area is not available. I hacked together
> a script which adds together the code, data, bss, work space and
> stack space requested. If this exceeds physical memory on the board,
> then the test will fail. It is possible to come close and still run out of
> memory during initialization (e.g. malloc, etc) but this approach could
> detect some tests which will fail by inspecting them on the host.
>
> This is a shell script but would be better built into the rtems-tools
> and using the gdb/mi. Combined with information on the
> available memory on the target, we could throw out some obvious
> failure cases without touching hardware.
>
> Thoughts?
>
Would it be worthwhile to instrument our build (post-link) to do
something like this?
> ===
> #! /bin/sh
>
> if [ $# -le 2 ] ; then
> echo "Usage: $0 ARCH EXE ..."
> exit 1
> fi
>
> ARCH=$1
> shift
>
> target=${ARCH}-rtems4.11
> type ${ARCH}-rtems4.11-size >/dev/null 2>&1
> if [ $? -ne 0 ] ; then
> echo "${ARCH} does not appear to have RTEMS 4.11 tools installed"
> exit 1
> fi
>
>
> extract_size()
> {
> ( echo "p Configuration.work_space_size" ; \
> echo "quit" ) | ${target}-gdb ${exe} 2>&1 | grep "\$1" | \
> cut -d'=' -f2
> }
>
> for exe in $*
> do
> image_size=`${target}-size ${exe} | tail -1 | cut -f4`
> wkspace_size=`extract_size Configuration.work_space_size`
> stackspace_size=`extract_size Configuration.stack_space_size`
>
> #echo ${image_size} ${wkspace_size} ${stackspace_size}
>
> total=`echo ${image_size} ${wkspace_size} + ${stackspace_size} + p | dc`
> echo ${total} ${exe}
> done
>
> exit 0
>
> ===
>
> --
> 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
>
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: Detecting Tests Which Don't Have Enough Workspace
On Thu, Mar 12, 2015 at 2:26 PM, Joel Sherrill
wrote:
>
>
> On 3/12/2015 12:45 PM, Gedare Bloom wrote:
>> On Thu, Mar 12, 2015 at 1:41 PM, Joel Sherrill
>> wrote:
>>> Hi
>>>
>>> Many BSPs can link a test but don't actually have enough memory
>>> to run the test. They will fail in the first few lines when the requested
>>> memory for the RTEMS work area is not available. I hacked together
>>> a script which adds together the code, data, bss, work space and
>>> stack space requested. If this exceeds physical memory on the board,
>>> then the test will fail. It is possible to come close and still run out of
>>> memory during initialization (e.g. malloc, etc) but this approach could
>>> detect some tests which will fail by inspecting them on the host.
>>>
>>> This is a shell script but would be better built into the rtems-tools
>>> and using the gdb/mi. Combined with information on the
>>> available memory on the target, we could throw out some obvious
>>> failure cases without touching hardware.
>>>
>>> Thoughts?
>>>
>> Would it be worthwhile to instrument our build (post-link) to do
>> something like this?
> I think it is worth doing something with this. We need to know a few
> things about a BSP to do this in the general case:
>
You could start by just printing a warning based on assumptions,
caveat emptor. You might be able to snoop some of the relevant info
from the link script if that is accessible.
> + Is code loaded into RAM? If not, it doesn't need to be taken into account.
> + How much RAM is there?
> + In some cases, the program may not load at offset 0 of RAM and there
>could be a reserved area. One case is m68k BSPs which sometimes load
> at 0x3000 or 0x4000 to leave space for a ROM monitor. We could ignore
> this factor and just take a hit when it is run.
>
> But it definitely could avoid running some tests which are guaranteed to
> fail. Consider this output:
>
> $ sh ../rtsize v850
> ./v850-rtems4.11/c/v850sim/testsuites/fstests/fsdos*/*.exe
> 216338
> ./v850-rtems4.11/c/v850sim/testsuites/fstests/fsdosfsformat01/fsdosfsformat01.exe
> 1259536
> ./v850-rtems4.11/c/v850sim/testsuites/fstests/fsdosfsname01/fsdosfsname01.exe
>
> There is only 1MB RAM for the simulator. The second test is doomed. It
> will not run. The first may run.
>
>>> ===
>>> #! /bin/sh
>>>
>>> if [ $# -le 2 ] ; then
>>> echo "Usage: $0 ARCH EXE ..."
>>> exit 1
>>> fi
>>>
>>> ARCH=$1
>>> shift
>>>
>>> target=${ARCH}-rtems4.11
>>> type ${ARCH}-rtems4.11-size >/dev/null 2>&1
>>> if [ $? -ne 0 ] ; then
>>> echo "${ARCH} does not appear to have RTEMS 4.11 tools installed"
>>> exit 1
>>> fi
>>>
>>>
>>> extract_size()
>>> {
>>> ( echo "p Configuration.work_space_size" ; \
>>> echo "quit" ) | ${target}-gdb ${exe} 2>&1 | grep "\$1" | \
>>> cut -d'=' -f2
>>> }
>>>
>>> for exe in $*
>>> do
>>> image_size=`${target}-size ${exe} | tail -1 | cut -f4`
>>> wkspace_size=`extract_size Configuration.work_space_size`
>>> stackspace_size=`extract_size Configuration.stack_space_size`
>>>
>>> #echo ${image_size} ${wkspace_size} ${stackspace_size}
>>>
>>> total=`echo ${image_size} ${wkspace_size} + ${stackspace_size} + p | dc`
>>> echo ${total} ${exe}
>>> done
>>>
>>> exit 0
>>>
>>> ===
>>>
>>> --
>>> 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
>>>
>>>
>>> ___
>>> devel mailing list
>>> devel@rtems.org
>>> http://lists.rtems.org/mailman/listinfo/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
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: Detecting Tests Which Don't Have Enough Workspace
On Thu, Mar 12, 2015 at 6:58 PM, Amar Takhar wrote: > On 2015-03-12 12:41 -0500, Joel Sherrill wrote: >> Hi >> >> Many BSPs can link a test but don't actually have enough memory >> to run the test. They will fail in the first few lines when the requested >> memory for the RTEMS work area is not available. I hacked together >> a script which adds together the code, data, bss, work space and >> stack space requested. If this exceeds physical memory on the board, >> then the test will fail. It is possible to come close and still run out of >> memory during initialization (e.g. malloc, etc) but this approach could >> detect some tests which will fail by inspecting them on the host. > > The waf build prints a warning during compile time that the test will not fit > and pass the build. I was going to add a summary at the end for any tests > that > won't fit and also add it to a report on BuildBot. > It includes the workspace size in its estimation of space? Already if a test's binary executable size doesn't fit the build will fail at link-time. > > Amar. > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Branching 4.11
On Fri, Mar 13, 2015 at 1:04 AM, Chris Johns wrote: > On 11/03/2015 1:33 am, Amar Takhar wrote: >> >> Can we come up with a plan for branching 4.11? >> >> We need to push off any commits made that are unrelated to tickets open in >> milestone 4.11 to the next release. This way any changes we make have a >> narrow >> scope. >> >> This close to the release we should really be in a slush period then a >> hard >> close once all issues are resolved and we are working on the release >> process. >> >> Any commits after branching should only be related to getting 4.11 out. >> > > I think we are in a slushy period and so we should be narrowing down > changes. > > A couple of major issues: > > 1. We need a suitable newlib snapshot to reference. > 2. We need to move to gdb-7.9 so we can at least build Windows > tools on Windows. GDB 7.9 does not build for SPARC with our > local patches. > I would like to consider landing the drvmgr and pci patch-set as a sparc-specific feature (e.g. only included in builds for sparc.) The code is effectively being used by sparc users already via RCC. The bad thing is it is a lot of "untested code" (from an RTEMS Project perspective), but we have no means to test it effectively anyways since it is all hardware-dependent. > In my view we cannot move until we have these items sorted. > > Chris > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: RPi Support GSoC 2015
Hi, RPi is a good open project. The BSP is in c/src/lib/libbsp/arm/raspberrypi I think the prior gsoc effort has some links/pointers in it. You will need to have the board and prove you can build RTEMS for it and run it. Gedare On Fri, Mar 13, 2015 at 11:43 AM, Юрий Шевцов wrote: > Hello there! I would like to participate in GSoC with RTEMS Project. As for > now I'm considering to improve RPi support. Project's page says that some > progress has done. Where can I found this code and some examples for other > boards maybe. I have lurked RTEMS git repo a little but haven't found any > RPi related stuff. Thanks in advance) > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: RPi Support GSoC 2015
On Fri, Mar 13, 2015 at 12:05 PM, Юрий Шевцов wrote: > Am I right that completing Hello is just change and somehow submit lines in > samples/hello/init.c ? And how can I submit the proof, of course?) > Correct. You can send an email here with patch attached and a link to a screenshot posted somewhere. > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC 2015 - Raspberry Pi improvements
You should read the blog pages starting at http://alanstechnotes.blogspot.com/2013/03/rtems-on-raspberry-pi.html There are a few blog posts there. Some is outdated but mostly it should work I guess, using git.rtems,org for the git repositories now that all support is in "upstream" RTEMS Project repos. -Gedare On Fri, Mar 13, 2015 at 12:39 PM, Rohini Kulkarni wrote: > Hi, > > I am new to using Raspberry pi. I saw the READ ME for Raspberry pi BSP. I > have got the files stated there, except the config.txt. I also read some > steps on the Raspberry pi website regarding getting the image onto the SD > card. > Also, I do not understand what the stripping step will do. I need some help > to figure out booting RTEMS on the board. > > Thanks! > > On 11 Mar 2015 19:29, "Gedare Bloom" wrote: >> >> On Wed, Mar 11, 2015 at 9:52 AM, Rohini Kulkarni >> wrote: >> > Hi, >> > >> > I am interested in contributing to this project. I referred the page >> > Raspberry Pi improvements and also took a look at the work done under >> > GSoc2013. It would be great if the mentors could help me with some >> > queries. >> > >> > [1] Is there any reference for already proposed ideas. On the page >> > Beagle >> > BSP improvements , I saw a list of missing peripherals. Is there such a >> > list >> > for Raspberry Pi as well? >> > >> There was an email thread about this recently, see [1]. I think there >> is plenty of work to do. >> >> > [2] What are the requirements and how should I proceed for this project. >> > >> You need to own a Raspberry Pi, or a Raspberry Pi 2. If you have an >> RPi2, you may consider adding it as a BSP variant and getting SMP >> working on it as a nice project. You should ideally demonstrate that >> you can build the tools and boot RTEMS on the RPi. >> >> [1] https://lists.rtems.org/pipermail/devel/2015-March/010181.html >> >> > >> > Thanks! >> > >> > >> > >> > ___ >> > devel mailing list >> > devel@rtems.org >> > http://lists.rtems.org/mailman/listinfo/devel > > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Branching 4.11
On Fri, Mar 13, 2015 at 8:38 PM, Chris Johns wrote: > On 14/03/2015 12:30 am, Gedare Bloom wrote: >> >> I would like to consider landing the drvmgr and pci patch-set as a >> sparc-specific feature (e.g. only included in builds for sparc.) > > > How is this controlled or are you saying we state in the release notes this > is only currently tested on SPARC BSPs ? > Correct. >> The >> code is effectively being used by sparc users already via RCC. The bad >> thing is it is a lot of "untested code" (from an RTEMS Project >> perspective), > > > I could not see any tests in the patch set. This is currently my main issue > with merging now. Adding code to cpukit tree should have some tests. The > drvmgr tests should be able to run on any BSP. > I agree, but I see this taking much more time due to the nature of hardware. We'll need some dummy drivers to exercise the drvmgr. I'd be happy to see this work taken up in a GSoC, but it will definitely be needed to move the code out of "sparc-specific" >> but we have no means to test it effectively anyways >> since it is all hardware-dependent. > > > Yes there is the issue of on going testing of some of the drivers added. I > suspect we need a commercial simulator to test. The buildbot work Amar is > doing should support slaves so it would be nice to see publicly a commitment > we can get access to a build slave hosted by someone with a suitable > simulator. > This is above my pay-grade. > Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] autoconf changes
Me too. I'm not sure why.. On Sat, Mar 14, 2015 at 1:44 PM, Ben Gras wrote: > Everytime I ./bootstrap && ./bootstrap -p, I get these changes > w.r.t. mainline. Just tried again with a new tools build. (With the > prefix/bin dir first in $PATH of course.) > > Or is it just me? > > --- > c/src/lib/libbsp/bfin/acinclude.m4| 4 ++-- > c/src/lib/libbsp/powerpc/acinclude.m4 | 4 ++-- > 2 files changed, 4 insertions(+), 4 deletions(-) > > diff --git a/c/src/lib/libbsp/bfin/acinclude.m4 > b/c/src/lib/libbsp/bfin/acinclude.m4 > index ab6082e..828fd89 100644 > --- a/c/src/lib/libbsp/bfin/acinclude.m4 > +++ b/c/src/lib/libbsp/bfin/acinclude.m4 > @@ -2,12 +2,12 @@ > AC_DEFUN([RTEMS_CHECK_BSPDIR], > [ >case "$1" in > - TLL6527M ) > -AC_CONFIG_SUBDIRS([TLL6527M]);; >bf537Stamp ) > AC_CONFIG_SUBDIRS([bf537Stamp]);; >eZKit533 ) > AC_CONFIG_SUBDIRS([eZKit533]);; > + TLL6527M ) > +AC_CONFIG_SUBDIRS([TLL6527M]);; >*) > AC_MSG_ERROR([Invalid BSP]);; >esac > diff --git a/c/src/lib/libbsp/powerpc/acinclude.m4 > b/c/src/lib/libbsp/powerpc/acinclude.m4 > index 6442399..e46fa2b 100644 > --- a/c/src/lib/libbsp/powerpc/acinclude.m4 > +++ b/c/src/lib/libbsp/powerpc/acinclude.m4 > @@ -38,12 +38,12 @@ AC_DEFUN([RTEMS_CHECK_BSPDIR], > AC_CONFIG_SUBDIRS([t32mppc]);; >tqm8xx ) > AC_CONFIG_SUBDIRS([tqm8xx]);; > - virtex ) > -AC_CONFIG_SUBDIRS([virtex]);; >virtex4 ) > AC_CONFIG_SUBDIRS([virtex4]);; >virtex5 ) > AC_CONFIG_SUBDIRS([virtex5]);; > + virtex ) > +AC_CONFIG_SUBDIRS([virtex]);; >*) > AC_MSG_ERROR([Invalid BSP]);; >esac > -- > 1.9.1 > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] beagle bsp: delete TIMER_FREQ, TIMER_COUNT
OK to commit.
On Sat, Mar 14, 2015 at 1:45 PM, Ben Gras wrote:
> unused and poorly named (no prefix) and colliding with sp68.
>
> Closes #2302.
> ---
> c/src/lib/libbsp/arm/beagle/include/bsp.h | 4
> 1 file changed, 4 deletions(-)
>
> diff --git a/c/src/lib/libbsp/arm/beagle/include/bsp.h
> b/c/src/lib/libbsp/arm/beagle/include/bsp.h
> index e235efa..0e7a5ff 100644
> --- a/c/src/lib/libbsp/arm/beagle/include/bsp.h
> +++ b/c/src/lib/libbsp/arm/beagle/include/bsp.h
> @@ -114,10 +114,6 @@ static inline void flush_data_cache(void)
> asm volatile("mov r0, #0; mcr p15, #0, r0, c7, c10, #4" : : : "memory");
> }
>
> -
> -#define TIMER_FREQ 1000/* clock frequency for OMAP timer (1ms) */
> -#define TIMER_COUNT(freq) (TIMER_FREQ/(freq)) /* initial value for counter*/
> -
> #define __arch_getb(a) (*(volatile unsigned char *)(a))
> #define __arch_getw(a) (*(volatile unsigned short *)(a))
> #define __arch_getl(a) (*(volatile unsigned int *)(a))
> --
> 1.9.1
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: Hello demo on RPI
On Sun, Mar 15, 2015 at 5:50 AM, QIAO YANG wrote: > Hi ! > > I've managed to run a hello demo on RPI B/B+, including a demo for loading > an image by u-boot (I don't have an ethernet cable on my hand, but I'm > going to be able to load the image by tftp for dev). > > If I've got it right, to prepare my proposal I may choose part of the TODO > list , look into the implementation detail and schedule it. The work list > may be divided for 3 students to complete. > > I've checked out the André's branch with GPIO, I2C, SPI implementations. > Should we develop based on his branch or the upstream? Have we said that > the I2C, SPI API has changed? I wonder that if anyone is working on it and > if we will merge Andre's work to upstream at the begining of GSOC. If not, > maybe I can get start by trying to do this job. > > The obvious projects I see from https://devel.rtems.org/wiki/Developer/Projects/Open/ImproveRaspberryPiBSP are: 1) Get #1-3 mergeable. May not take much. Then do #4 SD-card support and refactor the i2c to use the newer cpukit/dev/i2c interface. 2) #5 Graphics Frame Buffer + #7 HDMI/Graphics console 3) #6 USB + #7 Networking 4) Raspberry Pi 2 support, but this probably isn't enough. -Gedare ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [rtems commit] rtems: make error codes uintptr_t
On Mon, Mar 16, 2015 at 2:23 PM, Sebastian Huber
wrote:
>
> - Gedare Bloom schrieb:
>> Module:rtems
>> Branch:master
>> Commit:1ff449cfc473f6b88e1495492aebd665ad42b236
>> Changeset:
>> http://git.rtems.org/rtems/commit/?id=1ff449cfc473f6b88e1495492aebd665ad42b236
>>
>> Author:Gedare Bloom
>> Date: Mon Mar 16 12:15:27 2015 -0400
>>
>> rtems: make error codes uintptr_t
>>
>> ---
>>
>> cpukit/score/include/rtems/score/interr.h | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/cpukit/score/include/rtems/score/interr.h
>> b/cpukit/score/include/rtems/score/interr.h
>> index e0cedaf..7c2a604 100644
>> --- a/cpukit/score/include/rtems/score/interr.h
>> +++ b/cpukit/score/include/rtems/score/interr.h
>> @@ -164,7 +164,7 @@ typedef enum {
>>INTERNAL_ERROR_RESOURCE_IN_USE
>> } Internal_errors_Core_list;
>>
>> -typedef uint32_t Internal_errors_t;
>> +typedef uintptr_t Internal_errors_t;
>
> This is a problem on 16-bit targets. I suggest to use unsigned long here.
I guess this is fine as long as all 64-bit targets are LP64.
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [GSoC] "RPi BSP improvement" idea separation
On Mon, Mar 16, 2015 at 3:21 PM, Joel Sherrill wrote: > I don't know if this has been posted or merged into the WIki. > Alan, Gedare and I were discussing this earlier today. One thing > to remember is that it is always possible something we think > is 1/2 a summer is incredibly easy so bonus tasks should be > defined for every student. In broad strokes, a possible breakdown > could be. > > + Complete GPIO/I2C/SPI integration and add SD card > support (since it uses SPI) > > + USB and Network stack based on new BSP stack > > + Raspberry Pi 2 optimization and SMP support > Basic support is merged but the cache is clearly > not in the right state based on benchmarks and > the MMU might need initialization based on an > early report from Alan. For sure, all capabilities > that work now or begin to work on the Pi1 will > need to be checked on Pi 2. > My intuition is there needs to be extra work added beyond just fine-tuning the RPI2. > + User interface stack > This could include an HDMI/USB console, and perhaps a > port for the RTEMS graphics library. Obviously, you > can't use any USB devices for UI unless the USB stack > works so the USB effort would bring that up while > doing the graphics work. Then move to USB UI devices. > Avoid proposing any work that overlaps (conflict or dependent) on another. No USB UI devices should be proposed. > --joel > > > On 3/16/2015 1:59 PM, Yurii Shevtsov wrote: >> Is there any final list of items? I have red through this thread >> https://lists.rtems.org/pipermail/devel/2015-March/010175.html but I >> didn't found any final list, except Joel's Sherrill suggestion >> (https://lists.rtems.org/pipermail/devel/2015-March/010184.html). >> Personally I would like to work on USB-related stuff since I have >> experience in that field. Thanks in advance! >> ___ >> devel mailing list >> devel@rtems.org >> http://lists.rtems.org/mailman/listinfo/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 > > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [rtems commit] rtems: make error codes uintptr_t
On Mon, Mar 16, 2015 at 3:36 PM, Sebastian Huber
wrote:
>
> - Gedare Bloom schrieb:
>> On Mon, Mar 16, 2015 at 2:23 PM, Sebastian Huber
>> wrote:
>> >
>> > - Gedare Bloom schrieb:
>> >> Module:rtems
>> >> Branch:master
>> >> Commit:1ff449cfc473f6b88e1495492aebd665ad42b236
>> >> Changeset:
>> >> http://git.rtems.org/rtems/commit/?id=1ff449cfc473f6b88e1495492aebd665ad42b236
>> >>
>> >> Author:Gedare Bloom
>> >> Date: Mon Mar 16 12:15:27 2015 -0400
>> >>
>> >> rtems: make error codes uintptr_t
>> >>
>> >> ---
>> >>
>> >> cpukit/score/include/rtems/score/interr.h | 2 +-
>> >> 1 file changed, 1 insertion(+), 1 deletion(-)
>> >>
>> >> diff --git a/cpukit/score/include/rtems/score/interr.h
>> >> b/cpukit/score/include/rtems/score/interr.h
>> >> index e0cedaf..7c2a604 100644
>> >> --- a/cpukit/score/include/rtems/score/interr.h
>> >> +++ b/cpukit/score/include/rtems/score/interr.h
>> >> @@ -164,7 +164,7 @@ typedef enum {
>> >>INTERNAL_ERROR_RESOURCE_IN_USE
>> >> } Internal_errors_Core_list;
>> >>
>> >> -typedef uint32_t Internal_errors_t;
>> >> +typedef uintptr_t Internal_errors_t;
>> >
>> > This is a problem on 16-bit targets. I suggest to use unsigned long here.
>> I guess this is fine as long as all 64-bit targets are LP64.
>
> The rtems_task_argument has a similar problem. Maybe we need a new CPU type,
> e.g. CPU_Uintptr_and_at_least_32_bits.
OK, we could do something like
typedef unsigned long CPU_Uint32ptr;
in the 16-bit targets, and
typedef uintptr_t CPU_Uint32ptr;
in the rest, in their score/cpu.h files.
The only obvious alternative I see would be to limit strictly the
error code and task args to be int or ptr.
Gedare
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [rtems commit] rtems: make error codes uintptr_t
On Mon, Mar 16, 2015 at 3:53 PM, Gedare Bloom wrote:
> On Mon, Mar 16, 2015 at 3:36 PM, Sebastian Huber
> wrote:
>>
>> - Gedare Bloom schrieb:
>>> On Mon, Mar 16, 2015 at 2:23 PM, Sebastian Huber
>>> wrote:
>>> >
>>> > - Gedare Bloom schrieb:
>>> >> Module:rtems
>>> >> Branch:master
>>> >> Commit:1ff449cfc473f6b88e1495492aebd665ad42b236
>>> >> Changeset:
>>> >> http://git.rtems.org/rtems/commit/?id=1ff449cfc473f6b88e1495492aebd665ad42b236
>>> >>
>>> >> Author:Gedare Bloom
>>> >> Date: Mon Mar 16 12:15:27 2015 -0400
>>> >>
>>> >> rtems: make error codes uintptr_t
>>> >>
>>> >> ---
>>> >>
>>> >> cpukit/score/include/rtems/score/interr.h | 2 +-
>>> >> 1 file changed, 1 insertion(+), 1 deletion(-)
>>> >>
>>> >> diff --git a/cpukit/score/include/rtems/score/interr.h
>>> >> b/cpukit/score/include/rtems/score/interr.h
>>> >> index e0cedaf..7c2a604 100644
>>> >> --- a/cpukit/score/include/rtems/score/interr.h
>>> >> +++ b/cpukit/score/include/rtems/score/interr.h
>>> >> @@ -164,7 +164,7 @@ typedef enum {
>>> >>INTERNAL_ERROR_RESOURCE_IN_USE
>>> >> } Internal_errors_Core_list;
>>> >>
>>> >> -typedef uint32_t Internal_errors_t;
>>> >> +typedef uintptr_t Internal_errors_t;
>>> >
>>> > This is a problem on 16-bit targets. I suggest to use unsigned long here.
>>> I guess this is fine as long as all 64-bit targets are LP64.
>>
>> The rtems_task_argument has a similar problem. Maybe we need a new CPU
>> type, e.g. CPU_Uintptr_and_at_least_32_bits.
>
> OK, we could do something like
> typedef unsigned long CPU_Uint32ptr;
> in the 16-bit targets, and
> typedef uintptr_t CPU_Uint32ptr;
> in the rest, in their score/cpu.h files.
>
Actually, we can do something else by checking if size of pointer less
than size of long, use unsigned long, otherwise use uintptr_t.
> The only obvious alternative I see would be to limit strictly the
> error code and task args to be int or ptr.
>
> Gedare
>
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [rtems commit] rtems: make error codes uintptr_t
On Mon, Mar 16, 2015 at 3:53 PM, Gedare Bloom wrote:
> On Mon, Mar 16, 2015 at 3:36 PM, Sebastian Huber
> wrote:
>>
>> - Gedare Bloom schrieb:
>>> On Mon, Mar 16, 2015 at 2:23 PM, Sebastian Huber
>>> wrote:
>>> >
>>> > - Gedare Bloom schrieb:
>>> >> Module:rtems
>>> >> Branch:master
>>> >> Commit:1ff449cfc473f6b88e1495492aebd665ad42b236
>>> >> Changeset:
>>> >> http://git.rtems.org/rtems/commit/?id=1ff449cfc473f6b88e1495492aebd665ad42b236
>>> >>
>>> >> Author:Gedare Bloom
>>> >> Date: Mon Mar 16 12:15:27 2015 -0400
>>> >>
>>> >> rtems: make error codes uintptr_t
>>> >>
>>> >> ---
>>> >>
>>> >> cpukit/score/include/rtems/score/interr.h | 2 +-
>>> >> 1 file changed, 1 insertion(+), 1 deletion(-)
>>> >>
>>> >> diff --git a/cpukit/score/include/rtems/score/interr.h
>>> >> b/cpukit/score/include/rtems/score/interr.h
>>> >> index e0cedaf..7c2a604 100644
>>> >> --- a/cpukit/score/include/rtems/score/interr.h
>>> >> +++ b/cpukit/score/include/rtems/score/interr.h
>>> >> @@ -164,7 +164,7 @@ typedef enum {
>>> >>INTERNAL_ERROR_RESOURCE_IN_USE
>>> >> } Internal_errors_Core_list;
>>> >>
>>> >> -typedef uint32_t Internal_errors_t;
>>> >> +typedef uintptr_t Internal_errors_t;
>>> >
>>> > This is a problem on 16-bit targets. I suggest to use unsigned long here.
>>> I guess this is fine as long as all 64-bit targets are LP64.
>>
>> The rtems_task_argument has a similar problem. Maybe we need a new CPU
>> type, e.g. CPU_Uintptr_and_at_least_32_bits.
>
> OK, we could do something like
> typedef unsigned long CPU_Uint32ptr;
> in the 16-bit targets, and
> typedef uintptr_t CPU_Uint32ptr;
> in the rest, in their score/cpu.h files.
>
Actually, we can do something else by checking if size of pointer less
than size of long, use unsigned long, otherwise use uintptr_t.
> The only obvious alternative I see would be to limit strictly the
> error code and task args to be int or ptr.
>
> Gedare
>
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH] cpukit: add and use CPU_Uint32ptr type
---
cpukit/score/cpu/arm/rtems/score/types.h | 3 +++
cpukit/score/cpu/avr/rtems/score/types.h | 3 +++
cpukit/score/cpu/bfin/rtems/score/types.h| 3 +++
cpukit/score/cpu/h8300/rtems/score/types.h | 3 +++
cpukit/score/cpu/i386/rtems/score/types.h| 3 +++
cpukit/score/cpu/lm32/rtems/score/types.h| 3 +++
cpukit/score/cpu/m32c/rtems/score/types.h| 3 +++
cpukit/score/cpu/m32r/rtems/score/types.h| 3 +++
cpukit/score/cpu/m68k/rtems/score/types.h| 3 +++
cpukit/score/cpu/mips/rtems/score/types.h| 3 +++
cpukit/score/cpu/moxie/rtems/score/types.h | 4
cpukit/score/cpu/nios2/rtems/score/types.h | 3 +++
cpukit/score/cpu/no_cpu/rtems/score/types.h | 3 +++
cpukit/score/cpu/or1k/rtems/score/types.h| 3 +++
cpukit/score/cpu/powerpc/rtems/score/types.h | 4
cpukit/score/cpu/sh/rtems/score/types.h | 3 +++
cpukit/score/cpu/sparc/rtems/score/types.h | 3 +++
cpukit/score/cpu/sparc64/rtems/score/types.h | 3 +++
cpukit/score/cpu/v850/rtems/score/types.h| 3 +++
cpukit/score/include/rtems/score/interr.h| 2 +-
cpukit/score/include/rtems/score/thread.h| 2 +-
21 files changed, 61 insertions(+), 2 deletions(-)
diff --git a/cpukit/score/cpu/arm/rtems/score/types.h
b/cpukit/score/cpu/arm/rtems/score/types.h
index 6910e18..deefd54 100644
--- a/cpukit/score/cpu/arm/rtems/score/types.h
+++ b/cpukit/score/cpu/arm/rtems/score/types.h
@@ -37,6 +37,9 @@ extern "C" {
* This section defines the basic types for this processor.
*/
+/** Type that can store a 32-bit integer or a pointer. */
+typedef uintptr_t CPU_Uint32ptr;
+
typedef uint16_t Priority_bit_map_Word;
/** @} */
diff --git a/cpukit/score/cpu/avr/rtems/score/types.h
b/cpukit/score/cpu/avr/rtems/score/types.h
index 0de6ba2..f63f5d5 100644
--- a/cpukit/score/cpu/avr/rtems/score/types.h
+++ b/cpukit/score/cpu/avr/rtems/score/types.h
@@ -31,6 +31,9 @@ extern "C" {
* This section defines the basic types for this processor.
*/
+/** Type that can store a 32-bit integer or a pointer. */
+typedef unsigned long CPU_Uint32ptr;
+
typedef uint16_t Priority_bit_map_Word;
typedef void avr_isr;
typedef void ( *avr_isr_entry )( void );
diff --git a/cpukit/score/cpu/bfin/rtems/score/types.h
b/cpukit/score/cpu/bfin/rtems/score/types.h
index ff120b9..eaa8de6 100644
--- a/cpukit/score/cpu/bfin/rtems/score/types.h
+++ b/cpukit/score/cpu/bfin/rtems/score/types.h
@@ -31,6 +31,9 @@ extern "C" {
* This section defines the basic types for this processor.
*/
+/** Type that can store a 32-bit integer or a pointer. */
+typedef uintptr_t CPU_Uint32ptr;
+
/** This defines the type for a priority bit map entry. */
typedef uint16_t Priority_bit_map_Word;
diff --git a/cpukit/score/cpu/h8300/rtems/score/types.h
b/cpukit/score/cpu/h8300/rtems/score/types.h
index 7ac2b18..7fcac8b 100644
--- a/cpukit/score/cpu/h8300/rtems/score/types.h
+++ b/cpukit/score/cpu/h8300/rtems/score/types.h
@@ -31,6 +31,9 @@ extern "C" {
* This section defines the basic types for this processor.
*/
+/** Type that can store a 32-bit integer or a pointer. */
+typedef unsigned long CPU_Uint32ptr;
+
typedef uint16_t Priority_bit_map_Word;
typedef void h8300_isr;
typedef void ( *h8300_isr_entry )( void );
diff --git a/cpukit/score/cpu/i386/rtems/score/types.h
b/cpukit/score/cpu/i386/rtems/score/types.h
index 72461fb..40ccecb 100644
--- a/cpukit/score/cpu/i386/rtems/score/types.h
+++ b/cpukit/score/cpu/i386/rtems/score/types.h
@@ -31,6 +31,9 @@ extern "C" {
* This section defines the basic types for this processor.
*/
+/** Type that can store a 32-bit integer or a pointer. */
+typedef uintptr_t CPU_Uint32ptr;
+
typedef uint16_t Priority_bit_map_Word;
typedef void i386_isr;
typedef i386_isr ( *i386_isr_entry )( void );
diff --git a/cpukit/score/cpu/lm32/rtems/score/types.h
b/cpukit/score/cpu/lm32/rtems/score/types.h
index ab9dcbd..c0fc8a8 100644
--- a/cpukit/score/cpu/lm32/rtems/score/types.h
+++ b/cpukit/score/cpu/lm32/rtems/score/types.h
@@ -34,6 +34,9 @@ extern "C" {
* This section defines the basic types for this processor.
*/
+/** Type that can store a 32-bit integer or a pointer. */
+typedef uintptr_t CPU_Uint32ptr;
+
/** This defines the type for a priority bit map entry. */
typedef uint16_t Priority_bit_map_Word;
diff --git a/cpukit/score/cpu/m32c/rtems/score/types.h
b/cpukit/score/cpu/m32c/rtems/score/types.h
index 5c476c6..11e0a0c 100644
--- a/cpukit/score/cpu/m32c/rtems/score/types.h
+++ b/cpukit/score/cpu/m32c/rtems/score/types.h
@@ -31,6 +31,9 @@ extern "C" {
* This section defines the basic types for this processor.
*/
+/** Type that can store a 32-bit integer or a pointer. */
+typedef unsigned long CPU_Uint32ptr;
+
/** This defines the type for a priority bit map entry. */
typedef uint16_t Priority_bit_map_Word;
diff --git a/cpukit/score/cpu/m32r/rtems/score/types.h
b/cpukit/score/cpu/m32r/rtems/score/types.h
index 2439fb5..3ee57f2 100644
--- a/cpukit/sco
Re: [GSoC] "RPi BSP improvement" idea separation
On Mon, Mar 16, 2015 at 4:17 PM, Joel Sherrill wrote: > > > On 3/16/2015 2:57 PM, Yurii Shevtsov wrote: >>> On 3/16/2015 2:37 PM, Gedare Bloom wrote: >>>> On Mon, Mar 16, 2015 at 3:21 PM, Joel Sherrill >>>> wrote: >>>>> I don't know if this has been posted or merged into the WIki. >>>>> Alan, Gedare and I were discussing this earlier today. One thing >>>>> to remember is that it is always possible something we think >>>>> is 1/2 a summer is incredibly easy so bonus tasks should be >>>>> defined for every student. In broad strokes, a possible breakdown >>>>> could be. >>>>> >>>>> + Complete GPIO/I2C/SPI integration and add SD card >>>>> support (since it uses SPI) >>>>> >>>>> + USB and Network stack based on new BSP stack >>> My understanding is that USB will need to be done first since >>> the NIC is on the other side of USB. >>> >>> https://wiki.freebsd.org/FreeBSD/arm/Raspberry%20Pi >>> >>> makes it look like both USB and the NIC could come up easy. >>> And there is the potential to leverage more code. >>>>> + Raspberry Pi 2 optimization and SMP support >>>>> Basic support is merged but the cache is clearly >>>>> not in the right state based on benchmarks and >>>>> the MMU might need initialization based on an >>>>> early report from Alan. For sure, all capabilities >>>>> that work now or begin to work on the Pi1 will >>>>> need to be checked on Pi 2. >>>>> >>>> My intuition is there needs to be extra work added beyond just >>>> fine-tuning the RPI2. >>> +1 I just don't know what that is either. :) >>>>> + User interface stack >>>>> This could include an HDMI/USB console, and perhaps a >>>>> port for the RTEMS graphics library. Obviously, you >>>>> can't use any USB devices for UI unless the USB stack >>>>> works so the USB effort would bring that up while >>>>> doing the graphics work. Then move to USB UI devices. >>>>> >>>> Avoid proposing any work that overlaps (conflict or dependent) on >>>> another. No USB UI devices should be proposed. >>> Yes. The first step of this one could be to get the Graphics Toolkit into >>> the RSB. >>> >>> Then leave USB UI devices as bonus work. >> BTW, what do you mean by USB UI device? Something like external video card? > I am primarily thinking keyboard and mouse. User interface devices. > The video should (hopefully) be usable without incorporating pure > GPL code. FreeBSD and Minix should be references there. > SPI devices may be considered. > -- > 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 > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Warning Update
On Mon, Mar 16, 2015 at 5:06 PM, Joel Sherrill
wrote:
> Hi
>
> Gedare attempted to remove a couple of warnings and I wanted to pass
> along that in two cases, the warnings weren't resolved. These are from
> the sparc-erc32 and main_df.c previously didn't have warnings here.
>
> ../../../../../../rtems/c/src/../../cpukit/libmisc/shell/hexdump-conv.c:
> In function 'rtems_shell_hexdump_conv_c':
> ../../../../../../rtems/c/src/../../cpukit/libmisc/shell/hexdump-conv.c:145:6:
> warning: format '%lc' expects argument of type 'wint_t', but argument 4
> has type 'wchar_t' [-Wformat=]
> (void)printf("%*s%lc", pad, "", wc);
> ^
> ../../../../../../rtems/c/src/../../cpukit/libmisc/shell/hexdump-conv.c:145:6:
> warning: format '%lc' expects argument of type 'wint_t', but argument 4
> has type 'wchar_t' [-Wformat=]
These should be correct I think %lc is right for wchar_t?
> ../../../../../../rtems/c/src/../../cpukit/libmisc/shell/main_df.c: In
> function 'rtems_shell_df_print_entry':
> ../../../../../../rtems/c/src/../../cpukit/libmisc/shell/main_df.c:93:9:
> warning: format '%lu' expects argument of type 'long unsigned int', but
> argument 3 has type 'fsblkcnt_t' [-Wformat=]
> mt_entry->target == NULL ? "none" : mt_entry->target);
> ^
> ../../../../../../rtems/c/src/../../cpukit/libmisc/shell/main_df.c:93:9:
> warning: format '%lu' expects argument of type 'long unsigned int', but
> argument 4 has type 'fsblkcnt_t' [-Wformat=]
Have to look at this to see what the typedef is. if it is uint64_t
we'll need PRIu64 here.
> ../../../../../../rtems/c/src/../../cpukit/libmisc/shell/main_df.c:93:9:
> warning: format '%lu' expects argument of type 'long unsigned int', but
> argument 5 has type 'fsblkcnt_t' [-Wformat=]
> ../../../../../../rtems/c/src/../../cpukit/libmisc/shell/main_df.c:93:9:
> warning: format '%lu' expects argument of type 'long unsigned int', but
> argument 3 has type 'fsblkcnt_t' [-Wformat=]
> ../../../../../../rtems/c/src/../../cpukit/libmisc/shell/main_df.c:93:9:
> warning: format '%lu' expects argument of type 'long unsigned int', but
> argument 4 has type 'fsblkcnt_t' [-Wformat=]
> ../../../../../../rtems/c/src/../../cpukit/libmisc/shell/main_df.c:93:9:
> warning: format '%lu' expects argument of type 'long unsigned int', but
> argument 5 has type 'fsblkcnt_t' [-Wformat=]
>
> --
> 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
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: Rtems Google summer of code participation
Hi Waleed, Welcome! We have a lot of students who are interested in the Raspberry Pi this year. I encourage you to explore if any other project interests you, but if you really want to work with Raspberry Pi, the current info is available at https://devel.rtems.org/wiki/Developer/Projects/Open/ImproveRaspberryPiBSP and will be updated periodically. We're working to scope out a few distinct projects. We might accept competition, but we do prefer to avoid duplication of effort. The next steps are to get RTEMS working on the RPi, and to start working on your proposal. Gedare On Wed, Mar 18, 2015 at 3:13 PM, waleed ziad wrote: > Hello Everyone , > > I am Waleed Ziad CS student at Cairo University i intent to apply this year > in Google summer of code for rtems , i am particularly interested in > raspberry pi BSP improvement i have built rtems and ran the Hello world > example just like the Gsoc page stated you will find attached the proof and > the patch i also built it on raspberry pi device , i wanted to know more > about the details of the project what's mostly needed that is not done yet > and what should I do to get involved more with the project and rtems , > Thanks . > > -- > Waleed Ziad Maamoun > Senior student > Faculty of computers & information - Cairo University > > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Introduction
Welcome, You're not too late. We don't think the SMP support (broadly speaking) is suitable for GSoC projects at this time. There might be some specific aspects, such as SMP support for a particular platform, that you could undertake. Another project that may be suitable and timely could be to work on improving the newly submitted drvmgr code, this is listed as "Merge Leon", and there remains quite a few open problems to solve. There was an email thread on this (subject: [PATCH 000/111] GRLIB/LEON RTEMS RCC patches) Regardless, you should begin by going through our GSoC Getting Started Guide, that will familiarize you with building and running RTEMS in a simulator. Then, if the project you choose will use a particular target BSP, you should build tools for it and be able to demo it. You should get a reference letter from someone with KDE as well to strengthen your application. Feel free to ask questions here, and on IRC you may occasionally get some interactive discussions. Gedare On Wed, Mar 18, 2015 at 4:42 PM, Gowtham Ashok wrote: > Hello, I'm Gowtham, a senior CS undergraduate. I'm a KDE contributor and > have mentored Google Code-in 2014 for them. > I came across RTEMS while studying for my real-time systems midterm and > would like to become a regular contributor. > I thought that doing a GSoC would be a good starting point. Am I too late? > I have seen many interesting potential projects on the ideas page. I would > like to start working on it as soon as possible. > Would improving SMP support in RTEMS be a good contender for a GSoC-level > project? > > Best, > Gowtham > > -- > Gowtham Ashok > Madras Institute of Technology > Ph: +91 9003185651 > > IRC:gwty > > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: RTEMS build problem
You may add the export command to the file .bashrc in your home directory ($HOME/.bashrc), so that it gets set every time you create a new terminal window. On Thu, Mar 19, 2015 at 4:08 AM, Rohini Kulkarni wrote: > OK! I need to add this path to $PATH. > > Got it. Thanks! > > On Thu, Mar 19, 2015 at 1:30 PM, Chris Johns wrote: >> >> On 19/03/2015 6:23 pm, Rohini Kulkarni wrote: >>> >>> To tell exactly what I am doing, this is how I am updating the autoconf >>> everytime with reference from the source builder documentation >>> >>> $ ../source-builder/sb-set-builder --log=l-4.11-at.txt >>> --prefix=$HOME/development/rtems/4.11 4.11/rtems-autotools >>> >>> and then go on to build the toolset >>> $ export PATH=~/development/rtems/4.11/bin:$PATH >>> $ ../source-builder/sb-set-builder --log=l-4.11-sparc.txt >>> --prefix=$HOME/development/rtems/4.11 4.11/rtems-sparc >>> >> >> After a reboot just do: >> >> $ export PATH=~/development/rtems/4.11/bin:$PATH >> >> and the tools will work without needing to be rebuilt. >> >> Chris > > > > > -- > Rohini Kulkarni > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSOC 2015 Monkey HTTP Server
Eduardo, You may like to sign-up as a mentor for RTEMS Project in case the student decides to submit an application to port the Monkey server. Gedare On Thu, Mar 19, 2015 at 8:58 AM, Eduardo Silva wrote: > Hi Joel, > > sorry for the late reply, really busy days :) > > As you may know we were not selected this time. So how can we help on this > project ? > > best > > > On Wed, Mar 11, 2015 at 3:12 PM, Joel Sherrill > wrote: >> >> cc'ing Eduardo Silva from the Monkey project. Eduardo, >> you may have to subscribe to get messages back to the >> RTEMS list. >> >> On 3/11/2015 3:45 PM, Sujay Raj wrote: >> > Hi, >> > I am interested in working on porting the Monkey HTTP Server to RTEMS >> > as a GSOC project. >> > >> > This is the first time I am applying to GSOC and though I have written >> > a lot of code, it is also my first attempt at working in an Open >> > Source project. >> > >> > Some personal projects that I have worked on include developing a >> > hobby operating system ( following Bran's Kernel Development Tutorial >> > and osdev ), writing ray tracers, as well as porting the nweb web >> > server ( 200 lines of C code ) to python ( it was undertaken as an >> > exercise to learn more about the functioning and implementation of >> > webservers ). Further I have familiarity with x86 assembly (nasm), not >> > extraordinary, but fluent. >> > >> > I have successfully compiled and executed sample programs for >> > sparc-sis but from what I have read sparc-sis doesn't support TCP/IP. >> > So I followed the wiki and compiled it for pc386 on QEMU too as it had >> > networking support. >> You either want to use pc386 on qemu or arm/zynq on qemu. >> > I was wondering if this may be the required architecture and simulator >> > for this project. >> > >> > Further, I would like to mention, that though this may be an approach >> > with GSOC in mind, but I wish to end up as a full time contributor for >> > the RTEMS project in time to come as it suits my taste and past >> > experience. >> > >> > Kindly point out things I need to do to proceed and other comments. >> Eduardo mentioned that this may not be enough to occupy your entire >> summer. So we would need to identify other work to bundle with this. >> >> Monkey for RTEMS should get built as a package inside the RSB. This >> is like the BSD ports where it always builds from source. Fetch upstream, >> patch as needed and build for the embedded architecture. >> >> Random idea which would need other mentors to buy into. We have an >> old IPV4 stack in the current tree. We have a newer IPV4/V6 IP stack >> outside the tree. And there is a working LWIP port. My concept long >> term has been to divide things into packages: >> >> + RTEMS (ok done) >> + network stack of choice - done for new IPV4/IPV6 stack. current >>stack is in tree, would need to be pulled out into its own build >>module, LWIP is a candidate for RSB packaging but could get done >> by another student as part of BeagleBone work. >> + network tests - some in the tree, some in network-demos >> + network servers - ftpd, web servers, telnetd, pppd, etc should be >>packages that can be built against your network stack of choice >> >> This idea hasn't been reviewed by anyone so would need feedback >> but conceptually, it makes network services an add-on to the RTEMS >> core and makes it easier for users to pick a stack. More modular >> pieces. >> >> The first step though is getting Monkey ported as a package. The >> other steps would need discussing. >> > Regards >> > ___ >> > devel mailing list >> > devel@rtems.org >> > http://lists.rtems.org/mailman/listinfo/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 >> >> > > > > -- > Eduardo Silva > Monkey Software > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: imfs.h: warning cast from pointer to integer of different size
On Thu, Mar 19, 2015 at 10:49 AM, Joel Sherrill
wrote:
> Hi
>
> On one platform, we get a warning for this piece of code in imfs.h
>
> static inline ino_t IMFS_node_to_ino( const IMFS_jnode_t *node )
> {
> return (ino_t) node;
> }
>
> On this target, "typedef unsigned long ino_t;" and
> sizeof(void *) < sizeof(unsigned long) so the cast is safe.
>
> Would we be better off with ino_t being uintptr_t since we
> do cast it back and forth?
>
> Any other suggestions?
>
The safest fix is to use the new CPU_Uint32ptr type. This resolves to
uintptr_t on most 32-bit+ archs.
> --
> 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
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] score: Delete unused _Timestamp_Is_valid()
ok
On Thu, Mar 19, 2015 at 8:52 AM, Alexander Krutwig
wrote:
> ---
> cpukit/score/include/rtems/score/timestamp.h | 18 --
> cpukit/score/include/rtems/score/timestamp64.h | 13 -
> 2 files changed, 31 deletions(-)
>
> diff --git a/cpukit/score/include/rtems/score/timestamp.h
> b/cpukit/score/include/rtems/score/timestamp.h
> index 895afcc..5c23979 100644
> --- a/cpukit/score/include/rtems/score/timestamp.h
> +++ b/cpukit/score/include/rtems/score/timestamp.h
> @@ -109,24 +109,6 @@ extern "C" {
> #endif
>
> /**
> - * @brief Determines the validity of a timestamp.
> - *
> - * This method determines the validity of a timestamp.
> - *
> - * @param[in] _time points to the timestamp instance to validate.
> - *
> - * @retval This method returns true if @a time is valid and
> - * false otherwise.
> - */
> -#if CPU_TIMESTAMP_USE_STRUCT_TIMESPEC == TRUE
> - #define _Timestamp_Is_valid( _time ) \
> - _Timespec_Is_valid( _time )
> -#else
> - #define _Timestamp_Is_valid( _time ) \
> - _Timestamp64_Is_valid( _time )
> -#endif
> -
> -/**
> * @brief Less than operator for timestamps.
> *
> * This method is the less than operator for timestamps.
> diff --git a/cpukit/score/include/rtems/score/timestamp64.h
> b/cpukit/score/include/rtems/score/timestamp64.h
> index 55b7d07..3d40ca2 100644
> --- a/cpukit/score/include/rtems/score/timestamp64.h
> +++ b/cpukit/score/include/rtems/score/timestamp64.h
> @@ -106,19 +106,6 @@ static inline void
> _Timestamp64_implementation_Set_to_zero(
>);
> #endif
>
> -/**
> - * @brief Determines the validity of a 64-bit timestamp.
> - *
> - * This method determines the validity of a timestamp.
> - *
> - * @param[in] _time points to the timestamp instance to validate.
> - *
> - * @retval This method returns true if @a time is valid and
> - * false otherwise.
> - */
> -#define _Timestamp64_Is_valid( _time ) \
> - (1)
> -
> static inline bool _Timestamp64_implementation_Less_than(
>const Timestamp64_Control *_lhs,
>const Timestamp64_Control *_rhs
> --
> 1.8.4.5
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: imfs.h: warning cast from pointer to integer of different size
On Thu, Mar 19, 2015 at 11:30 AM, Sebastian Huber
wrote:
>
> - Joel Sherrill schrieb:
>>
>>
>> On March 19, 2015 9:52:56 AM CDT, Gedare Bloom wrote:
>> >On Thu, Mar 19, 2015 at 10:49 AM, Joel Sherrill
>> > wrote:
>> >> Hi
>> >>
>> >> On one platform, we get a warning for this piece of code in imfs.h
>> >>
>> >> static inline ino_t IMFS_node_to_ino( const IMFS_jnode_t *node )
>> >> {
>> >> return (ino_t) node;
>> >> }
>> >>
>> >> On this target, "typedef unsigned long ino_t;" and
>> >> sizeof(void *) < sizeof(unsigned long) so the cast is safe.
>> >>
>> >> Would we be better off with ino_t being uintptr_t since we
>> >> do cast it back and forth?
>> >>
>> >> Any other suggestions?
>> >>
>> >The safest fix is to use the new CPU_Uint32ptr type. This resolves to
>> >uintptr_t on most 32-bit+ archs.
>>
>> The type ino_t is defined in newlib so this doesn't work.
>
> The only requirement on the ino number is that it uniquely indentifies a node
> in a file system. We only have a problem if sizeof(IMFS_jnode_t *) >
> sizeof(long).
Then it should be safe to use uintptr_t instead: sizeof(IMFS_jnode_t
*) == sizeof(uintptr_t). For the 16/24-bit address spaces, this means
there should be less than 1<<16 or 1<<24 nodes, it seems reasonable.
For 32-bit archs we have no difference.
Gedare
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: imfs.h: warning cast from pointer to integer of different size
On Thu, Mar 19, 2015 at 12:00 PM, Ric Claus wrote:
>
> On Mar 19, 2015, at 4:30 PM, Sebastian Huber
> wrote:
>
>>
>> - Joel Sherrill schrieb:
>>>
>>>
>>> On March 19, 2015 9:52:56 AM CDT, Gedare Bloom wrote:
>>>> On Thu, Mar 19, 2015 at 10:49 AM, Joel Sherrill
>>>> wrote:
>>>>> Hi
>>>>>
>>>>> On one platform, we get a warning for this piece of code in imfs.h
>>>>>
>>>>> static inline ino_t IMFS_node_to_ino( const IMFS_jnode_t *node )
>>>>> {
>>>>> return (ino_t) node;
>>>>> }
>>>>>
>>>>> On this target, "typedef unsigned long ino_t;" and
>>>>> sizeof(void *) < sizeof(unsigned long) so the cast is safe.
>>>>>
>>>>> Would we be better off with ino_t being uintptr_t since we
>>>>> do cast it back and forth?
>>>>>
>>>>> Any other suggestions?
>>>>>
>>>> The safest fix is to use the new CPU_Uint32ptr type. This resolves to
>>>> uintptr_t on most 32-bit+ archs.
>>>
>>> The type ino_t is defined in newlib so this doesn't work.
>>
>> The only requirement on the ino number is that it uniquely indentifies a
>> node in a file system. We only have a problem if sizeof(IMFS_jnode_t *) >
>> sizeof(long).
>
Using the intermediate cast to uintptr_t is fine. We should keep ino_t
defined as a long.
> I’m curious what you all think about doing:
>
> return (const char*)node - (const char*)0;
>
This still results in a pointer-type, the return value will be cast to
ino_t implicitly and give a similar warning.
> Ric
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: imfs.h: warning cast from pointer to integer of different size
On Thu, Mar 19, 2015 at 1:10 PM, Ric Claus wrote:
>
> On Mar 19, 2015, at 5:06 PM, Gedare Bloom wrote:
>
>> On Thu, Mar 19, 2015 at 12:00 PM, Ric Claus wrote:
>>>
>>> On Mar 19, 2015, at 4:30 PM, Sebastian Huber
>>> wrote:
>>>
>>>>
>>>> - Joel Sherrill schrieb:
>>>>>
>>>>>
>>>>> On March 19, 2015 9:52:56 AM CDT, Gedare Bloom wrote:
>>>>>> On Thu, Mar 19, 2015 at 10:49 AM, Joel Sherrill
>>>>>> wrote:
>>>>>>> Hi
>>>>>>>
>>>>>>> On one platform, we get a warning for this piece of code in imfs.h
>>>>>>>
>>>>>>> static inline ino_t IMFS_node_to_ino( const IMFS_jnode_t *node )
>>>>>>> {
>>>>>>> return (ino_t) node;
>>>>>>> }
>>>>>>>
>>>>>>> On this target, "typedef unsigned long ino_t;" and
>>>>>>> sizeof(void *) < sizeof(unsigned long) so the cast is safe.
>>>>>>>
>>>>>>> Would we be better off with ino_t being uintptr_t since we
>>>>>>> do cast it back and forth?
>>>>>>>
>>>>>>> Any other suggestions?
>>>>>>>
>>>>>> The safest fix is to use the new CPU_Uint32ptr type. This resolves to
>>>>>> uintptr_t on most 32-bit+ archs.
>>>>>
>>>>> The type ino_t is defined in newlib so this doesn't work.
>>>>
>>>> The only requirement on the ino number is that it uniquely indentifies a
>>>> node in a file system. We only have a problem if sizeof(IMFS_jnode_t *) >
>>>> sizeof(long).
>>>
>> Using the intermediate cast to uintptr_t is fine. We should keep ino_t
>> defined as a long.
>>
>>> I’m curious what you all think about doing:
>>>
>>> return (const char*)node - (const char*)0;
>>>
>> This still results in a pointer-type, the return value will be cast to
>> ino_t implicitly and give a similar warning.
>
> No, I don’t think so. The difference of two pointers is the number of
> elements (chars in this case) between them.
I see. We'd have to see what the rules are for the implicit type then.
A quick test on my native (x86_64) host says it is a long int.
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] score: Delete unused _Timestamp_Divide_by_integer
ok to both
On Fri, Mar 20, 2015 at 4:08 AM, Alexander Krutwig
wrote:
> ---
> cpukit/score/Makefile.am | 2 +-
> cpukit/score/include/rtems/score/timestamp.h | 21 -
> cpukit/score/include/rtems/score/timestamp64.h | 31 -
> cpukit/score/src/ts64dividebyinteger.c | 32
> --
> 4 files changed, 1 insertion(+), 85 deletions(-)
> delete mode 100644 cpukit/score/src/ts64dividebyinteger.c
>
> diff --git a/cpukit/score/Makefile.am b/cpukit/score/Makefile.am
> index 509a243..e7d0181 100644
> --- a/cpukit/score/Makefile.am
> +++ b/cpukit/score/Makefile.am
> @@ -310,7 +310,7 @@ libscore_a_SOURCES += src/timespecaddto.c
> src/timespecfromticks.c \
> src/timespecdividebyinteger.c src/timespecgetasnanoseconds.c
>
> ## TIMESTAMP_INT64_C_FILES
> -libscore_a_SOURCES += src/ts64addto.c src/ts64dividebyinteger.c \
> +libscore_a_SOURCES += src/ts64addto.c \
> src/ts64divide.c src/ts64equalto.c \
> src/ts64getnanoseconds.c src/ts64getseconds.c \
> src/ts64lessthan.c \
> diff --git a/cpukit/score/include/rtems/score/timestamp.h
> b/cpukit/score/include/rtems/score/timestamp.h
> index 5c23979..d03dbc0 100644
> --- a/cpukit/score/include/rtems/score/timestamp.h
> +++ b/cpukit/score/include/rtems/score/timestamp.h
> @@ -236,27 +236,6 @@ extern "C" {
> #endif
>
> /**
> - * @brief Divides a timestamp by an integer value.
> - *
> - * This routine divides a timestamp by an integer value. The expected
> - * use is to assist in benchmark calculations where you typically
> - * divide a duration by a number of iterations.
> - *
> - * @param[in] _time points to the total
> - * @param[in] _iterations is the number of iterations
> - * @param[in] _result points to the average time.
> - *
> - * @retval This method fills in @a result.
> - */
> -#if CPU_TIMESTAMP_USE_STRUCT_TIMESPEC == TRUE
> - #define _Timestamp_Divide_by_integer( _time, _iterations, _result ) \
> - _Timespec_Divide_by_integer(_time, _iterations, _result )
> -#else
> - #define _Timestamp_Divide_by_integer( _time, _iterations, _result ) \
> - _Timestamp64_Divide_by_integer( _time, _iterations, _result )
> -#endif
> -
> -/**
> * @brief Divides a timestamp by another timestamp.
> *
> * This routine divides a timestamp by another timestamp. The
> diff --git a/cpukit/score/include/rtems/score/timestamp64.h
> b/cpukit/score/include/rtems/score/timestamp64.h
> index 3d40ca2..29e4297 100644
> --- a/cpukit/score/include/rtems/score/timestamp64.h
> +++ b/cpukit/score/include/rtems/score/timestamp64.h
> @@ -255,37 +255,6 @@ static inline void _Timestamp64_implementation_Subtract(
>);
> #endif
>
> -static inline void _Timestamp64_implementation_Divide_by_integer(
> - const Timestamp64_Control *_time,
> - uint32_t _iterations,
> - Timestamp64_Control *_result
> -)
> -{
> - *_result = *_time / _iterations;
> -}
> -
> -/**
> - * @brief Divide 64-bit timestamp by an integer.
> - *
> - * This routine divides a timestamp by an integer value. The expected
> - * use is to assist in benchmark calculations where you typically
> - * divide a duration by a number of iterations.
> - *
> - * @param[in] _time points to the total
> - * @param[in] _iterations is the number of iterations
> - * @param[out] _result points to the average time.
> - */
> -#if CPU_TIMESTAMP_USE_INT64_INLINE == TRUE
> - #define _Timestamp64_Divide_by_integer( _time, _iterations, _result ) \
> -_Timestamp64_implementation_Divide_by_integer( _time, _iterations,
> _result )
> -#else
> - void _Timestamp64_Divide_by_integer(
> -const Timestamp64_Control *_time,
> -uint32_t _iterations,
> -Timestamp64_Control *_result
> - );
> -#endif
> -
> /**
> * @brief Divide 64-bit timestamp by another 64-bit timestamp.
> *
> diff --git a/cpukit/score/src/ts64dividebyinteger.c
> b/cpukit/score/src/ts64dividebyinteger.c
> deleted file mode 100644
> index b48c928..000
> --- a/cpukit/score/src/ts64dividebyinteger.c
> +++ /dev/null
> @@ -1,32 +0,0 @@
> -/**
> - * @file
> - *
> - * @brief Divide Timestamp By Integer
> - * @ingroup SuperCore
> - */
> -
> -/*
> - * COPYRIGHT (c) 1989-2008.
> - * On-Line Applications Research Corporation (OAR).
> - *
> - * The license and distribution terms for this file may be
> - * found in the file LICENSE in this distribution or at
> - * http://www.rtems.org/license/LICENSE.
> - */
> -
> -#if HAVE_CONFIG_H
> -#include "config.h"
> -#endif
> -
> -#include
> -
> -#if CPU_TIMESTAMP_USE_INT64 == TRUE
> -void _Timestamp64_Divide_by_integer(
> - const Timestamp64_Control *_time,
> - uint32_t _iterations,
> - Timestamp64_Control *_result
> -)
> -{
> - _Timestamp64_implementation_Divide_by_integer( _time, _iterations, _result
> );
> -}
> -#endif
> --
> 1.8.4.5
>
> ___
> devel mailing list
> devel@rtems.
Re: [PING][PATCH] LPC176x: Add CAN, PWM, ADC and UART1/2/3 support to the BSP.
Please fix the URLs to be rtems.org (especially the license) -Gedare On Fri, Mar 20, 2015 at 4:18 AM, Sebastian Huber wrote: > Hello Martin, > > On 19/03/15 01:11, Martin Galvan wrote: >> >> This patch adds support for the following devices to the LPC176x BSP: >> >> * CAN >> * PWM >> * ADC > > > what is LPC176X specific in these drivers? See also > > https://lists.rtems.org/pipermail/devel/2014-June/007110.html > > Independent of this, I checked in the patch, since its not your fault that > the RTEMS project has no clear BSP developers guide. In the long run I think > that this driver diversity will lead to an unmaintainable state. > > -- > 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. > > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] Replace www.rtems.com with www.rtems.org
Push it. It touches a lot of files but pretty self-contained in each, shouldn't cause conflicts. On Fri, Mar 20, 2015 at 9:09 AM, Sebastian Huber wrote: > --- > c/src/lib/libbsp/arm/beagle/clock.c| 2 +- > c/src/lib/libbsp/arm/beagle/console/console-config.c | 2 +- > c/src/lib/libbsp/arm/beagle/include/bsp.h | 2 +- > c/src/lib/libbsp/arm/beagle/include/i2c.h | 2 +- > c/src/lib/libbsp/arm/beagle/irq.c | 2 +- > c/src/lib/libbsp/arm/beagle/misc/i2c.c | 2 +- > c/src/lib/libbsp/arm/lpc176x/adc/adc.c | 2 +- > c/src/lib/libbsp/arm/lpc176x/benchmark_timer/benchmark_timer.c | 2 +- > c/src/lib/libbsp/arm/lpc176x/can/can.c | 2 +- > c/src/lib/libbsp/arm/lpc176x/console/console-config.c | 2 +- > c/src/lib/libbsp/arm/lpc176x/gpio/gpio.c | 2 +- > c/src/lib/libbsp/arm/lpc176x/include/adc-defs.h| 2 +- > c/src/lib/libbsp/arm/lpc176x/include/adc.h | 2 +- > c/src/lib/libbsp/arm/lpc176x/include/bsp.h | 2 +- > c/src/lib/libbsp/arm/lpc176x/include/can-defs.h| 2 +- > c/src/lib/libbsp/arm/lpc176x/include/can.h | 2 +- > c/src/lib/libbsp/arm/lpc176x/include/common-types.h| 2 +- > c/src/lib/libbsp/arm/lpc176x/include/dma.h | 2 +- > c/src/lib/libbsp/arm/lpc176x/include/gpio-defs.h | 2 +- > c/src/lib/libbsp/arm/lpc176x/include/gpio.h| 2 +- > c/src/lib/libbsp/arm/lpc176x/include/io-defs.h | 2 +- > c/src/lib/libbsp/arm/lpc176x/include/io.h | 2 +- > c/src/lib/libbsp/arm/lpc176x/include/irq.h | 2 +- > c/src/lib/libbsp/arm/lpc176x/include/lpc-clock-config.h| 2 +- > c/src/lib/libbsp/arm/lpc176x/include/lpc176x.h | 2 +- > c/src/lib/libbsp/arm/lpc176x/include/mbed-pinmap.h | 2 +- > c/src/lib/libbsp/arm/lpc176x/include/pwmout-defs.h | 2 +- > c/src/lib/libbsp/arm/lpc176x/include/pwmout.h | 2 +- > c/src/lib/libbsp/arm/lpc176x/include/system-clocks.h | 2 +- > c/src/lib/libbsp/arm/lpc176x/include/timer-defs.h | 2 +- > c/src/lib/libbsp/arm/lpc176x/include/timer.h | 2 +- > c/src/lib/libbsp/arm/lpc176x/include/watchdog-defs.h | 2 +- > c/src/lib/libbsp/arm/lpc176x/include/watchdog.h| 2 +- > c/src/lib/libbsp/arm/lpc176x/irq/irq.c | 2 +- > c/src/lib/libbsp/arm/lpc176x/misc/bspidle.c| 2 +- > c/src/lib/libbsp/arm/lpc176x/misc/dma-copy.c | 2 +- > c/src/lib/libbsp/arm/lpc176x/misc/dma.c| 2 +- > c/src/lib/libbsp/arm/lpc176x/misc/io.c | 2 +- > c/src/lib/libbsp/arm/lpc176x/misc/restart.c| 2 +- > c/src/lib/libbsp/arm/lpc176x/misc/system-clocks.c | 2 +- > c/src/lib/libbsp/arm/lpc176x/pwmout/pwmout.c | 2 +- > c/src/lib/libbsp/arm/lpc176x/rtc/rtc-config.c | 2 +- > c/src/lib/libbsp/arm/lpc176x/startup/bspreset.c| 2 +- > c/src/lib/libbsp/arm/lpc176x/startup/bspstart.c| 2 +- > c/src/lib/libbsp/arm/lpc176x/startup/bspstarthooks.c | 2 +- > c/src/lib/libbsp/arm/lpc176x/timer/timer.c | 2 +- > c/src/lib/libbsp/arm/lpc176x/watchdog/watchdog.c | 2 +- > c/src/lib/libbsp/arm/stm32f4/include/stm32f4_adc.h | 2 +- > c/src/lib/libbsp/arm/stm32f4/include/stm32f4_exti.h| 2 +- > c/src/lib/libbsp/arm/stm32f4/include/stm32f4_flash.h | 2 +- > c/src/lib/libbsp/arm/stm32f4/include/stm32f4_otgfs.h | 2 +- > c/src/lib/libbsp/arm/stm32f4/include/stm32f4_pwr.h | 2 +- > c/src/lib/libbsp/arm/stm32f4/include/stm32f4_syscfg.h | 2 +- > c/src/lib/libbsp/arm/stm32f4/include/stm32f4_tim.h | 2 +- > c/src/lib/libcpu/arm/shared/include/am335x.h | 2 +- > c/src/lib/libcpu/arm/shared/include/omap3.h| 2 +- > cpukit/libdl/dlfcn-shell.c | 2 +- > cpukit/libdl/dlfcn-shell.h | 2 +- > cpukit/libdl/dlfcn.c | 2 +- > cpukit/libdl/rap-shell.c | 2 +- > cpukit/libdl/rap-shell.h | 2 +- > cpukit/libdl/rap.c | 2 +- > cpukit/libdl/rap.h | 2 +- > cpukit/libdl/rtl-chain-iterator.c | 2 +- > cpukit/libdl/rtl-chain-iterator.h | 2 +- > cpukit/libdl/rtl-debugger.c| 2 +- > cpukit/libdl/rtl-
Re: [PING][PATCH] LPC176x: Add CAN, PWM, ADC and UART1/2/3 support to the BSP.
On Fri, Mar 20, 2015 at 9:08 AM, Sebastian Huber wrote: > Maybe it makes sense to add a git commit hook, that rejects such patches. We > already have this issue in other places as well: Perhaps if we get Phabricator up, it can be configured to reject patches containing rtems.com easily? ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PING][PATCH] LPC176x: Add CAN, PWM, ADC and UART1/2/3 support to the BSP.
On Fri, Mar 20, 2015 at 10:47 AM, Joel Sherrill wrote: > On an odd note, did we finally kill that misformatted > license text? > Not sure what you mean. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSOC 2015 Monkey HTTP Server
On Fri, Mar 20, 2015 at 11:39 AM, Sujay Raj wrote: > Well I started writing the first draft of the project proposal ( which > I shall hopefully finish by tonight, Its 9 PM here ). > > I am making "porting the Monkey web server to RTEMS as well as a > partial reorganization of the network stacks present in RTEMS to make > it more modular", as the primary deliverable of this project. > > From what it appears, porting Monkey can be done in about a month + a > week for any delays. The development environment is already set up and > I am tweaking around with the code. So, by the mid-term evaluation I > expect to get monkey working on RTEMS (without enough time for > debugging). > What RTEMS target/BSP do you intend to use? > For the second part, that is, getting the network stack of choice > built from RSB for the applications to be built against, I am a bit > apprehensive about the time limit. This task, at the first glance > doesn't appear that difficult, but it might be. So the second half ( > till the final evaluation ) will involve getting the network stacks in > a separate build + a separate package for network tests + debugging. > I think there is a lot of complexity here. > I think debugging and testing will be a major part of the project. > Always. > I was thinking along the lines, that the second part of the project > should be done first, but as Joel pointed out, the first step should > be monkey getting ported as a package. > I agree with Joel. The second part is harder to scope. It will be much better for you to have a solid task and deliverable (port Monkey) for the first-half. > kindly point out any comments/suggestions. > Be sure you identify when and where you plan to submit code. We like to see code pushed into RTEMS, and into upstream projects if needed, throughout the summer, not just at the end. > > > On Fri, Mar 20, 2015 at 6:27 AM, Chris Johns wrote: >> On 20/03/2015 2:57 am, Eduardo Silva wrote: >>> >>> if there are some application for that project and some accepted >>> student, I would be glad to sign as a mentor to cover Monkey specifics. >>> Note: we will need a second mentor to cover RTEMS specifics, >> >> >> I can help, after all you and I have talked about the work to be done >> before. >> >> Chris >> >> ___ >> devel mailing list >> devel@rtems.org >> http://lists.rtems.org/mailman/listinfo/devel > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC Raspberry pi 2 project
Hi, Weekends tend to be slow around here. On Mon, Mar 23, 2015 at 10:30 AM, Rohini Kulkarni wrote: > Hi, > > I want to know what is the current work going on for Raspberry pi 2 support? > The BSP can be run, but there are performance problems with it, indicating the cache configuration is wrong. > The projects looks towards implementing arm architecture support, cache > configuration and enabling SMP support. These are all parts of the Raspberry > pi 2 BSP right? What work has already been done for the support. > So far the RPi2 only works on a single core. Getting it to work well on all 4-cores is the goal. Then you can consider stretch goals that could be optional, for example if there are peripherals available on rpi2 that aren't on rpi, or to do something else with SMP-support. > Thanks! > > On 21 Mar 2015 10:40, "Rohini Kulkarni" wrote: > > Hello, > > I had a look at updated the project groups for raspberry pi improvements for > my proposal. Because I had not tracked the page for a few days I was not > aware that the Raspberry pi 2 support tasks had been defined. > As I had also asked about SMP support earlier, this projects interests me > more. > Yes, I am new to bringing up an architecture support. Is the project > considered suitable for somebody new to rtems. This is a suitable project. > I want to prepare a draft proposal soon so that it can be reviewed in time. > How can I get an idea about the time requirements in order to do my > proposal? Some references to start with would be useful to know the current > status. Also level of familiarity required and other requirements for > implementation. > Estimating time is hard. I'd recommend working out what needs to be done first, and we can try to help you decide if you proposed too much or too little. It would be good for you to study some of the other SMP targets, especially the ARM ones, and to see what SMP-support is required at the BSP level. I think some of this info is available in the documentation, but you might have to hunt for the info because SMP is still quite new in RTEMS. > Thanks! > > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSOC 2015 Monkey HTTP Server
On Sun, Mar 22, 2015 at 6:56 PM, Sujay Raj wrote: > I submitted the tentative proposal on the proposal page > devel.rtems.org/wiki/GSoC/2015 . > Please also submit your proposal to the official GSOC Melange system. You can revise it until the deadline, and it is better to get it in early to avoid any technical difficulties. > I have a few points to mention. > 1. About the BSP to work upon, I have not mentioned anything > specifically in the proposal because that is to be discussed. I do not > have enough working experience with ARM/zynq architecture. ( I worked > with ARM last trying to make homebrew games for the Nintendo GBA where > the emulator was Visual Boy Advance :) ) I have always worked with > x86 architectures. But yes, I can easily switch over to it, in little > time if I am pointed towards some resources about emulating it with > QEMU, and any other specifics about zynq. > The BSP / arch shouldn't matter too much, although Monkey is probably more-used on x86 platforms. Really, it would be best for you to use both platforms so you can shake out any bugs that are arch-dependent. > 2. The sample proposal talked about setting up repository on > code.google.com, which is not accepting any new project and will close > within an year. > Use github. We need to update the sample. > 3. About the second part of my project, About separate RSB packaging > of network stacks, > i. should I include lwIP too? Yes. > ii. Is anyone else working on it? Should that affect my including > lwIP in my proposal? Possibly, but don't let it affect your proposal. The most recent port of lwIP appears to be for the beagleboard. We might have a student work on integrating it, possibly even into RSB. But you should still anticipate that you might get to do it yourself. > iii. Does the project look too ambitious to be completed in the timeframe? Hard to say. Sometimes things that look hard turn out easy, and vice versa. > iv. Will the inclusion of lwIP in the things to be done make the > project too big? No. I think it is a good set. You always want to have "stretch goals". > Regards, > Sujay Raj > > > > On Fri, Mar 20, 2015 at 9:45 PM, Joel Sherrill > wrote: >> >> >> On 3/20/2015 11:03 AM, Sujay Raj wrote: >>> BSP: pc386 simulated on QEMU >>> >>> On Fri, Mar 20, 2015 at 9:27 PM, Gedare Bloom wrote: >>>> On Fri, Mar 20, 2015 at 11:39 AM, Sujay Raj wrote: >>>>> Well I started writing the first draft of the project proposal ( which >>>>> I shall hopefully finish by tonight, Its 9 PM here ). >>>>> >>>>> I am making "porting the Monkey web server to RTEMS as well as a >>>>> partial reorganization of the network stacks present in RTEMS to make >>>>> it more modular", as the primary deliverable of this project. >>>>> >>>>> From what it appears, porting Monkey can be done in about a month + a >>>>> week for any delays. The development environment is already set up and >>>>> I am tweaking around with the code. So, by the mid-term evaluation I >>>>> expect to get monkey working on RTEMS (without enough time for >>>>> debugging). >>>>> >>>> What RTEMS target/BSP do you intend to use? >>>> >> The most likely candidates IMO are arm/zynq or i386/pc386 on qemu. >> Both include network simulators. The ARM might be more better since >> there are active core developers on Zynq. And I don't know how much >> action Monkey has seen on non-x86 architectures. >>>>> For the second part, that is, getting the network stack of choice >>>>> built from RSB for the applications to be built against, I am a bit >>>>> apprehensive about the time limit. This task, at the first glance >>>>> doesn't appear that difficult, but it might be. So the second half ( >>>>> till the final evaluation ) will involve getting the network stacks in >>>>> a separate build + a separate package for network tests + debugging. >>>>> >>>> I think there is a lot of complexity here. >> There is. First goal should be Monkey against the new stack. I >> **think** that's >> the only stack that Zynq has a driver for. Build order is: >> >> + rtems w/o networking >> + new stack >> + Monkey >> >> Once it is working, then upstream patches and make an RSB package. With >> documentation as needed. >> >> That is a good goal. >> >>>>> I think debugging and testing will be a major part of the project. >>>>&
Re: Trace status update.
Very nice! thanks for the update! On Mon, Mar 23, 2015 at 2:36 AM, Chris Johns wrote: > Hi, > > I have added some pages to the developer's wiki: > > https://devel.rtems.org/wiki/Developer/Tracing > > and I am slowly adding more detail. I intend to update the Trace Linker with > more detail on the configuration files. > > I have just updated the trace linker to support: > > 1. Option sections. > 2. Names, > 3. Enables, and > 4. Triggers > > The option sections allow you to put custom options into configuration > files. For example: > > [my-options] > dump-on-error = true > ; > ; Tools, linker for linking C++ > ; > prefix = /opt/work/rtems/4.11 > ld = arm-rtems4.11-g++ > rtems-bsp = arm/xilinx_zynq_zc706 > rtems-path = /opt/work/my/rtems/4.11 > cflags = -I/my/private/path > ; > ; Generator options. > ; > gen-enables = enable > gen-triggers = enable > > Names is adding the names of all trace functions to a 'const char*' array > indexed by the function index. > > Enables is a bitmap array of uint32_t where each bit is indexed by the trace > function index. The bit set means tracing is enabled for this function. > > Triggers is a bitmap array of uint32_t where each bit is indexed by the > trace function index. The bit set means trigger tracing. I have only defined > a single bit at this point in time. We should actually have more so we can > define entry and exit or both trigger states. > > These changes allow a standard alone buffered trace support as well as move > us a bit closer to integrating to the capture engine. > > Chris > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 12/42] libcrypt/crypt-md5.c: Fix overflow issues
I guess this is a problem for 16-bit targets? changing the constants to 16UL and 8UL also should work. A comment should be made that this is only for 16-bit targets. If we rid RTEMS of those, we can get rid of some of these shenanigans... On Mon, Mar 23, 2015 at 10:39 AM, Joel Sherrill wrote: > --- > cpukit/libcrypt/crypt-md5.c | 12 > 1 file changed, 12 insertions(+) > > diff --git a/cpukit/libcrypt/crypt-md5.c b/cpukit/libcrypt/crypt-md5.c > index c60dcf8..78ae0bc 100644 > --- a/cpukit/libcrypt/crypt-md5.c > +++ b/cpukit/libcrypt/crypt-md5.c > @@ -133,6 +133,17 @@ crypt_md5_r(const char *pw, const char *salt, struct > crypt_data *data) > > p = passwd + strlen(passwd); > > +#if defined(__rtems__) > + l = ((long int) final[ 0]<<16) | ((long int) final[ 6]<<8) | > final[12]; > + _crypt_to64(p, l, 4); p += 4; > + l = ((long int) final[ 1]<<16) | ((long int) final[ 7]<<8) | > final[13]; > + _crypt_to64(p, l, 4); p += 4; > + l = ((long int) final[ 2]<<16) | ((long int) final[ 8]<<8) | > final[14]; > + _crypt_to64(p, l, 4); p += 4; > + l = ((long int) final[ 3]<<16) | ((long int) final[ 9]<<8) | > final[15]; > + _crypt_to64(p, l, 4); p += 4; > + l = ((long int) final[ 4]<<16) | ((long int) final[10]<<8) | final[ > 5]; > +#else > l = (final[ 0]<<16) | (final[ 6]<<8) | final[12]; > _crypt_to64(p, l, 4); p += 4; > l = (final[ 1]<<16) | (final[ 7]<<8) | final[13]; > @@ -142,6 +153,7 @@ crypt_md5_r(const char *pw, const char *salt, struct > crypt_data *data) > l = (final[ 3]<<16) | (final[ 9]<<8) | final[15]; > _crypt_to64(p, l, 4); p += 4; > l = (final[ 4]<<16) | (final[10]<<8) | final[ 5]; > +#endif > _crypt_to64(p, l, 4); p += 4; > l = final[11]; > _crypt_to64(p, l, 2); p += 2; > -- > 1.9.3 > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Compiling POSIX based (hypercall + Rump Kernel) to run above RTEMS/POSIX issue
On Mon, Mar 23, 2015 at 12:41 PM, Joel Sherrill wrote: > > > On March 23, 2015 10:31:10 AM CDT, Antti Kantee wrote: >>On 23/03/15 14:30, Hesham ALMatary wrote: >>> Hi all, >>> >>> Thanks Antti for your reply. I'm reviving this thread as Dr.Joel >>suggested. >>> >>> On Thu, Feb 26, 2015 at 1:11 AM, Antti Kantee wrote: Hesham, [sorry for the slight delay, there were some mailing list snafus on >>this end] >> >>[nd due the those problems, the rump kernel mailing list migrated >>meanwhile. I'm sending my reply to the new list at >>rumpkernel-us...@freelists.org. Everyone replying please use the new >>list.] >> There are essentially 3 choices: 1) teach buildrump.sh to run ./configure like the RTEMS >>cross-compiler expects it to be run (assuming it's somehow possible to run >>./configure scripts against the RTEMS xcompiler; I'm not familiar with RTEMS so >>I can't comment) 2) hardcode the values for RTEMS. I don't really prefer this >>option, since it adds to maintenance overhead and potential breakage; the reason I originally added the autoconf goop was to get rid of the long-time >>hardcoded values causing the maintenance load. 3) skip the POSIX hypervisor entirely and go directly for >>implementing the hypercalls on the low level >>> I agree with this choice, however Dr. Joel sees that integrating Rump >>> Kernels above RTEMS/POSIX would be more stable. Antti may have some >>> words here. >> >>There are actually two points you need to integrate to, since the stack >> >>will look something like this: >> >>RTEMS application >>1 >>rump kernel >>2 >>RTEMS core >> Great examples. When the rump kernel should be accessible from within RTEMS core, we need to provide a non-POSIX implementation due to RTEMS software architecture requirements to avoid POSIX calls within the core. (Despite that they are possible due to being a SASOS, we don't allow them.) >>By "application" I mean anything that would want to use drivers >>provided >>by a rump kernel. It can be a regular POSIX application, in which case >> >>"1" would be system calls, or for example the networking stack wanting >>to use some NIC device driver. What "1" looks like will vary hugely >>based on that. For syscalls it's nice and stable, but for any >>integration point inside the kernel, not so much. For example, when >>using rump kernels to run file system drivers as microkernel style >>servers on NetBSD, "1" is the VFS/vnode interface. In that particular >>scenario, the VFS/vnode interface changing doesn't cause trouble >>because >>both the code using it and providing it is hosted in the NetBSD tree. >>The situation would be different if you want to interface from RTEMS on >> >>that level. > > I think that's the primary use case for RTEMS users. Accessing filesystems > and other services from otherwise "normal" RTEMS applications. So figuring > out how to do that is a goal. > In this case, we don't really want to go back into the POSIX layer, in case the user accesses the RTEMS services in a different way, or in case we want to access the rump kernel from within the RTEMS "core" or arch-specific pieces. > >>By "core" I mean anything that provides the necessary support for a >>rump >>kernel to run. It is absolutely true that using POSIX as the interface >> >>to the core is interface-wise more stable than hooking directly into >>the >>RTEMS entrails -- I assume RTEMS entrails can change. However, the >>interfaces required for implementing "2" (a.k.a. the rump kernel >>hypercall interface) are so simple that I wouldn't consider that >>stability the decisive metric. > > The way RTEMS is structured the APIs for concurrency and synchronization are > thin wrappers (direct calls) over core services. Since there is no separation > of user and kernel space, there isn't the overhead you might find in a > traditional POSIX system. > > Also you have to provide a wrapper above our core because the core is just > really a collection of classes. The APIs combine and tailor those as well as > aggregating them with an object instance so they have IDs and optional names. > > There may be value in bypassing this or providing a fourth API set for RTEMS > as a peer but that would still just be a façade over core services. But this > would end up being special code and more of it than a POSIX wrapper. > > Personally I always viewed this as a way to get another network stack, > filesystems, etc and make them part of regular RTEMS capabilities. How it is > implemented under the hood is secondary to what the user gains that we don't > have otherwise. So seamless integration into our system call layer is > valuable. > To get the seamless integration, we'll need to provide somethign closer to the "fourth API set", but not expose it as an API. The hypercall interface should be accessible within the RTEMS core, which means it can't just be s
Re: [rtems-source-builder commit] Bump newlib git head
Joel,
I think the snapshot should contain this patch now. We should switch
over to it, and start testing for release.
Gedare
On Mon, Mar 23, 2015 at 11:42 AM, Gedare Bloom wrote:
> Module:rtems-source-builder
> Branch:master
> Commit:65235333547902c735ff06667393a4f0e5009929
> Changeset:
> http://git.rtems.org/rtems-source-builder/commit/?id=65235333547902c735ff06667393a4f0e5009929
>
> Author:Gedare Bloom
> Date: Mon Mar 23 11:42:18 2015 -0400
>
> Bump newlib git head
>
> ---
>
> rtems/config/tools/rtems-gcc-4.8.3-newlib-git-1.cfg | 2 +-
> rtems/config/tools/rtems-gcc-4.9.1-newlib-git-1.cfg | 2 +-
> rtems/config/tools/rtems-gcc-4.9.2-newlib-git-1.cfg | 2 +-
> 3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/rtems/config/tools/rtems-gcc-4.8.3-newlib-git-1.cfg
> b/rtems/config/tools/rtems-gcc-4.8.3-newlib-git-1.cfg
> index 1931265..3a9e094 100644
> --- a/rtems/config/tools/rtems-gcc-4.8.3-newlib-git-1.cfg
> +++ b/rtems/config/tools/rtems-gcc-4.8.3-newlib-git-1.cfg
> @@ -3,7 +3,7 @@
> #
>
> %define gcc_version4.8.3
> -%define newlib_version 1c144ed142224cd112c1c9177a4231bef7975f9f
> +%define newlib_version ef23a12ff8f840cc571e47870cd5f4ad6bca4553
>
> %hash md5 gcc-%{gcc_version}.tar.bz2 7c60f24fab389f77af203d2516ee110f
>
> diff --git a/rtems/config/tools/rtems-gcc-4.9.1-newlib-git-1.cfg
> b/rtems/config/tools/rtems-gcc-4.9.1-newlib-git-1.cfg
> index 526fe08..08b6414 100644
> --- a/rtems/config/tools/rtems-gcc-4.9.1-newlib-git-1.cfg
> +++ b/rtems/config/tools/rtems-gcc-4.9.1-newlib-git-1.cfg
> @@ -3,7 +3,7 @@
> #
>
> %define gcc_version4.9.1
> -%define newlib_version 1c144ed142224cd112c1c9177a4231bef7975f9f
> +%define newlib_version ef23a12ff8f840cc571e47870cd5f4ad6bca4553
>
> %hash md5 gcc-%{gcc_version}.tar.bz2 fddf71348546af523353bd43d34919c1
>
> diff --git a/rtems/config/tools/rtems-gcc-4.9.2-newlib-git-1.cfg
> b/rtems/config/tools/rtems-gcc-4.9.2-newlib-git-1.cfg
> index 4d6737b..b339b8f 100644
> --- a/rtems/config/tools/rtems-gcc-4.9.2-newlib-git-1.cfg
> +++ b/rtems/config/tools/rtems-gcc-4.9.2-newlib-git-1.cfg
> @@ -3,7 +3,7 @@
> #
>
> %define gcc_version4.9.2
> -%define newlib_version 1c144ed142224cd112c1c9177a4231bef7975f9f
> +%define newlib_version ef23a12ff8f840cc571e47870cd5f4ad6bca4553
>
> %hash md5 gcc-%{gcc_version}.tar.bz2 4df8ee253b7f3863ad0b86359cd39c43
>
>
> ___
> vc mailing list
> v...@rtems.org
> http://lists.rtems.org/mailman/listinfo/vc
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [rtems-source-builder commit] Bump newlib git head
I didn't have time to switch to the snapshot today. -Gedare On Mon, Mar 23, 2015 at 5:38 PM, Chris Johns wrote: > On 24/03/2015 4:55 am, Joel Sherrill wrote: >> >> >> >> On March 23, 2015 12:01:55 PM CDT, Gedare Bloom wrote: >>> >>> Joel, >>> >>> I think the snapshot should contain this patch now. We should switch >>> over to it, and start testing for release. >> >> >> Ageed. AFAIK this is a good snapshot to start the freezing process with. >> Please update to use it and I will start a to build when I get home. >> > > Great to move back to a snapshot and thanks for pinging Jeff. There maybe a > chance of one more snapshot. It will depend on Sebastian's current newlib > patches. > >> We still have a gdb issue though. There are approximately two dozen >> patches we want against 7.9. It is all Jiri's work. I don't think we want to >> wait for a 7.9.1 since half are still on their mailing list pending. >> >> Can the RSB handle that many patches? > > > Yes it should. > >> I am prone to add them. I could flatten them into one. And put all into >> rtems - tools. Would that work? Just trying to narrow down issues. > > > My only comment is once in the rtems-tools repo they are difficult to remove > so a smaller number of patches keeps the repo a little cleaner. > > It would be good to get this moving again. > > Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC 2015 - Clang support and Eclipse plugin work
On Tue, Mar 24, 2015 at 10:52 AM, Charith Eranga wrote: > Hi All, > > I'm Charith Eranga from University of Moratuwa, Sri Lanka. I'm > currently a second year student specializing in embedded software > development. > > I'm particularly interested in compiling RTEMS with Clang [1] and the > improvements to the Eclipse plugin [2]. I've made a start with RTEMS > by compiling toolchain/rtems following the GSoC guide [3]. > > For clang support, I've made start by following the steps of [1]. I > also have an industry contact (llvm/clang committer) who's willing to > help me on that side of things. One question I have about this is, how It would be most helpful if your contact would be willing to sign-up in Google Melange as a mentor for RTEMS Project. Please have him/her contact me directly for any clarifications. > do we define a success measure for this project? I mean, RTEMS seem to > already compile with Clang with some local patches [1], but how do we Somewhat true, but I believe there are problems with using clang that have to do with the pervasive use of gcc spec files. A pre-requisite task may be to get the spec files completely eliminated, which there is an ongoing effort to do with the "waf branch" of RTEMS [1]. I think it makes the most sense to work from the waf branch and try to help push it forward. > evaluate whether the resulting binary is in good shape? should I also > be thinking of some test-plan as part of the project? Secondly, will RTEMS has an extensive test-suite [2], and you should be prepared to run it before/after. We have a tool that helps with automation [3]. > it be OK if I fork off clang in github and maintain the patches there? > Yes, we prefer for gsoc development to be done on github. > I haven't yet tried out the RTEMS Eclipse plugin (on my TODO list), > but I have an interest in learning Eclipse plugin development. I > suppose the objectives of this project would be implement as much as > possible in the TODO list of [2]? > Yes, but some of those may be obsolete. Perhaps users will chime in about what they would like to see in it. > Many thanks for your comments. > > - Charith > > PS: "Hello World" exercise attached herewith. Confirmed, thanks. Feel free to add yourself to the "Tracking Table" for 2015. [1] https://git.rtems.org/amar/waf.git/ [2] https://git.rtems.org/rtems/tree/testsuites [3] https://git.rtems.org/rtems-tools/tree/tester Gedare > > [1] https://devel.rtems.org/wiki/Projects/CLANG > [2] https://devel.rtems.org/wiki/Developer/Eclipse/Information > [3] https://devel.rtems.org/wiki/GSoC/GettingStarted > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSOC 2015: Review proposal for Beagle BSP improvements: Booting without U-boot
Looks pretty good. I have the same basic comment I give most students, which is that you should try to flesh out some more details about what exactly you will be doing, i.e. what code you might be able to use, what your software architecture may look like, draw some diagrams to clarify concepts, and so on. Gedare On Tue, Mar 24, 2015 at 11:43 PM, Jarielle Catbagan wrote: > Hello all: > > Below is the link to my proposal. Please feel free to make any > comments and/or suggestions. > > https://docs.google.com/document/d/1pGQ60e5A4JcXl9_gkBEutIgb6AhiQ00MPJN6J1rSKT8/edit?usp=sharing > > Thank you! > > Best Regards, > > Jarielle Catbagan > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSOC 2015: Raspberry Pi Low Level Peripherals and SD Card
On Wed, Mar 25, 2015 at 4:49 AM, André Marques wrote: > Hello everyone, > > My GSoC proposal entitled "Raspberry Pi Low Level Peripherals and SD Card" > can be found for review at: > > https://docs.google.com/document/d/11K0qU3OsbSMhNYkTTWt4kitAbd6uuJBcMfA_07Lg6j8 > > One issue I would like to discuss here is related to the SD card support, > which as exposed on the proposal the GPIOs to which the SD card is connected > internally do not have SPI hardware capabilities, meaning that to access the > card via SPI mode it would have to be bit-banged on those GPIOs (a problem > on performance). This is more detailed on the proposal, but another > alternative would be to use the SD mode instead, with the help of the PI's > EMMC module, and the SD simplified specifications as documentation for the > SD protocol. I have already used this setup with success in the past, and it > should have better performance. In this setup the FreeBSD SD/MMC stack may > be used (such as the one Sebastian Huber ported last year -> > https://git.rtems.org/sebh/rtems-libusb.git/tree/rtems/freebsd/dev/mmc?id=3c82a1500da3192de2504a1360e065fd84a1f3a0) Is this code in the libbsd.git now? > which implements the SD protocol also based on the simplified specs. This > would help avoiding implementing the protocol from scratch (which is sort of > what I did in my previous effort with the SD card and the PI) and would be > better for maintenance probably. > > My issue is then on the feasibily (licence wise) of having the FreeBSD SD > stack or having code based on the SD Simplified Specs on the RTEMS tree. > FreeBSD code should be fine. The complexity of getting libbsd working could be the real stumbling block. But I think others will be working on the same problem too, so there may be some ability to share knowledge. > In SPI mode an implementation of the protocol can be found in > libchip/i2c/spi-sd-card.*, which could in that case be used/improved further > during the project, if it is decided it is best to use SPI mode. This uses > the libi2c API, which is deprecated for I2C but, as I understand, still > stands as the API for SPI (information about that would also be > appreciated). > It's just the no one has replaced it yet! There seem to be multiple efforts going on now to get more driver-like frameworks into RTEMS. > Thanks, > André Marques. > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSOC 2015: Review Proposal for Configuration GUI
If you copied from the template and used the same sharing settings, it should just work. Gedare On Wed, Mar 25, 2015 at 9:52 AM, abd el-hamed Amer wrote: > Dear Anand, > > Thanks a lot, How can i set it to be visible to mentors(I just know mentor > name)? > > Regards, > Abdelhamid > > On Wed, Mar 25, 2015 at 3:41 PM, Anand Krishnan wrote: >> >> Hi, >> >> Create an account on RTEMS page, login using it to the tracking page and >> then you will find the link at the bottom of the page to edit the page. Go >> to that and edit the table and paste the link to your proposal google doc. >> Make sure it's visible to your mentors or make it public. >> >> All the best, >> Regards, >> Anand >> >> >> On Wed, Mar 25, 2015, 7:03 PM abd el-hamed Amer >> wrote: >>> >>> Dear, >>> >>> How can i share my proposal on RTEMS table with mentors? or just upload >>> it in Google Summer of Code account. It's the first time to apply please >>> help me. >>> >>> Best Reagrds >>> >>> On Wed, Mar 25, 2015 at 1:15 PM, Anand Krishnan >>> wrote: Attaching the google docs link as well: https://docs.google.com/document/d/1OOKr9px9yYtAjUvLJM1_Js4xxsg_fXxnN3AWaf3IUp0/edit?usp=sharing Thanks! Anand On Wed, Mar 25, 2015 at 8:49 AM, Anand Krishnan wrote: > > Dear Mentors and students, > > It'd be great if you could review my proposal. I am planning to build a > Configuration GUI for RTEMS - used for configuring RTEMS during waf build. > > > http://www.google-melange.com/gsoc/proposal/public/google/gsoc2015/anandkp92/5629499534213120 > > Any comments and reviews are welcome! > > Thank You, > Anand ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel >>> >>> > > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSOC and ESA SOCIS
P.S. mentors feel free to sign-up for GSoC. We have lots of interesting project proposals this year, does one catch your eye? https://devel.rtems.org/wiki/GSoC/2015 On Wed, Mar 25, 2015 at 12:24 PM, Joel Sherrill wrote: > Hi > > Only two days left to apply to GSOC. > > The ESA SOCIS application period is now open. If you are qualified > based on their rules, please apply to both the SOCIS and GSOC. > > Get those applications in! > > -- > 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 > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Tracing task id.
There are unused fields in the (32-bit) Objects_Id, but none are "reserved". Currently only 2-bits of the API are used, although 4 bits are available. Also, if you're not using RTEMS_MULTIPROCESSING, I guess none of the node bits are used. Gedare On Wed, Mar 25, 2015 at 10:52 PM, Chris Johns wrote: > Hi, > > Is there are bit in the Id that could be reserved and used to record the > interrupt nesting state when tracing ? > > This saves having to find a bit somewhere else in record to capture this > piece of information. I am thinking about testing the irq nesting level > and if set recording this. > > Chris > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Updated rtems GSOC table with my proposal for Nested Mutexes problem
Upload your official proposal to Google Melange. I would expect the multicore aspect to be mostly research, and any implementations for multicore are bonus. You could also consider implementing something like plist as a future improvement, if it makes sense to offer. Since this bug affects previous versions of RTEMS, you might like to consider a back-port to 4.10 (and, 4.11, if we will release it before GSoC which I anticipate). Deliverables should be specific software that you will submit to RTEMS for inclusion. Gedare On Thu, Mar 26, 2015 at 12:19 AM, Saurabh Gadia wrote: > Hello Sir, > I have updated https://devel.rtems.org/wiki/GSoC/2015 with my proposal for > Nested Mutexes project. Please guide on what can I add to my proposal for > following points: > > 1. Future improvement to the projects. > 2. Deliverable part of the report. > > Also provide me with complete review of the proposal and what changes are > required to it. I am also attaching a copy of proposal with this mail. > > Thanks, > > Saurabh Gadia ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GS0C 2015-Hello Word
Yes this is acceptable, thanks! Please post your patch too. -Gedare On Thu, Mar 26, 2015 at 1:07 AM, Rohini Kulkarni wrote: > Hi All, > > I have chosen Raspberry Pi 2 support as my project. I recently received the > raspberry pi board, but do not have a console set up yet. I have run the the > hello world using QEMU for raspberry pi. Can this be accepted as proof? I > will get the actual pi running as soon as possible. > > Please find the attached screenshot. > > Thanks! > > -- > Rohini Kulkarni > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSOC 2015: Porting MicroMonitor to the Beaglebone Black
On Thu, Mar 26, 2015 at 2:18 PM, Joel Sherrill wrote: > On 03/26/2015 11:35 AM, Jarielle Catbagan wrote: >> >> It looks like the internal ROM-based bootloader looks for a secondary >> program loader (SPL) that initializes the necessary devices to >> continue the boot process and pass control to a third-stage >> bootloader. So now I believe it's a matter of finding whether there >> are existing code implementations of this SPL, or last-case scenario >> this would have to be implemented. Time for more investigating. :) >> > My off the top of my head recommendation is to document the > sequence the BB goes through during initialization. Then > start with a goal of replacing U-Boot in that sequence with > Micromonitor. This keeps us in the world of at least documented > with code. However U-Boot has to be formatted, linked, etc. > is exactly what you will have to do with your Micromonitor. > > U-Boot can be a reference but not a source of code. > > The previous stages may be able to be replaced later but > I wouldn't worry about that now. >> >> On Thu, Mar 26, 2015 at 9:27 AM, Jarielle Catbagan >> wrote: >>> >>> To put things into context in regards to the conversation that I was >>> having with Ed, Dr. Joel, and Gedare: >>> >>> I am currently in the process of looking into porting MicroMonitor to >>> the Beaglebone Black. As indicated by Ed, "[t]he difficulty of the >>> port will depend on how much existing CPU-initialization >>> (clocks, cache, etc..) code we can reuse." >>> > Ed and the authors of the RTEMS code would have to agree but, > in principle, anything in the Beagle BSP should be fair game for > reuse in Micromonitor. > Yeah you have to get explicit permission, the RTEMS license is not compatible to the Micromonitor one in that direction. >>> Ed has also indicated to me that there might be an internal bootloader >>> stored in a ROM-based memory that might look for an image in a >>> specific format. I will definitely be investigating more into this. >>> I did manage to briefly browse through the Beaglebone Black System >>> Reference Manual Rev C.1 [1], and I have found that the boot >>> configuration/process is briefly elaborated in section 6.7. For >>> convenience, since it's a short section I will post it here: >>> >>> "The design supports two groups of boot options on the board. The user >>> can switch between these modes via the Boot button. The primary boot >>> source is the onboard eMMC device. By holding the Boot button, the >>> user can force the board to boot from the microSD slot. This enables >>> the eMMC to be overwritten when needed or to just boot an alternate >>> image... >>> >>> [T]the processor-external boot code is composed of two stages. After >>> the primary boot code in the processor ROM passes control, a secondary >>> stage (secondary program loader -- "SPL" or "MLO") takes over. The SPL >>> stage initializes only the required devices to continue the boot >>> process, and then control is transferred to the third stage "U-boot". >>> Based on the settings of the boot pins, the ROM knows where to go and >>> get the SPL and UBoot code. In the case of the BeagleBone Black, that >>> is either eMMC or microSD based on the position of the boot switch." >>> >>> I was kindly guided to look into programming a uSD card as it might be >>> more efficient to run MicroMonitor off of the uSD for quick testing >>> after every build. If all goes well, either an application image will >>> be located and booted off of the same SD card or via a network boot. >>> For serial debugging I have an FTDI 3.3V USB-to-Serial cable that I >>> have been previously using to access the U-boot monitor on the >>> Beaglebone Black. >>> > This is how we do a lot of our testing. It isn't worth the effort > to put something on the board itself. Plus it places wear and > tear on a replaceable item, not on the built-in flash. >>> >>> [1] >>> https://github.com/CircuitCo/BeagleBone-Black/blob/master/BBB_SRM.pdf?raw=true >> >> ___ >> devel mailing list >> devel@rtems.org >> http://lists.rtems.org/mailman/listinfo/devel > > > > -- > -- Joel Sherrill > Ask me about RTEMS: a free RTOS > Support and Training Available > > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 1/2] Add rtems-tester configurations for simsh family of BSPs
I guess you ran it? Could you post your results when you commit it. :)
On Thu, Mar 26, 2015 at 2:22 PM, Joel Sherrill
wrote:
> ---
> tester/rtems/testing/bsps/simsh1-run.mc | 54 ++
> tester/rtems/testing/bsps/simsh1.mc | 56
>
> tester/rtems/testing/bsps/simsh2-run.mc | 54 ++
> tester/rtems/testing/bsps/simsh2.mc | 56
>
> tester/rtems/testing/bsps/simsh2e-run.mc | 54 ++
> tester/rtems/testing/bsps/simsh2e.mc | 56
>
> tester/rtems/testing/bsps/simsh4-run.mc | 54 ++
> tester/rtems/testing/bsps/simsh4.mc | 56
>
> 8 files changed, 440 insertions(+)
> create mode 100644 tester/rtems/testing/bsps/simsh1-run.mc
> create mode 100644 tester/rtems/testing/bsps/simsh1.mc
> create mode 100644 tester/rtems/testing/bsps/simsh2-run.mc
> create mode 100644 tester/rtems/testing/bsps/simsh2.mc
> create mode 100644 tester/rtems/testing/bsps/simsh2e-run.mc
> create mode 100644 tester/rtems/testing/bsps/simsh2e.mc
> create mode 100644 tester/rtems/testing/bsps/simsh4-run.mc
> create mode 100644 tester/rtems/testing/bsps/simsh4.mc
>
> diff --git a/tester/rtems/testing/bsps/simsh1-run.mc
> b/tester/rtems/testing/bsps/simsh1-run.mc
> new file mode 100644
> index 000..2defb72
> --- /dev/null
> +++ b/tester/rtems/testing/bsps/simsh1-run.mc
> @@ -0,0 +1,54 @@
> +#
> +# RTEMS Tools Project (http://www.rtems.org/)
> +# Copyright 2015 On-Line Applications Research Corporation (OAR).
> +# All rights reserved.
> +#
> +# This file is part of the RTEMS Tools package in 'rtems-tools'.
> +#
> +# Redistribution and use in source and binary forms, with or without
> +# modification, are permitted provided that the following conditions are met:
> +#
> +# 1. Redistributions of source code must retain the above copyright notice,
> +# this list of conditions and the following disclaimer.
> +#
> +# 2. Redistributions in binary form must reproduce the above copyright
> notice,
> +# this list of conditions and the following disclaimer in the documentation
> +# and/or other materials provided with the distribution.
> +#
> +# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
> +# AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
> +# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
> +# ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
> +# LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
> +# CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
> +# SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
> +# INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
> +# CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
> +# ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
> +# POSSIBILITY OF SUCH DAMAGE.
> +#
> +
> +#
> +# All paths in defaults must be Unix format. Do not store any Windows format
> +# paths in the defaults.
> +#
> +# Every entry must describe the type of checking a host must pass.
> +#
> +# Records:
> +# key: type, attribute, value
> +# type : none, dir, exe, triplet
> +# attribute: none, required, optional
> +# value: 'single line', '''multi line'''
> +#
> +
> +#
> +# The simsh1 BSP
> +#
> +[global]
> +bsp: none,none, 'simsh1'
> +
> +[simsh1]
> +simsh1: none,none, '%{_rtscripts}/run.cfg'
> +simsh1_arch: none,none, 'sh'
> +bsp_run_cmd: none,none,
> '%{rtems_tools}/%{bsp_arch}-rtems%{rtems_version}-run'
> +bsp_run_opts: none,none, '-a -nouartrx'
> diff --git a/tester/rtems/testing/bsps/simsh1.mc
> b/tester/rtems/testing/bsps/simsh1.mc
> new file mode 100644
> index 000..5c6bdaf
> --- /dev/null
> +++ b/tester/rtems/testing/bsps/simsh1.mc
> @@ -0,0 +1,56 @@
> +#
> +# RTEMS Tools Project (http://www.rtems.org/)
> +# Copyright 2015 On-Line Applications Research Corporation (OAR).
> +# All rights reserved.
> +#
> +# This file is part of the RTEMS Tools package in 'rtems-tools'.
> +#
> +# Redistribution and use in source and binary forms, with or without
> +# modification, are permitted provided that the following conditions are met:
> +#
> +# 1. Redistributions of source code must retain the above copyright notice,
> +# this list of conditions and the following disclaimer.
> +#
> +# 2. Redistributions in binary form must reproduce the above copyright
> notice,
> +# this list of conditions and the following disclaimer in the documentation
> +# and/or other materials provided with the distribution.
> +#
> +# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
> +# AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT
Re: [PATCH] TMS570: Add board reset code to bsp_reset
On Thu, Mar 26, 2015 at 5:07 PM, Daniel Gutson
wrote:
> On Thu, Mar 26, 2015 at 5:16 PM, Martin Galvan
> wrote:
>> ---
>> c/src/lib/libbsp/arm/tms570/include/tms570.h | 19 +++--
>> c/src/lib/libbsp/arm/tms570/startup/bspreset.c | 37
>> --
>> 2 files changed, 34 insertions(+), 22 deletions(-)
>>
>> diff --git a/c/src/lib/libbsp/arm/tms570/include/tms570.h
>> b/c/src/lib/libbsp/arm/tms570/include/tms570.h
>> index 2023a29..50f1315 100644
>> --- a/c/src/lib/libbsp/arm/tms570/include/tms570.h
>> +++ b/c/src/lib/libbsp/arm/tms570/include/tms570.h
>> @@ -7,15 +7,9 @@
>> */
>>
>> /*
>> - * Copyright (c) 2014 Premysl Houdek
>> + * Copyright (c) 2015 Taller Technologies.
>
> Is this correct, or should we both be listed here? Be careful here.
>
Thanks, I think this is fine here since it was just some stub code
that probably isn't copyrightable, but..IANAL.
>> *
>> - * Google Summer of Code 2014 at
>> - * Czech Technical University in Prague
>> - * Zikova 1903/4
>> - * 166 36 Praha 6
>> - * Czech Republic
>> - *
>> - * Based on LPC24xx and LPC1768 BSP
>> + * @author Martin Galvan
>> *
>> * The license and distribution terms for this file may be
>> * found in the file LICENSE in this distribution or at
>> @@ -25,4 +19,13 @@
>> #ifndef LIBBSP_ARM_TMS570_H
>> #define LIBBSP_ARM_TMS570_H
>>
>> +#define SYSECR (*(uint32_t *)0xFFE0u) /* System Exception Control
>> Register */
>> +#define ESMIOFFHR (*(uint32_t *)0xF528) /* ESM Interrupt Offset High
>> Register */
>> +#define ESMSR1 (*(uint32_t *)0xF518u) /* ESM Status Register 1 */
>> +#define ESMSR2 (*(uint32_t *)0xF51Cu) /* ESM Status Register 2 */
>> +#define ESMSR3 (*(uint32_t *)0xF520u) /* ESM Status Register 3 */
>> +#define ESMSR4 (*(uint32_t *)0xF558u) /* ESM Status Register 4 */
>> +
>> +#define SYSECR_RESET 0x8u
>> +
>> #endif /* LIBBSP_ARM_TMS570_H */
>> diff --git a/c/src/lib/libbsp/arm/tms570/startup/bspreset.c
>> b/c/src/lib/libbsp/arm/tms570/startup/bspreset.c
>> index d47920c..a4b6647 100644
>> --- a/c/src/lib/libbsp/arm/tms570/startup/bspreset.c
>> +++ b/c/src/lib/libbsp/arm/tms570/startup/bspreset.c
>> @@ -7,30 +7,39 @@
>> */
>>
>> /*
>> - * Copyright (c) 2014 Premysl Houdek
>> + * Copyright (c) 2015 Taller Technologies.
>> *
>> - * Google Summer of Code 2014 at
>> - * Czech Technical University in Prague
>> - * Zikova 1903/4
>> - * 166 36 Praha 6
>> - * Czech Republic
>> - *
>> - * Based on LPC24xx and LPC1768 BSP
>> + * @author Martin Galvan
>> *
>> * The license and distribution terms for this file may be
>> * found in the file LICENSE in this distribution or at
>> * http://www.rtems.org/license/LICENSE.
>> */
>>
>> -#include
>> -
>> -#include
>> +#include
>> #include
>> #include
>>
>> -BSP_START_TEXT_SECTION __attribute__( ( flatten ) ) void bsp_reset( void )
>> +static void handle_esm_errors(uint32_t esm_irq_channel)
>> +{
>> + /* ESMR3 errors don't generate interrupts. */
>> + if (esm_irq_channel < 0x20u) {
>> +ESMSR1 = 1 << esm_irq_channel;
>> + } else if (esm_irq_channel < 0x40u) {
>> +ESMSR2 = 1 << (esm_irq_channel - 32u);
>> + } else if (esm_irq_channel < 0x60u) {
>> +ESMSR4 = 1 << (esm_irq_channel - 64u);
>> + }
>> +}
>> +
>> +void bsp_reset(void)
>> {
>> - while ( true ) {
>> -/* Do nothing */
>> + uint32_t esm_irq_channel = ESMIOFFHR - 1;
>> +
>> + if (esm_irq_channel) {
>> +handle_esm_errors(esm_irq_channel);
>>}
>> +
>> + /* Reset the board */
>> + SYSECR = SYSECR_RESET;
>> }
>> --
>> 2.3.4
>>
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>
>
>
> --
>
> Daniel F. Gutson
> Chief Engineering Officer, SPD
>
> San Lorenzo 47, 3rd Floor, Office 5
> Córdoba, Argentina
>
> Phone: +54 351 4217888 / +54 351 4218211
> Skype:dgutson
> LinkedIn: http://ar.linkedin.com/in/danielgutson
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: Introduction
Yes you may add yourself, and you should put your official proposal into Google Melange. Please also take a look at the patch set (about 100 patches) that Daniel Hellstrom delivered recently, my comments on them, and contact him to inquire whether/what can be done in this direction. Gedare On Fri, Mar 27, 2015 at 2:26 AM, Gowtham Ashok wrote: > Hello. Here is the proof of hello world patch. Attached is the screenshot > for sis and LEON3 simulators running the hello world program. > > I would like to work on the Merge Lion project and I am in the process of > writing a proposal for it. > > Is it okay if I add myself to the GSoC Tracking page? > > Best, > Gowtham Ashok > > On Thu, Mar 19, 2015 at 2:28 AM, Gedare Bloom wrote: >> >> Welcome, >> >> You're not too late. We don't think the SMP support (broadly speaking) >> is suitable for GSoC projects at this time. There might be some >> specific aspects, such as SMP support for a particular platform, that >> you could undertake. Another project that may be suitable and timely >> could be to work on improving the newly submitted drvmgr code, this is >> listed as "Merge Leon", and there remains quite a few open problems to >> solve. There was an email thread on this (subject: [PATCH 000/111] >> GRLIB/LEON RTEMS RCC patches) >> >> Regardless, you should begin by going through our GSoC Getting Started >> Guide, that will familiarize you with building and running RTEMS in a >> simulator. Then, if the project you choose will use a particular >> target BSP, you should build tools for it and be able to demo it. You >> should get a reference letter from someone with KDE as well to >> strengthen your application. Feel free to ask questions here, and on >> IRC you may occasionally get some interactive discussions. >> >> Gedare >> >> On Wed, Mar 18, 2015 at 4:42 PM, Gowtham Ashok wrote: >> > Hello, I'm Gowtham, a senior CS undergraduate. I'm a KDE contributor and >> > have mentored Google Code-in 2014 for them. >> > I came across RTEMS while studying for my real-time systems midterm and >> > would like to become a regular contributor. >> > I thought that doing a GSoC would be a good starting point. Am I too >> > late? >> > I have seen many interesting potential projects on the ideas page. I >> > would >> > like to start working on it as soon as possible. >> > Would improving SMP support in RTEMS be a good contender for a >> > GSoC-level >> > project? >> > >> > Best, >> > Gowtham >> > >> > -- >> > Gowtham Ashok >> > Madras Institute of Technology >> > Ph: +91 9003185651 >> > >> > IRC:gwty >> > >> > >> > ___ >> > devel mailing list >> > devel@rtems.org >> > http://lists.rtems.org/mailman/listinfo/devel > > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSOC 2015: Improve Coverage Analysis
Hermann, You should use our proposal template https://docs.google.com/document/d/1F5XCodvX8AYNqWX5ssu7dfjkmFT__83uf8ABKbB_Pkg/edit?usp=sharing Thanks, Gedare On Fri, Mar 27, 2015 at 8:26 AM, Hermann Felbinger wrote: > Hi all, > > I am interested in working on coverage analysis for RTEMS at GSOC and > beyond. I already submitted a proposal. So please review it and I would be > happy to hear your comments. > > Title: "Improve Code Coverage Analysis Meeting Aviation and Automotive > Standards" > > Best, > Hermann > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] TMS570: Add board reset code to bsp_reset
It looks good to me I'll try to get to it if Sebastian doesn't. -Gedare
On Thu, Mar 26, 2015 at 4:16 PM, Martin Galvan
wrote:
> ---
> c/src/lib/libbsp/arm/tms570/include/tms570.h | 19 +++--
> c/src/lib/libbsp/arm/tms570/startup/bspreset.c | 37
> --
> 2 files changed, 34 insertions(+), 22 deletions(-)
>
> diff --git a/c/src/lib/libbsp/arm/tms570/include/tms570.h
> b/c/src/lib/libbsp/arm/tms570/include/tms570.h
> index 2023a29..50f1315 100644
> --- a/c/src/lib/libbsp/arm/tms570/include/tms570.h
> +++ b/c/src/lib/libbsp/arm/tms570/include/tms570.h
> @@ -7,15 +7,9 @@
> */
>
> /*
> - * Copyright (c) 2014 Premysl Houdek
> + * Copyright (c) 2015 Taller Technologies.
> *
> - * Google Summer of Code 2014 at
> - * Czech Technical University in Prague
> - * Zikova 1903/4
> - * 166 36 Praha 6
> - * Czech Republic
> - *
> - * Based on LPC24xx and LPC1768 BSP
> + * @author Martin Galvan
> *
> * The license and distribution terms for this file may be
> * found in the file LICENSE in this distribution or at
> @@ -25,4 +19,13 @@
> #ifndef LIBBSP_ARM_TMS570_H
> #define LIBBSP_ARM_TMS570_H
>
> +#define SYSECR (*(uint32_t *)0xFFE0u) /* System Exception Control
> Register */
> +#define ESMIOFFHR (*(uint32_t *)0xF528) /* ESM Interrupt Offset High
> Register */
> +#define ESMSR1 (*(uint32_t *)0xF518u) /* ESM Status Register 1 */
> +#define ESMSR2 (*(uint32_t *)0xF51Cu) /* ESM Status Register 2 */
> +#define ESMSR3 (*(uint32_t *)0xF520u) /* ESM Status Register 3 */
> +#define ESMSR4 (*(uint32_t *)0xF558u) /* ESM Status Register 4 */
> +
> +#define SYSECR_RESET 0x8u
> +
> #endif /* LIBBSP_ARM_TMS570_H */
> diff --git a/c/src/lib/libbsp/arm/tms570/startup/bspreset.c
> b/c/src/lib/libbsp/arm/tms570/startup/bspreset.c
> index d47920c..a4b6647 100644
> --- a/c/src/lib/libbsp/arm/tms570/startup/bspreset.c
> +++ b/c/src/lib/libbsp/arm/tms570/startup/bspreset.c
> @@ -7,30 +7,39 @@
> */
>
> /*
> - * Copyright (c) 2014 Premysl Houdek
> + * Copyright (c) 2015 Taller Technologies.
> *
> - * Google Summer of Code 2014 at
> - * Czech Technical University in Prague
> - * Zikova 1903/4
> - * 166 36 Praha 6
> - * Czech Republic
> - *
> - * Based on LPC24xx and LPC1768 BSP
> + * @author Martin Galvan
> *
> * The license and distribution terms for this file may be
> * found in the file LICENSE in this distribution or at
> * http://www.rtems.org/license/LICENSE.
> */
>
> -#include
> -
> -#include
> +#include
> #include
> #include
>
> -BSP_START_TEXT_SECTION __attribute__( ( flatten ) ) void bsp_reset( void )
> +static void handle_esm_errors(uint32_t esm_irq_channel)
> +{
> + /* ESMR3 errors don't generate interrupts. */
> + if (esm_irq_channel < 0x20u) {
> +ESMSR1 = 1 << esm_irq_channel;
> + } else if (esm_irq_channel < 0x40u) {
> +ESMSR2 = 1 << (esm_irq_channel - 32u);
> + } else if (esm_irq_channel < 0x60u) {
> +ESMSR4 = 1 << (esm_irq_channel - 64u);
> + }
> +}
> +
> +void bsp_reset(void)
> {
> - while ( true ) {
> -/* Do nothing */
> + uint32_t esm_irq_channel = ESMIOFFHR - 1;
> +
> + if (esm_irq_channel) {
> +handle_esm_errors(esm_irq_channel);
>}
> +
> + /* Reset the board */
> + SYSECR = SYSECR_RESET;
> }
> --
> 2.3.4
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: GSOC 2015: Improve Coverage Analysis
Oops, for some reason, I only got a notification with the abstract in it from Melange. I'm taking a closer look now! Gedare On Fri, Mar 27, 2015 at 9:34 AM, Hermann Felbinger wrote: > Gedare, > > I cannot follow you. I used the proposal template resp. a copy of it and > provided the link at https://devel.rtems.org/wiki/GSoC/2015 . > What is wrong? > > Thanks, > Hermann > > Gedare Bloom schrieb am Fr., 27. März 2015 um 14:18 Uhr: > >> Hermann, >> >> You should use our proposal template >> >> https://docs.google.com/document/d/1F5XCodvX8AYNqWX5ssu7dfjkmFT__83uf8ABKbB_Pkg/edit?usp=sharing >> >> Thanks, >> Gedare >> >> On Fri, Mar 27, 2015 at 8:26 AM, Hermann Felbinger >> wrote: >> > Hi all, >> > >> > I am interested in working on coverage analysis for RTEMS at GSOC and >> > beyond. I already submitted a proposal. So please review it and I would >> > be >> > happy to hear your comments. >> > >> > Title: "Improve Code Coverage Analysis Meeting Aviation and Automotive >> > Standards" >> > >> > Best, >> > Hermann >> > >> > ___ >> > devel mailing list >> > devel@rtems.org >> > http://lists.rtems.org/mailman/listinfo/devel > > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [GSoC] Raspberry Pi BSP proposal
Please enable comments. -Gedare On Fri, Mar 27, 2015 at 11:00 AM, Carlos Falgueras García wrote: > Hello! > > I'm interesting to participate in GSoC with this organization. I've a > proposal for Rasberry Pi BSP layer improvement. I know maybe it's too late, > and that there are other proposal. But I have worked as hard and fast as I > could, and I must try it. > > The link to the proposal: > https://docs.google.com/document/d/1Ezr3bseIVOceYlb-pbFJ46vsj_U-q38tPs0-409WPCw/edit?usp=sharing > > Thank you, > Carlos Falgueras García. > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
GSOC submissions closed
Hi, Submissions have ended. We have received 18 legitimate applications, 3 spam, 1 duplicate, and 1 that was withdrawn. Any students who are eligible should submit applications to SOCIS as well. The general list of projects is at https://devel.rtems.org/wiki/GSoC/2015 although not all of them submitted their proposals to Melange. Mentors can still sign up. Gedare ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] libmisc/shell: Add the rtrace command for buffered tracing support.
Quick comments:
Avoid abbreviations but feel free to use acronyms in "rtems" APIs . Make sure
acronyms are documented, what is TBG?
If divide by 32 is on hot path might want to reconsider it if possible
A macro for the bit masks would improve readability
I've seen this print timestamp functionality before in shell I think, might be
worth sharing code
--
Sent from a mobile device.
-Original Message-
[PATCH] libmisc/shell: Add the rtrace command for buffered tracing support.
From: Chris Johns
To: ,
Sunday, March 29, 2015 at 3:55 AM
The rtrace command interfaces to the RTEMS Trace Linker's trace
buffering data allowing users to capture and report trace data.
---
cpukit/Makefile.am | 5 +
cpukit/libmisc/Makefile.am | 5 +-
cpukit/libmisc/capture/rtems-trace-buffer-vars.c | 178 ++
cpukit/libmisc/capture/rtems-trace-buffer-vars.h | 147 +
cpukit/libmisc/shell/main_rtrace.c | 676 +++
cpukit/libmisc/shell/shellconfig.h | 10 +
cpukit/preinstall.am | 9 +
7 files changed, 1028 insertions(+), 2 deletions(-)
create mode 100644 cpukit/libmisc/capture/rtems-trace-buffer-vars.c
create mode 100644 cpukit/libmisc/capture/rtems-trace-buffer-vars.h
create mode 100644 cpukit/libmisc/shell/main_rtrace.c
diff --git a/cpukit/Makefile.am b/cpukit/Makefile.am
index 10b59db..7df116c 100644
--- a/cpukit/Makefile.am
+++ b/cpukit/Makefile.am
@@ -172,6 +172,11 @@ include_rtems_HEADERS += libmisc/capture/capture.h
include_rtems_HEADERS += libmisc/capture/capture-cli.h
include_rtems_HEADERS += libmisc/capture/captureimpl.h
+# tracing headers
+include_rtems_tracedir = $(include_rtemsdir)/trace
+include_rtems_trace_HEADERS =
+include_rtems_trace_HEADERS += libmisc/capture/rtems-trace-buffer-vars.h
+
## cpuuse
include_rtems_HEADERS += libmisc/cpuuse/cpuuse.h
diff --git a/cpukit/libmisc/Makefile.am b/cpukit/libmisc/Makefile.am
index f09b69d..ac703ad 100644
--- a/cpukit/libmisc/Makefile.am
+++ b/cpukit/libmisc/Makefile.am
@@ -21,7 +21,8 @@ libcapture_a_SOURCES = capture/capture.c
capture/capture-cli.c \
capture/capture_user_extension.c capture/capture_buffer.c \
capture/capture_support.c \
capture/capture.h capture/captureimpl.h capture/capture-cli.h \
-capture/capture_buffer.h
+capture/capture_buffer.h \
+capture/rtems-trace-buffer-vars.c capture/rtems-trace-buffer-vars.h
## cpuuse
EXTRA_DIST += cpuuse/README
@@ -108,7 +109,7 @@ libshell_a_SOURCES = shell/cat_file.c shell/cmds.c
shell/internal.h \
shell/main_setenv.c shell/main_getenv.c shell/main_unsetenv.c \
shell/main_mkrfs.c shell/main_debugrfs.c shell/main_df.c \
shell/main_lsof.c shell/main_edit.c \
-shell/main_blkstats.c \
+shell/main_blkstats.c shell/main_rtrace.c \
shell/shell-wait-for-input.c
libshell_a_SOURCES += shell/main_cmdls.c
libshell_a_SOURCES += shell/main_cmdchown.c
diff --git a/cpukit/libmisc/capture/rtems-trace-buffer-vars.c
b/cpukit/libmisc/capture/rtems-trace-buffer-vars.c
new file mode 100644
index 000..92054bf
--- /dev/null
+++ b/cpukit/libmisc/capture/rtems-trace-buffer-vars.c
@@ -0,0 +1,178 @@
+/*
+ * Copyright (c) 2015 Chris Johns
+ *
+ * The license and distribution terms for this file may be
+ * found in the file LICENSE in this distribution or at
+ * http://www.rtems.org/license/LICENSE.
+ */
+
+#include
+
+#include
+
+/**
+ * External Trace Linker and TBG data. We provide weak versions to allow us to
+ * link and be present in an application that has not been trace linked.
+ */
+
+/*
+ * Trace linker data.
+ */
+uint32_t __rtld_trace_names_size __attribute__ ((weak));
+const char const* __rtld_trace_names[1] __attribute__ ((weak));
+uint32_t __rtld_trace_enables_size __attribute__ ((weak));
+const uint32_t __rtld_trace_enables[1] __attribute__ ((weak));
+uint32_t __rtld_trace_triggers_size __attribute__ ((weak));
+const uint32_t __rtld_trace_triggers[1] __attribute__ ((weak));
+const __rtld_trace_sig __rtld_trace_signatures[1] __attribute__ ((weak));
+
+/*
+ * Trace buffer generator data.
+ */
+const bool __rtld_tbg_present __attribute__ ((weak));
+const uint32_t __rtld_tbg_mode __attribute__ ((weak));
+const uint32_t __rtld_tbg_buffer_size __attribute__ ((weak));
+uint32_t __rtld_tbg_buffer[1] __attribute__ ((weak));
+volatile uint32_t __rtld_tbg_buffer_in __attribute__ ((weak));
+volatile bool __rtld_tbg_finished __attribute__ ((weak));
+volatile bool __rtld_tbg_triggered __attribute__ ((weak));
+
+uint32_t
+rtems_trace_names_size (void)
+{
+ return __rtld_trace_names_size;
+}
+
+const char*
+rtems_trace_names (const uint32_t index)
+{
+ return __rtld_trace_names[index];
+}
+
+uint32_t
+rtems_trace_enables_size (void)
+{
+ return __rtld_trace_enables_size;
+}
+
+uint32_t
+rtems_trace_enables (const uint32_t index)
+{
+ return __rtld_trace_enables[index];
+}
+
+uint32_t
+rtems_trace_triggers_size (void)
Re: Uptime difference between FreeBSD and RTEMS
Would you then subtract 1 from uptime when reporting it? Or would users be expected to know that uptime is off-by-1? On Wed, Apr 1, 2015 at 4:07 AM, Alexander Krutwig wrote: > Hello, > > during my work with FreeBSD timecounters, I found out that the FreeBSD > timecounters start with an uptime value of 1 second. Developers of FreeBSD > told me that this is due to problems in the ARP code. > RTEMS uptime is initialized to an uptime value to 0 seconds. > Are there any problems if the configuration of the RTEMS uptime is also > initialized to 1 second for synchonization? Else, we would have different > values for different API functions which is the second option. > > Best regards, > Alexander Krutwig > > -- > > embedded brains GmbH > Alexander Krutwig > Dornierstr. 4 > D-82178 Puchheim > Germany > email: alexander.krut...@embedded-brains.de > Phone: +49-89-18 94 741 - 17 > Fax: +49-89-18 94 741 - 09 > PGP: Public key available on request. > > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: RTEMS Driver
Hugo, RTEMS does not currently have much infrastructure for device drivers. There are some efforts underway that may lead to it, but for now, device drivers normally are written directly within a BSP, so you'd write the custom code to run your LCD driver directly, and provide your application with some way to access it. Gedare On Wed, Apr 1, 2015 at 6:58 AM, zj...@york.ac.uk wrote: > Hi: > > I am a student to work with RTEMS these days. > > I like this OS, but I found there's few information about RTEMS, I am really > desired to know how can I add a new driver for it, such as LCD driver or > others. > > From the official information, there is only some API and function > interface, is there any specifc course of it? step by step. > > Yous > Hugo > Wish to hear from you soon~ > > > zj...@york.ac.uk > > ___ > users mailing list > us...@rtems.org > http://lists.rtems.org/mailman/listinfo/users ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: RTEMS Driver
P.S. you may like to check out the work that has been done to add GPIO interface to raspberry pi, by Andre Marques in last years GSoC. It has not been merged, but you can find links to the code through the rtems wiki, open projects, improve raspberry pi project page. Gedare On Wed, Apr 1, 2015 at 10:21 AM, Gedare Bloom wrote: > Hugo, > > RTEMS does not currently have much infrastructure for device drivers. > There are some efforts underway that may lead to it, but for now, > device drivers normally are written directly within a BSP, so you'd > write the custom code to run your LCD driver directly, and provide > your application with some way to access it. > > Gedare > > On Wed, Apr 1, 2015 at 6:58 AM, zj...@york.ac.uk wrote: >> Hi: >> >> I am a student to work with RTEMS these days. >> >> I like this OS, but I found there's few information about RTEMS, I am really >> desired to know how can I add a new driver for it, such as LCD driver or >> others. >> >> From the official information, there is only some API and function >> interface, is there any specifc course of it? step by step. >> >> Yous >> Hugo >> Wish to hear from you soon~ >> >> >> zj...@york.ac.uk >> >> ___ >> users mailing list >> us...@rtems.org >> http://lists.rtems.org/mailman/listinfo/users ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: TMS570 BSP: RTEMS license compatible TMS570LS3137 header files progress
On Wed, Apr 1, 2015 at 7:01 AM, Pavel Pisa wrote: > Hello all, > > I would like to inform you that Premysl Houdek is near to finishing > preparation of complete registers header files for TMS570LS3137. > The register and fields definition are interactively retrieved > with help of some macro from MCU PDF manual files. This is a great effort > We decided to store retrieved data in JSON format. > > The raw files are available in rtems-tms570-utils repository > temporary branch > > https://github.com/AoLaD/rtems-tms570-utils/tree/Headers/headers/raw_files > > There are examples of the final JSON files after check/review > for completeness. I.e. for CRC module > > > https://github.com/AoLaD/rtems-tms570-utils/blob/Headers/headers/prepared_files/CRC.json > > Then there is a Python script which generates RTEMS style > headerfiles. Example > > > https://github.com/AoLaD/rtems-tms570-utils/blob/Headers/headers/headers/CRC.h > For headers/code that is automatically generated, I'd like to see a very permissive license applied to the tool output. Slapping an RTEMS License on it is ok, but not ideal to me. I guess we should just ensure the license on the Python script is suitable for use in generating usably-licensed code. I don't know what licensing models exist for this. > The single bit fields are generated as > > #define TMS570_CRC_CRC_INTR_CH2_TIMEOUTENR BSP_FLD32(12) > > The multibit fields should be generated as > > #define TMS570_CRC_CRC_PCOUNT_REG1_CRC_PAT_COUNT1(val) BSP_FLD32(val,0, 19) > #define TMS570_CRC_CRC_PCOUNT_REG1_CRC_PAT_COUNT1_GET(reg) > BSP_FLD32GET(reg,0, 19) > #define TMS570_CRC_CRC_PCOUNT_REG1_CRC_PAT_COUNT1_SET(reg,val) > BSP_FLD32SET(reg, val,0, 19) > This seems a little verbose. I guess the automatic definitions may be hard to generate, but CRC 3 times in the def name is a lot. > There is now mistake that GET is used once instead of SET in this example. > But that will be corrected. > > It would be great amount of work to prepare complete initialization > sequence from scratch to not touch problematically licensed HalCoGen > files. But when format of header files is agreed upon it is doable. > This is an interesting direction to go. The idea of generating init code (and bootstrap!) from documentation is compelling. > So generally, what is your opinion about the format? > (may be that tools and approach can be reused for other chips as well) > > We plan to shake-up actual RTEMS TMS570 serial port and timers > support to use proposed headers format. Then we start on HalCoGen-free > boot-up process work. So I hope we can have complete self-contained > RTEMS support mainlined one day. > Keep an eye out for development of RTEMS with micromonitor bootloader. This may be a useful tool for generating code in it maybe. > The first step is to finish headers and replace initial sparse > ones in RTEMS mainline by new set. I expect that we include only > header files in RTEMS and JSONs stay in utils repo. But we are open > to other suggestions as well. > > To Martin Galvan: What is your opinion? Would you join the work in > this direction? > > We have no contract for the work so I cannot promise any timing. > Premysl Houdek should to finish main part of the work before > his thesis submission. Which can be in two up to max eight months. > I think if you can get proof-of-concept for generating bootstrap code from documentation, this could be compelling for some users out there to give money to produce non-GPL bootloaders for other boards. Not that I know of any off-hand. > Best wishes, > > Pavel > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Propose to release 4.11 pending drvmgr/pci
I'd like to cut the 4.11 branch as soon as we get the drvmgr/pci patches merged. Please state if you have any other necessary patches or blockers for release. The plan will be to create a 4.11 branch and tag 4.11.0 and then only bug-fixes should go into 4.11 branch, and master becomes the next release branch. Gedare ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: libi2c device probing capability
Alex,
Can you resend with git-send-email? Also, please be sure to use the
same style as the rest of the file, or the RTEMS Style rules
otherwise. In particular, use { on same line as if, and spaces around
().
Other than style, I think this looks ok.
Gedare
On Wed, Apr 1, 2015 at 10:31 AM, Alexandru-Sever Horin
wrote:
> Hello,
>
> I am currently working on a project which uses I2C devices through libi2c
> API.
>
> The problem that I am facing is that this function:
> rtems_libi2c_register_drv actually registeres the device before
> drvtbl->ops->initialization_entry returns success or failure. This means
> that it is impossible to probe a device which might be at 2 different I2C
> addreses on different PCB revisions.
>
> For a device driver with no initialization function it should make no
> difference, the function call being ignored, and the minor being returned.
> If the device driver has a initialization function, it calls it and makes
> sure that the return value is 0 before registering the name. If it returns
> something different than RTEMS_SUCCESS, it makes sure the driver
> registration returns negative error code (so it's not mistaken with minor
> number), and does not register the device driver.
>
> I have attached a patch to solve this problem, and bypass device
> registration in the filesystem if the initialziation fails.
> Please review the changes and merge if you agree.
>
> Thank you,
> Alex H.
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 2/4] timecounter: Port to RTEMS New test: timecounter01
On Wed, Apr 1, 2015 at 10:37 AM, Alexander Krutwig
wrote:
> ---
> cpukit/score/Makefile.am | 10 ++
> cpukit/score/include/rtems/score/timecounter.h | 23 +++
> cpukit/score/include/sys/timeffc.h | 2 +
> cpukit/score/include/sys/timetc.h | 2 +
Adding a new subdirectory here should be considered carefully. It
certainly needs justification.
> cpukit/score/preinstall.am | 25 +++
> cpukit/score/src/kern_tc.c | 171
> -
> testsuites/sptests/sptimecounter01/Makefile.am | 19 +++
> testsuites/sptests/sptimecounter01/init.c | 130
> .../sptests/sptimecounter01/sptimecounter01.doc| 11 ++
> .../sptests/sptimecounter01/sptimecounter01.scn| 0
> 10 files changed, 390 insertions(+), 3 deletions(-)
> create mode 100644 cpukit/score/include/rtems/score/timecounter.h
> create mode 100644 testsuites/sptests/sptimecounter01/Makefile.am
> create mode 100644 testsuites/sptests/sptimecounter01/init.c
> create mode 100644 testsuites/sptests/sptimecounter01/sptimecounter01.doc
> create mode 100644 testsuites/sptests/sptimecounter01/sptimecounter01.scn
>
> diff --git a/cpukit/score/Makefile.am b/cpukit/score/Makefile.am
> index 090f7f6..55fdc99 100644
> --- a/cpukit/score/Makefile.am
> +++ b/cpukit/score/Makefile.am
> @@ -5,6 +5,15 @@ SUBDIRS = cpu
>
> ## include
>
> +include_sysdir = $(includedir)/sys
> +
> +include_sys_HEADERS =
> +include_sys_HEADERS += include/sys/_ffcounter.h
> +include_sys_HEADERS += include/sys/timeffc.h
> +include_sys_HEADERS += include/sys/timepps.h
> +include_sys_HEADERS += include/sys/timetc.h
> +include_sys_HEADERS += include/sys/timex.h
> +
> include_rtemsdir = $(includedir)/rtems
>
> include_rtems_HEADERS = include/rtems/debug.h
> @@ -343,6 +352,7 @@ libscore_a_SOURCES += src/profilingisrentryexit.c
> libscore_a_SOURCES += src/once.c
> libscore_a_SOURCES += src/resourceiterate.c
> libscore_a_SOURCES += src/smpbarrierwait.c
> +libscore_a_SOURCES += src/kern_tc.c
>
> EXTRA_DIST = src/Unlimited.txt
>
> diff --git a/cpukit/score/include/rtems/score/timecounter.h
> b/cpukit/score/include/rtems/score/timecounter.h
> new file mode 100644
> index 000..3744a76
> --- /dev/null
> +++ b/cpukit/score/include/rtems/score/timecounter.h
This file needs doxygen.
> @@ -0,0 +1,23 @@
> +
> +#include
> +
> +void _Timecounter_Initialize(void);
> +
> +void _Timecounter_Set_clock(const struct timespec *ts);
> +
> +void _Timecounter_Ticktock(int cnt);
> +
> +void rtems_bintime(struct bintime *bt);
> +void rtems_nanotime(struct timespec *tsp);
> +void rtems_microtime(struct timeval *tvp);
> +void rtems_binuptime(struct bintime *bt);
> +void rtems_nanouptime(struct timespec *tsp);
> +void rtems_microuptime(struct timeval *tvp);
> +void rtems_getbintime(struct bintime *bt);
> +void rtems_getnanotime(struct timespec *tsp);
> +void rtems_getmicrotime(struct timeval *tvp);
> +void rtems_getbinuptime(struct bintime *bt);
> +void rtems_getnanouptime(struct timespec *tsp);
> +void rtems_getmicrouptime(struct timeval *tvp);
If these are "public-facing" they should be declared somewhere other
than score header file, maybe add timecounter API to the classic
"rtems" api. then this should be more like rtems_timecounter_bintime;
> +
> +
> diff --git a/cpukit/score/include/sys/timeffc.h
> b/cpukit/score/include/sys/timeffc.h
> index 3bda5d4..c3aed67 100644
> --- a/cpukit/score/include/sys/timeffc.h
> +++ b/cpukit/score/include/sys/timeffc.h
> @@ -55,11 +55,13 @@ struct ffclock_estimate {
> #if __BSD_VISIBLE
> #ifdef _KERNEL
>
> +#ifndef __rtems__
> /* Define the kern.sysclock sysctl tree. */
> SYSCTL_DECL(_kern_sysclock);
>
> /* Define the kern.sysclock.ffclock sysctl tree. */
> SYSCTL_DECL(_kern_sysclock_ffclock);
> +#endif /* __rtems__ */
>
> /*
> * Index into the sysclocks array for obtaining the ASCII name of a
> particular
> diff --git a/cpukit/score/include/sys/timetc.h
> b/cpukit/score/include/sys/timetc.h
> index e68e327..1fed542 100644
> --- a/cpukit/score/include/sys/timetc.h
> +++ b/cpukit/score/include/sys/timetc.h
> @@ -12,9 +12,11 @@
> #ifndef _SYS_TIMETC_H_
> #define_SYS_TIMETC_H_
>
> +#ifndef __rtems__
> #ifndef _KERNEL
> #error "no user-serviceable parts inside"
> #endif
> +#endif /* __rtems__ */
>
> /*-
> * `struct timecounter' is the interface between the hardware which
> implements
> diff --git a/cpukit/score/preinstall.am b/cpukit/score/preinstall.am
> index 920c0d9..75c8be6 100644
> --- a/cpukit/score/preinstall.am
> +++ b/cpukit/score/preinstall.am
> @@ -13,6 +13,31 @@ all-am: $(PREINSTALL_FILES)
> PREINSTALL_FILES =
> CLEANFILES = $(PREINSTALL_FILES)
>
> +$(PROJECT_INCLUDE)/sys/$(dirstamp):
> + @$(MKDIR_P) $(PROJECT_INCLUDE)/sys
> + @: > $(PROJECT_INCLUDE)/sys/$(dirstamp)
> +PREINSTALL_DIRS += $(PROJECT_INCLUDE)/sys/$(dirstamp)
> +
> +$(PROJECT_INCLUDE)/sys/_ffcounter.h
Re: [PATCH 3/4] new rtems environment with the implementation of FreeBSD timecounters; modifications of certain tests in the testsuite New test: timecounter02
I didn't read much of this, but it needs doxygen, and probably part of the previous patch should be merged in here, or some better splitting/recombining of patches so I don't have to review code that gets fixed. It's worth repeating, the "rtems_*time" functions are not following the API conventions of rtems_package_method, it should be rtems_timecounter_*time like rtems_timecounter_bintime. Please use a short git-commit message for the first line, and longer git commit message after a blank line. This will avoid really long lines in git log, and long subjects in git-send-email. I guess this advice is in the Git page (https://devel.rtems.org/wiki/Developer/Git). Gedare On Wed, Apr 1, 2015 at 10:37 AM, Alexander Krutwig wrote: > --- > cpukit/libnetworking/rtems/rtems_bsdnet_internal.h | 3 +- > cpukit/libnetworking/rtems/rtems_glue.c| 4 - > cpukit/posix/src/clockgettime.c| 3 +- > cpukit/posix/src/posixtimespecabsolutetimeout.c| 2 +- > cpukit/posix/src/timergettime.c| 2 +- > cpukit/posix/src/timersettime.c| 4 +- > cpukit/posix/src/timertsr.c| 2 +- > cpukit/rtems/Makefile.am | 1 - > cpukit/rtems/include/rtems/rtems/clock.h | 25 -- > cpukit/rtems/src/clockgetuptimenanoseconds.c | 9 +- > cpukit/rtems/src/clockgetuptimeseconds.c | 6 +- > cpukit/rtems/src/clocksetnsecshandler.c| 34 -- > cpukit/sapi/Makefile.am| 1 + > cpukit/sapi/include/rtems/timecounter.h| 89 + > cpukit/sapi/preinstall.am | 4 + > cpukit/sapi/src/exinit.c | 3 + > cpukit/score/Makefile.am | 18 +- > cpukit/score/include/rtems/score/timecounter.h | 59 +++- > cpukit/score/include/rtems/score/timecounterimpl.h | 119 +++ > cpukit/score/include/rtems/score/timestamp.h | 267 --- > cpukit/score/include/rtems/score/timestamp64.h | 379 > - > cpukit/score/include/rtems/score/tod.h | 9 - > cpukit/score/include/rtems/score/todimpl.h | 101 ++ > cpukit/score/preinstall.am | 10 +- > cpukit/score/src/coretod.c | 18 +- > cpukit/score/src/coretodadjust.c | 9 +- > cpukit/score/src/coretodget.c | 46 --- > cpukit/score/src/coretodgetuptimetimespec.c| 32 -- > cpukit/score/src/coretodsecondssinceepoch.c| 32 -- > cpukit/score/src/coretodset.c | 10 +- > cpukit/score/src/coretodtickle.c | 22 +- > cpukit/score/src/tcgetscalerandmask.c | 40 +++ > cpukit/score/src/ts64addto.c | 31 -- > cpukit/score/src/ts64divide.c | 51 --- > cpukit/score/src/ts64equalto.c | 31 -- > cpukit/score/src/ts64getnanoseconds.c | 30 -- > cpukit/score/src/ts64getseconds.c | 30 -- > cpukit/score/src/ts64lessthan.c| 31 -- > cpukit/score/src/ts64set.c | 33 -- > cpukit/score/src/ts64settozero.c | 31 -- > cpukit/score/src/ts64subtract.c| 31 -- > cpukit/score/src/ts64totimespec.c | 32 -- > cpukit/score/src/ts64totimeval.c | 37 -- > testsuites/sptests/Makefile.am | 2 + > testsuites/sptests/configure.ac| 2 + > testsuites/sptests/spclock_err01/init.c| 8 - > testsuites/sptests/spsize/size.c | 3 - > testsuites/sptests/sptimecounter02/Makefile.am | 19 ++ > testsuites/sptests/sptimecounter02/init.c | 266 +++ > .../sptests/sptimecounter02/sptimecounter02.doc| 11 + > .../sptests/sptimecounter02/sptimecounter02.scn| 0 > 51 files changed, 818 insertions(+), 1224 deletions(-) > delete mode 100644 cpukit/rtems/src/clocksetnsecshandler.c > create mode 100644 cpukit/sapi/include/rtems/timecounter.h > create mode 100644 cpukit/score/include/rtems/score/timecounterimpl.h > delete mode 100644 cpukit/score/include/rtems/score/timestamp64.h > delete mode 100644 cpukit/score/src/coretodget.c > delete mode 100644 cpukit/score/src/coretodgetuptimetimespec.c > delete mode 100644 cpukit/score/src/coretodsecondssinceepoch.c > create mode 100644 cpukit/score/src/tcgetscalerandmask.c > delete mode 100644 cpukit/score/src/ts64addto.c > delete mode 100644 cpukit/score/src/ts64divide.c > delete mode 100644 cpukit/score/src/ts64equalto.c > delete mode 100644 cpukit/score/src/ts64getnanoseconds.c > delete mode 100644 cpukit/score/src/ts64getseconds.c > delete mode 100644 cpukit/score/src/ts64lessthan.c > delete mode 100644 cpukit/score/src/ts64set.c > delete mode 100644 cpukit/score/src/ts64set
Re: [PATCH 4/4] bsp clock configs
This patch could use some more explanation, and probably some
documentation in the BSP guide. Why is erc32 being changed, for what
purpose?
On Wed, Apr 1, 2015 at 10:37 AM, Alexander Krutwig
wrote:
> ---
> c/src/lib/libbsp/shared/clockdrv_shell.h| 31 -
> c/src/lib/libbsp/sparc/erc32/clock/ckinit.c | 54
> +++--
> 2 files changed, 66 insertions(+), 19 deletions(-)
>
> diff --git a/c/src/lib/libbsp/shared/clockdrv_shell.h
> b/c/src/lib/libbsp/shared/clockdrv_shell.h
> index 5dbea13..cf3237d 100644
> --- a/c/src/lib/libbsp/shared/clockdrv_shell.h
> +++ b/c/src/lib/libbsp/shared/clockdrv_shell.h
> @@ -20,6 +20,10 @@
> #include
> #include
>
> +#ifdef Clock_driver_nanoseconds_since_last_tick
> +#error "adjust your clock driver"
Please make error message more informative. I have no idea what it
should be adjusted to.
> +#endif
> +
> /**
> * @defgroup bsp_clock Clock Support
> *
> @@ -39,6 +43,14 @@
>#define Clock_driver_support_find_timer()
> #endif
>
> +/*
> + * A specialized clock driver may use for example _Timecounter_Tick_simple()
> + * instead of the default.
> + */
> +#ifndef Clock_driver_timecounter_tick
> + Clock_driver_timecounter_tick() _Timecounter_Tick()
> +#endif
> +
> /**
> * @brief ISRs until next clock tick
> */
> @@ -53,6 +65,12 @@ volatile uint32_tClock_driver_ticks;
>
> void Clock_exit( void );
>
> +static void Clock_tick( void )
> +{
> + Clock_driver_timecounter_tick();
> + rtems_clock_tick();
> +}
> +
> /**
> * @brief Clock_isr
> *
> @@ -79,7 +97,7 @@ rtems_isr Clock_isr(
>
>#if CLOCK_DRIVER_USE_FAST_IDLE
> do {
> - rtems_clock_tick();
> + Clock_tick();
> } while (
>_Thread_Heir == _Thread_Executing
> && _Thread_Executing->Start.entry_point
> @@ -101,7 +119,7 @@ rtems_isr Clock_isr(
> * The driver is multiple ISRs per clock tick.
> */
>if ( !Clock_driver_isrs ) {
> -rtems_clock_tick();
> +Clock_tick();
>
> Clock_driver_isrs = CLOCK_DRIVER_ISRS_PER_TICK;
>}
> @@ -110,7 +128,7 @@ rtems_isr Clock_isr(
>/*
> * The driver is one ISR per clock tick.
> */
> - rtems_clock_tick();
> + Clock_tick();
> #endif
>#endif
> }
> @@ -149,6 +167,7 @@ rtems_device_driver Clock_initialize(
>
>Clock_driver_ticks = 0;
>
> +
>/*
> * Find timer -- some BSPs search buses for hardware timer
> */
> @@ -160,12 +179,6 @@ rtems_device_driver Clock_initialize(
>(void) Old_ticker;
>Clock_driver_support_install_isr( Clock_isr, Old_ticker );
>
> - #if defined(Clock_driver_nanoseconds_since_last_tick)
> -rtems_clock_set_nanoseconds_extension(
> - Clock_driver_nanoseconds_since_last_tick
> -);
> - #endif
> -
>/*
> * Now initialize the hardware that is the source of the tick ISR.
> */
> diff --git a/c/src/lib/libbsp/sparc/erc32/clock/ckinit.c
> b/c/src/lib/libbsp/sparc/erc32/clock/ckinit.c
> index 2afe770..1fb186c 100644
> --- a/c/src/lib/libbsp/sparc/erc32/clock/ckinit.c
> +++ b/c/src/lib/libbsp/sparc/erc32/clock/ckinit.c
> @@ -25,6 +25,7 @@
> #include
> #include
> #include
> +#include
>
> #if SIMSPARC_FAST_IDLE==1
> #define CLOCK_DRIVER_USE_FAST_IDLE 1
> @@ -44,25 +45,33 @@
>
> extern int CLOCK_SPEED;
>
> -static uint32_t bsp_clock_nanoseconds_since_last_tick(void)
> +static struct timecounter erc32_tc;
> +
> +static uint64_t erc32_tc_scaler;
> +
> +static uint32_t erc32_tc_interval;
> +
> +static uint32_t erc32_tc_current(void)
> +{
> + return (ERC32_MEC.Real_Time_Clock_Counter * erc32_tc_scaler) >> 32;
> +}
> +
> +static u_int erc32_get_timecount(struct timecounter *tc)
> {
>uint32_t clicks;
> - uint32_t usecs;
> + uint32_t interval;
>
> - clicks = ERC32_MEC.Real_Time_Clock_Counter;
> + interval = erc32_tc_interval;
> + clicks = erc32_tc_current();
>
>if ( ERC32_Is_interrupt_pending( ERC32_INTERRUPT_REAL_TIME_CLOCK ) ) {
> -clicks = ERC32_MEC.Real_Time_Clock_Counter;
> -usecs = (2*rtems_configuration_get_microseconds_per_tick() - clicks);
> +clicks = erc32_tc_current();
> +return (2 * interval - clicks);
>} else {
> -usecs = (rtems_configuration_get_microseconds_per_tick() - clicks);
> +return (interval - clicks);
>}
> - return usecs * 1000;
> }
>
> -#define Clock_driver_nanoseconds_since_last_tick \
> - bsp_clock_nanoseconds_since_last_tick
> -
> static CPU_Counter_ticks erc32_counter_difference(
>CPU_Counter_ticks second,
>CPU_Counter_ticks first
> @@ -75,6 +84,7 @@ static CPU_Counter_ticks erc32_counter_difference(
>
> #define Clock_driver_support_initialize_hardware() \
>do { \
> +uint32_t mask; \
> /* approximately 1 us per countdown */ \
> ERC32_MEC.Real_Time_Clock_Scalar = CLOCK_SPEED - 1; \
> ERC32_MEC.Real_Time_Clock_Counter = \
> @@ -89,7 +99,18 @@ static CPU_Counter_ticks erc32_counter_difference(
> ERC32_MEC_Set_Real_Time_Clock_Timer_Contr
Re: Propose to release 4.11 pending drvmgr/pci
Daniel, On Wed, Apr 1, 2015 at 11:02 AM, Daniel Hellstrom wrote: > On 04/01/2015 04:40 PM, Gedare Bloom wrote: >> >> I'd like to cut the 4.11 branch as soon as we get the drvmgr/pci >> patches merged. Please state if you have any other necessary patches >> or blockers for release. The plan will be to create a 4.11 branch and >> tag 4.11.0 and then only bug-fixes should go into 4.11 branch, and >> master becomes the next release branch. >> >> Gedare > > > I hope that this includes the drivers that depends on the libpci/drvmgr too? > Otherwise I have no patches pending. > > Danielh Yes, I'd like for you to push the patches you have posted, and if you have fixes yet to push those, otherwise we will post fixes to both the 4.11 and new release series for drvmgr. We'll treat it as "sparc-specific" code for now despite that it is in cpukit, with the long-term goal to get a testing framework up and get it usable across architectures. Gedare ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] libi2c allowed to probe on device init libi2c registration of a device fails if the device initialization fails Benefits: allows for device probing on multiple addreses
Two line length/break issues, and I think we're set!
On Wed, Apr 1, 2015 at 11:18 AM, Alexandru-Sever Horin
wrote:
> From: Alexandru-Sever Horin
>
> ---
> cpukit/libi2c/libi2c.c | 21 +
> 1 file changed, 13 insertions(+), 8 deletions(-)
>
> diff --git a/cpukit/libi2c/libi2c.c b/cpukit/libi2c/libi2c.c
> index 233cb68..43daa86 100644
> --- a/cpukit/libi2c/libi2c.c
> +++ b/cpukit/libi2c/libi2c.c
> @@ -736,6 +736,17 @@ rtems_libi2c_register_drv (const char *name,
> rtems_libi2c_drv_t * drvtbl,
>/* found a free slot; encode slot + 1 ! */
>minor = ((i + 1) << 13) | RTEMS_LIBI2C_MAKE_MINOR (busno, i2caddr);
>
> + /* before registering, try to initialize the device to check it's
> there */
> + if (drvtbl->ops->initialization_entry) {
> +err = drvtbl->ops->initialization_entry (rtems_libi2c_major,
> + minor, 0);
This could be squeezed to fit in 80 characters on one line. like:
err = drvtbl->ops->initialization_entry(rtems_libi2c_major, minor, 0);
> +if (err) {
> + LIBUNLOCK ();
> + /* make sure the returned value is negative, not to mistake it for
> minor number */
Break up this comment or shorten it to < 80 characters on the line.
> + return err < 0 ? err : -err;
> +}
> + }
> +
>if (name) {
> size_t length = strlen (busses[busno].name) + strlen (name) + 2;
> str = malloc (length);
> @@ -761,17 +772,11 @@ rtems_libi2c_register_drv (const char *name,
> rtems_libi2c_drv_t * drvtbl,
>
>drvs[i].drv = drvtbl;
>
> - if (drvtbl->ops->initialization_entry)
> -err =
> - drvs[i].drv->ops->initialization_entry (rtems_libi2c_major, minor,
> - 0);
> - else
> -err = RTEMS_SUCCESSFUL;
> -
>LIBUNLOCK ();
> - return err ? -err : minor;
> + return minor;
> }
>}
> +
>LIBUNLOCK ();
>return -RTEMS_TOO_MANY;
> }
> --
> 2.3.5
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: Propose to release 4.11 pending drvmgr/pci
On Wed, Apr 1, 2015 at 11:25 AM, Joel Sherrill wrote: > > > On April 1, 2015 10:14:48 AM CDT, Daniel Hellstrom wrote: >>On 04/01/2015 05:05 PM, Gedare Bloom wrote: >>> Daniel, >>> >>> On Wed, Apr 1, 2015 at 11:02 AM, Daniel Hellstrom >> wrote: >>>> On 04/01/2015 04:40 PM, Gedare Bloom wrote: >>>>> I'd like to cut the 4.11 branch as soon as we get the drvmgr/pci >>>>> patches merged. Please state if you have any other necessary >>patches >>>>> or blockers for release. The plan will be to create a 4.11 branch >>and >>>>> tag 4.11.0 and then only bug-fixes should go into 4.11 branch, and >>>>> master becomes the next release branch. >>>>> >>>>> Gedare >>>> >>>> I hope that this includes the drivers that depends on the >>libpci/drvmgr too? >>>> Otherwise I have no patches pending. >>>> >>>> Danielh >>> Yes, I'd like for you to push the patches you have posted, and if you >>> have fixes yet to push those, otherwise we will post fixes to both >>the >>> 4.11 and new release series for drvmgr. We'll treat it as >>> "sparc-specific" code for now despite that it is in cpukit, with the >>> long-term goal to get a testing framework up and get it usable across >>> architectures. >>> >>> Gedare >> >>Ok. Then I will finish up the clean-up work I started and I will also >>make the libdrvmgr sparc specific since the libpci already is. After >>that I will push it to master. Then I will continue with the >>clean-ups and submit them to the list and we will see how/when that is >>included. > > Is there any user documentation at this point? I don't know what if any would > eventually be part of the BSP Guide. > > Just adding it to the testing task. > There is I believe a new texinfo for pci and a separate docbook for drvmgr IIRC. >>Danielh >>___ >>devel mailing list >>devel@rtems.org >>http://lists.rtems.org/mailman/listinfo/devel > > --joel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 3/4] new rtems environment with the implementation of FreeBSD timecounters; modifications of certain tests in the testsuite New test: timecounter02
On Wed, Apr 1, 2015 at 11:58 AM, Joel Sherrill wrote: > > > On 4/1/2015 10:01 AM, Gedare Bloom wrote: >> I didn't read much of this, but it needs doxygen, and probably part of >> the previous patch should be merged in here, or some better >> splitting/recombining of patches so I don't have to review code that >> gets fixed. It's worth repeating, the "rtems_*time" functions are not >> following the API conventions of rtems_package_method, it should be >> rtems_timecounter_*time like rtems_timecounter_bintime. >> >> Please use a short git-commit message for the first line, and longer >> git commit message after a blank line. This will avoid really long >> lines in git log, and long subjects in git-send-email. I guess this >> advice is in the Git page >> (https://devel.rtems.org/wiki/Developer/Git). > It is already combined so I am not going to complain but I see a method > renamed > in here (_TOD_Get). Personally I like a series of small patches and that > is an > example of something that could have been done independently. Remember > smaller patches are easier for everyone to review. It is often hard to > think that > way as you are working and knees deep in it, but it is important. > > Add an _ after _Timecount_Get and rtems_get_ in various API methods. But the > rtems_get methods are (as Gedare pointed out) named incorrectly per the > RTEMS API naming patterns. > The _ after get may not be needed if there is a reason such as wanting to be close to an upstream interface. > rtems_ methods should not be in the score. By convention, they should be in > the rtems_ directory. > > I think I see some tabs in the files particularly the test code. Check > all code for > tabs. They shouldn't be used in source files. > > Tests usually have a comment marking the beginning and end of the > configuration > section. Just check another test for the convention. > > I agree with Gedare that a lot of Doxygen is missing. File headers and > group annotation > appear to be largely missing in addition to methods not having any > documentation. > >> Gedare >> >> >> On Wed, Apr 1, 2015 at 10:37 AM, Alexander Krutwig >> wrote: >>> --- >>> cpukit/libnetworking/rtems/rtems_bsdnet_internal.h | 3 +- >>> cpukit/libnetworking/rtems/rtems_glue.c| 4 - >>> cpukit/posix/src/clockgettime.c| 3 +- >>> cpukit/posix/src/posixtimespecabsolutetimeout.c| 2 +- >>> cpukit/posix/src/timergettime.c| 2 +- >>> cpukit/posix/src/timersettime.c| 4 +- >>> cpukit/posix/src/timertsr.c| 2 +- >>> cpukit/rtems/Makefile.am | 1 - >>> cpukit/rtems/include/rtems/rtems/clock.h | 25 -- >>> cpukit/rtems/src/clockgetuptimenanoseconds.c | 9 +- >>> cpukit/rtems/src/clockgetuptimeseconds.c | 6 +- >>> cpukit/rtems/src/clocksetnsecshandler.c| 34 -- >>> cpukit/sapi/Makefile.am| 1 + >>> cpukit/sapi/include/rtems/timecounter.h| 89 + >>> cpukit/sapi/preinstall.am | 4 + >>> cpukit/sapi/src/exinit.c | 3 + >>> cpukit/score/Makefile.am | 18 +- >>> cpukit/score/include/rtems/score/timecounter.h | 59 +++- >>> cpukit/score/include/rtems/score/timecounterimpl.h | 119 +++ >>> cpukit/score/include/rtems/score/timestamp.h | 267 --- >>> cpukit/score/include/rtems/score/timestamp64.h | 379 >>> - >>> cpukit/score/include/rtems/score/tod.h | 9 - >>> cpukit/score/include/rtems/score/todimpl.h | 101 ++ >>> cpukit/score/preinstall.am | 10 +- >>> cpukit/score/src/coretod.c | 18 +- >>> cpukit/score/src/coretodadjust.c | 9 +- >>> cpukit/score/src/coretodget.c | 46 --- >>> cpukit/score/src/coretodgetuptimetimespec.c| 32 -- >>> cpukit/score/src/coretodsecondssinceepoch.c| 32 -- >>> cpukit/score/src/coretodset.c | 10 +- >>> cpukit/score/src/coretodtickle.c | 22 +- >>> cpukit/score/src/tcgetscalerandmask.c | 40 +++ >>> cpukit/score/src/ts64addto.c | 31 -- >>> cpukit/score/src/ts64divide.c | 51 --- >>> cpukit/score/sr
Re: Propose to release 4.11 pending drvmgr/pci
Thanks Sebastian, I saw your comment about holding a patch back and figured we better push this release to avoid a large backlog. I think we can expect to cut the branch next week, after DanielH gets a chance to push his drvmgr and pci code. On Wed, Apr 1, 2015 at 11:51 AM, Sebastian Huber wrote: > I hold back new stuff like > > - fine grained locking for semaphores and message queues, > - FreeBSD timecounters, > - watchdog SMP improvements, and > - SPARC FPU context switch improvments. > > I am really looking forward to working with the new build system. > > - Gedare Bloom schrieb: >> I'd like to cut the 4.11 branch as soon as we get the drvmgr/pci >> patches merged. Please state if you have any other necessary patches >> or blockers for release. The plan will be to create a 4.11 branch and >> tag 4.11.0 and then only bug-fixes should go into 4.11 branch, and >> master becomes the next release branch. >> >> Gedare >> ___ >> devel mailing list >> devel@rtems.org >> http://lists.rtems.org/mailman/listinfo/devel > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] libi2c allowed to probe on device init libi2c registration of a device fails if the device initialization fails Benefits: allows for device probing on multiple addreses
OK, sorry to nitpick, but could you do one more favor and split the
commit message up into a short one-liner and longer text separated by
a blank line, like:
---
cpukit/libi2c allowed to probe on device init
libi2c registration of a device fails if the device initialization fails
Benefits: allows for device probing on multiple addresses
---
then I'll merge I promise. :)
On Wed, Apr 1, 2015 at 11:41 AM, Alexandru-Sever Horin
wrote:
> From: Alexandru-Sever Horin
>
> ---
> cpukit/libi2c/libi2c.c | 27 ---
> 1 file changed, 16 insertions(+), 11 deletions(-)
>
> diff --git a/cpukit/libi2c/libi2c.c b/cpukit/libi2c/libi2c.c
> index 233cb68..315a761 100644
> --- a/cpukit/libi2c/libi2c.c
> +++ b/cpukit/libi2c/libi2c.c
> @@ -736,6 +736,16 @@ rtems_libi2c_register_drv (const char *name,
> rtems_libi2c_drv_t * drvtbl,
>/* found a free slot; encode slot + 1 ! */
>minor = ((i + 1) << 13) | RTEMS_LIBI2C_MAKE_MINOR (busno, i2caddr);
>
> + /* before registering, try to initialize the device to check it's
> there */
> + if (drvtbl->ops->initialization_entry) {
> +err = drvtbl->ops->initialization_entry (rtems_libi2c_major, minor,
> 0);
> +if (err) {
> + LIBUNLOCK ();
> + /* returned value must be negative on failure */
> + return err < 0 ? err : -err;
> +}
> + }
> +
>if (name) {
> size_t length = strlen (busses[busno].name) + strlen (name) + 2;
> str = malloc (length);
> @@ -751,9 +761,10 @@ rtems_libi2c_register_drv (const char *name,
> rtems_libi2c_drv_t * drvtbl,
>
> /* note that 'umask' is applied to 'mode' */
> if (mknod (str, mode, dev)) {
> - safe_printf( DRVNM
> - "Creating device node failed: %s; you can try to do it
> manually...\n",
> - strerror (errno));
> + safe_printf ( DRVNM
> +"Creating device node failed: %s;\n"
> +"you can try to do it manually...\n",
> +strerror (errno));
> }
>
> free (str);
> @@ -761,17 +772,11 @@ rtems_libi2c_register_drv (const char *name,
> rtems_libi2c_drv_t * drvtbl,
>
>drvs[i].drv = drvtbl;
>
> - if (drvtbl->ops->initialization_entry)
> -err =
> - drvs[i].drv->ops->initialization_entry (rtems_libi2c_major, minor,
> - 0);
> - else
> -err = RTEMS_SUCCESSFUL;
> -
>LIBUNLOCK ();
> - return err ? -err : minor;
> + return minor;
> }
>}
> +
>LIBUNLOCK ();
>return -RTEMS_TOO_MANY;
> }
> --
> 2.3.5
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: Uptime difference between FreeBSD and RTEMS
On Wed, Apr 1, 2015 at 2:42 PM, Sebastian Huber wrote: > > - Joel Sherrill schrieb: >> >> >> On 4/1/2015 9:18 AM, Gedare Bloom wrote: >> > Would you then subtract 1 from uptime when reporting it? Or would >> > users be expected to know that uptime is off-by-1? >> I would prefer we subtract one when reporting to the user. > > The question is reporting via which API. We have the RTEMS and POSIX APIs > and the FreeBSD kernel APIs. So the consensus is to report uptimes relative > to zero for the RTEMS and POSIX APIs and relative to one second for the > FreeBSD kernel APIs? > Yes I think so. We don't really want to change the expected behavior of existing APIs just to comply with FreeBSDs. >> > On Wed, Apr 1, 2015 at 4:07 AM, Alexander Krutwig >> > wrote: >> >> Hello, >> >> >> >> during my work with FreeBSD timecounters, I found out that the FreeBSD >> >> timecounters start with an uptime value of 1 second. Developers of FreeBSD >> >> told me that this is due to problems in the ARP code. >> >> RTEMS uptime is initialized to an uptime value to 0 seconds. >> >> Are there any problems if the configuration of the RTEMS uptime is also >> >> initialized to 1 second for synchonization? Else, we would have different >> >> values for different API functions which is the second option. >> >> >> >> Best regards, >> >> Alexander Krutwig >> >> >> >> -- >> >> >> >> embedded brains GmbH >> >> Alexander Krutwig >> >> Dornierstr. 4 >> >> D-82178 Puchheim >> >> Germany >> >> email: alexander.krut...@embedded-brains.de >> >> Phone: +49-89-18 94 741 - 17 >> >> Fax: +49-89-18 94 741 - 09 >> >> PGP: Public key available on request. >> >> >> >> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. >> >> >> >> ___ >> >> devel mailing list >> >> devel@rtems.org >> >> http://lists.rtems.org/mailman/listinfo/devel >> > ___ >> > users mailing list >> > us...@rtems.org >> > http://lists.rtems.org/mailman/listinfo/users >> >> -- >> 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 >> >> ___ >> devel mailing list >> devel@rtems.org >> http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 3/4] new rtems environment with the implementation of FreeBSD timecounters; modifications of certain tests in the testsuite New test: timecounter02
On Wed, Apr 1, 2015 at 2:54 PM, Sebastian Huber wrote: > > - Gedare Bloom schrieb: >> On Wed, Apr 1, 2015 at 11:58 AM, Joel Sherrill >> wrote: >> > >> > >> > On 4/1/2015 10:01 AM, Gedare Bloom wrote: >> >> I didn't read much of this, but it needs doxygen, and probably part of >> >> the previous patch should be merged in here, or some better >> >> splitting/recombining of patches so I don't have to review code that >> >> gets fixed. It's worth repeating, the "rtems_*time" functions are not >> >> following the API conventions of rtems_package_method, it should be >> >> rtems_timecounter_*time like rtems_timecounter_bintime. >> >> >> >> Please use a short git-commit message for the first line, and longer >> >> git commit message after a blank line. This will avoid really long >> >> lines in git log, and long subjects in git-send-email. I guess this >> >> advice is in the Git page >> >> (https://devel.rtems.org/wiki/Developer/Git). >> > It is already combined so I am not going to complain but I see a method >> > renamed >> > in here (_TOD_Get). Personally I like a series of small patches and that >> > is an >> > example of something that could have been done independently. Remember >> > smaller patches are easier for everyone to review. It is often hard to >> > think that >> > way as you are working and knees deep in it, but it is important. >> > >> > Add an _ after _Timecount_Get and rtems_get_ in various API methods. But >> > the >> > rtems_get methods are (as Gedare pointed out) named incorrectly per the >> > RTEMS API naming patterns. >> > >> The _ after get may not be needed if there is a reason such as wanting >> to be close to an upstream interface. > > The names are derived from the FreeBSD kernel space API, e.g. > bintime() -> rtems_bintime(). These functions have per se nothing to do with > timecounters. The timecounters are just one way to implement this API. So > maybe the header file is wrongly named, what about > ? > Do you prefer to nest it under rtems/sys/time.h? I'd worry about a clash some day in the header names otherwise. (I'm also not sure what the status of the includes will be after the source code reorg, but one problem at a time.) Should we consider making the "namespace" somehow point back to the bsd/freebsd instead? Rather than come up with a useful namespace for every function we mimic from the bsd kernel, something like: rtems_bsd_bintime() makes sense to me. > The driver interface function is _Timecounter_Install(). Should we provide a > rtems_timecounter_install()? If the function is expected to be called from user code, then yes. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] [RPI BSP] mailbox
On Mon, Apr 6, 2015 at 5:12 PM, QIAO YANG wrote:
> -
>
> diff --git a/c/src/lib/libbsp/arm/raspberrypi/Makefile.am
> b/c/src/lib/libbsp/arm/raspberrypi/Makefile.am
> index c6133df..70bc01d 100644
> --- a/c/src/lib/libbsp/arm/raspberrypi/Makefile.am
> +++ b/c/src/lib/libbsp/arm/raspberrypi/Makefile.am
> @@ -43,6 +43,7 @@ include_bsp_HEADERS += ../shared/include/arm-release-id.h
> include_bsp_HEADERS += include/irq.h
> include_bsp_HEADERS += include/mmu.h
> include_bsp_HEADERS += include/usart.h
> +include_bsp_HEADERS += include/mailbox.h
> include_bsp_HEADERS += include/raspberrypi.h
>
> include_libcpu_HEADERS = ../../../libcpu/arm/shared/include/cache_.h \
> @@ -123,6 +124,9 @@ libbsp_a_SOURCES += misc/timer.c
>
> # I2C
>
> +# Mailbox
> +libbsp_a_SOURCES += misc/mailbox.c
> +
> # Cache
> libbsp_a_SOURCES += ../../../libcpu/shared/src/cache_manager.c
> libbsp_a_SOURCES += ../../../libcpu/arm/shared/include/cache_.h
> diff --git a/c/src/lib/libbsp/arm/raspberrypi/include/mailbox.h
> b/c/src/lib/libbsp/arm/raspberrypi/include/mailbox.h
> new file mode 100644
> index 000..abdb258
> --- /dev/null
> +++ b/c/src/lib/libbsp/arm/raspberrypi/include/mailbox.h
> @@ -0,0 +1,7 @@
Need file header documentation. Please see
https://devel.rtems.org/wiki/Developer/Coding/Conventions
> +#ifndef MAILBOX_H
> +#define MAILBOX_H
> +
> +extern unsigned int readmailbox(unsigned int channel);
> +extern void writemailbox(unsigned int channel, unsigned int data);
> +
Please use function names with a "namespace". the usual convention in
RTEMS is to use Package_Class_Method like raspberrypi_mailbox_read()
and raspberrypi_mailbox_write().
> +#endif /* MAILBOX_H */
> \ No newline at end of file
> diff --git a/c/src/lib/libbsp/arm/raspberrypi/include/raspberrypi.h
> b/c/src/lib/libbsp/arm/raspberrypi/include/raspberrypi.h
> index c33e22a..e4ce18f 100644
> --- a/c/src/lib/libbsp/arm/raspberrypi/include/raspberrypi.h
> +++ b/c/src/lib/libbsp/arm/raspberrypi/include/raspberrypi.h
> @@ -208,6 +208,52 @@
>
> /** @} */
>
> + /**
> + * @name Mailbox Registers
> + *
> + * @{
> + */
> +
> +/**
> + * NOTE:
> + */
> +#define BCM2835_MBOX_BASE (RPI_PERIPHERAL_BASE+0xB880)
> +
> +#define BCM2835_MBOX_PEEK (BCM2835_MBOX_BASE+0x10)
> +#define BCM2835_MBOX_READ (BCM2835_MBOX_BASE+0x00)
> +#define BCM2835_MBOX_WRITE (BCM2835_MBOX_BASE+0x20)
> +#define BCM2835_MBOX_STATUS (BCM2835_MBOX_BASE+0x18)
> +#define BCM2835_MBOX_SENDER (BCM2835_MBOX_BASE+0x14)
> +#define BCM2835_MBOX_CONFIG (BCM2835_MBOX_BASE+0x1C)
> +
> +/* Power Manager channel */
> +#define BCM2835_MBOX_CHANNEL_PM0
> +/* Framebuffer channel */
> +#define BCM2835_MBOX_CHANNEL_FB1
> + /* Virtual UART channel */
> +#define BCM2835_MBOX_CHANNEL_VUART 2
> + /* VCHIQ channel */
> +#define BCM2835_MBOX_CHANNEL_VCHIQ 3
> + /* LEDs channel */
> +#define BCM2835_MBOX_CHANNEL_LED 4
> + /* Button channel */
> +#define BCM2835_MBOX_CHANNEL_BUTTON5
> + /* Touch screen channel */
> +#define BCM2835_MBOX_CHANNEL_TOUCHS6
> +/* Property tags (ARM <-> Video Core) channel */
> +#define BCM2835_MBOX_CHANNEL_PROP_AVC 8
> + /* Property tags (Video Core <-> ARM) channel */
> +#define BCM2835_MBOX_CHANNEL_PROP_VCA 9
> +
> +#define BCM2835_MBOX_SUCCESS (BCM2835_MBOX_BASE+0x8000)
> +
> +#define BCM2835_MBOX_FULL (BCM2835_MBOX_BASE+0x8000)
> +#define BCM2835_MBOX_EMPTY (BCM2835_MBOX_BASE+0x4000)
> +
> +
> +
> +/** @} */
> +
>
> /** @} */
>
> diff --git a/c/src/lib/libbsp/arm/raspberrypi/misc/mailbox.c
> b/c/src/lib/libbsp/arm/raspberrypi/misc/mailbox.c
> new file mode 100644
> index 000..7bfb7e3
> --- /dev/null
> +++ b/c/src/lib/libbsp/arm/raspberrypi/misc/mailbox.c
> @@ -0,0 +1,22 @@
Need file header documentation
> +#include
> +#include
> +#include
> +unsigned int readmailbox ( unsigned int channel )
> +{
> + unsigned int data;
> + unsigned int read_channel;
> +
> + while ( 1 )
> + {
> + while ( BCM2835_REG ( BCM2835_MBOX_STATUS ) &
> BCM2835_MBOX_EMPTY );
> + data = BCM2835_REG ( BCM2835_MBOX_READ );
> + read_channel = ( unsigned int ) ( data & 0xF );
> + if ( read_channel == channel )
> + return ( data & 0xFFF0 );
> + }
The white spaces look wrong here. Are they tabs? Or 8 blank spaces?
Please check the style rules in the Coding Conventions page.
> +}
> +void writemailbox( unsigned int channel, unsigned int data )
> +{
> + while ( BCM2835_REG ( BCM2835_MBOX_STATUS ) & BCM2835_MBOX_FULL );
> + BCM2835_REG (BCM2835_MBOX_WRITE) = ( data & 0xFFF0 ) | (unsigned
> int) ( channel & 0xF );
> +}
> \ No newline at end of file
> diff --git a/c/src/lib/libbsp/arm/raspberrypi/preinstall.am
> b/c/src/lib/libbsp/arm/raspberrypi/preinstall.am
> index 70259e2..4cb7ed6 100644
> --- a/c/src/lib/libbsp/arm/raspberrypi/preinstall.am
> +++ b/c/src/lib/libbsp/arm/raspberrypi/preinstall.am
Re: RTEMS libbsd port: how to link the driver
On Tue, Apr 7, 2015 at 4:46 AM, ragu nath wrote:
> Thanks for your help. I added the driver in the nexus-devices.h and it
> was working. I was missing the header file default-network-init.h in
> my application. Now I am able to link the driver to the application.
>
Documentation patches welcomed. :)
> Regards,
> Ragunath
>
>
> On Tue, Apr 7, 2015 at 10:55 AM, Sebastian Huber
> wrote:
>> Hello,
>>
>> do you refer to the new network stack (https://git.rtems.org/rtems-libbsd)?
>> There is documentation in the file 'libbsd.txt', but I have to admit its
>> poorly documented, mainly due to lack of time and budget. For the driver
>> registration see the file nexus-devices.h and the tests.
>>
>>
>> On 06/04/15 21:12, ragu nath wrote:
>>>
>>> Hi,
>>>
>>> What is the procedure to link a network driver to the application in
>>> rtems libbsd port? The drivers are compiled and available in the
>>> libbsd archive. I dont know how to link the driver to the application.
>>>
>>> I followed the RTEMS NETWORKING supplement document and tried defining
>>> the following structures. But it did not work
>>>
>>> static struct rtems_bsdnet_ifconfig netdriver_config = {
>>> RTEMS_BSP_NETWORK_DRIVER_NAME,
>>> RTEMS_BSP_NETWORK_DRIVER_ATTACH
>>> };
>>> struct rtems_bsdnet_config rtems_bsdnet_config = {
>>> &netdriver_config,
>>> rtems_bsdnet_do_bootp,
>>> };
>>>
>>> If there is any latest documentation available, pls let me know.
>>>
>>> Thanks,
>>> Ragunath
>>> ___
>>> devel mailing list
>>> devel@rtems.org
>>> http://lists.rtems.org/mailman/listinfo/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.
>>
>
>
>
> --
> ragu
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
GSOC Students and Mentors
Everyone else can ignore this. Students, please take a look in Melange to see if there are comments on your proposal to address. Apparently, the system is not sending you emails by default to notify you. Mentors, if you have time, please review some proposals, and mark any you would be interested to mentor as "Wish to Mentor". I've tried to make initial assignments already, but your input is welcomed. As always, feel free to contact me directly with any questions. Gedare ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 4/4 v2] score: Use _Thread_Clear_state() for _Thread_Ready
quick skim of these 4 looked good
On Wed, Apr 8, 2015 at 5:49 AM, Sebastian Huber
wrote:
> ---
> cpukit/score/Makefile.am | 2 +-
> cpukit/score/include/rtems/score/statesimpl.h | 3 +++
> cpukit/score/include/rtems/score/threadimpl.h | 30 ++---
> cpukit/score/src/threadready.c| 38
> ---
> 4 files changed, 19 insertions(+), 54 deletions(-)
> delete mode 100644 cpukit/score/src/threadready.c
>
> diff --git a/cpukit/score/Makefile.am b/cpukit/score/Makefile.am
> index 112f7e8..dc51e9a 100644
> --- a/cpukit/score/Makefile.am
> +++ b/cpukit/score/Makefile.am
> @@ -284,7 +284,7 @@ libscore_a_SOURCES += src/thread.c
> src/threadchangepriority.c \
> src/threaddelayended.c src/threaddispatch.c \
> src/threadenabledispatch.c src/threaddisabledispatch.c \
> src/threadget.c src/threadhandler.c src/threadinitialize.c \
> -src/threadloadenv.c src/threadready.c \
> +src/threadloadenv.c \
> src/threadrestart.c src/threadsetpriority.c \
> src/threadsetstate.c \
> src/threadstackallocate.c src/threadstackfree.c src/threadstart.c \
> diff --git a/cpukit/score/include/rtems/score/statesimpl.h
> b/cpukit/score/include/rtems/score/statesimpl.h
> index 4251b3c..074b352 100644
> --- a/cpukit/score/include/rtems/score/statesimpl.h
> +++ b/cpukit/score/include/rtems/score/statesimpl.h
> @@ -118,6 +118,9 @@ extern "C" {
> STATES_WAITING_ON_THREAD_QUEUE | \
> STATES_INTERRUPTIBLE_BY_SIGNAL )
>
> +/** All state bits set to one (provided for _Thread_Ready()) */
> +#define STATES_ALL_SET 0x
> +
> /**
> * This function sets the given states_to_set into the current_state
> * passed in. The result is returned to the user in current_state.
> diff --git a/cpukit/score/include/rtems/score/threadimpl.h
> b/cpukit/score/include/rtems/score/threadimpl.h
> index 0f37655..a13a0de 100644
> --- a/cpukit/score/include/rtems/score/threadimpl.h
> +++ b/cpukit/score/include/rtems/score/threadimpl.h
> @@ -227,21 +227,6 @@ void _Thread_Kill_zombies( void );
> void _Thread_Close( Thread_Control *the_thread, Thread_Control *executing );
>
> /**
> - * @brief Removes any set states for @a the_thread.
> - *
> - * This routine removes any set states for @a the_thread. It performs
> - * any necessary scheduling operations including the selection of
> - * a new heir thread.
> - *
> - * - INTERRUPT LATENCY:
> - *+ ready chain
> - *+ select heir
> - */
> -void _Thread_Ready(
> - Thread_Control *the_thread
> -);
> -
> -/**
> * @brief Clears the specified thread state.
> *
> * In case the previous state is a non-ready state and the next state is the
> @@ -274,6 +259,21 @@ States_Control _Thread_Set_state(
> );
>
> /**
> + * @brief Clears all thread states.
> + *
> + * In case the previous state is a non-ready state, then the thread is
> + * unblocked by the scheduler.
> + *
> + * @param[in] the_thread The thread.
> + */
> +RTEMS_INLINE_ROUTINE void _Thread_Ready(
> + Thread_Control *the_thread
> +)
> +{
> + _Thread_Clear_state( the_thread, STATES_ALL_SET );
> +}
> +
> +/**
> * @brief Initializes enviroment for a thread.
> *
> * This routine initializes the context of @a the_thread to its
> diff --git a/cpukit/score/src/threadready.c b/cpukit/score/src/threadready.c
> deleted file mode 100644
> index 5375294..000
> --- a/cpukit/score/src/threadready.c
> +++ /dev/null
> @@ -1,38 +0,0 @@
> -/**
> - * @file
> - *
> - * @brief Thread Ready
> - * @ingroup ScoreThread
> - */
> -
> -/*
> - * COPYRIGHT (c) 1989-2011.
> - * On-Line Applications Research Corporation (OAR).
> - *
> - * The license and distribution terms for this file may be
> - * found in the file LICENSE in this distribution or at
> - * http://www.rtems.org/license/LICENSE.
> - */
> -
> -#if HAVE_CONFIG_H
> -#include "config.h"
> -#endif
> -
> -#include
> -#include
> -#include
> -
> -void _Thread_Ready(
> - Thread_Control *the_thread
> -)
> -{
> - ISR_lock_Context lock_context;
> -
> - _Scheduler_Acquire( the_thread, &lock_context );
> -
> - the_thread->current_state = STATES_READY;
> -
> - _Scheduler_Unblock( the_thread );
> -
> - _Scheduler_Release( the_thread, &lock_context );
> -}
> --
> 1.8.4.5
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [rtems commit] sp13: Update configuration to account for messages on fourth message queue
On Wed, Apr 15, 2015 at 2:49 AM, Sebastian Huber wrote: > Two message queues get deleted before the forth is created. Why did this > work before and what is the root cause for this failure? We will never know > after this patch. > Yes I don't understand what this is fixing. The test, or the failure? > On 14/04/15 21:08, Joel Sherril wrote: >> >> Module:rtems >> Branch:master >> Commit:351858d75327d5bbda7e720157dced706bbe5688 >> Changeset: >> http://git.rtems.org/rtems/commit/?id=351858d75327d5bbda7e720157dced706bbe5688 >> >> Author:Joel Sherrill >> Date: Tue Apr 14 14:07:35 2015 -0500 >> >> sp13: Update configuration to account for messages on fourth message queue >> >> --- >> >> testsuites/sptests/sp13/system.h | 6 +- >> testsuites/sptests/sp13/task1.c | 1 + >> 2 files changed, 6 insertions(+), 1 deletion(-) >> >> diff --git a/testsuites/sptests/sp13/system.h >> b/testsuites/sptests/sp13/system.h >> index 7bb680c..3b170bf 100644 >> --- a/testsuites/sptests/sp13/system.h >> +++ b/testsuites/sptests/sp13/system.h >> @@ -65,10 +65,14 @@ TEST_EXTERN rtems_name Queue_name[ 4 ]; /* array >> of queue names */ >> #define CONFIGURE_RTEMS_INIT_TASKS_TABLE >> +/* >> + * First three created in init.c, last created in task1.c. >> + */ >> #define CONFIGURE_MESSAGE_BUFFER_MEMORY \ >> CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE( 100, MESSAGE_SIZE ) + \ >> CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE( 10, MESSAGE_SIZE ) + \ >> - CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE( 100, MESSAGE_SIZE ) >> + CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE( 100, MESSAGE_SIZE ) + \ >> + CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE( 100, 20 ) >> #define CONFIGURE_EXTRA_TASK_STACKS (3 * >> RTEMS_MINIMUM_STACK_SIZE) >> diff --git a/testsuites/sptests/sp13/task1.c >> b/testsuites/sptests/sp13/task1.c >> index e783e37..e104e8d 100644 >> --- a/testsuites/sptests/sp13/task1.c >> +++ b/testsuites/sptests/sp13/task1.c >> @@ -267,6 +267,7 @@ rtems_test_pause(); >> &Queue_id[ 1 ] >> ); >> directive_failed( status, "rtems_message_queue_create of Q1; 20 bytes >> each" ); >> + >> status = rtems_message_queue_send( Queue_id[ 1 ], big_send_buffer, 40 >> ); >> fatal_directive_status(status, >> RTEMS_INVALID_SIZE, >> >> ___ >> vc mailing list >> v...@rtems.org >> http://lists.rtems.org/mailman/listinfo/vc > > > -- > 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. > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] sp13: Document message buffer usage and adjust configuration
On Wed, Apr 15, 2015 at 3:41 PM, Joel Sherrill wrote: > --- > testsuites/sptests/sp13/system.h | 23 +++ > 1 file changed, 19 insertions(+), 4 deletions(-) > > diff --git a/testsuites/sptests/sp13/system.h > b/testsuites/sptests/sp13/system.h > index 3b170bf..8e5ffbb 100644 > --- a/testsuites/sptests/sp13/system.h > +++ b/testsuites/sptests/sp13/system.h > @@ -66,13 +66,28 @@ TEST_EXTERN rtems_name Queue_name[ 4 ]; /* array of > queue names */ > #define CONFIGURE_RTEMS_INIT_TASKS_TABLE > > /* > - * First three created in init.c, last created in task1.c. > + * Created in init.c: > + *Q1 - CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE( 100, MESSAGE_SIZE ) (1600) > + *Q2 - CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE( 10, MESSAGE_SIZE ) (160) > + *Q3 - CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE( 100, MESSAGE_SIZE ) (1600) > + * > + * Q1 and Q2 deleted in task1.c > + * > + * Q1 recreated in task1.c > + *Q1 - CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE( 100, 20 ) (2000) > + * > + * Q1 deleted again in task1.c. > + * Q1 repeatedly created and deleted for 2 messages of 1-1030 bytes > + * in length > + *Q1 - CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE( 1030, 2 ) (2000) > + * > + * Thus the peak message memory needed is technically only: > + * Q3 + third instance of Q1 at peak of two 1030 byte messages. > + * > */ > #define CONFIGURE_MESSAGE_BUFFER_MEMORY \ > CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE( 100, MESSAGE_SIZE ) + \ > - CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE( 10, MESSAGE_SIZE ) + \ > - CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE( 100, MESSAGE_SIZE ) + \ > - CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE( 100, 20 ) > + CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE( 1030, 2 ) Should be ( 2, 1030 ) > > #define CONFIGURE_EXTRA_TASK_STACKS (3 * RTEMS_MINIMUM_STACK_SIZE) > > -- > 1.9.3 > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] sp13: Document message buffer usage and adjust configuration
On Wed, Apr 15, 2015 at 3:46 PM, Joel Sherrill wrote: > > > On 4/15/2015 2:45 PM, Gedare Bloom wrote: >> On Wed, Apr 15, 2015 at 3:41 PM, Joel Sherrill >> wrote: >>> --- >>> testsuites/sptests/sp13/system.h | 23 +++ >>> 1 file changed, 19 insertions(+), 4 deletions(-) >>> >>> diff --git a/testsuites/sptests/sp13/system.h >>> b/testsuites/sptests/sp13/system.h >>> index 3b170bf..8e5ffbb 100644 >>> --- a/testsuites/sptests/sp13/system.h >>> +++ b/testsuites/sptests/sp13/system.h >>> @@ -66,13 +66,28 @@ TEST_EXTERN rtems_name Queue_name[ 4 ]; /* array >>> of queue names */ >>> #define CONFIGURE_RTEMS_INIT_TASKS_TABLE >>> >>> /* >>> - * First three created in init.c, last created in task1.c. >>> + * Created in init.c: >>> + *Q1 - CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE( 100, MESSAGE_SIZE ) (1600) >>> + *Q2 - CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE( 10, MESSAGE_SIZE ) (160) >>> + *Q3 - CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE( 100, MESSAGE_SIZE ) (1600) >>> + * >>> + * Q1 and Q2 deleted in task1.c >>> + * >>> + * Q1 recreated in task1.c >>> + *Q1 - CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE( 100, 20 ) (2000) >>> + * >>> + * Q1 deleted again in task1.c. >>> + * Q1 repeatedly created and deleted for 2 messages of 1-1030 bytes >>> + * in length >>> + *Q1 - CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE( 1030, 2 ) (2000) >>> + * >>> + * Thus the peak message memory needed is technically only: >>> + * Q3 + third instance of Q1 at peak of two 1030 byte messages. >>> + * >>> */ >>> #define CONFIGURE_MESSAGE_BUFFER_MEMORY \ >>> CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE( 100, MESSAGE_SIZE ) + \ >>> - CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE( 10, MESSAGE_SIZE ) + \ >>> - CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE( 100, MESSAGE_SIZE ) + \ >>> - CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE( 100, 20 ) >>> + CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE( 1030, 2 ) >> Should be ( 2, 1030 ) > Yep. Good catch. Is the comment clear? A bit verbose but good enough for posterity. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] sp13: Document message buffer usage and adjust configuration
Do you have any intuition to answer Sebastian's concern about why this test suddenly exposed a problem? (git-bisect?) On Thu, Apr 16, 2015 at 11:55 AM, Joel Sherrill wrote: > --- > testsuites/sptests/sp13/system.h | 31 ++- > 1 file changed, 26 insertions(+), 5 deletions(-) > > diff --git a/testsuites/sptests/sp13/system.h > b/testsuites/sptests/sp13/system.h > index 3b170bf..f879096 100644 > --- a/testsuites/sptests/sp13/system.h > +++ b/testsuites/sptests/sp13/system.h > @@ -66,13 +66,34 @@ TEST_EXTERN rtems_name Queue_name[ 4 ]; /* array of > queue names */ > #define CONFIGURE_RTEMS_INIT_TASKS_TABLE > > /* > - * First three created in init.c, last created in task1.c. > + * Created in init.c: > + *Q1 - CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE( 100, MESSAGE_SIZE ) (1600) > + *Q2 - CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE( 10, MESSAGE_SIZE ) (160) > + *Q3 - CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE( 100, MESSAGE_SIZE ) (1600) > + * > + * Q1 and Q2 deleted in task1.c. > + * > + * Q1 recreated in task1.c: > + *Q1 - CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE( 100, 20 ) (2000) > + * > + * Q1 deleted again in task1.c. > + * > + * Q1 repeatedly created and deleted for 2 messages of 1-1030 bytes > + * in length. Account for peak usage: > + *Q1 - CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE( 2, 1030 ) (2060) > + * > + * Because each message requires memory for the message plus two > + * pointers to place the buffer on lists, it is easier to just > + * allocate memory for all the message queues. But we can safely > + * ignore Q2 and the last instance of Q1 since enough memory is > + * free when the third instance of Q1 is created. > */ > #define CONFIGURE_MESSAGE_BUFFER_MEMORY \ > - CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE( 100, MESSAGE_SIZE ) + \ > - CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE( 10, MESSAGE_SIZE ) + \ > - CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE( 100, MESSAGE_SIZE ) + \ > - CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE( 100, 20 ) > + /* Q1 */ CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE( 100, MESSAGE_SIZE ) + \ > + /* Q2 */ /* CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE( 10, MESSAGE_SIZE ) + */ \ > + /* Q3 */ CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE( 100, MESSAGE_SIZE ) + \ > + /* Q1 */ CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE( 100, 20 ) + \ > + /* Q1 */ /* CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE( 2, 1030 ) */ > > #define CONFIGURE_EXTRA_TASK_STACKS (3 * RTEMS_MINIMUM_STACK_SIZE) > > -- > 1.9.3 > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 3/4] score: Add Watchdog_Iterator
I'm not a big fan of this "watchdog_remove_it" terminology. Can I
suggest the state be called something else like WATCHDOG_REMOVING or
maybe WATCHDOG_TRANSIENT, and perhaps the actual removal function be
renamed _Watchdog_Remove_internal() or something similar? Also, given
the refactoring here and that this _Watchdog_Remove_it() is only
called by Watchdog_Remove/Tickle, perhaps it makes sense to put all
three functions into a single source file and make the Remove_it()
function static in that file.
Gedare
On Fri, Apr 17, 2015 at 4:55 AM, Sebastian Huber
wrote:
> Rewrite the _Watchdog_Insert(), _Watchdog_Remove() and
> _Watchdog_Tickle() functions to use interator items to synchronize
> concurrent operations. This makes it possible to get rid of the global
> variables _Watchdog_Sync_level and _Watchdog_Sync_count which are a
> blocking point for scalable SMP solutions.
>
> Update #2307.
> ---
> cpukit/rtems/src/timercreate.c | 6 ++
> cpukit/score/include/rtems/score/watchdogimpl.h | 58 ---
> cpukit/score/src/watchdog.c | 2 -
> cpukit/score/src/watchdoginsert.c | 112 +++-
> cpukit/score/src/watchdogremove.c | 71 ++---
> cpukit/score/src/watchdogtickle.c | 130
>
> testsuites/sptests/spsize/size.c| 4 +-
> testsuites/sptests/spwatchdog/init.c| 103 +++
> 8 files changed, 317 insertions(+), 169 deletions(-)
>
> diff --git a/cpukit/rtems/src/timercreate.c b/cpukit/rtems/src/timercreate.c
> index 390c965..ef217e9 100644
> --- a/cpukit/rtems/src/timercreate.c
> +++ b/cpukit/rtems/src/timercreate.c
> @@ -28,6 +28,10 @@
> void _Timer_Cancel( Timer_Control *the_timer )
> {
>Timer_server_Control *timer_server;
> + ISR_Level level;
> +
> + /* The timer class must not change during the cancel operation */
> + _ISR_Disable( level );
>
>switch ( the_timer->the_class ) {
> case TIMER_INTERVAL:
> @@ -44,6 +48,8 @@ void _Timer_Cancel( Timer_Control *the_timer )
> default:
>break;
>}
> +
> + _ISR_Enable( level );
> }
>
> rtems_status_code rtems_timer_create(
> diff --git a/cpukit/score/include/rtems/score/watchdogimpl.h
> b/cpukit/score/include/rtems/score/watchdogimpl.h
> index f52b55d..304392b 100644
> --- a/cpukit/score/include/rtems/score/watchdogimpl.h
> +++ b/cpukit/score/include/rtems/score/watchdogimpl.h
> @@ -46,6 +46,28 @@ extern "C" {
>}
>
> /**
> + * @brief Iterator item to synchronize concurrent insert, remove and tickle
> + * operations.
> + */
> +typedef struct {
> + /**
> + * @brief A node for a Watchdog_Header::Iterators chain.
> + */
> + Chain_Node Node;
> +
> + /**
> + * @brief The current delta interval of the new watchdog to insert.
> + */
> + Watchdog_Interval delta_interval;
> +
> + /**
> + * @brief The current watchdog of the chain on the way to insert the new
> + * watchdog.
> + */
> + Chain_Node *current;
> +} Watchdog_Iterator;
> +
> +/**
> * @brief Watchdog header.
> */
> typedef struct {
> @@ -58,23 +80,15 @@ typedef struct {
> * @brief The chain of active or transient watchdogs.
> */
>Chain_Control Watchdogs;
> -} Watchdog_Header;
> -
> -/**
> - * @brief Watchdog synchronization level.
> - *
> - * This used for synchronization purposes
> - * during an insert on a watchdog delta chain.
> - */
> -SCORE_EXTERN volatile uint32_t_Watchdog_Sync_level;
>
> -/**
> - * @brief Watchdog synchronization count.
> - *
> - * This used for synchronization purposes
> - * during an insert on a watchdog delta chain.
> - */
> -SCORE_EXTERN volatile uint32_t_Watchdog_Sync_count;
> + /**
> + * @brief Currently active iterators.
> + *
> + * The iterators are registered in _Watchdog_Insert() and updated in case
> the
> + * watchdog chain changes.
> + */
> + Chain_Control Iterators;
> +} Watchdog_Header;
>
> /**
> * @brief Watchdog chain which is managed at ticks.
> @@ -139,6 +153,16 @@ Watchdog_States _Watchdog_Remove (
> );
>
> /**
> + * @brief Actually removes an WATCHDOG_ACTIVE or WATCHDOG_REMOVE_IT watchdog.
> + *
> + * @see _Watchdog_Remove() and _Watchdog_Tickle().
> + */
> +void _Watchdog_Remove_it(
> + Watchdog_Header *header,
> + Watchdog_Control *the_watchdog
> +);
> +
> +/**
> * @brief Adjusts the header watchdog chain in the backward direction for
> * units ticks.
> *
> @@ -437,7 +461,9 @@ RTEMS_INLINE_ROUTINE void _Watchdog_Header_initialize(
>Watchdog_Header *header
> )
> {
> + _ISR_lock_Initialize( &header->Lock, "Watchdog" );
>_Chain_Initialize_empty( &header->Watchdogs );
> + _Chain_Initialize_empty( &header->Iterators );
> }
>
> /** @} */
> diff --git a/cpukit/score/src/watchdog.c b/cpukit/score/src/watchdog.c
> index 0db60ef..11d3cf2 100644
> --- a/cpukit/score/src/watchdog.c
> +++ b/cpukit/score/src/watchdog.c
> @@ -25,8 +25,6 @@
>
> void _Watchdog_Handler_initializa
Re: [PATCH 4/4] score: New timer server implementation
Tested on / results?
On Fri, Apr 17, 2015 at 4:55 AM, Sebastian Huber
wrote:
> Use mostly the standard watchdog operations. Use a system event for
> synchronization. This implementation is simpler and offers better SMP
> performance.
>
> Update #2307.
> ---
> cpukit/rtems/include/rtems/rtems/event.h | 5 +
> cpukit/rtems/include/rtems/rtems/timerimpl.h | 51 +-
> cpukit/rtems/src/timerserver.c | 570
> +++--
> cpukit/score/Makefile.am | 2 +-
> cpukit/score/include/rtems/score/watchdogimpl.h| 59 ++-
> cpukit/score/src/watchdogadjust.c | 35 +-
> cpukit/score/src/watchdogadjusttochain.c | 75 ---
> cpukit/score/src/watchdoginsert.c | 21 +-
> testsuites/sptests/spintrcritical17/init.c | 163 +++---
> .../sptests/spintrcritical17/spintrcritical17.doc | 6 +-
> 10 files changed, 370 insertions(+), 617 deletions(-)
> delete mode 100644 cpukit/score/src/watchdogadjusttochain.c
>
> diff --git a/cpukit/rtems/include/rtems/rtems/event.h
> b/cpukit/rtems/include/rtems/rtems/event.h
> index dce7de1..012452a 100644
> --- a/cpukit/rtems/include/rtems/rtems/event.h
> +++ b/cpukit/rtems/include/rtems/rtems/event.h
> @@ -319,6 +319,11 @@ rtems_status_code rtems_event_receive (
> #define RTEMS_EVENT_SYSTEM_NETWORK_CLOSE RTEMS_EVENT_26
>
> /**
> + * @brief Reserved system event for the timer server.
> + */
> +#define RTEMS_EVENT_SYSTEM_TIMER_SERVER RTEMS_EVENT_30
> +
> +/**
> * @brief Reserved system event for transient usage.
> */
> #define RTEMS_EVENT_SYSTEM_TRANSIENT RTEMS_EVENT_31
> diff --git a/cpukit/rtems/include/rtems/rtems/timerimpl.h
> b/cpukit/rtems/include/rtems/rtems/timerimpl.h
> index 4f200ef..e5b37aa 100644
> --- a/cpukit/rtems/include/rtems/rtems/timerimpl.h
> +++ b/cpukit/rtems/include/rtems/rtems/timerimpl.h
> @@ -65,24 +65,43 @@ typedef struct {
>Watchdog_Control System_watchdog;
>
>/**
> + * @brief Remaining delta of the system watchdog.
> + */
> + Watchdog_Interval system_watchdog_delta;
> +
> + /**
> + * @brief Unique identifier of the context which deals currently with the
> + * system watchdog.
> + */
> + Thread_Control *system_watchdog_helper;
> +
> + /**
> + * @brief Each insert and tickle operation increases the generation count
> so
> + * that the system watchdog dealer notices updates of the watchdog chain.
> + */
> + uint32_t generation;
> +
> + /**
> * @brief Watchdog header managed by the timer server.
> */
>Watchdog_Header Header;
>
>/**
> - * @brief Last known time snapshot of the timer server.
> + * @brief Last time snapshot of the timer server.
> *
> * The units may be ticks or seconds.
> */
> - Watchdog_Interval volatile last_snapshot;
> -} Timer_server_Watchdogs;
> + Watchdog_Interval last_snapshot;
>
> -struct Timer_server_Control {
>/**
> - * @brief Timer server thread.
> + * @brief Current time snapshot of the timer server.
> + *
> + * The units may be ticks or seconds.
> */
> - Thread_Control *thread;
> + Watchdog_Interval current_snapshot;
> +} Timer_server_Watchdogs;
>
> +struct Timer_server_Control {
>/**
> * @brief The cancel method of the timer server.
> */
> @@ -102,26 +121,6 @@ struct Timer_server_Control {
> * @brief TOD watchdogs triggered by the timer server.
> */
>Timer_server_Watchdogs TOD_watchdogs;
> -
> - /**
> - * @brief Chain of timers scheduled for insert.
> - *
> - * This pointer is not @c NULL whenever the interval and TOD chains are
> - * processed. After the processing this list will be checked and if
> - * necessary the processing will be restarted. Processing of these chains
> - * can be only interrupted through interrupts.
> - */
> - Chain_Control *volatile insert_chain;
> -
> - /**
> - * @brief Indicates that the timer server is active or not.
> - *
> - * The server is active after the delay on a system watchdog. The activity
> - * period of the server ends when no more watchdogs managed by the server
> - * fire. The system watchdogs must not be manipulated when the server is
> - * active.
> - */
> - bool volatile active;
> };
>
> /**
> diff --git a/cpukit/rtems/src/timerserver.c b/cpukit/rtems/src/timerserver.c
> index 15cbdfd..db38f48 100644
> --- a/cpukit/rtems/src/timerserver.c
> +++ b/cpukit/rtems/src/timerserver.c
> @@ -15,7 +15,7 @@
> /* COPYRIGHT (c) 1989-2008.
> * On-Line Applications Research Corporation (OAR).
> *
> - * Copyright (c) 2009 embedded brains GmbH.
> + * Copyright (c) 2009-2015 embedded brains GmbH.
> *
> * The license and distribution terms for this file may be
> * found in the file LICENSE in this distribution or at
> @@ -26,200 +26,128 @@
> #include "config.h"
> #endif
>
> +#include
> #include
> #include
> -#include
> -#include
> #include
>
> static Timer_server_Control _Timer_server_Default;
>
> -s
Re: [PATCH] Rename or1ksim BSP to generic_or1k
Looks straightforward to me. Any doc need updating? On Sat, Apr 18, 2015 at 12:25 PM, Hesham ALMatary wrote: > or1ksim BSP was initially named after or1ksim simulator, and it was > intented to only run there. But now it can also run on QEMU, jor1k and > real FPGA boards without modifications. It makes more sense to give > it a new generic name like generic_or1k. > --- > c/src/lib/libbsp/or1k/acinclude.m4 | 4 +- > c/src/lib/libbsp/or1k/configure.ac | 2 +- > c/src/lib/libbsp/or1k/generic_or1k/Makefile.am | 110 + > c/src/lib/libbsp/or1k/generic_or1k/README | 34 > c/src/lib/libbsp/or1k/generic_or1k/bsp_specs | 11 ++ > .../lib/libbsp/or1k/generic_or1k/clock/clockdrv.c | 152 + > c/src/lib/libbsp/or1k/generic_or1k/configure.ac| 30 > .../or1k/generic_or1k/console/console-config.c | 58 +++ > c/src/lib/libbsp/or1k/generic_or1k/console/uart.c | 152 + > c/src/lib/libbsp/or1k/generic_or1k/include/bsp.h | 47 ++ > .../or1k/generic_or1k/include/generic_or1k.h | 118 + > c/src/lib/libbsp/or1k/generic_or1k/include/irq.h | 45 + > c/src/lib/libbsp/or1k/generic_or1k/include/uart.h | 42 + > c/src/lib/libbsp/or1k/generic_or1k/irq/irq.c | 42 + > .../make/custom/generic_or1k-testsuite.tcfg| 5 + > .../or1k/generic_or1k/make/custom/generic_or1k.cfg | 7 + > c/src/lib/libbsp/or1k/generic_or1k/preinstall.am | 120 ++ > c/src/lib/libbsp/or1k/generic_or1k/sim.cfg | 105 > c/src/lib/libbsp/or1k/generic_or1k/start/start.S | 182 > + > .../libbsp/or1k/generic_or1k/startup/bspstart.c| 25 +++ > .../lib/libbsp/or1k/generic_or1k/startup/linkcmds | 41 + > c/src/lib/libbsp/or1k/generic_or1k/timer/timer.c | 64 > c/src/lib/libbsp/or1k/or1ksim/Makefile.am | 110 - > c/src/lib/libbsp/or1k/or1ksim/README | 37 - > c/src/lib/libbsp/or1k/or1ksim/bsp_specs| 11 -- > c/src/lib/libbsp/or1k/or1ksim/clock/clockdrv.c | 149 - > c/src/lib/libbsp/or1k/or1ksim/configure.ac | 30 > .../libbsp/or1k/or1ksim/console/console-config.c | 58 --- > c/src/lib/libbsp/or1k/or1ksim/console/uart.c | 152 - > c/src/lib/libbsp/or1k/or1ksim/include/bsp.h| 47 -- > c/src/lib/libbsp/or1k/or1ksim/include/irq.h| 45 - > c/src/lib/libbsp/or1k/or1ksim/include/or1ksim.h| 118 - > c/src/lib/libbsp/or1k/or1ksim/include/uart.h | 42 - > c/src/lib/libbsp/or1k/or1ksim/irq/irq.c| 42 - > .../or1ksim/make/custom/or1ksim-testsuite.tcfg | 5 - > .../libbsp/or1k/or1ksim/make/custom/or1ksim.cfg| 7 - > c/src/lib/libbsp/or1k/or1ksim/preinstall.am| 120 -- > c/src/lib/libbsp/or1k/or1ksim/sim.cfg | 105 > c/src/lib/libbsp/or1k/or1ksim/start/start.S| 182 > - > c/src/lib/libbsp/or1k/or1ksim/startup/bspstart.c | 25 --- > c/src/lib/libbsp/or1k/or1ksim/startup/linkcmds | 41 - > c/src/lib/libbsp/or1k/or1ksim/timer/timer.c| 64 > 42 files changed, 1393 insertions(+), 1393 deletions(-) > create mode 100644 c/src/lib/libbsp/or1k/generic_or1k/Makefile.am > create mode 100644 c/src/lib/libbsp/or1k/generic_or1k/README > create mode 100644 c/src/lib/libbsp/or1k/generic_or1k/bsp_specs > create mode 100644 c/src/lib/libbsp/or1k/generic_or1k/clock/clockdrv.c > create mode 100644 c/src/lib/libbsp/or1k/generic_or1k/configure.ac > create mode 100644 > c/src/lib/libbsp/or1k/generic_or1k/console/console-config.c > create mode 100644 c/src/lib/libbsp/or1k/generic_or1k/console/uart.c > create mode 100644 c/src/lib/libbsp/or1k/generic_or1k/include/bsp.h > create mode 100644 c/src/lib/libbsp/or1k/generic_or1k/include/generic_or1k.h > create mode 100644 c/src/lib/libbsp/or1k/generic_or1k/include/irq.h > create mode 100644 c/src/lib/libbsp/or1k/generic_or1k/include/uart.h > create mode 100644 c/src/lib/libbsp/or1k/generic_or1k/irq/irq.c > create mode 100644 > c/src/lib/libbsp/or1k/generic_or1k/make/custom/generic_or1k-testsuite.tcfg > create mode 100644 > c/src/lib/libbsp/or1k/generic_or1k/make/custom/generic_or1k.cfg > create mode 100644 c/src/lib/libbsp/or1k/generic_or1k/preinstall.am > create mode 100644 c/src/lib/libbsp/or1k/generic_or1k/sim.cfg > create mode 100644 c/src/lib/libbsp/or1k/generic_or1k/start/start.S > create mode 100644 c/src/lib/libbsp/or1k/generic_or1k/startup/bspstart.c > create mode 100644 c/src/lib/libbsp/or1k/generic_or1k/startup/linkcmds > create mode 100644 c/src/lib/libbsp/or1k/generic_or1k/timer/timer.c > delete mode 100644 c/src/lib/libbsp/or1k/or1ksim/Makefile.am > delete mode 100644 c/src/lib/libbsp/or1k/or1ksim/README > delete mode 100644 c/src/lib/libbsp/or1k/or1ksim/bsp_specs > d
Re: [PATCH] Rename or1ksim BSP to generic_or1k
On Sun, Apr 19, 2015 at 6:24 AM, Hesham ALMatary wrote: > On Sun, Apr 19, 2015 at 1:49 AM, Joel Sherrill > wrote: >> On 04/18/2015 04:57 PM, Gedare Bloom wrote: >>> >>> Looks straightforward to me. Any doc need updating? >>> >> Maybe the wiki. But the other pieces are sim-scripts >> and rtems-tools for the simulator scripts. >> >> I don't know of much else unless Hesham wants to >> update his blog about this. > Yeah once this patch got merged I'll send patches for sim-scripts, > tester, and update my blog. Done. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 1/5] score: _Objects_Get_isr_disable()
Looks ok to me. -Gedare On Mon, Apr 20, 2015 at 9:47 AM, Sebastian Huber wrote: > Sorry, this is the first patch. This should go into the 4.11 release. > > -- > 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. > > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] score: Fix priority message queue insert
Joel, On Tue, Apr 21, 2015 at 12:13 PM, Joel Sherrill wrote: > > > On 4/21/2015 2:24 AM, Sebastian Huber wrote: >> Move the linear search into a critical section to avoid corruption due >> to higher priority interrupts. The interrupt disable time depends now >> on the count of pending messages. >> >> Close #2328. >> --- >> cpukit/score/include/rtems/score/coremsgimpl.h | 32 +-- >> cpukit/score/src/coremsginsert.c | 113 >> +++-- >> 2 files changed, 50 insertions(+), 95 deletions(-) >> +#if defined(RTEMS_SCORE_COREMSG_ENABLE_NOTIFICATION) >> + notify = the_message_queue->number_of_pending_messages == 0; >> +#endif > Add parentheses around expression to make it clear that is the intent. Our coding conventions say to avoid unnecessary parens. If you'd like to make some adjustment to the conventions please start a separate thread. Gedare ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: RTEMS Fault Tolerance Project for SOCIS 2015
On Wed, Apr 22, 2015 at 2:15 PM, Saeed Ehteshamifar wrote: > Hi, > > I'm interested to take part in development of RTEMS via fault tolerance > project. I've read the wiki page for the project, the page for open > projects, and the page for GSoC and GSoC getting started. I've also skimmed > RTEMS 4.5.0 evaluation report. > Make sure you complete the hello world requirements. > I also have the experience of using RTEMS for 14 months as part of a > research team during 05.12 - 07.13. > > My idea is to apply an extended tool based on CMU's Ballista to generate > test cases for injecting faults (RTEMS C programs). However I've 2 basic > questions: > 1. What is the scope of this SOCIS project? Should it include all the scopes > as written in the evaluation report (i.e. RTEMS Executive Core, RTEMS > Classic API, POSIX, Robustness, and Stress Testing)? Or it could be narrowed > down? You should narrow it down to be feasible during the program duration (3 months?) > 2. Of course source codes, documentation, and the tests output should be > included in the final result but what about an analysis on tests output? > should that be included as well? > Analysis or better yet tools for analysis would be useful. > Thanks in advance, for your time and attention. > > Kind Regards, > SAeeD > > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] score: Fix POSIX thread join
On Thu, Apr 23, 2015 at 9:30 AM, Sebastian Huber
wrote:
> A thread join twofold. One side uses a thread queue and the other not.
> So we must not use the same state.
>
> Update #2035.
> ---
> cpukit/libmisc/monitor/mon-prmisc.c | 1 +
> cpukit/posix/src/pthreadjoin.c| 2 +-
> cpukit/score/include/rtems/score/statesimpl.h | 4 +++-
> 3 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/cpukit/libmisc/monitor/mon-prmisc.c
> b/cpukit/libmisc/monitor/mon-prmisc.c
> index ff54d79..f981a4e 100644
> --- a/cpukit/libmisc/monitor/mon-prmisc.c
> +++ b/cpukit/libmisc/monitor/mon-prmisc.c
> @@ -138,6 +138,7 @@ static const rtems_assoc_t rtems_monitor_state_assoc[] = {
> { "ZOMBI", STATES_ZOMBIE, 0 },
> { "MIGRA", STATES_MIGRATING, 0 },
> { "RESTA", STATES_RESTARTING, 0 },
> +{ "Wjoin", STATES_WAITING_FOR_JOIN, 0 },
Does the order matter here, or can the state be located next to "Wjatx"?
> { 0, 0, 0 },
> };
>
> diff --git a/cpukit/posix/src/pthreadjoin.c b/cpukit/posix/src/pthreadjoin.c
> index 99cc4d3..e2b1664 100644
> --- a/cpukit/posix/src/pthreadjoin.c
> +++ b/cpukit/posix/src/pthreadjoin.c
> @@ -71,7 +71,7 @@ on_EINTR:
> _Thread_queue_Enqueue(
>&api->Join_List,
>executing,
> - STATES_WAITING_FOR_JOIN_AT_EXIT | STATES_INTERRUPTIBLE_BY_SIGNAL,
> + STATES_WAITING_FOR_JOIN | STATES_INTERRUPTIBLE_BY_SIGNAL,
>WATCHDOG_NO_TIMEOUT
> );
>}
> diff --git a/cpukit/score/include/rtems/score/statesimpl.h
> b/cpukit/score/include/rtems/score/statesimpl.h
> index 074b352..9f94675 100644
> --- a/cpukit/score/include/rtems/score/statesimpl.h
> +++ b/cpukit/score/include/rtems/score/statesimpl.h
> @@ -84,6 +84,8 @@ extern "C" {
> #define STATES_MIGRATING 0x40
> /** This macro corresponds to a task restarting. */
> #define STATES_RESTARTING 0x80
> +/** This macro corresponds to a task waiting for a join. */
> +#define STATES_WAITING_FOR_JOIN0x100
>
> /** This macro corresponds to a task which is in an interruptible
> * blocking state.
> @@ -97,7 +99,7 @@ extern "C" {
> STATES_WAITING_FOR_SEMAPHORE | \
> STATES_WAITING_FOR_MUTEX | \
> STATES_WAITING_FOR_CONDITION_VARIABLE | \
> - STATES_WAITING_FOR_JOIN_AT_EXIT | \
> + STATES_WAITING_FOR_JOIN | \
Is it right to remove WAITING_FOR_JOIN_AT_EXIT here?
Is it possible to replace all WAITING_FOR_JOIN_AT_EXIT with
WAITING_FOR_JOIN? Then the enum and bit values can be just renamed.
> STATES_WAITING_FOR_SIGNAL | \
> STATES_WAITING_FOR_BARRIER| \
> STATES_WAITING_FOR_BSD_WAKEUP | \
> --
> 1.8.4.5
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] score: Fix POSIX thread join
On Thu, Apr 23, 2015 at 3:09 PM, Sebastian Huber
wrote:
>
> - Gedare Bloom schrieb:
>> On Thu, Apr 23, 2015 at 9:30 AM, Sebastian Huber
>> wrote:
>> > A thread join twofold. One side uses a thread queue and the other not.
>> > So we must not use the same state.
>> >
>> > Update #2035.
>> > ---
>> > cpukit/libmisc/monitor/mon-prmisc.c | 1 +
>> > cpukit/posix/src/pthreadjoin.c| 2 +-
>> > cpukit/score/include/rtems/score/statesimpl.h | 4 +++-
>> > 3 files changed, 5 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/cpukit/libmisc/monitor/mon-prmisc.c
>> > b/cpukit/libmisc/monitor/mon-prmisc.c
>> > index ff54d79..f981a4e 100644
>> > --- a/cpukit/libmisc/monitor/mon-prmisc.c
>> > +++ b/cpukit/libmisc/monitor/mon-prmisc.c
>> > @@ -138,6 +138,7 @@ static const rtems_assoc_t rtems_monitor_state_assoc[]
>> > = {
>> > { "ZOMBI", STATES_ZOMBIE, 0 },
>> > { "MIGRA", STATES_MIGRATING, 0 },
>> > { "RESTA", STATES_RESTARTING, 0 },
>> > +{ "Wjoin", STATES_WAITING_FOR_JOIN, 0 },
>> Does the order matter here, or can the state be located next to "Wjatx"?
>>
>
> Ok.
>
>> > { 0, 0, 0 },
>> > };
>> >
>> > diff --git a/cpukit/posix/src/pthreadjoin.c
>> > b/cpukit/posix/src/pthreadjoin.c
>> > index 99cc4d3..e2b1664 100644
>> > --- a/cpukit/posix/src/pthreadjoin.c
>> > +++ b/cpukit/posix/src/pthreadjoin.c
>> > @@ -71,7 +71,7 @@ on_EINTR:
>> > _Thread_queue_Enqueue(
>> >&api->Join_List,
>> >executing,
>> > - STATES_WAITING_FOR_JOIN_AT_EXIT |
>> > STATES_INTERRUPTIBLE_BY_SIGNAL,
>> > + STATES_WAITING_FOR_JOIN | STATES_INTERRUPTIBLE_BY_SIGNAL,
>> >WATCHDOG_NO_TIMEOUT
>> > );
>> >}
>> > diff --git a/cpukit/score/include/rtems/score/statesimpl.h
>> > b/cpukit/score/include/rtems/score/statesimpl.h
>> > index 074b352..9f94675 100644
>> > --- a/cpukit/score/include/rtems/score/statesimpl.h
>> > +++ b/cpukit/score/include/rtems/score/statesimpl.h
>> > @@ -84,6 +84,8 @@ extern "C" {
>> > #define STATES_MIGRATING 0x40
>> > /** This macro corresponds to a task restarting. */
>> > #define STATES_RESTARTING 0x80
>> > +/** This macro corresponds to a task waiting for a join. */
>> > +#define STATES_WAITING_FOR_JOIN0x100
>> >
>> > /** This macro corresponds to a task which is in an interruptible
>> > * blocking state.
>> > @@ -97,7 +99,7 @@ extern "C" {
>> > STATES_WAITING_FOR_SEMAPHORE | \
>> > STATES_WAITING_FOR_MUTEX | \
>> > STATES_WAITING_FOR_CONDITION_VARIABLE | \
>> > - STATES_WAITING_FOR_JOIN_AT_EXIT | \
>> > + STATES_WAITING_FOR_JOIN | \
>> Is it right to remove WAITING_FOR_JOIN_AT_EXIT here?
>
> Yes, this is the key point of the patch. The join is twofold. There is one
> thread that exists and an arbitrary number of threads that wait for the
> thread exit (one-to-many relation). The exitting thread may want to wait for
> a thread that wants to join its exit (STATES_WAITING_FOR_JOIN_AT_EXIT in
> _POSIX_Thread_Exit()). On the other side we need a thread queue for all the
> threads that wait for the exit (STATES_WAITING_FOR_JOIN in pthread_join()).
>
OK thanks this explanation would be useful somewhere, maybe just to
clarify the commit message a little bit more.
Gedare
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: Git Master Freeze for 4.11
On Fri, Apr 24, 2015 at 3:13 AM, Sebastian Huber wrote: > > > On 24/04/15 09:11, Chris Johns wrote: >>> >>> >For the tools I propose to use GCC 4.9.3 (should get released soon) and >>> >the next Newlib snapshot. >>> > >> >> Snapshot name ? > > > Its not available yet, but we are close to the end of the month. > We can ping Jeff if it is an appropriate amount of time since the last one, and newlib has everything we need in it. > -- > 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. > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [rtems commit] posix: Use right thread dispatch disable function
Why do we have these two functions with similar names and commented to have the same functionality? If one is for SMP and the other for UP, should they be unified or is there a good reason to have separate functions? On Fri, Apr 24, 2015 at 2:42 AM, Sebastian Huber wrote: > Module:rtems > Branch:master > Commit:d83127e9bd39c1a8c7ef51aa4d9034b06a2bd115 > Changeset: > http://git.rtems.org/rtems/commit/?id=d83127e9bd39c1a8c7ef51aa4d9034b06a2bd115 > > Author:Sebastian Huber > Date: Fri Apr 24 08:36:33 2015 +0200 > > posix: Use right thread dispatch disable function > > --- > > cpukit/posix/src/mutexlocksupp.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/cpukit/posix/src/mutexlocksupp.c > b/cpukit/posix/src/mutexlocksupp.c > index 92c6556..9b20f58 100644 > --- a/cpukit/posix/src/mutexlocksupp.c > +++ b/cpukit/posix/src/mutexlocksupp.c > @@ -55,7 +55,7 @@ int _POSIX_Mutex_Lock_support( > > case OBJECTS_LOCAL: > #if defined(RTEMS_SMP) > - _Thread_Dispatch_disable(); > + _Thread_Disable_dispatch(); > #endif >executing = _Thread_Executing; >_CORE_mutex_Seize( > > ___ > vc mailing list > v...@rtems.org > http://lists.rtems.org/mailman/listinfo/vc ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: 4.11 BLOCKER - Multiple BSPs fail to build - cache changes?
Wouldn't it be better to fix the or1k function declarations unless there is going to be or1k-specific implementation provided? On Fri, Apr 24, 2015 at 1:07 PM, Hesham ALMatary wrote: > Hi, > > I believe this commit is the one which broke it [1], I'm going to > discard the usage of the shared cache_manager.c file and provide or1k > with private stubs. > > [1] > https://github.com/RTEMS/rtems/commit/26c142e5ad4a63ad42baa17159c1821afe473a00 > > On Fri, Apr 24, 2015 at 5:16 PM, Joel Sherrill > wrote: >> Hi >> >> Multiple BSPs failed to build in my overnight sweep. All >> bfin and or1k BSPs plus 18 m68k failed with this: >> >> ../../../../../../../rtems/c/src/lib/libcpu/m68k/../shared/src/cache_manager.c:340:1: >> error: static declaration of '_CPU_cache_invalidate_instruction_range' >> follows non-static declaration >> _CPU_cache_invalidate_instruction_range( >> ^ >> In file included from >> ../../../../../../../rtems/c/src/lib/libcpu/m68k/shared/cache/cache_.h:37:0, >> from >> ../../../../../../../rtems/c/src/lib/libcpu/m68k/../shared/src/cache_manager.c:39: >> ../../../../.././mcf5329/lib/include/libcpu/cache.h:30:6: note: previous >> declaration of '_CPU_cache_invalidate_instruction_range' was here >> void _CPU_cache_invalidate_instruction_range(const void *i_addr, size_t >> n_bytes); >> ^ >> >> bfin/bf537Stamp, or1k/or1k_generic, and m68k/mvme136 should >> be sufficient to reproduce and fix the problem. >> >> -- >> 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 >> >> ___ >> devel mailing list >> devel@rtems.org >> http://lists.rtems.org/mailman/listinfo/devel > > > > -- > Hesham > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
