Re: USB Host and MMC/SD Card Stack
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
Re: [PATCH 09/45] score: New timer server implementation
On 17/05/15 04:36, Gedare Bloom wrote: -/* FIXME: This locking approach for SMP is improvable! */ + ++watchdogs->generation; We should probably try to file a ticket associated with any FIXME type comments, and refer to it in the FIXME too. Yes, in this case it is: https://devel.rtems.org/ticket/2131 -- 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
Re: [PATCH 18/45] score: Add Thread_queue_Control::Lock
On 17/05/15 14:14, Gedare Bloom wrote: On Sun, May 17, 2015 at 7:04 AM, Gedare Bloom wrote: On Fri, May 15, 2015 at 7:41 AM, Sebastian Huber wrote: /** - * @brief Gets a pointer to the "first" thread on the_thread_queue. + * @brief Returns the first thread on the thread queue if it exists, otherwise + * @c NULL (locked). + * + * The caller must be the owner of the thread queue lock. + * + * @param[in] the_thread_queue The thread queue. * - * This function returns a pointer to the "first" thread - * on the_thread_queue. The "first" thread is selected - * based on the discipline of the_thread_queue. + * @retval NULL No thread is present on the thread queue. + * @retval first The first thread on the thread queue according to the enqueue + * order. + */ +Thread_Control *_Thread_queue_First_locked( + Thread_queue_Control *the_thread_queue +); + In other places we call such a function variant _unprotected. In the doxygen, I don't know what you mean by @c NULL (locked) in the @brief, or why there are two @brief. Please clarify the distinctions between _locked(), _critical(), and _unprotected(). The _locked() is commonly used in Linux and FreeBSD and indicates that the caller must be the lock owner. The _unprotected() is mainly used for the chains. Once the Giant lock is eliminated, we can delete the "protected" chain variants and drop the _unprotected(). What about @c NULL (locked) -> @c NULL (caller locked variant)? The _critical() functions call _Thread_Dispatch_disable_critical() and do an ISR lock to thread dispatch disabled transition to carry out scheduler operations. -- 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
Re: [PATCH 20/45] score: More thread queue operations
On 17/05/15 13:23, Gedare Bloom wrote:
On Fri, May 15, 2015 at 7:41 AM, Sebastian Huber
wrote:
Move thread queue discipline specific operations into
Thread_queue_Operations. Use a separate node in the thread control
block for the thread queue to make it independent of the scheduler data
structures.
Update #2273.
---
[...]
const Thread_queue_Operations _Thread_queue_Operations_default = {
- .priority_change = _Thread_queue_Do_nothing_priority_change
+ .priority_change = _Thread_queue_Do_nothing_priority_change,
+ .extract = _Thread_queue_Do_nothing_extract
};
Any reason not to set default values for the other operations? Or
explicitly to NULL?
I add this comment:
/* The default operations are only used in _Thread_Change_priority() and
_Thread_Timeout() and don't have a thread queue associated with them, so
the enqueue and first operations are superfluous. */
I just noticed that the dequeue operation is obsolete. I will remove it.
const Thread_queue_Operations _Thread_queue_Operations_FIFO = {
- .priority_change = _Thread_queue_Do_nothing_priority_change
+ .priority_change = _Thread_queue_Do_nothing_priority_change,
+ .initialize = _Thread_queue_FIFO_initialize,
+ .enqueue = _Thread_queue_FIFO_enqueue,
+ .dequeue = _Thread_queue_FIFO_dequeue,
+ .extract = _Thread_queue_FIFO_extract,
+ .first = _Thread_queue_FIFO_first
};
const Thread_queue_Operations _Thread_queue_Operations_priority = {
- .priority_change = _Thread_queue_Priority_priority_change
+ .priority_change = _Thread_queue_Priority_priority_change,
+ .initialize = _Thread_queue_Priority_initialize,
+ .enqueue = _Thread_queue_Priority_enqueue,
+ .dequeue = _Thread_queue_Priority_dequeue,
+ .extract = _Thread_queue_Priority_extract,
+ .first = _Thread_queue_Priority_first
};
Would it make sense to separate the _Thread_queue_Priority operations
to their own file?
Since the thread queues are initialized with the discipline enum, we
always have these operations in the executable.
--
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
Re: [PATCH 34/45] score: Do not inline SMP lock if profiling enabled
On 17/05/15 04:21, Gedare Bloom wrote: Not really related, but what is the "rule" for when we should use RTEMS_INLINE_ROUTINE versus being able to say "static inline"? This file already used "static inline" and this is fine, since it requires at least C11 or C++11. We should eliminate RTEMS_INLINE_ROUTINE and maybe define inline to __inline__ if desired in basedefs.h. -- 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
Re: [PATCH 40/45] timecounter: Import from FreeBSD
On 17/05/15 15:19, Gedare Bloom wrote: + * $FreeBSD$ >+ */ >+ I assume the code in this commit is all directly imported from some FreeBSD so I'm not going to review it too closely, but I do have one question. How are we tracking the upstream version? Should we include the populated $FreeBSD$ tag (checked-out id)? Ok, I change it to "$FreeBSD r277406 /2015-01-20T///03:54:30//Z$". -- 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
Re: [PATCH 40/45] timecounter: Import from FreeBSD
On 18/05/15 09:46, Sebastian Huber wrote: On 17/05/15 15:19, Gedare Bloom wrote: + * $FreeBSD$ >+ */ >+ I assume the code in this commit is all directly imported from some FreeBSD so I'm not going to review it too closely, but I do have one question. How are we tracking the upstream version? Should we include the populated $FreeBSD$ tag (checked-out id)? Ok, I change it to "$FreeBSD r277406 /2015-01-20T///03:54:30//Z$". I like smart e-mail clients, this should be: $FreeBSD r277406 2015-01-20T03:54:30Z$ -- 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
Re: [PATCH 41/45] timecounter: Use uint32_t instead of u_int
On 17/05/15 15:22, Gedare Bloom wrote: On Fri, May 15, 2015 at 7:47 AM, Sebastian Huber wrote: From: Alexander Krutwig FreeBSD assumes that u_int is a 32-bit integer type. This is wrong for some 16-bit targets supported by RTEMS. Update #2271. --- Can we undef u_int and redefine it to uint32_t instead? This will be a more localized RTEMS-specific change. I think this is very confusing. This patch is separate since we try to submit it to FreeBSD. -- 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
Re: [PATCH 18/45] score: Add Thread_queue_Control::Lock
On Mon, May 18, 2015 at 3:20 AM, Sebastian Huber wrote: > > > On 17/05/15 14:14, Gedare Bloom wrote: >> >> On Sun, May 17, 2015 at 7:04 AM, Gedare Bloom wrote: >>> >>> On Fri, May 15, 2015 at 7:41 AM, Sebastian Huber >>> wrote: /** - * @brief Gets a pointer to the "first" thread on the_thread_queue. + * @brief Returns the first thread on the thread queue if it exists, otherwise + * @c NULL (locked). + * + * The caller must be the owner of the thread queue lock. + * + * @param[in] the_thread_queue The thread queue. * - * This function returns a pointer to the "first" thread - * on the_thread_queue. The "first" thread is selected - * based on the discipline of the_thread_queue. + * @retval NULL No thread is present on the thread queue. + * @retval first The first thread on the thread queue according to the enqueue + * order. + */ +Thread_Control *_Thread_queue_First_locked( + Thread_queue_Control *the_thread_queue +); + >>> >>> In other places we call such a function variant _unprotected. In the >>> doxygen, I don't know what you mean by @c NULL (locked) in the @brief, >>> or why there are two @brief. >> >> Please clarify the distinctions between _locked(), _critical(), and >> _unprotected(). > > > The _locked() is commonly used in Linux and FreeBSD and indicates that the > caller must be the lock owner. The _unprotected() is mainly used for the > chains. Once the Giant lock is eliminated, we can delete the "protected" > chain variants and drop the _unprotected(). > OK. > What about @c NULL (locked) -> @c NULL (caller locked variant)? > Well I don't see a need for anything in parens. I first read the (locked) to imply this was a condition. I would instead prefer a more explicit comment in the @brief that says the caller must hold the lock. Eventually of course we can assume this is the case for functions named _locked(*). > The _critical() functions call _Thread_Dispatch_disable_critical() and do an > ISR lock to thread dispatch disabled transition to carry out scheduler > operations. > > -- > 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
Re: [PATCH 34/45] score: Do not inline SMP lock if profiling enabled
On Mon, May 18, 2015 at 3:36 AM, Sebastian Huber wrote: > > > On 17/05/15 04:21, Gedare Bloom wrote: >> >> Not really related, but what is the "rule" for when we should use >> RTEMS_INLINE_ROUTINE versus being able to say "static inline"? > > > This file already used "static inline" and this is fine, since it requires > at least C11 or C++11. > > We should eliminate RTEMS_INLINE_ROUTINE and maybe define inline to > __inline__ if desired in basedefs.h. > OK this propoasl can go to a ticket for further discussion. > -- > 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
Re: [PATCH 41/45] timecounter: Use uint32_t instead of u_int
On Mon, May 18, 2015 at 3:50 AM, Sebastian Huber wrote: > > > On 17/05/15 15:22, Gedare Bloom wrote: >> >> On Fri, May 15, 2015 at 7:47 AM, Sebastian Huber >> wrote: >>> >>> From: Alexander Krutwig >>> >>> FreeBSD assumes that u_int is a 32-bit integer type. This is wrong for >>> some 16-bit targets supported by RTEMS. >>> >>> Update #2271. >>> --- >> >> Can we undef u_int and redefine it to uint32_t instead? This will be a >> more localized RTEMS-specific change. > > > I think this is very confusing. This patch is separate since we try to > submit it to FreeBSD. > OK that works better. > -- > 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 45/45] bsps: Convert clock drivers to use a timecounter
On Fri, May 15, 2015 at 7:47 AM, Sebastian Huber wrote: > From: Alexander Krutwig > > Update #2271. > --- I only looked at a few of these, they are fairly mechanical. Is there a status sheet somewhere that indicates which BSPs have which clock support? This would be useful to have, probably in a wiki table. Someone working on RPI this summer should provide its updated clock driver. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 44/45] timecounter: Use in RTEMS
On Fri, May 15, 2015 at 7:41 AM, Sebastian Huber wrote: > From: Alexander Krutwig > > Replace timestamp implementation with FreeBSD bintime and timecounters. > > New test sptests/sptimecounter02. > > Update #2271. > --- Very nice work. Did you test with the old networking stack? Do you all plan to write a report about this effort? I think it would be worthwhile to re-write some of what went into the ticket description as a paper. Gedare ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Got errors compiling latest version of rtems-libbsd
commit 66ec94a3fc3c41470f90b7d20913ea1fafc019a9 make install prints this http://paste.kolibrios.org/show/394/ I copied _timeval.h (found it somewhere in rtems folder) to rtemsbsd/include/rtems/bsd/sys/. It seemed like it helped but I got new errors http://paste.kolibrios.org/show/395/ Result doesn't depend on architecture. Thanks in advance ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Got errors compiling latest version of rtems-libbsd
On 5/18/2015 10:17 AM, Yurii Shevtsov wrote: > commit 66ec94a3fc3c41470f90b7d20913ea1fafc019a9 > make install prints this http://paste.kolibrios.org/show/394/ > I copied _timeval.h (found it somewhere in rtems folder) to > rtemsbsd/include/rtems/bsd/sys/. It seemed like it helped but I got > new errors http://paste.kolibrios.org/show/395/ > Result doesn't depend on architecture. It looks like you need to update your RTEMS tools. is now provided by newlib. I think that was done in the past month or so. > 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
GSoC/SOCIS: first IRC meeting tomorrow!
Hello GSoC and SOCIS students (mentors, and interested parties), We'll have our first "all hands meeting" for GSoC students tomorrow at 11:00 AM EST (UTC-4). Since the coding period has not officially started, this will be more of a meet-and-greet than anything else. I look forward to checking in with everyone! If for some reason you (student) can't make it tomorrow, drop me an email so I can give you personal instructions. Gedare ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
