Re: [PATCH] grspw: descriptor tables no longer statically allocated
Hello,
Haven't tested but seems good.
Thanks,
Daniel
On 01/21/2015 05:05 PM, Gedare Bloom wrote:
Claudio and Daniel H,
OK to commit?
-Gedare
On Tue, Dec 23, 2014 at 10:08 PM, Gedare Bloom wrote:
This is a patch proposed for PR 1761
[https://devel.rtems.org/ticket/1761]. Comment if OK or not.
On Tue, Dec 23, 2014 at 10:05 PM, Gedare Bloom wrote:
From: Daniel Ramirez
---
c/src/lib/libbsp/sparc/shared/spw/grspw.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/c/src/lib/libbsp/sparc/shared/spw/grspw.c
b/c/src/lib/libbsp/sparc/shared/spw/grspw.c
index b311500..d3eb9b9 100644
--- a/c/src/lib/libbsp/sparc/shared/spw/grspw.c
+++ b/c/src/lib/libbsp/sparc/shared/spw/grspw.c
@@ -84,6 +84,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -149,8 +150,6 @@ typedef struct {
#define BUFMEM_PER_LINK
(SPACEWIRE_TXBUFS_NR*(SPACEWIRE_TXD_SIZE+SPACEWIRE_TXH_SIZE) +
SPACEWIRE_RXBUFS_NR*SPACEWIRE_RXPCK_SIZE)
-#define SPW_ALIGN(p,c) unsigned int)(p))+((c)-1))&~((c)-1))
-
typedef struct {
/* configuration parameters */
spw_config config;
@@ -190,9 +189,6 @@ typedef struct {
#ifdef GRSPW_STATIC_MEM
unsigned int membase, memend, mem_bdtable;
-#else
- char _rxtable[SPACEWIRE_BDTABLE_SIZE*2];
- char _txtable[SPACEWIRE_BDTABLE_SIZE*2];
#endif
LEON3_SPACEWIRE_Regs_Map *regs;
@@ -1383,8 +1379,8 @@ static int grspw_hw_init(GRSPW_DEV *pDev) {
pDev->rx = (SPACEWIRE_RXBD *) pDev->mem_bdtable;
pDev->tx = (SPACEWIRE_RXBD *) pDev->mem_bdtable +
SPACEWIRE_BDTABLE_SIZE;
#else
-pDev->rx = (SPACEWIRE_RXBD *) SPW_ALIGN(&pDev->_rxtable,
SPACEWIRE_BDTABLE_SIZE);
-pDev->tx = (SPACEWIRE_TXBD *) SPW_ALIGN(&pDev->_txtable,
SPACEWIRE_BDTABLE_SIZE);
+pDev->rx = (SPACEWIRE_RXBD *)
rtems_heap_allocate_aligned_with_boundry( SPACEWIRE_BDTABLE_SIZE, 1024, 0 );
+pDev->tx = (SPACEWIRE_TXBD *)
rtems_heap_allocate_aligned_with_boundry( SPACEWIRE_BDTABLE_SIZE, 1024, 0 );
#endif
SPACEWIRE_DBG("hw_init [minor %i]\n", pDev->minor);
@@ -1425,6 +1421,10 @@ static void grspw_hw_reset(GRSPW_DEV *pDev)
SPW_STATUS_WRITE(pDev, SPW_STATUS_TO | SPW_STATUS_CE | SPW_STATUS_ER
| SPW_STATUS_DE | SPW_STATUS_PE |
SPW_STATUS_WE | SPW_STATUS_IA | SPW_STATUS_EE);
/*clear status*/
SPW_CTRL_WRITE(pDev, SPW_CTRL_LINKSTART); /*start link core*/
+#ifndef GRSPW_STATIC_MEM
+free(pDev->rx);
+free(pDec->tx);
+#endif
}
static void grspw_hw_read_config(GRSPW_DEV *pDev)
--
1.8.3.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] grspw: descriptor tables no longer statically allocated
Hello,
OK with me.
Best Regards,
Cláudio
On Jan 22, 2015 8:15 AM, "Daniel Hellstrom" wrote:
> Hello,
>
> Haven't tested but seems good.
>
> Thanks,
> Daniel
>
> On 01/21/2015 05:05 PM, Gedare Bloom wrote:
>
>> Claudio and Daniel H,
>> OK to commit?
>>
>> -Gedare
>>
>> On Tue, Dec 23, 2014 at 10:08 PM, Gedare Bloom wrote:
>>
>>> This is a patch proposed for PR 1761
>>> [https://devel.rtems.org/ticket/1761]. Comment if OK or not.
>>>
>>>
>>> On Tue, Dec 23, 2014 at 10:05 PM, Gedare Bloom wrote:
>>>
From: Daniel Ramirez
---
c/src/lib/libbsp/sparc/shared/spw/grspw.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/c/src/lib/libbsp/sparc/shared/spw/grspw.c
b/c/src/lib/libbsp/sparc/shared/spw/grspw.c
index b311500..d3eb9b9 100644
--- a/c/src/lib/libbsp/sparc/shared/spw/grspw.c
+++ b/c/src/lib/libbsp/sparc/shared/spw/grspw.c
@@ -84,6 +84,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -149,8 +150,6 @@ typedef struct {
#define BUFMEM_PER_LINK (SPACEWIRE_TXBUFS_NR*(
SPACEWIRE_TXD_SIZE+SPACEWIRE_TXH_SIZE) + SPACEWIRE_RXBUFS_NR*SPACEWIRE_
RXPCK_SIZE)
-#define SPW_ALIGN(p,c) unsigned int)(p))+((c)-1))&~((c)-1))
-
typedef struct {
/* configuration parameters */
spw_config config;
@@ -190,9 +189,6 @@ typedef struct {
#ifdef GRSPW_STATIC_MEM
unsigned int membase, memend, mem_bdtable;
-#else
- char _rxtable[SPACEWIRE_BDTABLE_SIZE*2];
- char _txtable[SPACEWIRE_BDTABLE_SIZE*2];
#endif
LEON3_SPACEWIRE_Regs_Map *regs;
@@ -1383,8 +1379,8 @@ static int grspw_hw_init(GRSPW_DEV *pDev) {
pDev->rx = (SPACEWIRE_RXBD *) pDev->mem_bdtable;
pDev->tx = (SPACEWIRE_RXBD *) pDev->mem_bdtable +
SPACEWIRE_BDTABLE_SIZE;
#else
-pDev->rx = (SPACEWIRE_RXBD *) SPW_ALIGN(&pDev->_rxtable,
SPACEWIRE_BDTABLE_SIZE);
-pDev->tx = (SPACEWIRE_TXBD *) SPW_ALIGN(&pDev->_txtable,
SPACEWIRE_BDTABLE_SIZE);
+pDev->rx = (SPACEWIRE_RXBD *)
rtems_heap_allocate_aligned_with_boundry(
SPACEWIRE_BDTABLE_SIZE, 1024, 0 );
+pDev->tx = (SPACEWIRE_TXBD *)
rtems_heap_allocate_aligned_with_boundry(
SPACEWIRE_BDTABLE_SIZE, 1024, 0 );
#endif
SPACEWIRE_DBG("hw_init [minor %i]\n", pDev->minor);
@@ -1425,6 +1421,10 @@ static void grspw_hw_reset(GRSPW_DEV *pDev)
SPW_STATUS_WRITE(pDev, SPW_STATUS_TO | SPW_STATUS_CE |
SPW_STATUS_ER | SPW_STATUS_DE | SPW_STATUS_PE |
SPW_STATUS_WE | SPW_STATUS_IA |
SPW_STATUS_EE); /*clear status*/
SPW_CTRL_WRITE(pDev, SPW_CTRL_LINKSTART); /*start link core*/
+#ifndef GRSPW_STATIC_MEM
+free(pDev->rx);
+free(pDec->tx);
+#endif
}
static void grspw_hw_read_config(GRSPW_DEV *pDev)
--
1.8.3.1
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH] IMFS: Replace node union with individual struct
This reduces the average node size.
Add and use IMFS_GENERIC_INITIALIZER().
---
cpukit/dev/i2c/i2c-bus.c| 16 +-
cpukit/dev/i2c/i2c-dev.c| 16 +-
cpukit/libblock/src/blkdev-imfs.c | 21 +-
cpukit/libfs/Makefile.am| 2 +-
cpukit/libfs/src/imfs/deviceio.c| 40 ++--
cpukit/libfs/src/imfs/imfs.h| 291 ++--
cpukit/libfs/src/imfs/imfs_creat.c | 10 +-
cpukit/libfs/src/imfs/imfs_debug.c | 138 ---
cpukit/libfs/src/imfs/imfs_directory.c | 55 +++--
cpukit/libfs/src/imfs/imfs_eval.c | 43 ++--
cpukit/libfs/src/imfs/imfs_fifo.c | 4 +-
cpukit/libfs/src/imfs/imfs_fsunmount.c | 2 +-
cpukit/libfs/src/imfs/imfs_handlers_device.c| 15 +-
cpukit/libfs/src/imfs/imfs_handlers_directory.c | 27 ++-
cpukit/libfs/src/imfs/imfs_handlers_link.c | 36 +--
cpukit/libfs/src/imfs/imfs_handlers_memfile.c | 30 ++-
cpukit/libfs/src/imfs/imfs_initsupp.c | 14 +-
cpukit/libfs/src/imfs/imfs_link.c | 10 +-
cpukit/libfs/src/imfs/imfs_load_tar.c | 25 +-
cpukit/libfs/src/imfs/imfs_make_generic_node.c | 63 +++--
cpukit/libfs/src/imfs/imfs_mknod.c | 25 +-
cpukit/libfs/src/imfs/imfs_mount.c | 6 +-
cpukit/libfs/src/imfs/imfs_readlink.c | 10 +-
cpukit/libfs/src/imfs/imfs_symlink.c| 12 +-
cpukit/libfs/src/imfs/imfs_unmount.c| 6 +-
cpukit/libfs/src/imfs/memfile.c | 244 ++--
testsuites/fstests/fsimfsgeneric01/init.c | 37 +--
testsuites/libtests/newlib01/init.c | 12 +-
testsuites/libtests/tar02/init.c| 1 -
testsuites/libtests/tar02/tar02.scn | 14 +-
testsuites/psxtests/psxfile01/psxfile01.scn | 75 +-
testsuites/psxtests/psxfile01/test.c| 14 +-
testsuites/psxtests/psximfs02/init.c| 3 -
testsuites/psxtests/psximfs02/psximfs02.scn | 32 +--
34 files changed, 563 insertions(+), 786 deletions(-)
delete mode 100644 cpukit/libfs/src/imfs/imfs_debug.c
diff --git a/cpukit/dev/i2c/i2c-bus.c b/cpukit/dev/i2c/i2c-bus.c
index dafd758..0f27d06 100644
--- a/cpukit/dev/i2c/i2c-bus.c
+++ b/cpukit/dev/i2c/i2c-bus.c
@@ -223,23 +223,21 @@ static const rtems_filesystem_file_handlers_r
i2c_bus_handler = {
.writev_h = rtems_filesystem_default_writev
};
-static IMFS_jnode_t *i2c_bus_node_destroy(IMFS_jnode_t *node)
+static void i2c_bus_node_destroy(IMFS_jnode_t *node)
{
i2c_bus *bus;
bus = IMFS_generic_get_context_by_node(node);
(*bus->destroy)(bus);
- return node;
+ IMFS_node_destroy_default(node);
}
-static const IMFS_node_control i2c_bus_node_control = {
- .imfs_type = IMFS_GENERIC,
- .handlers = &i2c_bus_handler,
- .node_initialize = IMFS_node_initialize_generic,
- .node_remove = IMFS_node_remove_default,
- .node_destroy = i2c_bus_node_destroy
-};
+static const IMFS_node_control i2c_bus_node_control = IMFS_GENERIC_INITIALIZER(
+ &i2c_bus_handler,
+ IMFS_node_initialize_generic,
+ i2c_bus_node_destroy
+);
int i2c_bus_register(
i2c_bus *bus,
diff --git a/cpukit/dev/i2c/i2c-dev.c b/cpukit/dev/i2c/i2c-dev.c
index 76ae757..6710632 100644
--- a/cpukit/dev/i2c/i2c-dev.c
+++ b/cpukit/dev/i2c/i2c-dev.c
@@ -116,23 +116,21 @@ static const rtems_filesystem_file_handlers_r
i2c_dev_handler = {
.writev_h = rtems_filesystem_default_writev
};
-static IMFS_jnode_t *i2c_dev_node_destroy(IMFS_jnode_t *node)
+static void i2c_dev_node_destroy(IMFS_jnode_t *node)
{
i2c_dev *dev;
dev = IMFS_generic_get_context_by_node(node);
(*dev->destroy)(dev);
- return node;
+ IMFS_node_destroy_default(node);
}
-static const IMFS_node_control i2c_dev_node_control = {
- .imfs_type = IMFS_GENERIC,
- .handlers = &i2c_dev_handler,
- .node_initialize = IMFS_node_initialize_generic,
- .node_remove = IMFS_node_remove_default,
- .node_destroy = i2c_dev_node_destroy
-};
+static const IMFS_node_control i2c_dev_node_control = IMFS_GENERIC_INITIALIZER(
+ &i2c_dev_handler,
+ IMFS_node_initialize_generic,
+ i2c_dev_node_destroy
+);
int i2c_dev_register(
i2c_dev *dev,
diff --git a/cpukit/libblock/src/blkdev-imfs.c
b/cpukit/libblock/src/blkdev-imfs.c
index d6134f9..7a2d00b 100644
--- a/cpukit/libblock/src/blkdev-imfs.c
+++ b/cpukit/libblock/src/blkdev-imfs.c
@@ -229,13 +229,13 @@ static const rtems_filesystem_file_handlers_r
rtems_blkdev_imfs_node = {
static IMFS_jnode_t *rtems_blkdev_imfs_initialize(
IMFS_jnode_t *node,
- const IMFS_types_union *info
+ void *arg
)
{
rtems_blkdev_imfs_context *ctx;
rtems_disk_device *dd;
- node = IMFS_node_initialize_generic(node, info);
+ node = IMFS_node_initialize_generic(node, arg);
ctx = IMFS_generic_get_context_by_node(node);
dd = &ctx->dd;
@@ -244,7 +244,7 @@ static IMFS_jnode_t *rte
ANN: RDUC RTEMS Developers and Users Conference
Hello, today I want to announce a planned event for June 2015: The First RTEMS Developers and Users Conference (RDUC). Sharing ideas, problems, solutions and future visions via email and chat is fine for the daily work, but the RTEMS community is now big enough to justify a regular conference event. We are in an early planning stage, but already want to ask you all to save the date! Location The first RDUC will be organized in good old Europe, in the area of Munich, Germany. Schedule This will be a two day event. The exact date is not yet fixed, but will be most likely either 11./12. June or 18./19. June 2015. Audience The conference is intended for - application developers using RTEMS in their systems, - system developers interested in extending RTEMS, - system architects looking for a reliable realtime system, - and solution providers for the ecosystem around RTEMS Sessions The individual sessions are not yet fixed, but a number of topics seem interesting for presentation and discussion, like: - best practices for RTEMS with small memory footprint - RTEMS-SMP support: present and future - debugging RTEMS systems with COTS tools - applications with RTEMS: challenges, problems and solutions - verification and validation: present infrastructure and future requirements - fancy plattforms for RTEMS - distributed, fail safe systems - christmas in June: RTEMS wishlist for the next years Orga Team = The embedded brains RTEMS team will organize this conference, so if: - you want to keep updated on this event - you want to attend the conference - you have ideas and recommendations - you want to present your work please send us an email on r...@rtems.eu We will keep this list informed while we proceed with our plannings. With kind regards, Thomas Doerfler. -- embedded brains GmbH Thomas Doerfler Dornierstr. 4 D-82178 Puchheim Germany email: thomas.doerf...@embedded-brains.de Phone: +49-89-18 94 741-12 Fax: +49-89-18 94 741-09 PGP: Public key available on request. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: 4.11 Branching To Do
I updated the benchmark to include also the RTEMS chain implementation for comparison with the red-black trees. Below 60 nodes it is faster than the red-black trees. https://github.com/sebhub/rb-bench Is a red-black tree really the best choice for our priority queues? A semaphore with 60 waiting tasks is likely a problem itself in an application. On 17/12/14 10:46, Sebastian Huber wrote: Hello, I added some very simple benchmark code here: https://github.com/sebhub/rb-bench On 06/11/14 07:53, Sebastian Huber wrote: Hello, I have a new item for the list: Very desirable == + Since red-black trees are now used to implement the priority queues and they will play an important part in future SMP improvements I would like to do some performance measurements with alternative implementations. I would like to compare 1. the RTEMS red-black tree implementation, 2. the RTEMS red-black tree implementation with the colour encoded in the parent pointer, 3. the implementation from Eternally Confuzzled, see http://www.eternallyconfuzzled.com/tuts/datastructures/jsw_tut_rbtree.aspx, 4. the BSD implementation , and 5. the JFFS2 implementation (cpukit/libfs/src/jffs2/include/linux/rbtree.h), see http://lwn.net/Articles/184495/. I intend to use real hardware ARM, ColdFire, PowerPC and SPARC targets. Do we have other interesting red-black tree implementations? On 29/10/14 22:49, Joel Sherrill wrote: Hi Since we are long over due for a release. I can count 4 new children and a grandchild among the core developers since 4.10. :) Here is what I have off the top of my head: Mandatory == + Tool version selection - Likely gcc 4.9 on almost all targets. - binutils last release - newlib TBD - GDB could be new release + BeagleBoard BSP added + Run-Time Loader merged and tested + Visit the Getting Started manual. It is dated. + Push a bit more on warnings. - Three BSPs represent bulk of remaining warnings Very desirable = + x86 context switch SMP handoff logic + Pi GSOC Code merged. Anything else? -- 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
Rump Kernels
Hi, Has anyone taken a look at Rump Kernels, and feasibility to use any of it with RTEMS? http://rumpkernel.org/ Rump Kernels encapsulate parts of the NetBSD kernel that can be reused in other OS kernels. The obvious big wins come from device drivers, but also maintenance efforts are much reduced. Gedare ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Rump Kernels
On 1/22/2015 3:32 PM, Gedare Bloom wrote: > Hi, > > Has anyone taken a look at Rump Kernels, and feasibility to use any of > it with RTEMS? http://rumpkernel.org/ > > Rump Kernels encapsulate parts of the NetBSD kernel that can be reused > in other OS kernels. The obvious big wins come from device drivers, > but also maintenance efforts are much reduced. This would make an interesting GSoC project. The RUMP API adapter doesn't look too large and could be implemented by a student. It would be interesting to see what could be brought over this way. Hint... someone write this up. :) > Gedare > ___ > 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
Open Tickets for 4.11 Branching
Hi Thirty tickets are currently listed as non-admin issues with a milestone of 4.11. This means they are issues to be resolved before we can branch. http://goo.gl/HeziKs Please help review these. If you can resolve an issue, please help do so. If the issue is not going to get fixed or get attention before 4.11 branches, then we need to move the milestone out. Thanks. -- 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
POSIX Compliance Issue
Hi
In running the Open Group FACE Conformance Test Suite on RTEMS, it
spotted that the old network stack's does not include
the types.h (or sys/types.h) to get ssize_t. That means you get a type
undefined error if you followk
http://pubs.opengroup.org/onlinepubs/7908799/xns/syssocket.h.html
This impacts all the methods in since the test suite assumes
that it only needs to include the .h file(s) specified by Open Group.
+ Does this occur with the new stack?
+ Is it OK to add the appropiate include file to old stack's socket.h?
Here is a test case.
=
#include
void f(void)
{
ssize_t s;
int socket = 0;
void *buffer = 0;
size_t length = 0;
int flags = 0;
struct sockaddr *address = 0;
socklen_t *address_len = 0;
s = recvfrom(socket, buffer, length, flags, address, address_len);
}
=
--
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: POSIX Compliance Issue
On 23/01/15 01:37, Joel Sherrill wrote: Hi In running the Open Group FACE Conformance Test Suite on RTEMS, it spotted that the old network stack's does not include the types.h (or sys/types.h) to get ssize_t. That means you get a type undefined error if you followk http://pubs.opengroup.org/onlinepubs/7908799/xns/syssocket.h.html This impacts all the methods in since the test suite assumes that it only needs to include the .h file(s) specified by Open Group. + Does this occur with the new stack? No. + Is it OK to add the appropiate include file to old stack's socket.h? The real FreeBSD includes and defines only the necessary types for . In the new stack I simply include . -- 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
