RTEMS Release Snapshot: 5.0.0-m2003 (03 Mar 2020)
RTEMS Release Build - 5.0.0-m2003 RTEMS 5 Release snapshot m2003 is avaliable for testing. It can be found at: https://ftp.rtems.org/pub/rtems/releases/5/5.0.0/5.0.0-m2003 Please test and report any issues to the u...@rtems.org or devel@rtems.org mailing lists or please raise a ticket. If you are part of the RTEMS testing program please build on your preferred host posting build and BSP test results to bu...@rtems.org. This is a development release and may have errors and be unstable. Thanks Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH 2/5] imfs: Simplify IMFS_create_node()
Update #3894.
---
cpukit/libfs/src/imfs/imfs_creat.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/cpukit/libfs/src/imfs/imfs_creat.c
b/cpukit/libfs/src/imfs/imfs_creat.c
index b72ae491a6..e476d74852 100644
--- a/cpukit/libfs/src/imfs/imfs_creat.c
+++ b/cpukit/libfs/src/imfs/imfs_creat.c
@@ -33,6 +33,7 @@ IMFS_jnode_t *IMFS_create_node(
)
{
IMFS_jnode_t *allocated_node;
+ char *allocated_name;
IMFS_jnode_t *node;
allocated_node = calloc( 1, node_size + namelen );
@@ -42,10 +43,12 @@ IMFS_jnode_t *IMFS_create_node(
return NULL;
}
+ allocated_name = (char *) allocated_node + node_size;
+ allocated_name = memcpy( allocated_name, name, namelen );
node = IMFS_initialize_node(
allocated_node,
node_control,
-(char *) allocated_node + node_size,
+allocated_name,
namelen,
mode,
arg
@@ -53,8 +56,6 @@ IMFS_jnode_t *IMFS_create_node(
if ( node != NULL ) {
IMFS_jnode_t *parent = parentloc->node_access;
-memcpy( RTEMS_DECONST( char *, node->name ), name, namelen );
-
/*
* This node MUST have a parent, so put it in that directory list.
*/
--
2.16.4
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH 3/5] imfs: Add IMFS_add_node()
Update #3894.
---
cpukit/Makefile.am| 2 +
cpukit/include/rtems/imfs.h | 159 +++--
cpukit/libfs/src/imfs/imfs_add_node.c | 112
cpukit/libfs/src/imfs/imfs_node.c | 8 +-
cpukit/libfs/src/imfs/imfs_node_destroy_default.c | 47 +
testsuites/fstests/fsimfsgeneric01/init.c | 206 ++
6 files changed, 484 insertions(+), 50 deletions(-)
create mode 100644 cpukit/libfs/src/imfs/imfs_add_node.c
create mode 100644 cpukit/libfs/src/imfs/imfs_node_destroy_default.c
diff --git a/cpukit/Makefile.am b/cpukit/Makefile.am
index 298580e20d..884fb8c402 100644
--- a/cpukit/Makefile.am
+++ b/cpukit/Makefile.am
@@ -413,6 +413,7 @@ librtemscpu_a_SOURCES += libfs/src/dosfs/msdos_rename.c
librtemscpu_a_SOURCES += libfs/src/dosfs/msdos_rmnod.c
librtemscpu_a_SOURCES += libfs/src/dosfs/msdos_statvfs.c
librtemscpu_a_SOURCES += libfs/src/imfs/deviceio.c
+librtemscpu_a_SOURCES += libfs/src/imfs/imfs_add_node.c
librtemscpu_a_SOURCES += libfs/src/imfs/imfs_chown.c
librtemscpu_a_SOURCES += libfs/src/imfs/imfs_config.c
librtemscpu_a_SOURCES += libfs/src/imfs/imfs_creat.c
@@ -435,6 +436,7 @@ librtemscpu_a_SOURCES += libfs/src/imfs/imfs_memfile.c
librtemscpu_a_SOURCES += libfs/src/imfs/imfs_mknod.c
librtemscpu_a_SOURCES += libfs/src/imfs/imfs_mount.c
librtemscpu_a_SOURCES += libfs/src/imfs/imfs_node.c
+librtemscpu_a_SOURCES += libfs/src/imfs/imfs_node_destroy_default.c
librtemscpu_a_SOURCES += libfs/src/imfs/imfs_rename.c
librtemscpu_a_SOURCES += libfs/src/imfs/imfs_rmnod.c
librtemscpu_a_SOURCES += libfs/src/imfs/imfs_stat.c
diff --git a/cpukit/include/rtems/imfs.h b/cpukit/include/rtems/imfs.h
index 1490186287..565d103226 100644
--- a/cpukit/include/rtems/imfs.h
+++ b/cpukit/include/rtems/imfs.h
@@ -206,6 +206,15 @@ typedef void (*IMFS_node_control_destroy)( IMFS_jnode_t
*node );
*/
void IMFS_node_destroy_default( IMFS_jnode_t *node );
+/**
+ * @brief Does nothing.
+ *
+ * @param node The IMFS node.
+ *
+ * @see IMFS_node_control.
+ */
+void IMFS_do_nothing_destroy( IMFS_jnode_t *node );
+
/**
* @brief IMFS node control.
*/
@@ -319,6 +328,11 @@ typedef struct {
size_t size;
} IMFS_linearfile_context;
+static inline IMFS_jnode_t *IMFS_iop_to_node( const rtems_libio_t *iop )
+{
+ return (IMFS_jnode_t *) iop->pathinfo.node_access;
+}
+
static inline IMFS_directory_t *IMFS_iop_to_directory(
const rtems_libio_t *iop
)
@@ -594,6 +608,92 @@ static inline bool IMFS_is_imfs_instance(
return loc->mt_entry->ops->clonenod_h == IMFS_node_clone;
}
+/**
+ * @brief Initializer for an IMFS node control.
+ *
+ * @param handlers The file system node handlers.
+ * @param init The node initialization method.
+ * @param destroy The node destruction method.
+ */
+#define IMFS_NODE_CONTROL_INITIALIZER( handlers, init, destroy ) \
+ { \
+( handlers ), \
+( init ), \
+IMFS_node_remove_default, \
+( destroy ) \
+ }
+
+/**
+ * @brief Initializer for an IMFS node.
+ *
+ * Initialize the node control with IMFS_NODE_CONTROL_INITIALIZER().
+ *
+ * @param node_control The node control of the IMFS node.
+ * @param name The name of the IMFS node.
+ * @param namelen The length of the name of the IMFS node.
+ * @param mode The mode of the IMFS node.
+ *
+ * @see IMFS_node_preinitialize().
+ */
+#define IMFS_NODE_INITIALIZER( node_control, name, namelen, mode ) \
+ { \
+{ NULL, NULL }, \
+NULL, \
+( name ), \
+( namelen ), \
+( mode ), \
+0, \
+0, \
+0, \
+0, \
+0, \
+0, \
+0, \
+( node_control ) \
+ }
+
+/**
+ * @brief Preinitializes an IMFS node.
+ *
+ * Initialize the node control with IMFS_NODE_CONTROL_INITIALIZER().
+ *
+ * @param node The IMFS node to preinitialize.
+ * @param node_control The node control of the IMFS node.
+ * @param name The name of the IMFS node.
+ * @param namelen The length of the name of the IMFS node.
+ * @param mode The mode of the IMFS node.
+ *
+ * @see IMFS_NODE_INITIALIZER().
+ */
+static inline void IMFS_node_preinitialize(
+ IMFS_jnode_t*node,
+ const IMFS_node_control *node_control,
+ const char *name,
+ size_t namelen,
+ mode_t mode
+)
+{
+ node->control = node_control;
+ node->name = name;
+ node->namelen = namelen;
+ node->st_mode = mode;
+}
+
+/**
+ * @brief Adds an IMFS node.
+ *
+ * Initialize the node with IMFS_NODE_INITIALIZER(), IMFS_node_preinitialize(),
+ * IMFS_GENERIC_NODE_INITIALIZER(), or IMFS_generic_node_preinitialize().
+ *
+ * @param path The path of parent directories for the IMFS node to add.
+ * @param node The IMFS node to add.
+ * @param arg The argument passed to the node initialization method.
+ *
+ * @retval 0 Successful operation.
+ * @retval -1 An error occurred. The @c errno indicates the error.
+ */
+int IMFS_add_node( const char *path, IMFS_jnode_t *node, void *arg );
+
extern
[PATCH 4/5] console: Use IMFS_add_node() for simple console
Update #3894.
---
cpukit/libcsupport/src/consolesimple.c | 55 +++---
1 file changed, 38 insertions(+), 17 deletions(-)
diff --git a/cpukit/libcsupport/src/consolesimple.c
b/cpukit/libcsupport/src/consolesimple.c
index 94aa40c9fd..4316fa321a 100644
--- a/cpukit/libcsupport/src/consolesimple.c
+++ b/cpukit/libcsupport/src/consolesimple.c
@@ -1,17 +1,34 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
/*
- * Copyright (c) 2017 embedded brains GmbH. All rights reserved.
+ * Copyright (C) 2017, 2020 embedded brains GmbH
(http://www.embedded-brains.de)
*
- * embedded brains GmbH
- * Dornierstr. 4
- * 82178 Puchheim
- * Germany
- *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
*
- * 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.
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF SUCH DAMAGE.
*/
+#if HAVE_CONFIG_H
+#include "config.h"
+#endif
+
#include
#include
#include
@@ -56,18 +73,22 @@ static const rtems_filesystem_file_handlers_r
_Console_simple_Handlers = {
};
static const IMFS_node_control
-_Console_simple_Node_control = IMFS_GENERIC_INITIALIZER(
+_Console_simple_Node_control = IMFS_NODE_CONTROL_INITIALIZER(
&_Console_simple_Handlers,
IMFS_node_initialize_default,
- IMFS_node_destroy_default
+ IMFS_do_nothing_destroy
+);
+
+static const char _Console_simple_Name[] = "console";
+
+static IMFS_jnode_t _Console_simple_Node = IMFS_NODE_INITIALIZER(
+ &_Console_simple_Node_control,
+ _Console_simple_Name,
+ sizeof( _Console_simple_Name ) - 1,
+ S_IFCHR | S_IRWXU | S_IRWXG | S_IRWXO
);
void _Console_simple_Initialize( void )
{
- IMFS_make_generic_node(
-CONSOLE_DEVICE_NAME,
-S_IFCHR | S_IRWXU | S_IRWXG | S_IRWXO,
-&_Console_simple_Node_control,
-NULL
- );
+ IMFS_add_node( "/dev", &_Console_simple_Node, NULL );
}
--
2.16.4
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH 5/5] console: Use IMFS_add_node() for simple task cons
Update #3894.
---
cpukit/libcsupport/src/consolesimpletask.c | 70 +-
1 file changed, 50 insertions(+), 20 deletions(-)
diff --git a/cpukit/libcsupport/src/consolesimpletask.c
b/cpukit/libcsupport/src/consolesimpletask.c
index 1f83a4920a..5b12cc6647 100644
--- a/cpukit/libcsupport/src/consolesimpletask.c
+++ b/cpukit/libcsupport/src/consolesimpletask.c
@@ -1,17 +1,34 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
/*
- * Copyright (c) 2018 embedded brains GmbH. All rights reserved.
+ * Copyright (C) 2018, 2020 embedded brains GmbH
(http://www.embedded-brains.de)
*
- * embedded brains GmbH
- * Dornierstr. 4
- * 82178 Puchheim
- * Germany
- *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
*
- * 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.
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF SUCH DAMAGE.
*/
+#if HAVE_CONFIG_H
+#include "config.h"
+#endif
+
#include
#include
#include
@@ -24,6 +41,7 @@
#define CONSOLE_SIMPLE_TASK_MAX_JUNK_SIZE 80
typedef struct {
+ IMFS_jnode_t Node;
RTEMS_INTERRUPT_LOCK_MEMBER( buf_lock )
rtems_mutex output_mutex;
rtems_id task;
@@ -48,6 +66,13 @@ static size_t _Console_simple_task_Available(
return ( cons->head - cons->tail ) % CONSOLE_SIMPLE_TASK_BUFFER_SIZE;
}
+static Console_simple_task_Control *_Console_simple_task_Iop_to_control(
+ const rtems_libio_t *iop
+)
+{
+ return (Console_simple_task_Control *) IMFS_iop_to_node( iop );
+}
+
static ssize_t _Console_simple_task_Write(
rtems_libio_t *iop,
const void*buffer,
@@ -58,7 +83,7 @@ static ssize_t _Console_simple_task_Write(
const char *buf;
size_t todo;
- cons = IMFS_generic_get_context_by_iop( iop );
+ cons = _Console_simple_task_Iop_to_control( iop );
buf = buffer;
todo = count;
@@ -137,7 +162,7 @@ static int _Console_simple_task_Fsync( rtems_libio_t *iop )
{
Console_simple_task_Control *cons;
- cons = IMFS_generic_get_context_by_iop( iop );
+ cons = _Console_simple_task_Iop_to_control( iop );
_Console_simple_task_Put_chars( cons );
return 0;
@@ -161,10 +186,10 @@ static const rtems_filesystem_file_handlers_r
_Console_simple_task_Handlers = {
};
static const IMFS_node_control
-_Console_simple_task_Node_control = IMFS_GENERIC_INITIALIZER(
+_Console_simple_task_Node_control = IMFS_NODE_CONTROL_INITIALIZER(
&_Console_simple_task_Handlers,
- IMFS_node_initialize_generic,
- IMFS_node_destroy_default
+ IMFS_node_initialize_default,
+ IMFS_do_nothing_destroy
);
static void _Console_simple_task_Task( rtems_task_argument arg )
@@ -187,21 +212,26 @@ static void _Console_simple_task_Task(
rtems_task_argument arg )
}
}
+static const char _Console_simple_task_Name[] = "console";
+
void _Console_simple_task_Initialize( void )
{
Console_simple_task_Control *cons;
cons = &_Console_simple_task_Instance;
+ IMFS_node_preinitialize(
+&cons->Node,
+&_Console_simple_task_Node_control,
+_Console_simple_task_Name,
+sizeof( _Console_simple_task_Name ) - 1,
+S_IFCHR | S_IRWXU | S_IRWXG | S_IRWXO
+ );
+
rtems_interrupt_lock_initialize( &cons->buf_lock, "Console" );
rtems_mutex_init( &cons->output_mutex, "Console" );
- IMFS_make_generic_node(
-CONSOLE_DEVICE_NAME,
-S_IFCHR | S_IRWXU | S_IRWXG | S_IRWXO,
-&_Console_simple_task_Node_control,
-cons
- );
+ IMFS_add_node( "/dev", &cons->Node, NULL );
rtems_task_create(
rtems_build_name('C', 'O', 'N', 'S'),
--
2.16.4
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH 1/5] imfs: Remove IMFS_NODE_FLAG_NAME_ALLOCATED
Remove IMFS_NODE_FLAG_NAME_ALLOCATED and instead replace the node
control in rename operations. This avoids a special case in the general
node destruction which pulled in free().
Update #3894.
---
cpukit/include/rtems/imfs.h | 3 ---
cpukit/libfs/src/imfs/imfs_node.c | 4 ---
cpukit/libfs/src/imfs/imfs_rename.c | 49 +
3 files changed, 39 insertions(+), 17 deletions(-)
diff --git a/cpukit/include/rtems/imfs.h b/cpukit/include/rtems/imfs.h
index 5327d632f9..1490186287 100644
--- a/cpukit/include/rtems/imfs.h
+++ b/cpukit/include/rtems/imfs.h
@@ -244,7 +244,6 @@ struct IMFS_jnode_tt {
IMFS_jnode_t *Parent;/* Parent node */
const char *name; /* "basename" (not \0 terminated)
*/
uint16_tnamelen; /* Length of "basename" */
- uint16_tflags; /* Node flags */
mode_t st_mode; /* File mode */
unsigned short reference_count;
nlink_t st_nlink; /* Link count */
@@ -258,8 +257,6 @@ struct IMFS_jnode_tt {
const IMFS_node_control *control;
};
-#define IMFS_NODE_FLAG_NAME_ALLOCATED 0x1
-
typedef struct {
IMFS_jnode_t Node;
rtems_chain_control Entries;
diff --git a/cpukit/libfs/src/imfs/imfs_node.c
b/cpukit/libfs/src/imfs/imfs_node.c
index 0c296de339..ae087bd58f 100644
--- a/cpukit/libfs/src/imfs/imfs_node.c
+++ b/cpukit/libfs/src/imfs/imfs_node.c
@@ -107,9 +107,5 @@ IMFS_jnode_t *IMFS_node_remove_default(
void IMFS_node_destroy_default( IMFS_jnode_t *node )
{
- if ( ( node->flags & IMFS_NODE_FLAG_NAME_ALLOCATED ) != 0 ) {
-free( RTEMS_DECONST( char *, node->name ) );
- }
-
free( node );
}
diff --git a/cpukit/libfs/src/imfs/imfs_rename.c
b/cpukit/libfs/src/imfs/imfs_rename.c
index 5bc0b3be25..bf86f320f6 100644
--- a/cpukit/libfs/src/imfs/imfs_rename.c
+++ b/cpukit/libfs/src/imfs/imfs_rename.c
@@ -23,6 +23,29 @@
#include
#include
+typedef struct {
+ IMFS_node_control Base;
+ const IMFS_node_control *replaced;
+ char name[ RTEMS_ZERO_LENGTH_ARRAY ];
+} IMFS_renamed_control;
+
+static void IMFS_restore_replaced_control( IMFS_jnode_t *node )
+{
+ const IMFS_node_control *base;
+ IMFS_renamed_control*control;
+
+ base = RTEMS_DECONST( IMFS_node_control *, node->control );
+ control = (IMFS_renamed_control *) base;
+ node->control = control->replaced;
+ free( control );
+}
+
+static void IMFS_renamed_destroy( IMFS_jnode_t *node )
+{
+ IMFS_restore_replaced_control( node );
+ ( *node->control->node_destroy )( node );
+}
+
int IMFS_rename(
const rtems_filesystem_location_info_t *oldparentloc,
const rtems_filesystem_location_info_t *oldloc,
@@ -31,15 +54,18 @@ int IMFS_rename(
size_t namelen
)
{
- IMFS_jnode_t *node = oldloc->node_access;
- IMFS_jnode_t *new_parent = newparentloc->node_access;
- char *allocated_name;
+ IMFS_jnode_t *node;
+ IMFS_jnode_t *new_parent;
+ IMFS_renamed_control *control;
/*
* FIXME: Due to insufficient checks we can create inaccessible nodes with
* this operation.
*/
+ node = oldloc->node_access;
+ new_parent = newparentloc->node_access;
+
if ( node->Parent == NULL ) {
rtems_set_errno_and_return_minus_one( EINVAL );
}
@@ -48,20 +74,23 @@ int IMFS_rename(
rtems_set_errno_and_return_minus_one( ENAMETOOLONG );
}
- allocated_name = malloc( namelen );
- if ( allocated_name == NULL ) {
+ control = malloc( sizeof( *control ) + namelen );
+ if ( control == NULL ) {
rtems_set_errno_and_return_minus_one( ENOMEM );
}
- memcpy( allocated_name, name, namelen );
+ memcpy( control->name, name, namelen );
- if ( ( node->flags & IMFS_NODE_FLAG_NAME_ALLOCATED ) != 0 ) {
-free( RTEMS_DECONST( char *, node->name ) );
+ if ( node->control->node_destroy == IMFS_renamed_destroy ) {
+IMFS_restore_replaced_control( node );
}
- node->name = allocated_name;
+ control->Base = *node->control;
+ control->Base.node_destroy = IMFS_renamed_destroy;
+ control->replaced = node->control;
+ node->control = &control->Base;
+ node->name = control->name;
node->namelen = namelen;
- node->flags |= IMFS_NODE_FLAG_NAME_ALLOCATED;
IMFS_remove_from_directory( node );
IMFS_add_to_directory( new_parent, node );
--
2.16.4
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] test for fegetround and fesetround
On Mon, Mar 2, 2020 at 11:11 AM Eshan Dhawan wrote:
>
>
>
> On Mon, Mar 2, 2020 at 9:38 PM Gedare Bloom wrote:
>>
>> On Tue, Feb 25, 2020 at 7:56 AM Eshan dhawan wrote:
>> >
>> > ---
>> > testsuites/psxtests/psxfenv01/init.c | 42 +++-
>> > 1 file changed, 41 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/testsuites/psxtests/psxfenv01/init.c
>> > b/testsuites/psxtests/psxfenv01/init.c
>> > index 05f3cdc880..4339139c58 100644
>> > --- a/testsuites/psxtests/psxfenv01/init.c
>> > +++ b/testsuites/psxtests/psxfenv01/init.c
>> > @@ -106,7 +106,47 @@ rtems_task Init(rtems_task_argument ignored)
>> >printf("fesetexceptflag ==> 0x%x\n", r);
>> > rtems_test_assert(r == 0);
>
>
>>
>> >Similarly, the ability to trigger coverity scan on a
>
>
> How to do that, could you guide me through
>
> thanks
I think this was a copy-paste error in my email client. Ignore it.
>>
>> > -
>> > +
>> > +/*test for fegetround() and fesetround()*/
>> add white space around text
>>
>> > +/*they have four main macros to be tested seperated by ifdef*/
>> typo: separated
>>
>> > +/* since all the architectures dont support them */
>> typo: don't
>> grammer: "since not all architectures support them" would be better.
>> "all the architectures don't support them" means there is no support
>> at all.
>>
>> > +/*the test cases gets and sets the rounding directions */
>> typo: case
>>
>> > +#ifdef FE_TONEAREST
>> > +
>> no blank line needed/wanted after #ifdef statements
>> > +r=fegetround();
>>
>> whitespace needed around =. Please review
>> https://docs.rtems.org/branches/master/eng/coding.html
>>
>> > +if(r)
>> whitespace needed, and brackets needed even for 1-line blocks.
>>
>> > + printf("fegetround ==> 0x%x\n", r);
>> > +rtems_test_assert(r == FE_TONEAREST) ;
>> > +#endif
>> > +#ifdef FE_TOWARDZERO
>> > +
>> The same errors from above repeat here and below. fix all.
>>
>> > + r=fesetround(FE_TOWARDZERO);
>> > + if(r)
>> > + printf("fesetround ==> 0x%x\n", r);
>> > + rtems_test_assert(r == 0) ;
>> > + rtems_test_assert(fegetround() == FE_TOWARDZERO) ;
>> > +#endif
>> > +#ifdef FE_DOWNWARD
>> > +
>> > + r=fesetround(FE_DOWNWARD);
>> > + if(r)
>> > + printf("fesetround ==> 0x%x\n", r);
>> > + rtems_test_assert(r == 0) ;
>> > + rtems_test_assert(fegetround() == FE_DOWNWARD) ;
>> > +#endif
>> > +#ifdef FE_UPWARD
>> > + r=fesetround(FE_UPWARD);
>> > + if(r)
>> > + printf("fesetround ==> 0x%x\n", r);
>> > + rtems_test_assert(r == 0) ;
>> > + rtems_test_assert(fegetround() == FE_UPWARD) ;
>> > +#endif
>> > +#ifdef FE_TONEAREST
>> > + r=fesetround(FE_TONEAREST);
>> > + if(r)
>> > + printf("fesetround ==> 0x%x\n", r);
>> > + rtems_test_assert(r == 0) ;
>> > +#endif
>> >
>> >
>> > #ifdef FE_DIVBYZERO
>> > --
>> > 2.17.1
>> >
>> > ___
>> > devel mailing list
>> > devel@rtems.org
>> > http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH] config: Remove include
The use of CONFIGURE_APPLICATION_NEEDS_TIMER_DRIVER does not define anything, so remove the include. Update #3875. --- testsuites/tmtests/tm01/task1.c| 2 ++ testsuites/tmtests/tm02/tm02impl.h | 2 ++ testsuites/tmtests/tm03/tm03impl.h | 2 ++ testsuites/tmtests/tm04/task1.c| 2 ++ testsuites/tmtests/tm05/task1.c| 2 ++ testsuites/tmtests/tm06/task1.c| 2 ++ testsuites/tmtests/tm07/task1.c| 2 ++ testsuites/tmtests/tm08/task1.c| 2 ++ testsuites/tmtests/tm09/task1.c| 2 ++ testsuites/tmtests/tm10/task1.c| 2 ++ testsuites/tmtests/tm11/task1.c| 2 ++ testsuites/tmtests/tm12/task1.c| 2 ++ testsuites/tmtests/tm13/task1.c| 2 ++ testsuites/tmtests/tm14/task1.c| 2 ++ testsuites/tmtests/tm15/task1.c| 2 ++ testsuites/tmtests/tm16/task1.c| 2 ++ testsuites/tmtests/tm17/task1.c| 2 ++ testsuites/tmtests/tm18/task1.c| 2 ++ testsuites/tmtests/tm19/task1.c| 2 ++ testsuites/tmtests/tm20/task1.c| 2 ++ testsuites/tmtests/tm21/task1.c| 2 ++ testsuites/tmtests/tm22/task1.c| 2 ++ testsuites/tmtests/tm23/task1.c| 2 ++ testsuites/tmtests/tm24/task1.c| 2 ++ testsuites/tmtests/tm25/task1.c| 2 ++ testsuites/tmtests/tm26/task1.c| 1 + testsuites/tmtests/tm27/task1.c| 1 + testsuites/tmtests/tm28/task1.c| 2 ++ testsuites/tmtests/tm29/task1.c| 2 ++ testsuites/tmtests/tmck/task1.c| 2 ++ testsuites/tmtests/tmoverhd/testtask.c | 2 ++ 31 files changed, 60 insertions(+) diff --git a/testsuites/tmtests/tm01/task1.c b/testsuites/tmtests/tm01/task1.c index ce19c5a874..052c1455a8 100644 --- a/testsuites/tmtests/tm01/task1.c +++ b/testsuites/tmtests/tm01/task1.c @@ -15,6 +15,8 @@ #include "config.h" #endif +#include + #define CONFIGURE_INIT #include "system.h" diff --git a/testsuites/tmtests/tm02/tm02impl.h b/testsuites/tmtests/tm02/tm02impl.h index 8fe1bfd08f..5a08600f9b 100644 --- a/testsuites/tmtests/tm02/tm02impl.h +++ b/testsuites/tmtests/tm02/tm02impl.h @@ -15,6 +15,8 @@ #include "config.h" #endif +#include + #define CONFIGURE_INIT #include "system.h" diff --git a/testsuites/tmtests/tm03/tm03impl.h b/testsuites/tmtests/tm03/tm03impl.h index 50bbe1b4d2..9140695a71 100644 --- a/testsuites/tmtests/tm03/tm03impl.h +++ b/testsuites/tmtests/tm03/tm03impl.h @@ -15,6 +15,8 @@ #include "config.h" #endif +#include + #define CONFIGURE_INIT #include "system.h" diff --git a/testsuites/tmtests/tm04/task1.c b/testsuites/tmtests/tm04/task1.c index af78e940b2..d99ade58bd 100644 --- a/testsuites/tmtests/tm04/task1.c +++ b/testsuites/tmtests/tm04/task1.c @@ -15,6 +15,8 @@ #include "config.h" #endif +#include + #define CONFIGURE_INIT #include "system.h" diff --git a/testsuites/tmtests/tm05/task1.c b/testsuites/tmtests/tm05/task1.c index 4784e36ec8..f385088ee4 100644 --- a/testsuites/tmtests/tm05/task1.c +++ b/testsuites/tmtests/tm05/task1.c @@ -11,6 +11,8 @@ #include "config.h" #endif +#include + #define CONFIGURE_INIT #include "system.h" diff --git a/testsuites/tmtests/tm06/task1.c b/testsuites/tmtests/tm06/task1.c index 4983f5df33..81588005a4 100644 --- a/testsuites/tmtests/tm06/task1.c +++ b/testsuites/tmtests/tm06/task1.c @@ -15,6 +15,8 @@ #include "config.h" #endif +#include + #define CONFIGURE_INIT #include "system.h" diff --git a/testsuites/tmtests/tm07/task1.c b/testsuites/tmtests/tm07/task1.c index f54388feb6..84acbb8e0d 100644 --- a/testsuites/tmtests/tm07/task1.c +++ b/testsuites/tmtests/tm07/task1.c @@ -15,6 +15,8 @@ #include "config.h" #endif +#include + #define CONFIGURE_INIT #include "system.h" diff --git a/testsuites/tmtests/tm08/task1.c b/testsuites/tmtests/tm08/task1.c index 5d013a6f71..f7cf987070 100644 --- a/testsuites/tmtests/tm08/task1.c +++ b/testsuites/tmtests/tm08/task1.c @@ -15,6 +15,8 @@ #include "config.h" #endif +#include + #define CONFIGURE_INIT #include "system.h" diff --git a/testsuites/tmtests/tm09/task1.c b/testsuites/tmtests/tm09/task1.c index 8f7edf3163..c95fdd6d72 100644 --- a/testsuites/tmtests/tm09/task1.c +++ b/testsuites/tmtests/tm09/task1.c @@ -15,6 +15,8 @@ #include "config.h" #endif +#include + #define CONFIGURE_INIT #include "system.h" diff --git a/testsuites/tmtests/tm10/task1.c b/testsuites/tmtests/tm10/task1.c index c5e7d6ea64..137507beb2 100644 --- a/testsuites/tmtests/tm10/task1.c +++ b/testsuites/tmtests/tm10/task1.c @@ -15,6 +15,8 @@ #include "config.h" #endif +#include + #define CONFIGURE_INIT #include "system.h" diff --git a/testsuites/tmtests/tm11/task1.c b/testsuites/tmtests/tm11/task1.c index 23f78d99f8..c51c66a881 100644 --- a/testsuites/tmtests/tm11/task1.c +++ b/testsuites/tmtests/tm11/task1.c @@ -15,6 +15,8 @@ #include "config.h" #endif +#include + #define CONFIGURE_INIT #include "system.h" diff --git a/testsuites/tmtests/tm12/task1.c b/testsuites/tm
Re: [PATCH] c-user: Document thread switch extension changes
On Tue, Mar 3, 2020 at 12:03 AM Sebastian Huber wrote: > > Close #3885. > --- > c-user/symmetric_multiprocessing_services.rst | 2 ++ > c-user/user_extensions.rst| 40 > ++- > 2 files changed, 29 insertions(+), 13 deletions(-) > > diff --git a/c-user/symmetric_multiprocessing_services.rst > b/c-user/symmetric_multiprocessing_services.rst > index 337de98..acfee56 100644 > --- a/c-user/symmetric_multiprocessing_services.rst > +++ b/c-user/symmetric_multiprocessing_services.rst > @@ -683,6 +683,8 @@ The withdraw operation takes away scheduler nodes once > the thread is no longer > allowed to use them, e.g. it released a mutex. The availability of scheduler > nodes for a thread is controlled by the thread queues. > > +.. _SMPThreadDispatchDetails: > + > Thread Dispatch Details > --- > > diff --git a/c-user/user_extensions.rst b/c-user/user_extensions.rst > index 0840f65..7edbea5 100644 > --- a/c-user/user_extensions.rst > +++ b/c-user/user_extensions.rst > @@ -261,9 +261,7 @@ destructors and thread-local object destructors run in > this context. > Thread Switch Extension > --- > > -The thread switch extension is invoked before the context switch from the > -currently executing thread to the heir thread. The thread switch extension > is > -defined as follows. > +The thread switch extension is defined as follows. > > .. code-block:: c > > @@ -272,18 +270,34 @@ defined as follows. >rtems_tcb *heir > ); > > -The :c:data:`executing` is a pointer to the TCB of the currently executing > -thread. The :c:data:`heir` is a pointer to the TCB of the heir thread. > +The invocation conditions of the thread switch extension depend on whether > RTEMS > +was configured for uniprocessor or SMP systems. A user must pay attention to > +the differences to correctly implement a thread switch extension. > + > +In uniprocessor configurations, the thread switch extension is invoked before > +the context switch from the currently executing thread to the heir thread. > The > +:c:data:`executing` is a pointer to the TCB of the currently executing > thread. > +The :c:data:`heir` is a pointer to the TCB of the heir thread. The context > +switch initiated through the multitasking start is not covered by the thread > +switch extension. > + > +In SMP configurations, the thread switch extension is invoked after the > context > +switch to the new executing thread (previous heir thread). The > +:c:data:`executing` is a pointer to the TCB of the previously executing > thread. > +Despite the name, this is not the currently executing thread. The > +:c:data:`heir` is a pointer to the TCB of the newly executing thread. This > is > +the executing thread. The context switches initiated through the > multitasking Although I understand it, I think you might put "the currently executing thread" here as well. Rest looks good. > +start are covered by the thread switch extension. The reason for the > +differences to uniprocessor configurations is that the context switch may > update > +the heir thread of the processor, see :ref:`SMPThreadDispatchDetails`. The > +thread switch extensions are invoked with disabled interrupts and with > ownership > +of a per-processor SMP lock. Thread switch extensions may run in parallel on > +multiple processors. It is recommended to use thread-local or per-processor > +data structures for thread switch extensions. A global SMP lock should be > +avoided for performance reasons. > > The thread switch extension is invoked in forward order with thread > dispatching > -disabled. In SMP configurations, interrupts are disabled and the > per-processor > -SMP lock is owned. Thread switch extensions may run in parallel on multiple > -processors. It is recommended to use thread-local or per-processor data > -structures in SMP configurations for thread switch extensions. A global SMP > -lock should be avoided for performance reasons. > - > -The context switches initiated through the multitasking start are not covered > -by the thread switch extension. > +disabled. > > .. index:: rtems_task_begin_extension > > -- > 2.16.4 > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] c-user: Document thread switch extension changes
On 03/03/2020 13:09, Gedare Bloom wrote: +In SMP configurations, the thread switch extension is invoked after the context +switch to the new executing thread (previous heir thread). The +:c:data:`executing` is a pointer to the TCB of the previously executing thread. +Despite the name, this is not the currently executing thread. The +:c:data:`heir` is a pointer to the TCB of the newly executing thread. This is +the executing thread. The context switches initiated through the multitasking Although I understand it, I think you might put "the currently executing thread" here as well. Rest looks good. Thanks for the review. I checked it in with the suggested modification. -- 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: Coverity Scan broken?
On 03/03/2020 08:34, Sebastian Huber wrote: On 26/02/2020 11:55, Sebastian Huber wrote: On 25/02/2020 21:51, Gedare Bloom wrote: It's working for me. I see the results from Joel's recent run. Maybe try again. The interface has been changed, and I don't see any results for other projects (RTEMS-Newlib, RTEMS-Tools). I don't see anything. I tried it with Firefox and Safari. I will try to add a new account. I tried it with a new account, with Chromium and Microsoft Edge browsers. I cannot see the defects. I can now see the defects. I had do click on the "View All" field in the project list. This enabled me to see and select the RTEMS project. -- 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
[PATCH] rtems: rtems_scheduler_get_processor_maximum()
In uniprocessor configurations, use compile-time constants for
rtems_scheduler_get_processor_maximum() and
rtems_scheduler_get_processor(). This helps compilers and static
analyzers to deduce that some loops bodies are only executed once and
some conditional statements have a fixed outcome.
In SMP configurations, directly provide the internal implementation for
performance reasons.
---
cpukit/Makefile.am | 2 --
cpukit/include/rtems/rtems/tasks.h | 5 +++--
cpukit/rtems/src/getcurrentprocessor.c | 25 -
cpukit/rtems/src/getprocessorcount.c | 25 -
4 files changed, 3 insertions(+), 54 deletions(-)
delete mode 100644 cpukit/rtems/src/getcurrentprocessor.c
delete mode 100644 cpukit/rtems/src/getprocessorcount.c
diff --git a/cpukit/Makefile.am b/cpukit/Makefile.am
index 298580e20d..783a9bbf42 100644
--- a/cpukit/Makefile.am
+++ b/cpukit/Makefile.am
@@ -700,8 +700,6 @@ librtemscpu_a_SOURCES += rtems/src/eventseize.c
librtemscpu_a_SOURCES += rtems/src/eventsend.c
librtemscpu_a_SOURCES += rtems/src/eventsurrender.c
librtemscpu_a_SOURCES += rtems/src/getapiconfig.c
-librtemscpu_a_SOURCES += rtems/src/getcurrentprocessor.c
-librtemscpu_a_SOURCES += rtems/src/getprocessorcount.c
librtemscpu_a_SOURCES += rtems/src/intrbody.c
librtemscpu_a_SOURCES += rtems/src/intrcatch.c
librtemscpu_a_SOURCES += rtems/src/modes.c
diff --git a/cpukit/include/rtems/rtems/tasks.h
b/cpukit/include/rtems/rtems/tasks.h
index 3519bbf795..a4af236b6b 100644
--- a/cpukit/include/rtems/rtems/tasks.h
+++ b/cpukit/include/rtems/rtems/tasks.h
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#ifdef __cplusplus
extern "C" {
@@ -600,7 +601,7 @@ rtems_status_code rtems_scheduler_ident_by_processor_set(
*
* @return The index of the current processor.
*/
-uint32_t rtems_scheduler_get_processor( void );
+#define rtems_scheduler_get_processor() _SMP_Get_current_processor()
/**
* @brief Returns the index of the current processor.
@@ -633,7 +634,7 @@ rtems_get_current_processor( void )
*
* @see rtems_scheduler_add_processor() and rtems_scheduler_remove_processor().
*/
-RTEMS_CONST uint32_t rtems_scheduler_get_processor_maximum( void );
+#define rtems_scheduler_get_processor_maximum() _SMP_Get_processor_maximum()
/**
* @brief Returns the processor maximum supported by the system.
diff --git a/cpukit/rtems/src/getcurrentprocessor.c
b/cpukit/rtems/src/getcurrentprocessor.c
deleted file mode 100644
index 10811ade66..00
--- a/cpukit/rtems/src/getcurrentprocessor.c
+++ /dev/null
@@ -1,25 +0,0 @@
-/*
- * Copyright (c) 2014 embedded brains GmbH. All rights reserved.
- *
- * embedded brains GmbH
- * Dornierstr. 4
- * 82178 Puchheim
- * Germany
- *
- *
- * The license and distribution terms for this file may be
- * found in the file LICENSE in this distribution or at
- * http://www.rtems.org/license/LICENSE.
- */
-
-#if HAVE_CONFIG_H
- #include "config.h"
-#endif
-
-#include
-#include
-
-uint32_t rtems_scheduler_get_processor(void)
-{
- return _SMP_Get_current_processor();
-}
diff --git a/cpukit/rtems/src/getprocessorcount.c
b/cpukit/rtems/src/getprocessorcount.c
deleted file mode 100644
index 68de749225..00
--- a/cpukit/rtems/src/getprocessorcount.c
+++ /dev/null
@@ -1,25 +0,0 @@
-/*
- * Copyright (c) 2014 embedded brains GmbH. All rights reserved.
- *
- * embedded brains GmbH
- * Dornierstr. 4
- * 82178 Puchheim
- * Germany
- *
- *
- * The license and distribution terms for this file may be
- * found in the file LICENSE in this distribution or at
- * http://www.rtems.org/license/LICENSE.
- */
-
-#if HAVE_CONFIG_H
- #include "config.h"
-#endif
-
-#include
-#include
-
-uint32_t rtems_scheduler_get_processor_maximum(void)
-{
- return _SMP_Get_processor_maximum();
-}
--
2.16.4
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH v2 1/4] added fesetexeptflag() test to the psxfenv test
---
testsuites/psxtests/psxfenv01/init.c | 36
1 file changed, 31 insertions(+), 5 deletions(-)
diff --git a/testsuites/psxtests/psxfenv01/init.c
b/testsuites/psxtests/psxfenv01/init.c
index cdb0fa596e..8ffb9395b9 100644
--- a/testsuites/psxtests/psxfenv01/init.c
+++ b/testsuites/psxtests/psxfenv01/init.c
@@ -46,6 +46,9 @@
#include
#include
#include
+#include
+
+#define rtems_test_assert(x) assert(x)
const char rtems_test_name[] = "PSXFENV 01";
@@ -71,19 +74,19 @@ rtems_task Init(rtems_task_argument ignored)
r = fesetenv(FE_DFL_ENV);
if (r)
printf("fesetenv ==> %d\n", r);
-rtems_test_assert( r == 0 );
+assert( r == 0 );
/* Test 'feclearexcept()' and 'fetestexcept()' in one go. */
puts( "feclearexcept(FE_ALL_EXCEPT)." );
r = feclearexcept(FE_ALL_EXCEPT);
if (r)
printf("feclearexcept ==> 0x%x\n", r);
-rtems_test_assert( r == 0 );
+assert( r == 0 );
r = fetestexcept( FE_ALL_EXCEPT );
if (r)
printf("fetestexcept ==> 0x%x\n", r);
-rtems_test_assert( r == 0 );
+assert( r == 0 );
/* Test 'FE_DIVBYZERO' */
puts( "Divide by zero and confirm fetestexcept()" );
@@ -91,12 +94,22 @@ rtems_task Init(rtems_task_argument ignored)
b = 1.0;
c = b/a;
(void) c;
+/* Test fegetexceptflag() and fesetexceptflag().*/
+r=fegetexceptflag(&excepts,FE_ALL_EXCEPT);
+if(r)
+ printf("fegetexceptflag ==> 0x%x\n", r);
+assert(r == 0);
+
+r=fesetexceptflag(&excepts, FE_ALL_EXCEPT);
+if(r)
+ printf("fesetexceptflag ==> 0x%x\n", r);
+assert(r == 0);
+
-fegetexceptflag(&excepts,FE_ALL_EXCEPT);
#ifdef FE_DIVBYZERO
r = feraiseexcept(FE_DIVBYZERO);
-rtems_test_assert( fetestexcept( FE_DIVBYZERO ) );
+assert( fetestexcept( FE_DIVBYZERO ) );
#endif
/* Test 'FE_INEXACT' */
@@ -125,3 +138,16 @@ rtems_task Init(rtems_task_argument ignored)
#define CONFIGURE_INIT
#include
/* end of file */
+
+
+/*
+fegetenv()
+
+fegetround()
+feholdexcept()
+
+fesetexceptflag()
+fesetround()
+
+feupdateenv()
+*/
--
2.17.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH v2 4/4] test for fenv.h functions
---
testsuites/psxtests/psxfenv01/init.c | 75 +---
1 file changed, 46 insertions(+), 29 deletions(-)
diff --git a/testsuites/psxtests/psxfenv01/init.c
b/testsuites/psxtests/psxfenv01/init.c
index 4339139c58..dc9ec3c766 100644
--- a/testsuites/psxtests/psxfenv01/init.c
+++ b/testsuites/psxtests/psxfenv01/init.c
@@ -74,19 +74,25 @@ rtems_task Init(rtems_task_argument ignored)
puts( "fesetenv(FE_DFL_ENV)." );
r = fesetenv(FE_DFL_ENV);
if (r)
- printf("fesetenv ==> %d\n", r);
+ {
+printf("fesetenv ==> %d\n", r);
+ }
rtems_test_assert( r == 0 );
/* Test 'feclearexcept()' and 'fetestexcept()' in one go. */
puts( "feclearexcept(FE_ALL_EXCEPT)." );
r = feclearexcept(FE_ALL_EXCEPT);
if (r)
+{
printf("feclearexcept ==> 0x%x\n", r);
+}
rtems_test_assert( r == 0 );
r = fetestexcept( FE_ALL_EXCEPT );
if (r)
- printf("fetestexcept ==> 0x%x\n", r);
+ {
+printf("fetestexcept ==> 0x%x\n", r);
+ }
rtems_test_assert( r == 0 );
/* Test 'FE_DIVBYZERO' */
@@ -95,56 +101,67 @@ rtems_task Init(rtems_task_argument ignored)
b = 1.0;
c = b/a;
(void) c;
-/* Test fegetexceptflag() and fesetexceptflag().*/
-r=fegetexceptflag(&excepts,FE_ALL_EXCEPT);
-if(r)
- printf("fegetexceptflag ==> 0x%x\n", r);
+/* Test 'fegetexceptflag()' and 'fesetexceptflag()'. */
+r = fegetexceptflag(&excepts,FE_ALL_EXCEPT);
+if (r)
+{
+ printf("fegetexceptflag ==> 0x%x\n", r);
+}
rtems_test_assert(r == 0);
-r=fesetexceptflag(&excepts, FE_ALL_EXCEPT);
-if(r)
+r = fesetexceptflag(&excepts, FE_ALL_EXCEPT);
+if (r)
+{
printf("fesetexceptflag ==> 0x%x\n", r);
+}
rtems_test_assert(r == 0);
-/*test for fegetround() and fesetround()*/
-/*they have four main macros to be tested seperated by ifdef*/
-/* since all the architectures dont support them */
-/*the test cases gets and sets the rounding directions */
+/* Test for 'fegetround()' and 'fesetround()' */
+/*They have four main macros to be tested separated by ifdef */
+/* since not all architectures support them */
+/* the test case gets and sets the rounding directions */
#ifdef FE_TONEAREST
-
-r=fegetround();
-if(r)
+r = fegetround();
+if (r)
+{
printf("fegetround ==> 0x%x\n", r);
+}
rtems_test_assert(r == FE_TONEAREST) ;
#endif
#ifdef FE_TOWARDZERO
-
- r=fesetround(FE_TOWARDZERO);
- if(r)
- printf("fesetround ==> 0x%x\n", r);
+ r = fesetround(FE_TOWARDZERO);
+ if (r)
+ {
+ printf("fesetround ==> 0x%x\n", r);
+ }
rtems_test_assert(r == 0) ;
rtems_test_assert(fegetround() == FE_TOWARDZERO) ;
#endif
#ifdef FE_DOWNWARD
-
- r=fesetround(FE_DOWNWARD);
- if(r)
- printf("fesetround ==> 0x%x\n", r);
+ r = fesetround(FE_DOWNWARD);
+ if (r)
+ {
+ printf("fesetround ==> 0x%x\n", r);
+ }
rtems_test_assert(r == 0) ;
rtems_test_assert(fegetround() == FE_DOWNWARD) ;
#endif
#ifdef FE_UPWARD
- r=fesetround(FE_UPWARD);
- if(r)
- printf("fesetround ==> 0x%x\n", r);
+ r = fesetround(FE_UPWARD);
+ if (r)
+ {
+ printf("fesetround ==> 0x%x\n", r);
+ }
rtems_test_assert(r == 0) ;
rtems_test_assert(fegetround() == FE_UPWARD) ;
#endif
#ifdef FE_TONEAREST
- r=fesetround(FE_TONEAREST);
- if(r)
- printf("fesetround ==> 0x%x\n", r);
+ r = fesetround(FE_TONEAREST);
+ if (r)
+ {
+printf("fesetround ==> 0x%x\n", r);
+ }
rtems_test_assert(r == 0) ;
#endif
--
2.17.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH v2 2/4] added test for fegetexeptflag and fesetexeptflag
---
testsuites/psxtests/psxfenv01/init.c | 27 +--
1 file changed, 9 insertions(+), 18 deletions(-)
diff --git a/testsuites/psxtests/psxfenv01/init.c
b/testsuites/psxtests/psxfenv01/init.c
index 8ffb9395b9..05f3cdc880 100644
--- a/testsuites/psxtests/psxfenv01/init.c
+++ b/testsuites/psxtests/psxfenv01/init.c
@@ -47,8 +47,9 @@
#include
#include
#include
+#include
+
-#define rtems_test_assert(x) assert(x)
const char rtems_test_name[] = "PSXFENV 01";
@@ -74,19 +75,19 @@ rtems_task Init(rtems_task_argument ignored)
r = fesetenv(FE_DFL_ENV);
if (r)
printf("fesetenv ==> %d\n", r);
-assert( r == 0 );
+rtems_test_assert( r == 0 );
/* Test 'feclearexcept()' and 'fetestexcept()' in one go. */
puts( "feclearexcept(FE_ALL_EXCEPT)." );
r = feclearexcept(FE_ALL_EXCEPT);
if (r)
printf("feclearexcept ==> 0x%x\n", r);
-assert( r == 0 );
+rtems_test_assert( r == 0 );
r = fetestexcept( FE_ALL_EXCEPT );
if (r)
printf("fetestexcept ==> 0x%x\n", r);
-assert( r == 0 );
+rtems_test_assert( r == 0 );
/* Test 'FE_DIVBYZERO' */
puts( "Divide by zero and confirm fetestexcept()" );
@@ -98,18 +99,19 @@ rtems_task Init(rtems_task_argument ignored)
r=fegetexceptflag(&excepts,FE_ALL_EXCEPT);
if(r)
printf("fegetexceptflag ==> 0x%x\n", r);
-assert(r == 0);
+rtems_test_assert(r == 0);
r=fesetexceptflag(&excepts, FE_ALL_EXCEPT);
if(r)
printf("fesetexceptflag ==> 0x%x\n", r);
-assert(r == 0);
+rtems_test_assert(r == 0);
+
#ifdef FE_DIVBYZERO
r = feraiseexcept(FE_DIVBYZERO);
-assert( fetestexcept( FE_DIVBYZERO ) );
+rtems_test_assert( fetestexcept( FE_DIVBYZERO ) );
#endif
/* Test 'FE_INEXACT' */
@@ -140,14 +142,3 @@ rtems_task Init(rtems_task_argument ignored)
/* end of file */
-/*
-fegetenv()
-
-fegetround()
-feholdexcept()
-
-fesetexceptflag()
-fesetround()
-
-feupdateenv()
-*/
--
2.17.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH v2 3/4] test for fegetround and fesetround
---
testsuites/psxtests/psxfenv01/init.c | 42 +++-
1 file changed, 41 insertions(+), 1 deletion(-)
diff --git a/testsuites/psxtests/psxfenv01/init.c
b/testsuites/psxtests/psxfenv01/init.c
index 05f3cdc880..4339139c58 100644
--- a/testsuites/psxtests/psxfenv01/init.c
+++ b/testsuites/psxtests/psxfenv01/init.c
@@ -106,7 +106,47 @@ rtems_task Init(rtems_task_argument ignored)
printf("fesetexceptflag ==> 0x%x\n", r);
rtems_test_assert(r == 0);
-
+
+/*test for fegetround() and fesetround()*/
+/*they have four main macros to be tested seperated by ifdef*/
+/* since all the architectures dont support them */
+/*the test cases gets and sets the rounding directions */
+#ifdef FE_TONEAREST
+
+r=fegetround();
+if(r)
+ printf("fegetround ==> 0x%x\n", r);
+rtems_test_assert(r == FE_TONEAREST) ;
+#endif
+#ifdef FE_TOWARDZERO
+
+ r=fesetround(FE_TOWARDZERO);
+ if(r)
+ printf("fesetround ==> 0x%x\n", r);
+ rtems_test_assert(r == 0) ;
+ rtems_test_assert(fegetround() == FE_TOWARDZERO) ;
+#endif
+#ifdef FE_DOWNWARD
+
+ r=fesetround(FE_DOWNWARD);
+ if(r)
+ printf("fesetround ==> 0x%x\n", r);
+ rtems_test_assert(r == 0) ;
+ rtems_test_assert(fegetround() == FE_DOWNWARD) ;
+#endif
+#ifdef FE_UPWARD
+ r=fesetround(FE_UPWARD);
+ if(r)
+ printf("fesetround ==> 0x%x\n", r);
+ rtems_test_assert(r == 0) ;
+ rtems_test_assert(fegetround() == FE_UPWARD) ;
+#endif
+#ifdef FE_TONEAREST
+ r=fesetround(FE_TONEAREST);
+ if(r)
+ printf("fesetround ==> 0x%x\n", r);
+ rtems_test_assert(r == 0) ;
+#endif
#ifdef FE_DIVBYZERO
--
2.17.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: Introducing myself and HelloWorld completion.
Hi, > > Great. Those are two quite distinct projects. The "Improve the SMP > Scheduler" will require strong C programming skills. The "Release > Notes Generator" would involve Python programming. Depending on which > language you are stronger in, you might choose to pursue one of them. > How can I acquire the required skills to do projects like 'Improve the SMP Scheduler'. If there is a way that I can learn and work on it, then I would prefer it over the ' Release Notes Generator' project. Meanwhile, I have entered to work with the later on GSoC Tracking page. Thank you. Denil Verghese On Mon, Mar 2, 2020 at 10:50 PM Gedare Bloom wrote: > Hi Denil, > > > On Mon, Mar 2, 2020 at 10:07 AM Denil Verghese wrote: > > > > Hi everyone, > > > > Myself Denil C Verghese, doing a degree in Bachelors of Technology. > I'm here because of two reasons. Foremost, I would like to be part of this > endeavor. Second, I want to be an intern as a part of GSoC. > > > Welcome. > > > > > I have done the hello world program mentioned at the wiki page and I > have attached the patch file with this mail. I not sure whether it is the > correct output or not. For some reason, I can't load the simulator by > executing 'tar sim' in gdb. Hence I used sis command with -gdb argument and > used 'tar remote:1234' to run the simulator. Is this enough? > > > Yes, this is good. Thank you. I received your screenshot proof. > > > > > Thanks to Jiri Gaisler for helping me out with the hello World program. > > > > > > > > I would like to work on RTEMS Release Notes Generator or Improve the SMP > scheduler with arbitrary processor affinity support. It would be great if > someone could guide me in selecting the project. > > > Great. Those are two quite distinct projects. The "Improve the SMP > Scheduler" will require strong C programming skills. The "Release > Notes Generator" would involve Python programming. Depending on which > language you are stronger in, you might choose to pursue one of them. > > > > > I'm ready to resolve any mistakes that I may make. Hoping that I would > get some guidance on how to be a part of this. > > > > > > Thank You, > > > > Denil C Verghese > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Introducing myself and HelloWorld completion.
Hi , I have updated https://devel.rtems.org/wiki/GSoC/2020 page. Were there any documentation issues that need resolving for this? > sis has recently been split out of gdb and there are multiple places > that used sis as the example. It is hard to find them all. > Indeed I have found some pages that mention the use of standalone 'sis' command, but I think they all work (never tested them). I don't know why I couldn't get to run the simulator within the 'gdb' command. Is this command deprecated? Thank you. Denil Verghese On Mon, Mar 2, 2020 at 10:58 PM Joel Sherrill wrote: > > > On Mon, Mar 2, 2020 at 11:20 AM Gedare Bloom wrote: > >> Hi Denil, >> >> >> On Mon, Mar 2, 2020 at 10:07 AM Denil Verghese >> wrote: >> > >> > Hi everyone, >> > >> > Myself Denil C Verghese, doing a degree in Bachelors of >> Technology. I'm here because of two reasons. Foremost, I would like to be >> part of this endeavor. Second, I want to be an intern as a part of GSoC. >> > >> Welcome. >> >> > >> > I have done the hello world program mentioned at the wiki page and I >> have attached the patch file with this mail. I not sure whether it is the >> correct output or not. For some reason, I can't load the simulator by >> executing 'tar sim' in gdb. Hence I used sis command with -gdb argument and >> used 'tar remote:1234' to run the simulator. Is this enough? >> > >> Yes, this is good. Thank you. I received your screenshot proof. >> >> > Add yourself to https://devel.rtems.org/wiki/GSoC/2020 > > >> > >> > Thanks to Jiri Gaisler for helping me out with the hello World program. >> > >> >> > Were there any documentation issues that need resolving for this? > sis has recently been split out of gdb and there are multiple places > that used sis as the example. It is hard to find them all. > > >> > >> > I would like to work on RTEMS Release Notes Generator or Improve the >> SMP scheduler with arbitrary processor affinity support. It would be great >> if someone could guide me in selecting the project. >> > >> Great. Those are two quite distinct projects. The "Improve the SMP >> Scheduler" will require strong C programming skills. The "Release >> Notes Generator" would involve Python programming. Depending on which >> language you are stronger in, you might choose to pursue one of them. >> >> > >> > > Sebastian should comment on the SMP Scheduler Improvements. I > have no idea what he has in mind. > > The Release Notes Generator was started a couple of years ago. > Chris Johns knows what's left to make it production worthy. > > Start threads on each topic to attract the right mentors attention. :) > > >> > I'm ready to resolve any mistakes that I may make. Hoping that I would >> get some guidance on how to be a part of this. >> > >> > >> > Thank You, >> > >> > Denil C Verghese >> ___ >> devel mailing list >> devel@rtems.org >> http://lists.rtems.org/mailman/listinfo/devel >> > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH 2/2] Add to wscript and add python2 shebang.
This script does work but needs some user friendliness added which is
acknowledged by the author as it was meant as a quick replacement.
---
misc/tools/mkimage.py | 2 ++
misc/wscript | 1 +
2 files changed, 3 insertions(+)
mode change 100644 => 100755 misc/tools/mkimage.py
diff --git a/misc/tools/mkimage.py b/misc/tools/mkimage.py
old mode 100644
new mode 100755
index ee57481..39a12a0
--- a/misc/tools/mkimage.py
+++ b/misc/tools/mkimage.py
@@ -1,3 +1,5 @@
+#!/usr/bin/env python2
+
# A quickly bashed together replacement for u-boot's mkimage written in python
#
# Copyright 2010 Craig Barker
diff --git a/misc/wscript b/misc/wscript
index 7d90968..d82bde3 100644
--- a/misc/wscript
+++ b/misc/wscript
@@ -79,6 +79,7 @@ def build(bld):
'tools/cmd-tftpproxy.py',
'tools/tftpproxy.py',
'tools/getmac/__init__.py',
+ 'tools/mkimage.py',
'tools/getmac/getmac.py'],
install_from = '.',
install_path = '${PREFIX}/share/rtems/misc')
--
2.25.0
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH 1/2] Add a pure Python clone of mkimage written by Craig Barker.
I emailed Craig Barker to ask if he would release his mkimage Python rewrite
as 2BSD. He graciously accepted and you can see his work here:
https://github.com/cmbarker83/pythonmkimage
This is a verbatim commit of 35d6d from his repository.
---
misc/tools/mkimage.py | 139 ++
1 file changed, 139 insertions(+)
create mode 100644 misc/tools/mkimage.py
diff --git a/misc/tools/mkimage.py b/misc/tools/mkimage.py
new file mode 100644
index 000..ee57481
--- /dev/null
+++ b/misc/tools/mkimage.py
@@ -0,0 +1,139 @@
+# A quickly bashed together replacement for u-boot's mkimage written in python
+#
+# Copyright 2010 Craig Barker
+#
+# Redistribution and use in source and binary forms, with or without
+# modification, are permitted provided that the following conditions are met:
+#
+# 1. Redistributions of source code must retain the above copyright notice,
+#this list of conditions and the following disclaimer.
+#
+# 2. Redistributions in binary form must reproduce the above copyright notice,
+#this list of conditions and the following disclaimer in the documentation
+#and/or other materials provided with the distribution.
+#
+# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+# AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+# ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
+# LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+# CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+# SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+# INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+# CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+# ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+# POSSIBILITY OF SUCH DAMAGE.
+
+
+from optparse import OptionParser
+from struct import *
+import sys
+import os.path
+import time
+import binascii
+
+MAGIC = 0x27051956
+IMG_NAME_LENGTH = 32
+
+archs = {'invalid':0, 'alpha':1, 'arm':2, 'x86':3, 'ia64':4, 'm68k':12,
+ 'microblaze':14, 'mips':5, 'mips64':6, 'nios':13, 'nios2':15,
+ 'powerpc':7, 'ppc':7, 's390':8, 'sh':9, 'sparc':10,
+ 'sparc64':11, 'blackfin':16, 'arv32':17, 'st200':18 }
+
+oss = {'invalid':0, 'openbsd':1, 'netbsd':2, 'freebsd':3, '4_4bsd':4,
+ 'linux':5, 'svr4':6, 'esix':7, 'solaris':8, 'irix':9,
+ 'sco':10, 'dell':11, 'ncr':12, 'lynos':13, 'vxworks':14,
+ 'psos':15, 'qnx':16, 'u-boot':17, 'rtems':18, 'artos':19,
+ 'unity':20, 'integrity':21 }
+
+types = {'invalid':0, 'standalone':1, 'kernel':2, 'ramdisk':3, 'multi':4,
+ 'firmware':5,'script':6, 'filesystem':7, 'flat_dt':8 }
+
+comps = {'none':0, 'bzip2':2, 'gzip':1, 'lzma':3 }
+
+usage = "usage: %prog [options] image"
+parser = OptionParser(usage=usage)
+parser.add_option("-A","--arch", dest="arch", default="powerpc",
+ help="set architecture to 'arch'", metavar="ARCH")
+parser.add_option("-O","--os", dest="os", default="linux",
+ help="set operating system to 'os'", metavar="OS")
+parser.add_option("-T","--type", dest="type", default="kernel",
+ help="set image type to 'type'", metavar="TYPE")
+parser.add_option("-C","--comp", dest="comp", default="gzip",
+ help="set compression type 'comp'", metavar="COMP")
+parser.add_option("-a","--addr", dest="addr", default="0",
+ help="set load address to 'addr' (hex)", metavar="ADDR")
+parser.add_option("-e","--ep", dest="ep", default="0",
+ help="set entry point to 'ep' (hex)", metavar="EP")
+parser.add_option("-n","--name", dest="name", default="",
+ help="set image name to 'name'", metavar="NAME")
+parser.add_option("-d","--datafile", dest="datafile",
+ help="use image data from 'datafile'", metavar="DATAFILE")
+parser.add_option("-x","--xip", action="store_true", dest="xip", default=False,
+ help="set XIP (execute in place)")
+
+(options, args) = parser.parse_args()
+
+if len(args) != 1: parser.print_help()
+
+if options.arch not in archs:
+print "Invalid architecture specified, aborting"
+sys.exit(2)
+
+if options.os not in oss:
+print "Invalid operating system specified, aborting"
+sys.exit(2)
+
+if options.comp not in comps:
+print "Invalid compression specified, aborting"
+sys.exit(2)
+
+if options.type not in types:
+print "Invalid image type specified, aborting"
+sys.exit(2)
+
+try:
+inputsize = os.path.getsize(options.datafile)
+inputfile = open(options.datafile, 'rb')
+
+except IOError:
+print "Invalid datafile specified, aborting"
+sys.exit(2)
+
+try:
+outputfile = open(args[0],'wb')
RTEMS Release Notes Generator - GSoC Project
I've read the ticket page at https://devel.rtems.org/ticket/3314, but it was last modified a couple of years ago. I would like to know if there are any changes or information that are missing from the ticket. I have intermediate knowledge on python, have a good grasp on both HTML and CSS and basic level on XML. Thank you. Denil Verghese ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: RTEMS Release Notes Generator - GSoC Project
On 4/3/20 1:04 pm, Denil Verghese wrote: > I've read the ticket page at https://devel.rtems.org/ticket/3314, but it was > last modified a couple of years ago. I would like to know if there are any > changes or information that are missing from the ticket. > > I have intermediate knowledge on python, have a good grasp on both HTML and > CSS > and basic level on XML. Thank you for the interest. I have updated the ticket. The existing work can be found in this repo ... https://github.com/dh0072/ReleaseNotesGenerator There is working code to fetch the tickets from Trac. The next stage is to generate ReST output from the data that can built into HTML or PDF by Sphinx. There is existing MarkDown support but it not right or suitable for use. I am not sure how usable that part of the code is. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Device Tree Blob for Beaglebone Black?
Sorry about delay in getting back to this. I have been focused on getting the release into something close to what we want for RC1. On 28/2/20 9:48 pm, Christian Mauderer wrote: > Hello Gedare and Chris, > > On 27/02/2020 23:14, Gedare Bloom wrote: >> On Thu, Feb 27, 2020 at 3:01 PM Chris Johns wrote: >>> >>> On 28/2/20 7:23 am, Alan Cudmore wrote: I noticed that the Zephyr RTOS (https://www.zephyrproject.org) uses a device tree based initialization for all of its BSPs. For example, here is the top level device tree source for the Adafruit Trinket M0, which is a very small Atmel Cortex M0 based board: https://github.com/zephyrproject-rtos/zephyr/blob/master/boards/arm/adafruit_trinket_m0/adafruit_trinket_m0.dts The rest of the device tree source for common processors and devices are here: https://github.com/zephyrproject-rtos/zephyr/tree/master/dts To me, it looks like they have to develop (or port) and maintain device trees for each board and device that is supported. Does that look like a model that RTEMS could use? I'm not sure I understand everything that deploying such a model implies, or if it just makes more sense to use the existing FreeBSD or linux device trees. >>> >>> This is where I was heading in my thinking but I am not sure. I am settling >>> on >>> having a dts tree in rtems.git and we may just have to manually manage the >>> files. I am not sure there are enough files to warrant a system like libbsd >>> and >>> FreeBSD at this point in time. That may change with the new build system and >>> python being available however until then manual is fine. Let me explain ... >>> >>> I have been looking beyond the internal development aspects and to how we >>> use >>> FDT blobs and I am wondering if the approach we have with the shared FDT BSP >>> support is the right fit for RTEMS and a statically linked executable. >>> >>> I believe currently we need a suitable bootloader, ie u-boot, to load a >>> blob. >>> This is the Linux way of doing things and this may be the right approach for >>> Linux but I am not so sure it is for us. It means you need u-boot and a >>> suitable >>> file system plus you have a lot more items to configuration manage in >>> production >>> systems and a lot more complexity for self upgrading. > > I think for Boards that normally run a Linux it is a sane approach to > just replace the Linux Kernel with a RTEMS binary and otherwise keep the > boot process with for example U-Boot. Everything else is a lot of extra > effort to implement and not necessary in a lot of situations. Is there documentation about that shows this process for an existing board? I get what you are saying and it make prefect sense and it would be no issue for me to do this however there are a number of steps involved and there is a certain amount of assumed knowledge here. How do we establish a framework or template that lets are capture this so it is useful and usable to our users? > >>> >>> Why do we have a bootloader load the FDT files when we statically link >>> everything else?>> >>> Why not link them into the executable and register them? It s easy to do. >>> > > One BSP where it is a disadvantage to statically link is Raspberry Pi. > With the recent work you currently can use the same binary for RPi2 and > 3 with only a different FDT. Same for RPi1 and RPi Zero / Zero W. Great example and a good point. > I'm not against the possibility to link the FDT. But we should be open > to use both methods. OK >>> The flow on from doing this has some real advantages. FDT files that are >>> linked >>> into an executable can then live in the rtems.git repo. If you move branches >>> when testing or in production you do not need to manage and match suitable >>> FDT >>> blobs. >>> >>> I am not advocating this is the only solution. I can see for some BSPs this >>> will >>> not work and u-boot loading is the only or best solution. I however believe >>> for >>> DTS that is open and available we should avoid the whole mess of needing to >>> build and manage them on boot media separately to the executable. > > Note the licensing issues if you use FreeBSD or Linux FDTs: They are > GPL. If you statically link them you will infect other code too. Ouch, that is a blocker to linking to the image. In light of this maybe any effort to link it is not worth it. I wonder what you do with a board that needs an FDT but has no media to hold one? > Although for BSPs where no FDT exists it might is a good idea to write > your own FDT and license it with a RTEMS compatible license. For BSPs > like BBB it's not a good idea if you ask me. It's a lot of work. Yes I agree. >>> The issue of RTEMS version mismatch of blobs is a real issue waiting to hit >>> our >>> users and simply linking the blobs into the executable would solve this. > > Again: It opens licensing issues for our users! > Understood. I had not considered this
Re: Introducing myself and HelloWorld completion.
On Tue, Mar 3, 2020 at 6:02 PM Denil Verghese wrote: > > Hi, >> >> >> Great. Those are two quite distinct projects. The "Improve the SMP >> Scheduler" will require strong C programming skills. The "Release >> Notes Generator" would involve Python programming. Depending on which >> language you are stronger in, you might choose to pursue one of them. > > > How can I acquire the required skills to do projects like 'Improve the SMP > Scheduler'. If there is a way that I can learn and work on it, then I would > prefer it over the ' Release Notes Generator' project. > Meanwhile, I have entered to work with the later on GSoC Tracking page. > You need to have pretty good C programming skills before the summer even begins. More of a concern is whether anyone is able to mentor that project this year. > Thank you. > Denil Verghese > > On Mon, Mar 2, 2020 at 10:50 PM Gedare Bloom wrote: >> >> Hi Denil, >> >> >> On Mon, Mar 2, 2020 at 10:07 AM Denil Verghese wrote: >> > >> > Hi everyone, >> > >> > Myself Denil C Verghese, doing a degree in Bachelors of Technology. >> > I'm here because of two reasons. Foremost, I would like to be part of this >> > endeavor. Second, I want to be an intern as a part of GSoC. >> > >> Welcome. >> >> > >> > I have done the hello world program mentioned at the wiki page and I have >> > attached the patch file with this mail. I not sure whether it is the >> > correct output or not. For some reason, I can't load the simulator by >> > executing 'tar sim' in gdb. Hence I used sis command with -gdb argument >> > and used 'tar remote:1234' to run the simulator. Is this enough? >> > >> Yes, this is good. Thank you. I received your screenshot proof. >> >> > >> > Thanks to Jiri Gaisler for helping me out with the hello World program. >> > >> > >> > >> > I would like to work on RTEMS Release Notes Generator or Improve the SMP >> > scheduler with arbitrary processor affinity support. It would be great if >> > someone could guide me in selecting the project. >> > >> Great. Those are two quite distinct projects. The "Improve the SMP >> Scheduler" will require strong C programming skills. The "Release >> Notes Generator" would involve Python programming. Depending on which >> language you are stronger in, you might choose to pursue one of them. >> >> > >> > I'm ready to resolve any mistakes that I may make. Hoping that I would get >> > some guidance on how to be a part of this. >> > >> > >> > Thank You, >> > >> > Denil C Verghese ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 1/2] Add a pure Python clone of mkimage written by Craig Barker.
On 04/03/2020 02:46, Amar Takhar wrote: I emailed Craig Barker to ask if he would release his mkimage Python rewrite as 2BSD. He graciously accepted and you can see his work here: https://github.com/cmbarker83/pythonmkimage This is a verbatim commit of 35d6d from his repository. This is really nice. Getting mkimage for Windows was always a pain. -- 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: Device Tree Blob for Beaglebone Black?
On 04/03/2020 05:55, Chris Johns wrote: I think for Boards that normally run a Linux it is a sane approach to just replace the Linux Kernel with a RTEMS binary and otherwise keep the boot process with for example U-Boot. Everything else is a lot of extra effort to implement and not necessary in a lot of situations. Is there documentation about that shows this process for an existing board? I get what you are saying and it make prefect sense and it would be no issue for me to do this however there are a number of steps involved and there is a certain amount of assumed knowledge here. How do we establish a framework or template that lets are capture this so it is useful and usable to our users? My approach would be to use the devices trees shipped by the hardware vendor and fix our drivers if necessary. For example, I had to adjust the Altera Cyclone V BSP for these modules: https://www.enclustra.com/en/products/system-on-chip-modules/mars-ma3/ The device tree has a different clock structure compared to the Altera Development Kit, so the update_clocks() function supports both: https://git.rtems.org/rtems/tree/bsps/arm/altera-cyclone-v/start/bspstart.c#n79 -- 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: Introducing myself and HelloWorld completion.
On 04/03/2020 06:28, Gedare Bloom wrote: On Tue, Mar 3, 2020 at 6:02 PM Denil Verghese wrote: Hi, Great. Those are two quite distinct projects. The "Improve the SMP Scheduler" will require strong C programming skills. The "Release Notes Generator" would involve Python programming. Depending on which language you are stronger in, you might choose to pursue one of them. How can I acquire the required skills to do projects like 'Improve the SMP Scheduler'. If there is a way that I can learn and work on it, then I would prefer it over the ' Release Notes Generator' project. Meanwhile, I have entered to work with the later on GSoC Tracking page. You need to have pretty good C programming skills before the summer even begins. More of a concern is whether anyone is able to mentor that project this year. Improving an SMP scheduler this year is not in my focus. I am quite happy with the current SMP EDF scheduler. -- 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
