Re: Error while compiling rtems main branch for sparc
Hi Saurabh, This is a current problem in RTEMS. You need to have 'pax' installed on your development host to build the dl tests. So, it looks good to me! Gedare On Thu, Jun 4, 2015 at 9:16 PM, Saurabh Gadia wrote: > I am sorry for not attaching the patch and configuration command: > > ../rtems/configure --target=sparc-rtems4.11 --enable-rtemsbsp=sis > --enable-tests --disable-posix ENABLE_STRICT_ORDER_MUTEX=1 > > > > Thanks, > > Saurabh Gadia > > On Thu, Jun 4, 2015 at 6:08 PM, Saurabh Gadia wrote: >> >> Hi, >> I worked out that bug related to strict_mutex and gone past that bug. But >> now I have issue while compiling the libtests. Below is the error log: >> >> ''' >> sparc-rtems4.11-size syscall01.exe >>text databssdechexfilename >> 266128 6064 11456 283648 45400syscall01.exe >> cp syscall01.exe syscall01.ralf >> make[6]: Leaving directory >> `/home/saurabh/dev1/kernel/b-sis/sparc-rtems4.11/c/sis/testsuites/libtests/syscall01' >> Making all in dl01 >> make[6]: Entering directory >> `/home/saurabh/dev1/kernel/b-sis/sparc-rtems4.11/c/sis/testsuites/libtests/dl01' >> sparc-rtems4.11-gcc -B../../../../../sis/lib/ -specs bsp_specs -qrtems >> -DHAVE_CONFIG_H -I. >> -I../../../../../../../rtems/c/src/../../testsuites/libtests/dl01 -I.. >> -I../../../../../../../rtems/c/src/../../testsuites/libtests/../support/include >> -mcpu=cypress -O2 -g -ffunction-sections -fdata-sections -Wall >> -Wmissing-prototypes -Wimplicit-function-declaration -Wstrict-prototypes >> -Wnested-externs -MT dl-o1.o -MD -MP -MF .deps/dl-o1.Tpo -c -o dl-o1.o >> ../../../../../../../rtems/c/src/../../testsuites/libtests/dl01/dl-o1.c >> mv -f .deps/dl-o1.Tpo .deps/dl-o1.Po >> w -f dl.tar dl-o1.o >> 17:44:17 up 2:31, 2 users, load average: 2.27, 0.99, 0.53 >> USER TTYLOGIN@ IDLE JCPU PCPU WHAT >> ../../../../../../tools/build/rtems-bin2c -C dl.tar dl-tar.c >> cannot open dl.tar for reading >> make[6]: *** [dl-tar.c] Error 1 >> make[6]: Leaving directory >> `/home/saurabh/dev1/kernel/b-sis/sparc-rtems4.11/c/sis/testsuites/libtests/dl01' >> make[5]: *** [all-local] Error 1 >> make[5]: Leaving directory >> `/home/saurabh/dev1/kernel/b-sis/sparc-rtems4.11/c/sis/testsuites/libtests' >> make[4]: *** [all] Error 2 >> make[4]: Leaving directory >> `/home/saurabh/dev1/kernel/b-sis/sparc-rtems4.11/c/sis/testsuites/libtests' >> make[3]: *** [all-recursive] Error 1 >> make[3]: Leaving directory >> `/home/saurabh/dev1/kernel/b-sis/sparc-rtems4.11/c/sis/testsuites' >> make[2]: *** [all-recursive] Error 1 >> make[2]: Leaving directory >> `/home/saurabh/dev1/kernel/b-sis/sparc-rtems4.11/c/sis' >> make[1]: *** [all-recursive] Error 1 >> make[1]: Leaving directory >> `/home/saurabh/dev1/kernel/b-sis/sparc-rtems4.11/c' >> make: *** [all-recursive] Error 1 >> saurabh@saurabh-Inspiron-N5010:~/dev1/kernel/b-sis$ ls >> ''' >> >> I am not able to find dl-tar.c but we have dl-tar.Po. Can anyone guide me >> on this. How should I proceed with this. >> >> Thanks, >> >> Saurabh Gadia >> >> On Mon, Jun 1, 2015 at 7:48 AM, Saurabh Gadia wrote: >>> >>> I am on it. >>> >>> >>> On Monday, June 1, 2015, Gedare Bloom wrote: Hi Saurabh, Please try to figure out how to fix the compile-error. You can see that the problem occurs in the #ifdef'd STRICT_ORDER_MUTEX_CODE, so that makes sense why others have not observed the same issue. It appears you will have to reconcile the new _Thread_Change_priority arguments with what is being used in that block of code. If you need more guidance please ask. Gedare On Mon, Jun 1, 2015 at 12:35 AM, Saurabh Gadia wrote: > I wanted to test the ENABLE_STRICT_ORDER_MUTEX=1 related sptests for > "nested > mutex" GSOC project. So please let me know what can be done. > > Thanks, > > Saurabh Gadia > > On Sun, May 31, 2015 at 9:33 PM, Saurabh Gadia wrote: >> >> Hi, >> so I am working for sparc-sis setting and master branch. And if you >> see >> the code in threadimpl.h and threadchangepriority.c and >> coremutexsurrender.c >> the definition of _Thread_Change_priority() is having mismatch >> calling. Git >> records says that there was change to above function structure done >> by >> sebastian huber. But I guess he forgot to change the definition of >> _Thread_Change_priority() in threadimpl.h and call in >> coremutexsurrender.c >> >> Configuration command: >> ./configure --target=sparc-rtems4.11 --enable-rtemsbsp=sis >> --enable-tests >> --disable-posix ENABLE_STRICT_ORDER_MUTEX=1 >> >> Error Log: >> >> >> ^ >> In file included from >> >> ../../cpukit/../../../sis/lib/include/rtems/score/coremuteximpl.h:24:0, >> from >> >> ../../../../../../rtems/c/src/../../cpukit/score/src/coremutexsurrender.c:2
Re: TMS570 headers ready for review
On Tue, Jun 2, 2015 at 9:39 AM, Pavel Pisa wrote: > Hello all, > > Premysl Houdek has prepared new and hopefully near ready > complete header files for TMS570LS3137 microcontroller. > They are based on PDF documentation and license is > RTEMS compatible. The scripts used during process can be > found in > > https://github.com/AoLaD/rtems-tms570-utils/tree/headers/headers/python > > The RTEMS updated and compiled with actual headers can be > found in his tms570-bsp branch > > > https://github.com/AoLaD/rtems/tree/tms570-bsp/c/src/lib/libbsp/arm/tms570/include > > Please, look on the files and express your opinion. > The new temporary top level header files is tms5702.h. > It should replace tms570.h. > I took a glance at some, I didn't see anything overtly bad, although the generated license is (1) interleaved with excess newlines, and (2) possibly spurious to apply on automatically generated content. The script he wrote should specify itself what the license is on generated files. I'd recommend something that is as permissive as possible when dealing with generated files. I'll be curious to see what tms570 users think of the generated headers. > As for the header files organization, we propose to > move peripherals registers header files to the > subdirectory of BSP include path. But because Texas Instruments > IP blocks can appear even on slightly modified chips we > do not propose tms570 name. Our idea is to use "tmsreg" name > and use peripherals headers file names in lowercase form. > The files would be generally included from code through > "tms570.h". > I'm fine with the more generic use of names, although I might prefer separation of tms_reg. We also have some generic BSPs that span multiple boards, and I think we prefer something like generic_tms_... now, e.g. generic_or1k was recently added. Older generic code used something more like gen5200. If the IP blocks may be unrelated to the TMS line however, it might be sensible to have something more like generic_ti_... However, until the code is actually shared by multiple BSPs, I might prefer to see it kept local to the tms570. > Do you agree with proposal? > Have you some more ideas? > > The adjustment of actual BSP sources for the new header files > is minimal. See separate commits. The BSP builds completely > with all examples. We plan more testing in next days. > A document of what/how testing was done would be nice, and a relatively good (English) report about the whole process would help I think, if time and energy permit. > 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
Re: USB Host and MMC/SD Card Stack
Hi Sebastian, is this industrial-grade fully functional, or has known issues? If it has, we could fix them. Thanks, Daniel. On Mon, May 18, 2015 at 4:01 AM, Sebastian Huber wrote: > On 16/05/15 20:53, Afshin Jamaali (Arian) wrote: >> >> Hi Sebastian, >> >> Sorry, it seems a problem exists. The link >> "http://git.rtems.org/rtems-libbsd.git/"; says: >> "No repositories found" > > > Sorry, the right link is: > > https://git.rtems.org/rtems-libbsd > >> >> Best Regards, >> Afshin Jamaali >> >> >> -Original Message- >> From: devel [mailto:devel-boun...@rtems.org] On Behalf Of Sebastian Huber >> Sent: Friday, May 15, 2015 18:25 >> To: devel@rtems.org >> Subject: Re: USB Host and MMC/SD Card Stack >> >> Hello, >> >> the USB host and MMC/SD card stack for RTEMS is now available via the >> libbsd: >> >> http://git.rtems.org/rtems-libbsd.git/ >> >> I will remove my libusb repository to avoid confusion. >> >> On 27/08/14 14:19, Sebastian Huber wrote: >>> >>> Hello, >>> >>> I added a USB host and MMC/SD card stack for RTEMS (libusb) to my Git >>> repository area: >>> >>> http://git.rtems.org/sebh/rtems-libusb.git/ >>> >>> It was previously only available as a snapshot: >>> >>> https://www.rtems.org/bugzilla/show_bug.cgi?id=1601 >>> >>> The USB host stack is a port from FreeBSD 8. The MMC/SD card stack is >>> a port from FreeBSD 9.3. >>> >>> The libusb is a subset an older version of the libbsd which contains >>> also the network stack from FreeBSD 9.3. We use libusb on some boards >>> and projects. I simply had no time to test the USB and MMC/SD parts >>> in libbsd. >>> >>> http://git.rtems.org/rtems-libbsd/ >>> >>> Both libraries lack documentation. The basic network stack in libbsd >>> works well, but more work is required to polish 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 > > > -- > 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 -- 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
Re: TMS570 headers ready for review
On Fri, Jun 5, 2015 at 1:18 PM, Gedare Bloom wrote: > I'll be curious to see what tms570 users think of the generated headers. We've been quite busy lately, but I'll take a look as soon as I can. -- Martin Galvan Software Engineer Taller Technologies Argentina San Lorenzo 47, 3rd Floor, Office 5 Córdoba, Argentina Phone: 54 351 4217888 / +54 351 4218211 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
rtems-libbsd waf params
Since 'waf' requires four params and 'make' only three in config.inc, I got confused with waf. Could anyone help me with waf params? Here is my config.inc: TARGET = arm-rtems4.11 BSP = c/raspberrypi/make PREFIX = /home/gtament/development/rtems/src/b-rpi Thanks in advance) ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Error while compiling rtems main branch for sparc
Ok. Thanks a lot. Will continue with compiling and JPF setup this week as discussed with Cyrille. And if time permits will look into how to emulate the things in JPF. And also provide ppt in deoxygen for revised rtems code. On Friday, June 5, 2015, Gedare Bloom wrote: > Hi Saurabh, > > This is a current problem in RTEMS. You need to have 'pax' installed > on your development host to build the dl tests. So, it looks good to > me! > > Gedare > > On Thu, Jun 4, 2015 at 9:16 PM, Saurabh Gadia > wrote: > > I am sorry for not attaching the patch and configuration command: > > > > ../rtems/configure --target=sparc-rtems4.11 --enable-rtemsbsp=sis > > --enable-tests --disable-posix ENABLE_STRICT_ORDER_MUTEX=1 > > > > > > > > Thanks, > > > > Saurabh Gadia > > > > On Thu, Jun 4, 2015 at 6:08 PM, Saurabh Gadia > wrote: > >> > >> Hi, > >> I worked out that bug related to strict_mutex and gone past that bug. > But > >> now I have issue while compiling the libtests. Below is the error log: > >> > >> ''' > >> sparc-rtems4.11-size syscall01.exe > >>text databssdechexfilename > >> 266128 6064 11456 283648 45400syscall01.exe > >> cp syscall01.exe syscall01.ralf > >> make[6]: Leaving directory > >> > `/home/saurabh/dev1/kernel/b-sis/sparc-rtems4.11/c/sis/testsuites/libtests/syscall01' > >> Making all in dl01 > >> make[6]: Entering directory > >> > `/home/saurabh/dev1/kernel/b-sis/sparc-rtems4.11/c/sis/testsuites/libtests/dl01' > >> sparc-rtems4.11-gcc -B../../../../../sis/lib/ -specs bsp_specs -qrtems > >> -DHAVE_CONFIG_H -I. > >> -I../../../../../../../rtems/c/src/../../testsuites/libtests/dl01 -I.. > >> > -I../../../../../../../rtems/c/src/../../testsuites/libtests/../support/include > >> -mcpu=cypress -O2 -g -ffunction-sections -fdata-sections -Wall > >> -Wmissing-prototypes -Wimplicit-function-declaration -Wstrict-prototypes > >> -Wnested-externs -MT dl-o1.o -MD -MP -MF .deps/dl-o1.Tpo -c -o dl-o1.o > >> ../../../../../../../rtems/c/src/../../testsuites/libtests/dl01/dl-o1.c > >> mv -f .deps/dl-o1.Tpo .deps/dl-o1.Po > >> w -f dl.tar dl-o1.o > >> 17:44:17 up 2:31, 2 users, load average: 2.27, 0.99, 0.53 > >> USER TTYLOGIN@ IDLE JCPU PCPU WHAT > >> ../../../../../../tools/build/rtems-bin2c -C dl.tar dl-tar.c > >> cannot open dl.tar for reading > >> make[6]: *** [dl-tar.c] Error 1 > >> make[6]: Leaving directory > >> > `/home/saurabh/dev1/kernel/b-sis/sparc-rtems4.11/c/sis/testsuites/libtests/dl01' > >> make[5]: *** [all-local] Error 1 > >> make[5]: Leaving directory > >> > `/home/saurabh/dev1/kernel/b-sis/sparc-rtems4.11/c/sis/testsuites/libtests' > >> make[4]: *** [all] Error 2 > >> make[4]: Leaving directory > >> > `/home/saurabh/dev1/kernel/b-sis/sparc-rtems4.11/c/sis/testsuites/libtests' > >> make[3]: *** [all-recursive] Error 1 > >> make[3]: Leaving directory > >> `/home/saurabh/dev1/kernel/b-sis/sparc-rtems4.11/c/sis/testsuites' > >> make[2]: *** [all-recursive] Error 1 > >> make[2]: Leaving directory > >> `/home/saurabh/dev1/kernel/b-sis/sparc-rtems4.11/c/sis' > >> make[1]: *** [all-recursive] Error 1 > >> make[1]: Leaving directory > >> `/home/saurabh/dev1/kernel/b-sis/sparc-rtems4.11/c' > >> make: *** [all-recursive] Error 1 > >> saurabh@saurabh-Inspiron-N5010:~/dev1/kernel/b-sis$ ls > >> ''' > >> > >> I am not able to find dl-tar.c but we have dl-tar.Po. Can anyone guide > me > >> on this. How should I proceed with this. > >> > >> Thanks, > >> > >> Saurabh Gadia > >> > >> On Mon, Jun 1, 2015 at 7:48 AM, Saurabh Gadia > wrote: > >>> > >>> I am on it. > >>> > >>> > >>> On Monday, June 1, 2015, Gedare Bloom > > wrote: > > Hi Saurabh, > > Please try to figure out how to fix the compile-error. You can see > that the problem occurs in the #ifdef'd STRICT_ORDER_MUTEX_CODE, so > that makes sense why others have not observed the same issue. It > appears you will have to reconcile the new _Thread_Change_priority > arguments with what is being used in that block of code. If you need > more guidance please ask. > > Gedare > > On Mon, Jun 1, 2015 at 12:35 AM, Saurabh Gadia > wrote: > > I wanted to test the ENABLE_STRICT_ORDER_MUTEX=1 related sptests for > > "nested > > mutex" GSOC project. So please let me know what can be done. > > > > Thanks, > > > > Saurabh Gadia > > > > On Sun, May 31, 2015 at 9:33 PM, Saurabh Gadia > wrote: > >> > >> Hi, > >> so I am working for sparc-sis setting and master branch. And if you > >> see > >> the code in threadimpl.h and threadchangepriority.c and > >> coremutexsurrender.c > >> the definition of _Thread_Change_priority() is having mismatch > >> calling. Git > >> records says that there was change to above function structure done > >> by > >> sebastian huber. But I guess he forgot to change the definition of > >> _Thread_Change_prior
Re: rtems-libbsd waf params
>From what I could make out from the documentation in README.waf, in waf configure , --prefix is where you would like to install rtems-libbsd, --rtems is where you installed your bsp, that is, the '--prefix' you passed while configuring the bsp. '--rtems-tools' points to the tool-set you built using RSB (the --prefix you passed to the RSB) and '--rtems-bsps' should be provided with the string 'architecture/bsp'. (everything without quotes, quotes are just for illustration) usually --prefix and --rtems would have the same value, but it depends on how you are setting things up. Further, from libbsd.txt, in config.inc BSP should only be the name of your BSP, not c/raspberrypi/make. See if this helps. Regards On Fri, Jun 5, 2015 at 10:47 PM, Yurii Shevtsov wrote: > Since 'waf' requires four params and 'make' only three in config.inc, > I got confused with waf. Could anyone help me with waf params? Here is > my config.inc: > TARGET = arm-rtems4.11 > BSP = c/raspberrypi/make > PREFIX = /home/gtament/development/rtems/src/b-rpi > > 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: rtems-libbsd waf params
2015-06-05 21:02 GMT+03:00 Sujay Raj : > From what I could make out from the documentation in README.waf, > in waf configure , --prefix is where you would like to install rtems-libbsd, > --rtems is where you installed your bsp, that is, the '--prefix' you > passed while configuring the bsp. > '--rtems-tools' points to the tool-set you built using RSB (the > --prefix you passed to the RSB) and > '--rtems-bsps' should be provided with the string 'architecture/bsp'. > > (everything without quotes, quotes are just for illustration) > > usually --prefix and --rtems would have the same value, but it depends > on how you are setting things up. Thanks, I'll try. > Further, from libbsd.txt, in config.inc BSP should only be the name of > your BSP, not c/raspberrypi/make. Can't agree with you here. This path is exactly what is needed for successful build > See if this helps. > Regards > > > > On Fri, Jun 5, 2015 at 10:47 PM, Yurii Shevtsov wrote: >> Since 'waf' requires four params and 'make' only three in config.inc, >> I got confused with waf. Could anyone help me with waf params? Here is >> my config.inc: >> TARGET = arm-rtems4.11 >> BSP = c/raspberrypi/make >> PREFIX = /home/gtament/development/rtems/src/b-rpi >> >> 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: TMS570 headers ready for review
Hello Gedare, thanks for response. On Friday 05 of June 2015 18:18:15 Gedare Bloom wrote: > On Tue, Jun 2, 2015 at 9:39 AM, Pavel Pisa wrote: > > Please, look on the files and express your opinion. > > The new temporary top level header files is tms5702.h. > > It should replace tms570.h. > > I took a glance at some, I didn't see anything overtly bad, although > the generated license is (1) interleaved with excess newlines That is already corrected in the script. > and (2) possibly spurious to apply on automatically generated content. > The script he wrote should specify itself what the license is on generated > files. I'd recommend something that is as permissive as possible when > dealing with generated files. The license is not part of the script, it is provided as template so everybody who contributes can add his/her name there. I support to provide some license in the headers because if there is no license then users have no guarantee that would not be sued. At least in our country code without writtent premission or copyright can be considered as fully owned by author. We have switched to two clause BSD, which is really permissive license after last discussion. I would even prefer that over RTEMS specific one because it allows to use header files even in other projects. I.e. U-boot for TMS570 would be great even that I do not expect to find resources for that. Last but not least, Premysl Houdek has spent considerable time on that work so he deserves some attribution in my opinion. > I'll be curious to see what tms570 users think of the generated headers. > > > As for the header files organization, we propose to > > move peripherals registers header files to the > > subdirectory of BSP include path. But because Texas Instruments > > IP blocks can appear even on slightly modified chips we > > do not propose tms570 name. Our idea is to use "tmsreg" name > > and use peripherals headers file names in lowercase form. > > The files would be generally included from code through > > "tms570.h". > > I'm fine with the more generic use of names, although I might prefer > separation of tms_reg. We also have some generic BSPs that span > multiple boards, and I think we prefer something like generic_tms_... > now, e.g. generic_or1k was recently added. Older generic code used > something more like gen5200. If the IP blocks may be unrelated to the > TMS line however, it might be sensible to have something more like > generic_ti_... > > However, until the code is actually shared by multiple BSPs, I might > prefer to see it kept local to the tms570. Yes I agree to keep them local for now but moving to include subdirs ensures that they do not mix with the real programmers written BSP files. As for the name we could use something like ti_hercules. In the fact we should use the gen_ti_hercules for BSP if we expect to extend it in future for RM48 and RM57. Ti tools seems to put generic stuff of CCS under "Hercules" name so there is some hope that they keep IPs from name clashing in that family. We have now RM48 boards because paying industry partner wants or Matlab/Simulink for both TMS570 and RM48 now. But that project is based on Ti tools unfortunately. > > Do you agree with proposal? > > Have you some more ideas? > > > > The adjustment of actual BSP sources for the new header files > > is minimal. See separate commits. The BSP builds completely > > with all examples. We plan more testing in next days. > > A document of what/how testing was done would be nice, and a > relatively good (English) report about the whole process would help I > think, if time and energy permit. I hope that we get to better documentation but the testing is critical now. Next task is Ethernet support, it is on the Premek's thesis check list to be defended. He has spent to much time on headers so he needs to postpone his thesis till end of year to finish that. Another important task is to implement correct startup but it is above his planned involvement. As for other thesis, Jan Dolezal's i386 VESA work, he defends his thesis over next week and it is written in English so I post the link as it is published on the university pages. It can be copied to RTEMS as well then. Best wishes, Pavel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: TMS570 headers ready for review
On Fri, Jun 5, 2015 at 3:01 PM, Pavel Pisa wrote: > Hello Gedare, > > thanks for response. > > On Friday 05 of June 2015 18:18:15 Gedare Bloom wrote: >> On Tue, Jun 2, 2015 at 9:39 AM, Pavel Pisa wrote: >> > Please, look on the files and express your opinion. >> > The new temporary top level header files is tms5702.h. >> > It should replace tms570.h. >> >> I took a glance at some, I didn't see anything overtly bad, although >> the generated license is (1) interleaved with excess newlines > > That is already corrected in the script. > >> and (2) possibly spurious to apply on automatically generated content. >> The script he wrote should specify itself what the license is on generated >> files. I'd recommend something that is as permissive as possible when >> dealing with generated files. > > The license is not part of the script, it is provided as template > so everybody who contributes can add his/her name there. > > I support to provide some license in the headers because > if there is no license then users have no guarantee that > would not be sued. At least in our country code without > writtent premission or copyright can be considered > as fully owned by author. We have switched to two clause BSD, > which is really permissive license after last discussion. > I would even prefer that over RTEMS specific one because it > allows to use header files even in other projects. > I.e. U-boot for TMS570 would be great even that I do not > expect to find resources for that. > Good, perhaps tms570 can be a next target for umon after this GSoC's effort with beagleboard. > Last but not least, Premysl Houdek has spent considerable time > on that work so he deserves some attribution in my opinion. > Certainly! I don't mind that the author notice and license appears, I just meant that it should be appropriate to the fact the code is generated automatically, and I'm happy to see 2-BSD used. >> I'll be curious to see what tms570 users think of the generated headers. >> >> > As for the header files organization, we propose to >> > move peripherals registers header files to the >> > subdirectory of BSP include path. But because Texas Instruments >> > IP blocks can appear even on slightly modified chips we >> > do not propose tms570 name. Our idea is to use "tmsreg" name >> > and use peripherals headers file names in lowercase form. >> > The files would be generally included from code through >> > "tms570.h". >> >> I'm fine with the more generic use of names, although I might prefer >> separation of tms_reg. We also have some generic BSPs that span >> multiple boards, and I think we prefer something like generic_tms_... >> now, e.g. generic_or1k was recently added. Older generic code used >> something more like gen5200. If the IP blocks may be unrelated to the >> TMS line however, it might be sensible to have something more like >> generic_ti_... >> >> However, until the code is actually shared by multiple BSPs, I might >> prefer to see it kept local to the tms570. > > Yes I agree to keep them local for now but moving to include subdirs > ensures that they do not mix with the real programmers written BSP > files. As for the name we could use something like ti_hercules. > In the fact we should use the gen_ti_hercules for BSP if we > expect to extend it in future for RM48 and RM57. Ti tools seems > to put generic stuff of CCS under "Hercules" name so there is some > hope that they keep IPs from name clashing in that family. > We have now RM48 boards because paying industry partner wants > or Matlab/Simulink for both TMS570 and RM48 now. But that project > is based on Ti tools unfortunately. > Oh, yes, a subdir to encapsulate all of them would be good, especially with their rather simple names. Using ti_hercules should be fine. >> > Do you agree with proposal? >> > Have you some more ideas? >> > >> > The adjustment of actual BSP sources for the new header files >> > is minimal. See separate commits. The BSP builds completely >> > with all examples. We plan more testing in next days. >> >> A document of what/how testing was done would be nice, and a >> relatively good (English) report about the whole process would help I >> think, if time and energy permit. > > I hope that we get to better documentation but the testing is > critical now. Next task is Ethernet support, it is on the Premek's > thesis check list to be defended. He has spent to much time on headers > so he needs to postpone his thesis till end of year to finish that. > Another important task is to implement correct startup but > it is above his planned involvement. > > As for other thesis, Jan Dolezal's i386 VESA work, he defends > his thesis over next week and it is written in English so I post > the link as it is published on the university pages. It can be > copied to RTEMS as well then. > OK sounds good. I read a previous draft of Jan's thesis it seemed nice at the time! Good luck! > Best wishes, > >Pavel > >
Re: Error while compiling rtems main branch for sparc
Hi, installing pax work. But you have to again do the bootstrap step, configuration and compiling. Thanks. Thanks, Saurabh Gadia On Fri, Jun 5, 2015 at 12:44 PM, Gedare Bloom wrote: > I'm not really sure, but I think you probably have to re-run configure. > > On Fri, Jun 5, 2015 at 3:40 PM, Saurabh Gadia wrote: > > Hi Gedare, > > I installed pax but same problem persists. So should I again bootstrap > the > > complete thing or do we have to refer pax in any make or config files? > > > > Thanks, > > > > Saurabh Gadia > > > > On Fri, Jun 5, 2015 at 10:56 AM, Saurabh Gadia wrote: > >> > >> Ok. Thanks a lot. Will continue with compiling and JPF setup this week > as > >> discussed with Cyrille. And if time permits will look into how to > emulate > >> the things in JPF. And also provide ppt in deoxygen for revised rtems > code. > >> > >> > >> On Friday, June 5, 2015, Gedare Bloom wrote: > >>> > >>> Hi Saurabh, > >>> > >>> This is a current problem in RTEMS. You need to have 'pax' installed > >>> on your development host to build the dl tests. So, it looks good to > >>> me! > >>> > >>> Gedare > >>> > >>> On Thu, Jun 4, 2015 at 9:16 PM, Saurabh Gadia wrote: > >>> > I am sorry for not attaching the patch and configuration command: > >>> > > >>> > ../rtems/configure --target=sparc-rtems4.11 --enable-rtemsbsp=sis > >>> > --enable-tests --disable-posix ENABLE_STRICT_ORDER_MUTEX=1 > >>> > > >>> > > >>> > > >>> > Thanks, > >>> > > >>> > Saurabh Gadia > >>> > > >>> > On Thu, Jun 4, 2015 at 6:08 PM, Saurabh Gadia wrote: > >>> >> > >>> >> Hi, > >>> >> I worked out that bug related to strict_mutex and gone past that > bug. > >>> >> But > >>> >> now I have issue while compiling the libtests. Below is the error > log: > >>> >> > >>> >> ''' > >>> >> sparc-rtems4.11-size syscall01.exe > >>> >>text databssdechexfilename > >>> >> 266128 6064 11456 283648 45400syscall01.exe > >>> >> cp syscall01.exe syscall01.ralf > >>> >> make[6]: Leaving directory > >>> >> > >>> >> > `/home/saurabh/dev1/kernel/b-sis/sparc-rtems4.11/c/sis/testsuites/libtests/syscall01' > >>> >> Making all in dl01 > >>> >> make[6]: Entering directory > >>> >> > >>> >> > `/home/saurabh/dev1/kernel/b-sis/sparc-rtems4.11/c/sis/testsuites/libtests/dl01' > >>> >> sparc-rtems4.11-gcc -B../../../../../sis/lib/ -specs bsp_specs > -qrtems > >>> >> -DHAVE_CONFIG_H -I. > >>> >> -I../../../../../../../rtems/c/src/../../testsuites/libtests/dl01 > -I.. > >>> >> > >>> >> > -I../../../../../../../rtems/c/src/../../testsuites/libtests/../support/include > >>> >> -mcpu=cypress -O2 -g -ffunction-sections -fdata-sections -Wall > >>> >> -Wmissing-prototypes -Wimplicit-function-declaration > >>> >> -Wstrict-prototypes > >>> >> -Wnested-externs -MT dl-o1.o -MD -MP -MF .deps/dl-o1.Tpo -c -o > dl-o1.o > >>> >> > >>> >> > ../../../../../../../rtems/c/src/../../testsuites/libtests/dl01/dl-o1.c > >>> >> mv -f .deps/dl-o1.Tpo .deps/dl-o1.Po > >>> >> w -f dl.tar dl-o1.o > >>> >> 17:44:17 up 2:31, 2 users, load average: 2.27, 0.99, 0.53 > >>> >> USER TTYLOGIN@ IDLE JCPU PCPU WHAT > >>> >> ../../../../../../tools/build/rtems-bin2c -C dl.tar dl-tar.c > >>> >> cannot open dl.tar for reading > >>> >> make[6]: *** [dl-tar.c] Error 1 > >>> >> make[6]: Leaving directory > >>> >> > >>> >> > `/home/saurabh/dev1/kernel/b-sis/sparc-rtems4.11/c/sis/testsuites/libtests/dl01' > >>> >> make[5]: *** [all-local] Error 1 > >>> >> make[5]: Leaving directory > >>> >> > >>> >> > `/home/saurabh/dev1/kernel/b-sis/sparc-rtems4.11/c/sis/testsuites/libtests' > >>> >> make[4]: *** [all] Error 2 > >>> >> make[4]: Leaving directory > >>> >> > >>> >> > `/home/saurabh/dev1/kernel/b-sis/sparc-rtems4.11/c/sis/testsuites/libtests' > >>> >> make[3]: *** [all-recursive] Error 1 > >>> >> make[3]: Leaving directory > >>> >> `/home/saurabh/dev1/kernel/b-sis/sparc-rtems4.11/c/sis/testsuites' > >>> >> make[2]: *** [all-recursive] Error 1 > >>> >> make[2]: Leaving directory > >>> >> `/home/saurabh/dev1/kernel/b-sis/sparc-rtems4.11/c/sis' > >>> >> make[1]: *** [all-recursive] Error 1 > >>> >> make[1]: Leaving directory > >>> >> `/home/saurabh/dev1/kernel/b-sis/sparc-rtems4.11/c' > >>> >> make: *** [all-recursive] Error 1 > >>> >> saurabh@saurabh-Inspiron-N5010:~/dev1/kernel/b-sis$ ls > >>> >> ''' > >>> >> > >>> >> I am not able to find dl-tar.c but we have dl-tar.Po. Can anyone > guide > >>> >> me > >>> >> on this. How should I proceed with this. > >>> >> > >>> >> Thanks, > >>> >> > >>> >> Saurabh Gadia > >>> >> > >>> >> On Mon, Jun 1, 2015 at 7:48 AM, Saurabh Gadia > wrote: > >>> >>> > >>> >>> I am on it. > >>> >>> > >>> >>> > >>> >>> On Monday, June 1, 2015, Gedare Bloom wrote: > >>> > >>> Hi Saurabh, > >>> > >>> Please try to figure out how to fix the compile-error. You can see > >>> that the problem occurs in the #ifdef'd STRICT_ORDER_MUTEX_CODE, > so > >>> that makes sense why others have not observed the
Re: rtems-libbsd waf params
Here is what I get now: No valid arch/bsps found where --rtems-bsps=arm/raspberrypi also tried archs: armv6, arm-rtems4.11 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: rtems-libbsd waf params
On 6/06/2015 8:47 am, Yurii Shevtsov wrote: > Here is what I get now: >No valid arch/bsps found > where --rtems-bsps=arm/raspberrypi > also tried archs: armv6, arm-rtems4.11 Have you installed the BSP ? What is the full rtems configure command line ? What is the full waf configure command line ? Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: rtems-libbsd waf params
On 6/06/2015 4:38 am, Yurii Shevtsov wrote: > 2015-06-05 21:02 GMT+03:00 Sujay Raj : >> From what I could make out from the documentation in README.waf, >> in waf configure , --prefix is where you would like to install rtems-libbsd, >> --rtems is where you installed your bsp, that is, the '--prefix' you >> passed while configuring the bsp. >> '--rtems-tools' points to the tool-set you built using RSB (the >> --prefix you passed to the RSB) and >> '--rtems-bsps' should be provided with the string 'architecture/bsp'. >> >> (everything without quotes, quotes are just for illustration) >> >> usually --prefix and --rtems would have the same value, but it depends >> on how you are setting things up. > > Thanks, I'll try. > The 'waf --help' command lists all the options. >> Further, from libbsd.txt, in config.inc BSP should only be the name of >> your BSP, not c/raspberrypi/make. > > Can't agree with you here. This path is exactly what is needed for > successful build > The libbsd.txt details building with make and README.waf details building with waf. If you think README.waf needs more detail please feel free to send me a patch. There is also an option '-net-test-config' where you can supply the path to a config.inc type file outside the source tree. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: USB Host and MMC/SD Card Stack
On 6/06/2015 2:27 am, Daniel Gutson wrote: > Hi Sebastian, Sebastian is away at the moment so I will answer. >is this industrial-grade fully functional, or has known issues? This is goal. > If it has, we could fix them. Please test and send any issues or even better patches. We would welcome them. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Error while compiling rtems main branch for sparc
Hi, I tried to run spsem02 test case and found that the results were not as per mentioned in the respective document. And even document had some typos which I have corrected in my branch. *** BEGIN OF TEST SPSEM 2 *** init: S0 created init: S1 created init: TA01 created with priority 36 init: TA02 created with priority 34 init: TA03 created with priority 32 TA01: started with priority 36 TA01: priority 36, holding S0 TA01: priority 36, holding S0, S1 TA02: started with priority 34 TA03: started with priority 32 TA01: priority 32, holding S0, S1 TA02: priority 34, holding S1 *TA02: suspendingTA01: priority 36, holding S0 ---> priority not properly stepped down!!!TA03: priority 32, holding S0* TA03: priority 32 TA03: exiting TA01: priority 36 TA01: exiting *** END OF TEST SPSEM 2 *** You can find link for my wiki and github: github link: https://github.com/saurabhgadia4/rtems wiki link: https://devel.rtems.org/wiki/GSoC/2015/NestedMutex I feel like I should implement my solution very soon along with progressing on JPF and check if expected output is achieved or not. Thanks, Saurabh Gadia On Fri, Jun 5, 2015 at 1:42 PM, Saurabh Gadia wrote: > Hi, > installing pax work. But you have to again do the bootstrap step, > configuration and compiling. > Thanks. > > Thanks, > > Saurabh Gadia > > On Fri, Jun 5, 2015 at 12:44 PM, Gedare Bloom wrote: > >> I'm not really sure, but I think you probably have to re-run configure. >> >> On Fri, Jun 5, 2015 at 3:40 PM, Saurabh Gadia wrote: >> > Hi Gedare, >> > I installed pax but same problem persists. So should I again bootstrap >> the >> > complete thing or do we have to refer pax in any make or config files? >> > >> > Thanks, >> > >> > Saurabh Gadia >> > >> > On Fri, Jun 5, 2015 at 10:56 AM, Saurabh Gadia wrote: >> >> >> >> Ok. Thanks a lot. Will continue with compiling and JPF setup this week >> as >> >> discussed with Cyrille. And if time permits will look into how to >> emulate >> >> the things in JPF. And also provide ppt in deoxygen for revised rtems >> code. >> >> >> >> >> >> On Friday, June 5, 2015, Gedare Bloom wrote: >> >>> >> >>> Hi Saurabh, >> >>> >> >>> This is a current problem in RTEMS. You need to have 'pax' installed >> >>> on your development host to build the dl tests. So, it looks good to >> >>> me! >> >>> >> >>> Gedare >> >>> >> >>> On Thu, Jun 4, 2015 at 9:16 PM, Saurabh Gadia wrote: >> >>> > I am sorry for not attaching the patch and configuration command: >> >>> > >> >>> > ../rtems/configure --target=sparc-rtems4.11 --enable-rtemsbsp=sis >> >>> > --enable-tests --disable-posix ENABLE_STRICT_ORDER_MUTEX=1 >> >>> > >> >>> > >> >>> > >> >>> > Thanks, >> >>> > >> >>> > Saurabh Gadia >> >>> > >> >>> > On Thu, Jun 4, 2015 at 6:08 PM, Saurabh Gadia >> wrote: >> >>> >> >> >>> >> Hi, >> >>> >> I worked out that bug related to strict_mutex and gone past that >> bug. >> >>> >> But >> >>> >> now I have issue while compiling the libtests. Below is the error >> log: >> >>> >> >> >>> >> ''' >> >>> >> sparc-rtems4.11-size syscall01.exe >> >>> >>text databssdechexfilename >> >>> >> 266128 6064 11456 283648 45400 >> syscall01.exe >> >>> >> cp syscall01.exe syscall01.ralf >> >>> >> make[6]: Leaving directory >> >>> >> >> >>> >> >> `/home/saurabh/dev1/kernel/b-sis/sparc-rtems4.11/c/sis/testsuites/libtests/syscall01' >> >>> >> Making all in dl01 >> >>> >> make[6]: Entering directory >> >>> >> >> >>> >> >> `/home/saurabh/dev1/kernel/b-sis/sparc-rtems4.11/c/sis/testsuites/libtests/dl01' >> >>> >> sparc-rtems4.11-gcc -B../../../../../sis/lib/ -specs bsp_specs >> -qrtems >> >>> >> -DHAVE_CONFIG_H -I. >> >>> >> -I../../../../../../../rtems/c/src/../../testsuites/libtests/dl01 >> -I.. >> >>> >> >> >>> >> >> -I../../../../../../../rtems/c/src/../../testsuites/libtests/../support/include >> >>> >> -mcpu=cypress -O2 -g -ffunction-sections -fdata-sections -Wall >> >>> >> -Wmissing-prototypes -Wimplicit-function-declaration >> >>> >> -Wstrict-prototypes >> >>> >> -Wnested-externs -MT dl-o1.o -MD -MP -MF .deps/dl-o1.Tpo -c -o >> dl-o1.o >> >>> >> >> >>> >> >> ../../../../../../../rtems/c/src/../../testsuites/libtests/dl01/dl-o1.c >> >>> >> mv -f .deps/dl-o1.Tpo .deps/dl-o1.Po >> >>> >> w -f dl.tar dl-o1.o >> >>> >> 17:44:17 up 2:31, 2 users, load average: 2.27, 0.99, 0.53 >> >>> >> USER TTYLOGIN@ IDLE JCPU PCPU WHAT >> >>> >> ../../../../../../tools/build/rtems-bin2c -C dl.tar dl-tar.c >> >>> >> cannot open dl.tar for reading >> >>> >> make[6]: *** [dl-tar.c] Error 1 >> >>> >> make[6]: Leaving directory >> >>> >> >> >>> >> >> `/home/saurabh/dev1/kernel/b-sis/sparc-rtems4.11/c/sis/testsuites/libtests/dl01' >> >>> >> make[5]: *** [all-local] Error 1 >> >>> >> make[5]: Leaving directory >> >>> >> >> >>> >> >> `/home/saurabh/dev1/kernel/b-sis/sparc-rtems4.11/c/sis/testsuites/libtests' >> >>> >> make[4]: *** [all] Error 2 >> >>> >> make[4]: Leaving directory >> >>> >> >> >>> >> >> `/hom
Re: Error while compiling rtems main branch for sparc
Is this error with the default gglg priority inherit algorithm or with the onf which restores at each unlock step? If the default algorithm, the test is broken. If the alternative algorithm, the test needs to be reworked a bit to check the correct behavior for each algorithm. Fwiw the test should fail if there is an error detected. Printing a message and continuing isn't right. So this much is broken either way. Sorry to be imprecise but I don't know how you configured. If the .doc or .scn file isn't up to date, submit patches. On June 5, 2015 7:09:53 PM CDT, Saurabh Gadia wrote: >Hi, > >I tried to run spsem02 test case and found that the results were not as >per mentioned in the respective document. And even document had some >typos which I have corrected in my branch. > >*** BEGIN OF TEST SPSEM 2 *** >init: S0 created >init: S1 created >init: TA01 created with priority 36 >init: TA02 created with priority 34 >init: TA03 created with priority 32 >TA01: started with priority 36 >TA01: priority 36, holding S0 >TA01: priority 36, holding S0, S1 >TA02: started with priority 34 >TA03: started with priority 32 >TA01: priority 32, holding S0, S1 >TA02: priority 34, holding S1 >TA02: suspending >TA01: priority 36, holding S0 ---> priority not properly stepped >down!!! >TA03: priority 32, holding S0 >TA03: priority 32 >TA03: exiting >TA01: priority 36 >TA01: exiting >*** END OF TEST SPSEM 2 *** > >You can find link for my wiki and github: > >github link: https://github.com/saurabhgadia4/rtems > >wiki link: https://devel.rtems.org/wiki/GSoC/2015/NestedMutex > > >I feel like I should implement my solution very soon along with >progressing on JPF and check if expected output is achieved or not. > > > > >Thanks, > > >Saurabh Gadia > > >On Fri, Jun 5, 2015 at 1:42 PM, Saurabh Gadia wrote: > >Hi, > >installing pax work. But you have to again do the bootstrap step, >configuration and compiling. > >Thanks. > > >Thanks, > > >Saurabh Gadia > > >On Fri, Jun 5, 2015 at 12:44 PM, Gedare Bloom wrote: > >I'm not really sure, but I think you probably have to re-run configure. > > >On Fri, Jun 5, 2015 at 3:40 PM, Saurabh Gadia wrote: >> Hi Gedare, >> I installed pax but same problem persists. So should I again >bootstrap the >> complete thing or do we have to refer pax in any make or config >files? >> >> Thanks, >> >> Saurabh Gadia >> >> On Fri, Jun 5, 2015 at 10:56 AM, Saurabh Gadia wrote: >>> >>> Ok. Thanks a lot. Will continue with compiling and JPF setup this >week as >>> discussed with Cyrille. And if time permits will look into how to >emulate >>> the things in JPF. And also provide ppt in deoxygen for revised >rtems code. >>> >>> >>> On Friday, June 5, 2015, Gedare Bloom wrote: Hi Saurabh, This is a current problem in RTEMS. You need to have 'pax' >installed on your development host to build the dl tests. So, it looks good >to me! Gedare On Thu, Jun 4, 2015 at 9:16 PM, Saurabh Gadia >wrote: > I am sorry for not attaching the patch and configuration command: > > ../rtems/configure --target=sparc-rtems4.11 --enable-rtemsbsp=sis > --enable-tests --disable-posix ENABLE_STRICT_ORDER_MUTEX=1 > > > > Thanks, > > Saurabh Gadia > > On Thu, Jun 4, 2015 at 6:08 PM, Saurabh Gadia >wrote: >> >> Hi, >> I worked out that bug related to strict_mutex and gone past that >bug. >> But >> now I have issue while compiling the libtests. Below is the >error log: >> >> ''' >> sparc-rtems4.11-size syscall01.exe >>text databssdechexfilename >> 266128 6064 11456 283648 45400 >syscall01.exe >> cp syscall01.exe syscall01.ralf >> make[6]: Leaving directory >> >> >`/home/saurabh/dev1/kernel/b-sis/sparc-rtems4.11/c/sis/testsuites/libtests/syscall01' >> Making all in dl01 >> make[6]: Entering directory >> >> >`/home/saurabh/dev1/kernel/b-sis/sparc-rtems4.11/c/sis/testsuites/libtests/dl01' >> sparc-rtems4.11-gcc -B../../../../../sis/lib/ -specs bsp_specs >-qrtems >> -DHAVE_CONFIG_H -I. >> >-I../../../../../../../rtems/c/src/../../testsuites/libtests/dl01 -I.. >> >> >-I../../../../../../../rtems/c/src/../../testsuites/libtests/../support/include >> -mcpu=cypress -O2 -g -ffunction-sections -fdata-sections -Wall >> -Wmissing-prototypes -Wimplicit-function-declaration >> -Wstrict-prototypes >> -Wnested-externs -MT dl-o1.o -MD -MP -MF .deps/dl-o1.Tpo -c -o >dl-o1.o >> >> >../../../../../../../rtems/c/src/../../testsuites/libtests/dl01/dl-o1.c >> mv -f .deps/dl-o1.Tpo .deps/dl-o1.Po >> w -f dl.tar dl-o1.o >> 17:44:17 up 2:31, 2 users, load average: 2.27, 0.99, 0.53 >> USER TTYLOGIN@ IDLE JCPU PCPU WHAT >> ../../../../../../tools/build/rtems-bin2c -C dl.tar dl-tar.c >> cannot open d
Re: Error while compiling rtems main branch for sparc
This is the test committed with the original ticket #2124 ticket see https://devel.rtems.org/ticket/2124 and http://comments.gmane.org/gmane.os.rtems.devel/78. The test is a bit confusing because the output in .scn matches when configured without RTEMS_ENABLE_STRICT_ORDER_MUTEX=1 but doesn't match when configured with that option. It definitely should be an explicit failure (rather than an output mismatch) to handle both configuration cases. Also updating the .doc to include a note about testing strict order mutexes would probably be best. On Fri, Jun 5, 2015 at 9:57 PM, Joel Sherrill wrote: > Is this error with the default gglg priority inherit algorithm or with the > onf which restores at each unlock step? If the default algorithm, the test > is broken. If the alternative algorithm, the test needs to be reworked a > bit to check the correct behavior for each algorithm. > > Fwiw the test should fail if there is an error detected. Printing a > message and continuing isn't right. So this much is broken either way. > > Sorry to be imprecise but I don't know how you configured. > > If the .doc or .scn file isn't up to date, submit patches. > > On June 5, 2015 7:09:53 PM CDT, Saurabh Gadia wrote: > >Hi, > > > >I tried to run spsem02 test case and found that the results were not as > >per mentioned in the respective document. And even document had some > >typos which I have corrected in my branch. > > > >*** BEGIN OF TEST SPSEM 2 *** > >init: S0 created > >init: S1 created > >init: TA01 created with priority 36 > >init: TA02 created with priority 34 > >init: TA03 created with priority 32 > >TA01: started with priority 36 > >TA01: priority 36, holding S0 > >TA01: priority 36, holding S0, S1 > >TA02: started with priority 34 > >TA03: started with priority 32 > >TA01: priority 32, holding S0, S1 > >TA02: priority 34, holding S1 > >TA02: suspending > >TA01: priority 36, holding S0 ---> priority not properly stepped > >down!!! > >TA03: priority 32, holding S0 > >TA03: priority 32 > >TA03: exiting > >TA01: priority 36 > >TA01: exiting > >*** END OF TEST SPSEM 2 *** > > > >You can find link for my wiki and github: > > > >github link: https://github.com/saurabhgadia4/rtems > > > >wiki link: https://devel.rtems.org/wiki/GSoC/2015/NestedMutex > > > > > >I feel like I should implement my solution very soon along with > >progressing on JPF and check if expected output is achieved or not. > > > > > > > > > >Thanks, > > > > > >Saurabh Gadia > > > > > >On Fri, Jun 5, 2015 at 1:42 PM, Saurabh Gadia wrote: > > > >Hi, > > > >installing pax work. But you have to again do the bootstrap step, > >configuration and compiling. > > > >Thanks. > > > > > >Thanks, > > > > > >Saurabh Gadia > > > > > >On Fri, Jun 5, 2015 at 12:44 PM, Gedare Bloom wrote: > > > >I'm not really sure, but I think you probably have to re-run configure. > > > > > >On Fri, Jun 5, 2015 at 3:40 PM, Saurabh Gadia wrote: > >> Hi Gedare, > >> I installed pax but same problem persists. So should I again > >bootstrap the > >> complete thing or do we have to refer pax in any make or config > >files? > >> > >> Thanks, > >> > >> Saurabh Gadia > >> > >> On Fri, Jun 5, 2015 at 10:56 AM, Saurabh Gadia wrote: > >>> > >>> Ok. Thanks a lot. Will continue with compiling and JPF setup this > >week as > >>> discussed with Cyrille. And if time permits will look into how to > >emulate > >>> the things in JPF. And also provide ppt in deoxygen for revised > >rtems code. > >>> > >>> > >>> On Friday, June 5, 2015, Gedare Bloom wrote: > > Hi Saurabh, > > This is a current problem in RTEMS. You need to have 'pax' > >installed > on your development host to build the dl tests. So, it looks good > >to > me! > > Gedare > > On Thu, Jun 4, 2015 at 9:16 PM, Saurabh Gadia > >wrote: > > I am sorry for not attaching the patch and configuration command: > > > > ../rtems/configure --target=sparc-rtems4.11 --enable-rtemsbsp=sis > > --enable-tests --disable-posix ENABLE_STRICT_ORDER_MUTEX=1 > > > > > > > > Thanks, > > > > Saurabh Gadia > > > > On Thu, Jun 4, 2015 at 6:08 PM, Saurabh Gadia > >wrote: > >> > >> Hi, > >> I worked out that bug related to strict_mutex and gone past that > >bug. > >> But > >> now I have issue while compiling the libtests. Below is the > >error log: > >> > >> ''' > >> sparc-rtems4.11-size syscall01.exe > >>text databssdechexfilename > >> 266128 6064 11456 283648 45400 > >syscall01.exe > >> cp syscall01.exe syscall01.ralf > >> make[6]: Leaving directory > >> > >> > > >`/home/saurabh/dev1/kernel/b-sis/sparc-rtems4.11/c/sis/testsuites/libtests/syscall01' > >> Making all in dl01 > >> make[6]: Entering directory > >> > >> > > >`/home/saurabh/dev1/kernel/b-sis/sparc-rtems4.11/c/sis/testsuites/libtests/dl01' > >>
