[PATCH] score: Use ISR lock for IO driver registration
Create implementation header file.
Update #2555.
---
cpukit/libmisc/monitor/mon-driver.c | 1 +
cpukit/sapi/Makefile.am | 1 +
cpukit/sapi/include/confdefs.h| 1 +
cpukit/sapi/include/rtems/io.h| 13 ---
cpukit/sapi/include/rtems/ioimpl.h| 65 +++
cpukit/sapi/preinstall.am | 4 +++
cpukit/sapi/src/exinit.c | 2 +-
cpukit/sapi/src/io.c | 2 +-
cpukit/sapi/src/ioclose.c | 3 +-
cpukit/sapi/src/iocontrol.c | 3 +-
cpukit/sapi/src/ioinitialize.c| 3 +-
cpukit/sapi/src/ioopen.c | 3 +-
cpukit/sapi/src/ioread.c | 3 +-
cpukit/sapi/src/ioregisterdriver.c| 15
cpukit/sapi/src/iounregisterdriver.c | 10 +++---
cpukit/sapi/src/iowrite.c | 3 +-
testsuites/sptests/sp40/init.c| 2 ++
testsuites/sptests/spsysinit01/init.c | 1 +
18 files changed, 96 insertions(+), 39 deletions(-)
create mode 100644 cpukit/sapi/include/rtems/ioimpl.h
diff --git a/cpukit/libmisc/monitor/mon-driver.c
b/cpukit/libmisc/monitor/mon-driver.c
index ebbf0ec..504d509 100644
--- a/cpukit/libmisc/monitor/mon-driver.c
+++ b/cpukit/libmisc/monitor/mon-driver.c
@@ -22,6 +22,7 @@
#endif
#include
+#include
#include
#include
diff --git a/cpukit/sapi/Makefile.am b/cpukit/sapi/Makefile.am
index 7377177..edfdfc1 100644
--- a/cpukit/sapi/Makefile.am
+++ b/cpukit/sapi/Makefile.am
@@ -13,6 +13,7 @@ include_rtems_HEADERS += include/rtems/extensionimpl.h
include_rtems_HEADERS += include/rtems/fatal.h
include_rtems_HEADERS += include/rtems/init.h
include_rtems_HEADERS += include/rtems/io.h
+include_rtems_HEADERS += include/rtems/ioimpl.h
include_rtems_HEADERS += include/rtems/mptables.h
include_rtems_HEADERS += include/rtems/cbs.h
include_rtems_HEADERS += include/rtems/profiling.h
diff --git a/cpukit/sapi/include/confdefs.h b/cpukit/sapi/include/confdefs.h
index ee2558c..89beb23 100644
--- a/cpukit/sapi/include/confdefs.h
+++ b/cpukit/sapi/include/confdefs.h
@@ -26,6 +26,7 @@
* Include the executive's configuration
*/
#include
+#include
#include
#include
#include
diff --git a/cpukit/sapi/include/rtems/io.h b/cpukit/sapi/include/rtems/io.h
index f5876a0..760d412 100644
--- a/cpukit/sapi/include/rtems/io.h
+++ b/cpukit/sapi/include/rtems/io.h
@@ -246,19 +246,6 @@ rtems_status_code rtems_io_lookup_name(
rtems_driver_name_t *device_info
) RTEMS_DEPRECATED;
-extern const size_t _IO_Number_of_drivers;
-
-extern rtems_driver_address_table _IO_Driver_address_table[];
-
-extern bool _IO_All_drivers_initialized;
-
-/**
- * @brief Initialization of all device drivers.
- *
- * Initializes all device drivers.
- */
-void _IO_Initialize_all_drivers( void );
-
#ifdef __cplusplus
}
#endif
diff --git a/cpukit/sapi/include/rtems/ioimpl.h
b/cpukit/sapi/include/rtems/ioimpl.h
new file mode 100644
index 000..5c4a82e
--- /dev/null
+++ b/cpukit/sapi/include/rtems/ioimpl.h
@@ -0,0 +1,65 @@
+/**
+ * @file
+ *
+ * @brief Classic Input/Output Manager Implementation API
+ */
+
+/*
+ * 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.
+ */
+
+#ifndef _RTEMS_IOIMPL_H
+#define _RTEMS_IOIMPL_H
+
+#include
+#include
+
+#ifdef __cplusplus
+extern "C" {
+#endif /* __cplusplus */
+
+extern const size_t _IO_Number_of_drivers;
+
+extern rtems_driver_address_table _IO_Driver_address_table[];
+
+extern bool _IO_All_drivers_initialized;
+
+/**
+ * @brief Initialization of all device drivers.
+ *
+ * Initializes all device drivers.
+ */
+void _IO_Initialize_all_drivers( void );
+
+ISR_LOCK_DECLARE( extern, _IO_Driver_registration_lock )
+
+RTEMS_INLINE_ROUTINE void _IO_Driver_registration_acquire(
+ ISR_lock_Context *lock_context
+)
+{
+ _ISR_lock_ISR_disable_and_acquire(
+&_IO_Driver_registration_lock,
+lock_context
+ );
+}
+
+RTEMS_INLINE_ROUTINE void _IO_Driver_registration_release(
+ ISR_lock_Context *lock_context
+)
+{
+ _ISR_lock_Release_and_ISR_enable(
+&_IO_Driver_registration_lock,
+lock_context
+ );
+}
+
+#ifdef __cplusplus
+}
+#endif /* __cplusplus */
+
+#endif /* _RTEMS_IOIMPL_H */
diff --git a/cpukit/sapi/preinstall.am b/cpukit/sapi/preinstall.am
index 969edfe..b1bdf48 100644
--- a/cpukit/sapi/preinstall.am
+++ b/cpukit/sapi/preinstall.am
@@ -58,6 +58,10 @@ $(PROJECT_INCLUDE)/rtems/io.h: include/rtems/io.h
$(PROJECT_INCLUDE)/rtems/$(dir
$(INSTALL_DATA) $< $(PROJECT_INCLUDE)/rtems/io.h
PREINSTALL_FILES += $(PROJECT_INCLUDE)/rtems/io.h
+$(PROJECT_INCLUDE)/rtems/ioimpl.h: include/rtems/ioimpl.h
$(PROJECT_INCLUDE)/rtems/$(dirstamp)
+ $(INSTALL_DATA) $< $(PROJECT_INCLUDE)/rtems/ioimpl.h
+PREINSTALL_FILES += $(PROJECT_INCLUDE)/rtems/ioimpl.h
+
$(PROJECT_INCLUDE)/rtems/mptables.h: include/rtems/mp
Re: BBB GSoC Projects was Re: Gsoc 2016 project proposal
On Wed, Mar 9, 2016 at 1:38 AM, punit vara wrote: > > > > On Sun, Mar 6, 2016 at 8:54 PM, punit vara wrote: >> >> >> >> On Sun, Mar 6, 2016 at 2:09 PM, Ketul Shah wrote: >>> >>> Hello Punit and all, >>> >>> According to me, Punit you must have completed some gpio test through gpio >>> API that was merged last year. So till the final result of accepted student >>> you can start working with PWM driver that plays an important role for any >>> embedded project. This would be a good kick-start for you as well as a >>> strong reason to showcase in your proposal. Try to give hardware test and >>> post the video if possible. >>> >>> Coming to further I2C and SPI can be next milestones. To me these should be >>> at the highest priorities. I had done I2C driver but was not able to make >>> the hardware test. So you can also refer that and come up with the output >>> along with best modifications. >>> >>> Next target you can set for SPI after both drivers are tested and committed. >>> >>> For the references you can always have a loot at code of GPIO >>> API,MINIX,FreeBSD for BBB drivers. >>> >>> Any suggestions ? >>> >>> In case of any queries you can always ping. >>> >>> Cheers, >>> Ketul >>> >>> On 5 March 2016 at 01:02, Marcos Díaz >>> wrote: We use I2c but using drivers from TI's baremetal drivers they provide in their StarterWare software suite. So, currently we cannot commit that into RTEMS. But those drivers should be very useful to port to RTEMS. On Wed, Mar 2, 2016 at 5:53 PM, Joel Sherrill wrote: > > > > On Wed, Mar 2, 2016 at 2:22 PM, Marcos Díaz > wrote: >> >> >> >> On Wed, Mar 2, 2016 at 4:56 PM, Joel Sherrill wrote: >>> >>> >>> >>> On Wed, Mar 2, 2016 at 1:41 PM, punit vara wrote: Yes I have checked previous year work of ketul . He has done ADC and GPIO BSP . It seems SPI,USB BSP need to be developed as I have checked rtems.git and I am not sure about I2C .I asked last year student Ketul .According to him , I2c is also need to be modified. I tried to contact Ben but he is unreachable on mailing list :-( >>> >>> Let me reach out to Ketul and see if a private ping helps. >>> >>> Start with the assumption that USB needs work. That involves the >>> rtems-libbsd tree and >>> there is likely code to import from FreeBSD that will help a lot. >>> >>> SPI and i2c are close to one another in my understanding. Likely Ketul >>> is referring to changes >>> in the RTEMS i2c interfaces. >>> >>> My recollection is that the NIC had performance issues based on the >>> version of U-Boot >>> used. There was some traffic at the end of GSoC about this. I don't >>> know if it was >>> ever resolved. But the NIC should work. Maybe worth benchmarking. >> >> We had more of these problems when trying to use I2C. It was fixed in >> https://git.rtems.org/rtems/commit/?id=8c5c53f4788eb74264a053f8293fed26da85b764. >> I think we dont need tos ee these problems any more >>> >>> > > Marcos.. does this mean that the BBB i2c is complete now? > > And is my understanding that this covers SPI correct? > > What else on the BBB is left? > > --joel > >>> >>> --joel >>> >>> On Thu, Mar 3, 2016 at 12:57 AM, Joel Sherrill wrote: > > > > On Wed, Mar 2, 2016 at 1:24 PM, Hesham Almatary > wrote: >> >> Hi Punit, >> >> You can have a look at the open projects here [1] and find one or >> more >> that match your experience/interests. >> >> [1] https://devel.rtems.org/wiki/Developer/OpenProjects >> > > I have added Ben Gras. He knows more about the BBB than anyone. I am > unsure what is left > to do. Have you compared the status of last year's projects versus > the git repository? > > --joel > >> >> Regards, >> >> On Wed, Mar 2, 2016 at 7:14 PM, punit vara >> wrote: >> > I have asked for BBB BSP proposal before but I haven't found any >> > good >> > response from someone. What are the projects you are going to >> > mentor @joel ? >> > Would anyone please suggest me to pick any other project ? >> > >> > ___ >> > 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 > > >>> >>> >>> __
Re: Building RTEMS hello world image using CMake
Hi, Sorry for the delay. I am attaching my CMakeLists.txt with this.The test.c is the source code from examples-v2. I created a separate build folder to hold the builds. And from inside that gave the command $ cmake .. and then for the generated makefile,I gave the command $ make all After the executable was created,I used the simulator to get the output $ $HOME/development/rtems/4.11.0-rc1/bin/sparc-rtems4.11-run ./HELLO And then I got the ouput as *** MODIFIED HELLO WORLD TEST *** Hello Sambeet!How are You? *** END OF MODIFIED HELLO WORLD TEST *** On Mon, Mar 14, 2016 at 5:14 AM, Chris Johns wrote: > On 14/03/2016 09:33, Pavel Pisa wrote: > >> Hello Chris and others, >> >> On Sunday 13 of March 2016 22:28:14 Chris Johns wrote: >> >>> On 13/03/2016 1:53 AM, Gedare Bloom wrote: >>> If this works for you, and you are sufficiently interested, it would be useful to provide CMake example for the examples-v2.git repository for others to benefit. >>> >>> I am not sure about adding this to examples-v2.git. I would prefer it to >>> be a waf only build system. I am not sure if make support is still >>> present and working but it will go once Makefile.inc goes as it is not >>> supported in the new RTEMS waf build system. >>> >> >> please, consider to keep/add some mechanism, rule etc. >> to export Makefile.inc equivalent content to some file >> in /opt/rtems/arch/bsp directory in easily readable form >> (make, shell assignments or some other sed parsable format). >> > > We have discussed this before in detail. I refer you to the thread from > October last year .. > https://lists.rtems.org/pipermail/devel/2015-October/012659.html. > > I could try to find how to do that when I find time to >> switch to 4.12 and WAF. I think, that it is so minimal >> information and it worth to be archived/documented with >> installed BSP anyway and if it is in easily readable form >> then it is better. >> > > The project as a whole needs to address this issue in a robust method and > what is made available as an interface for make file based applications > should be the same interface for waf, cmake, scons, nmake, jam, or even a > hand written batch file on Windows (haha). > > I see future when this information is not stored and easily >> readable from installed libraries tree, as a real problem, >> so I vote to not cut support for other make systems >> for applications. >> > > RTEMS installs many files that are not human readable, for example all > library archives and tools, (nm, readelf etc) are provided to examine them. > The problem with easy to read files and exposing this type of information > is users not using the provided API and then being disappointed when the > format changes. Being able to easily access and review the information > installed is important, it maybe via a provided tool. > > How you propose to maintain for >> example Microwindows and other libraries in future? >> > > https://lists.rtems.org/pipermail/devel/2015-October/012666.html > > Being able to build a make based application is not going away. What RTEMS > uses to build itself is the domain of the RTEMS kernel and should not > effect any user application in anyway. We could decide to build RTEMS using > manually edited Power Shell batch files only on Windows and a user's > application should not notice. > > Makefile.inc is broken because it exports internal information we cannot > control and maintain and we have no choice in what we do. We cannot state > these leaking internal makefile fragments are now part of the formally > exported API and we cannot determine what users have used on purpose or by > accident. We can only create an API and move forward and address specific > user issues as they arise. The key issue internally in RTEMS with the BSP > .cfg files is the wide variations of how things are done and it is this > that exported. I suspect most BSP developers never considered what they did > in a BSP deep in RTEMS was visible to user applications and nor should they > have needed too. > > The other important fact is not all users use make or Makefile.inc because > it is only usable in make based application. I am one because Makefile.inc > is inherently broken and leaks uncontrollable details into applications. > This means for a long time, and I would say easily over 10 years RTEMS has > left other build systems users out in the cold. This needs to end and we > need to provide support for all possible build systems. > > If these libraries are rewritten to WAF build then >> each time when mainline is changed it would require >> to analyze and update WAF based fork. May it be that >> it stay to be solved by RSB. But again forcing every project >> and application to be build through RSB is not win either. >> > > This is not what is being stated and it never has. Please do not > confuse the fact the examples-v2 is using waf as a statement that all RTEMS > applications _must_ be built with waf. The whole point of offeri
Re: Porting Rock on RTEMS as GSoC project
Hi, I have followed the instructions on the https://devel.rtems.org/wiki/Developer/Simulators/QEMU#Usingthertems-testingModule But each time I run the pc386 simscript, I get the message on the console tcg doesn't support requested feature:cpuid.01h.edx.vme[bit 1] and then nothing happens, I do not get any output. Can someone resolve this error? On Fri, Mar 4, 2016 at 8:08 PM, Gedare Bloom wrote: > The quickest way to get started is to follow the directions at > > https://devel.rtems.org/wiki/Developer/Simulators/QEMU#Usingthertems-testingModule > > you can use the rtems-source-builder/bare/devel/qemu.bset to compile qemu. > > On Thu, Mar 3, 2016 at 10:30 PM, Sambeet Panigrahi > wrote: > > Thank you. I would still like to continue with my work with Rock because > I > > like it and the experience would help. > > So I did not get your previous answer.How am I supposed to run the build > > conf?Qemu is an emulator so I can run it on my system and then emulate > > i386-rtems/pc486 BSP and then try running Rock on it. > > > > https://devel.rtems.org/wiki/Developer/Simulators/QEMU > > > > Can you be a little more elaborate please? > > > > On Thu, Mar 3, 2016 at 12:54 PM, Sambeet Panigrahi > > wrote: > >> This is not an open project. But Joel has suggested for a ROS port.Will > >> that > >> be a feasible project for GSoC-2016? Is RTEMS community interested for a > >> ROS > >> port if I can find co-mentors? > >> > >> On Mar 3, 2016 11:17 PM, "Gedare Bloom" wrote: > >>> > >>> The IoT project is interesting, but it needs some additional fleshing > >>> out. I tend to agree with Sebastian's interpretation of the lack of > >>> interest from the Rock community will make it hard to complete a GSoC > >>> successfully. > >>> > >>> On Thu, Mar 3, 2016 at 10:19 AM, Sambeet Panigrahi > >>> wrote: > >>> > Hi, > >>> > I have had the opportunity of talking to Sebastian Huber. He does not > >>> > consider the porting of Rock on RTEMS as a suitable GSoC project.In > his > >>> > words > >>> > > >>> > "since the rock project seems to have no interest in RTEMS support I > >>> > don't > >>> > think this is a suitable GSoC project" > >>> > > >>> > I have made some progress in understanding CMake and rock libraries > for > >>> > the > >>> > purpose of the port. But the fact is the replies have been really > late. > >>> > It > >>> > is true to some extent. Should I reconsider the project? > >>> > If so, my next choice after Tiny RTEMS is the IOT project. How far do > >>> > you > >>> > think that is feasible? > >>> > Regards > >>> > Sambeet > >>> > > >>> > > >>> > On Thu, Feb 25, 2016 at 10:55 PM, Gedare Bloom > >>> > wrote: > >>> >> > >>> >> There is no official work. If he has been answering questions, that > is > >>> >> good. You should work on creating a suitably complete proposal, and > >>> >> you should attempt to recreate the prior work as well as you can. We > >>> >> do not want you spending the first chunk of summer just getting to > the > >>> >> point that previous attempts got already. > >>> >> > >>> >> Gedare > >>> >> > >>> >> On Wed, Feb 24, 2016 at 1:28 PM, Sambeet Panigrahi > >>> >> wrote: > >>> >> > Hi, > >>> >> > I have talked with previous socis students and people from > dfki.They > >>> >> > are > >>> >> > all > >>> >> > ready to answer questions, but not hold any official position. I > >>> >> > have > >>> >> > contacted Martin Zenzes of dfki and he has been very helpful in > >>> >> > helping > >>> >> > me > >>> >> > to understand the project and I quote from his mail: > >>> >> > > >>> >> > "and lets say you can ask me anything, but i'm hesitant to fill > >>> >> > official > >>> >> > positions?" > >>> >> > > >>> >> > So will it solve the purpose.Does he need to apply for > co-mentoring > >>> >> > with > >>> >> > google or is there some official work involved? > >>> >> > > >>> >> > Rock co-mentor is not mandatory, but highly encouraged and will > >>> >> > improve your project's chances to be accepted and to be > successful. > >>> >> > You should reach out to the SOCIS student and mentors to see if > they > >>> >> > would be willing to co-mentor for GSoC. > >>> >> > > >>> >> > TinyRTEMS is not a great project currently as there are many > efforts > >>> >> > ongoing that make this a moving target. The most likely work to be > >>> >> > done is to fix the remaining linkcmds files (ld linker scripts) to > >>> >> > add > >>> >> > the right KEEP() directives so that our gcc per-function and > >>> >> > per-section optimizations work correctly. I don't see this as > >>> >> > sufficient for GSoC currently. > >>> >> > > >>> >> > Gedare > >>> >> > > >>> >> > On Sun, Feb 14, 2016 at 1:38 AM, Sambeet Panigrahi > >>> >> > wrote: > >>> >> >> I have been trying to reach potential co-mentors from the Rock > >>> >> >> community.However the response has not been that good. Is > >>> >> >> co-mentoring > >>> >> >> a > >>> >> >> compulsory condition? I also wanted to know if Tiny RTEMS project > >>> >> >> can > >>> >> >> be > >>>
RTEMS testing module does not execute
Hi, I have followed the instructions on the https://devel.rtems.org/wiki/Developer/Simulators/QEMU#Usingthertems-testingModule But each time I run the pc386 simscript as mentioned in the page, I get the message on the console tcg doesn't support requested feature:cpuid.01h.edx.vme[bit 1] and then nothing happened for an hour or more.After that I had to kill the process.Is it an error or the processing just takes this much time usually? Can someone provide a solution for this? ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
