Rework of Initialization Chapter in BSP Howto
Hello, I reworked the heavily out dated system initialization chapter in the RTEMS BSP and Driver Guide: https://docs.rtems.org/branches/master/bsp-howto/initilization_code.html I would be happy if some want to review 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
Re: [PATCH 00/21] Support statically allocated threads
Hello, any objects to push this patch set with the additional _Objects_Allocate_with_extend()? https://lists.rtems.org/pipermail/devel/2020-January/056724.html I will work on a documentation update afterwards. - Am 16. Dez 2019 um 15:28 schrieb Sebastian Huber sebastian.hu...@embedded-brains.de: > This change set makes it possible to statically allocate threads. This means > the thread control block is provided by a statically allocated thread > information and the thread stack is provided by the user. Currently, no API > function exists for this. Adding this API is a follow up change set. Only > the > internal threads use statically allocated thread stacks in this change set. > > Sebastian Huber (21): > score: Remove superfluous FP types/defines > score: Simplify thread stack allocation > score: Simplify thread stack free > score: Remove _Stack_Ensure_minimum() call > score: Simplify FP context allocation > score: Simplify TLS area allocation > score: Split stack allocator configuration > score: Add Thread_Configuration > score: Add _Stack_Extend_size() > score: Move thread stack allocation > score: Statically allocate idle/MPCI stacks > score: Add _Objects_Free_objects_block() > score: Split up objects allocation > score: Split up objects free > score: Inline _Objects_Namespace_remove_u32() > score: _Objects_Extend_information() > score: Add _Freechain_Is_empty() > score: Add _Freechain_Pop() > score: Add _Freechain_Extend() > score: Add _Objects_Activate_unlimited() > score: Simplify _Thread_Initialize() ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH] config: Remove BSP_ZERO_WORKSPACE_AUTOMATICALLY
Update #3863. --- cpukit/include/rtems/confdefs.h | 8 +--- 1 file changed, 1 insertion(+), 7 deletions(-) diff --git a/cpukit/include/rtems/confdefs.h b/cpukit/include/rtems/confdefs.h index ffb13fd262..0a63dcc461 100644 --- a/cpukit/include/rtems/confdefs.h +++ b/cpukit/include/rtems/confdefs.h @@ -59,7 +59,6 @@ #undef BSP_INITIAL_EXTENSION #undef BSP_INTERRUPT_STACK_SIZE #undef BSP_MAXIMUM_DEVICES - #undef BSP_ZERO_WORKSPACE_AUTOMATICALLY #undef CONFIGURE_BSP_PREREQUISITE_DRIVERS #undef CONFIGURE_MALLOC_BSP_SUPPORTS_SBRK #else @@ -1240,12 +1239,7 @@ extern rtems_initialization_tasks_table Initialization_tasks[]; * at system start up? */ #ifndef CONFIGURE_ZERO_WORKSPACE_AUTOMATICALLY - #ifdef BSP_ZERO_WORKSPACE_AUTOMATICALLY -#define CONFIGURE_ZERO_WORKSPACE_AUTOMATICALLY \ -BSP_ZERO_WORKSPACE_AUTOMATICALLY - #else -#define CONFIGURE_ZERO_WORKSPACE_AUTOMATICALLY FALSE - #endif + #define CONFIGURE_ZERO_WORKSPACE_AUTOMATICALLY FALSE #endif /**@}*/ /* end of add to group Configuration */ -- 2.16.4 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH] Remove BSP_ZERO_WORKSPACE_AUTOMATICALLY
Close #3863. --- bsp-howto/miscellanous_support.rst | 7 --- c-user/configuring_a_system.rst| 28 2 files changed, 35 deletions(-) diff --git a/bsp-howto/miscellanous_support.rst b/bsp-howto/miscellanous_support.rst index efb4454..015adb4 100644 --- a/bsp-howto/miscellanous_support.rst +++ b/bsp-howto/miscellanous_support.rst @@ -206,13 +206,6 @@ macros: stack size as recommended when using this BSP. This is sometimes required when the BSP developer has knowledge of stack intensive interrupt handlers. -.. index:: BSP_ZERO_WORKSPACE_AUTOMATICALLY - -- ``BSP_ZERO_WORKSPACE_AUTOMATICALLY`` is defined when the BSP requires that - RTEMS zero out the RTEMS C Program Heap at initialization. If the memory is - already zeroed out by a test sequence or boot ROM, then the boot time can be - reduced by not zeroing memory twice. - .. index:: BSP_DEFAULT_UNIFIED_WORK_AREAS - ``BSP_DEFAULT_UNIFIED_WORK_AREAS`` is defined when the BSP recommends that diff --git a/c-user/configuring_a_system.rst b/c-user/configuring_a_system.rst index 36c7f15..967cb74 100644 --- a/c-user/configuring_a_system.rst +++ b/c-user/configuring_a_system.rst @@ -3187,34 +3187,6 @@ NOTES: only impacts the devFS and thus is only used by when ``CONFIGURE_USE_DEVFS_AS_BASE_FILESYSTEM`` is specified. -.. index:: BSP_ZERO_WORKSPACE_AUTOMATICALLY - -.. _BSP_ZERO_WORKSPACE_AUTOMATICALLY: - -BSP_ZERO_WORKSPACE_AUTOMATICALLY - - -CONSTANT: -``BSP_ZERO_WORKSPACE_AUTOMATICALLY`` - -DATA TYPE: -Boolean feature macro. - -RANGE: -Defined or undefined. - -DEFAULT VALUE: -This option is BSP specific. - -DESCRIPTION: -If ``BSP_ZERO_WORKSPACE_AUTOMATICALLY`` is defined by the BSP and -``CONFIGURE_ZERO_WORKSPACE_AUTOMATICALLY`` is not defined by the -application, then the workspace will be zeroed automatically. - -NOTES: -Zeroing memory can add significantly to system boot time. It is not -necessary for RTEMS but is often assumed by support libraries. - .. index:: CONFIGURE_BSP_PREREQUISITE_DRIVERS .. _CONFIGURE_BSP_PREREQUISITE_DRIVERS: -- 2.16.4 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH 1/2] samples/iostream: Simplify configuration
Remove CONFIGURE_ZERO_WORKSPACE_AUTOMATICALLY since it is not needed and just increases the boot time. --- testsuites/samples/iostream/system.h | 1 - 1 file changed, 1 deletion(-) diff --git a/testsuites/samples/iostream/system.h b/testsuites/samples/iostream/system.h index 0ae1d8f94f..fbcc56e063 100644 --- a/testsuites/samples/iostream/system.h +++ b/testsuites/samples/iostream/system.h @@ -21,7 +21,6 @@ /* NOTICE: the clock driver is explicitly disabled */ #define CONFIGURE_APPLICATION_DOES_NOT_NEED_CLOCK_DRIVER #define CONFIGURE_APPLICATION_NEEDS_SIMPLE_CONSOLE_DRIVER -#define CONFIGURE_ZERO_WORKSPACE_AUTOMATICALLY TRUE #define CONFIGURE_MAXIMUM_TASKS1 -- 2.16.4 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH 2/2] config: CONFIGURE_ZERO_WORKSPACE_AUTOMATICALLY
Canonicalize CONFIGURE_ZERO_WORKSPACE_AUTOMATICALLY and use
defined/undefined instead of TRUE/FALSE.
Close #3862.
---
cpukit/include/rtems/confdefs.h | 15 +--
testsuites/sptests/sp54/init.c | 5 ++---
2 files changed, 7 insertions(+), 13 deletions(-)
diff --git a/cpukit/include/rtems/confdefs.h b/cpukit/include/rtems/confdefs.h
index 0a63dcc461..7d0d3fbeab 100644
--- a/cpukit/include/rtems/confdefs.h
+++ b/cpukit/include/rtems/confdefs.h
@@ -1234,15 +1234,6 @@ extern rtems_initialization_tasks_table
Initialization_tasks[];
*/
/**@{*/
-/**
- * Should the RTEMS Workspace and C Program Heap be cleared automatically
- * at system start up?
- */
-#ifndef CONFIGURE_ZERO_WORKSPACE_AUTOMATICALLY
- #define CONFIGURE_ZERO_WORKSPACE_AUTOMATICALLY FALSE
-#endif
-/**@}*/ /* end of add to group Configuration */
-
/**
* @defgroup ConfigurationMalloc RTEMS Malloc configuration
*
@@ -2787,7 +2778,11 @@ struct _reent *__getreent(void)
CONFIGURE_TASK_STACK_ALLOCATOR_INIT, /* stack allocator init */
CONFIGURE_TASK_STACK_ALLOCATOR, /* stack allocator */
CONFIGURE_TASK_STACK_DEALLOCATOR, /* stack deallocator */
-CONFIGURE_ZERO_WORKSPACE_AUTOMATICALLY, /* true to clear memory */
+#ifdef CONFIGURE_ZERO_WORKSPACE_AUTOMATICALLY /* true to clear memory */
+ true,
+#else
+ false,
+#endif
#ifdef CONFIGURE_UNIFIED_WORK_AREAS /* true for unified work areas */
true,
#else
diff --git a/testsuites/sptests/sp54/init.c b/testsuites/sptests/sp54/init.c
index cf7f4dbda4..7bedb46497 100644
--- a/testsuites/sptests/sp54/init.c
+++ b/testsuites/sptests/sp54/init.c
@@ -82,10 +82,9 @@ rtems_initialization_tasks_table Initialization_tasks[1] =
#define CONFIGURE_INIT_TASK_STACK_SIZE 0
/*
- * Ensure we test the case where memory is zero. Not
- * all BSPs will set this to TRUE by default.
+ * Ensure we test the case where memory is zero.
*/
-#define CONFIGURE_ZERO_WORKSPACE_AUTOMATICALLY TRUE
+#define CONFIGURE_ZERO_WORKSPACE_AUTOMATICALLY
#define CONFIGURE_INIT
#include
--
2.16.4
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
GCC Git Conversion Done
Hello, it seems GCC finished the Git conversion: https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;a=summary This means our GCC Git mirror refers to a deprecated Git repository. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH] sysinit: Add RTEMS_SYSINIT_ZERO_MEMORY
Use a dedicate system initialization step to zero the memory used for
the workspace and C program heap.
This avoids dead code in case CONFIGURE_ZERO_WORKSPACE_AUTOMATICALLY is
not configured.
---
cpukit/Makefile.am | 2 ++
cpukit/include/rtems/confdefs.h| 15 +-
cpukit/include/rtems/config.h | 11 ++
cpukit/include/rtems/score/memory.h| 13
cpukit/include/rtems/sysinit.h | 3 ++-
cpukit/sapi/src/sysinitverbose.c | 10 -
cpukit/score/src/memoryzerobeforeuse.c | 34 +++
cpukit/score/src/memoryzerofreeareas.c | 37 ++
cpukit/score/src/wkspace.c | 6 --
testsuites/sptests/sp54/init.c | 2 ++
10 files changed, 111 insertions(+), 22 deletions(-)
create mode 100644 cpukit/score/src/memoryzerobeforeuse.c
create mode 100644 cpukit/score/src/memoryzerofreeareas.c
diff --git a/cpukit/Makefile.am b/cpukit/Makefile.am
index 2bfa2ddabd..b9ab123b49 100644
--- a/cpukit/Makefile.am
+++ b/cpukit/Makefile.am
@@ -854,6 +854,8 @@ librtemscpu_a_SOURCES += score/src/heapgreedy.c
librtemscpu_a_SOURCES += score/src/heapnoextend.c
librtemscpu_a_SOURCES += score/src/memoryallocate.c
librtemscpu_a_SOURCES += score/src/memoryfill.c
+librtemscpu_a_SOURCES += score/src/memoryzerobeforeuse.c
+librtemscpu_a_SOURCES += score/src/memoryzerofreeareas.c
librtemscpu_a_SOURCES += score/src/objectallocate.c
librtemscpu_a_SOURCES += score/src/objectclose.c
librtemscpu_a_SOURCES += score/src/objectextendinformation.c
diff --git a/cpukit/include/rtems/confdefs.h b/cpukit/include/rtems/confdefs.h
index 7d0d3fbeab..982e3ddb56 100644
--- a/cpukit/include/rtems/confdefs.h
+++ b/cpukit/include/rtems/confdefs.h
@@ -2778,11 +2778,6 @@ struct _reent *__getreent(void)
CONFIGURE_TASK_STACK_ALLOCATOR_INIT, /* stack allocator init */
CONFIGURE_TASK_STACK_ALLOCATOR, /* stack allocator */
CONFIGURE_TASK_STACK_DEALLOCATOR, /* stack deallocator */
-#ifdef CONFIGURE_ZERO_WORKSPACE_AUTOMATICALLY /* true to clear memory */
- true,
-#else
- false,
-#endif
#ifdef CONFIGURE_UNIFIED_WORK_AREAS /* true for unified work areas */
true,
#else
@@ -2807,6 +2802,16 @@ struct _reent *__getreent(void)
#endif
};
+ #ifdef CONFIGURE_ZERO_WORKSPACE_AUTOMATICALLY
+const bool _Memory_Zero_before_use = true;
+
+RTEMS_SYSINIT_ITEM(
+ _Memory_Zero_free_areas,
+ RTEMS_SYSINIT_ZERO_MEMORY,
+ RTEMS_SYSINIT_ORDER_MIDDLE
+);
+ #endif
+
#if CONFIGURE_RECORD_PER_PROCESSOR_ITEMS > 0
#if (CONFIGURE_RECORD_PER_PROCESSOR_ITEMS &
(CONFIGURE_RECORD_PER_PROCESSOR_ITEMS - 1)) != 0
#error "CONFIGURE_RECORD_PER_PROCESSOR_ITEMS must be a power of two"
diff --git a/cpukit/include/rtems/config.h b/cpukit/include/rtems/config.h
index 15e944dd2f..fac5c6e009 100644
--- a/cpukit/include/rtems/config.h
+++ b/cpukit/include/rtems/config.h
@@ -29,6 +29,7 @@
#include
#include
+#include
#include
#include
#include
@@ -148,14 +149,6 @@ typedef struct {
*/
rtems_stack_free_hook stack_free_hook;
- /**
- * If this element is TRUE, then RTEMS will zero the Executive Workspace.
- * When this element is FALSE, it is assumed that the BSP or invoking
- * environment has ensured that memory was cleared before RTEMS was
- * invoked.
- */
- bool do_zero_of_workspace;
-
/**
* @brief Specifies if a unified work area is used or not.
*
@@ -241,7 +234,7 @@ uint32_t rtems_configuration_get_maximum_extensions( void );
* RTEMS is responsible for zeroing the Executive Workspace.
*/
#define rtems_configuration_get_do_zero_of_workspace() \
- (Configuration.do_zero_of_workspace)
+ _Memory_Zero_before_use
#define rtems_configuration_get_number_of_initial_extensions() \
((uint32_t) _User_extensions_Initial_count)
diff --git a/cpukit/include/rtems/score/memory.h
b/cpukit/include/rtems/score/memory.h
index f26c7f4031..ffc4897ed5 100644
--- a/cpukit/include/rtems/score/memory.h
+++ b/cpukit/include/rtems/score/memory.h
@@ -331,6 +331,19 @@ void *_Memory_Allocate(
*/
void _Memory_Fill( const Memory_Information *information, int c );
+/**
+ * @brief Indicates if the memory is zeroed during system initialization.
+ *
+ * This value is provided via in case
+ * CONFIGURE_ZERO_WORKSPACE_AUTOMATICALLY is defined.
+ */
+extern const bool _Memory_Zero_before_use;
+
+/**
+ * @brief Zeros all free memory areas of the system.
+ */
+void _Memory_Zero_free_areas( void );
+
/** @} */
#ifdef __cplusplus
diff --git a/cpukit/include/rtems/sysinit.h b/cpukit/include/rtems/sysinit.h
index 58f35542b7..d181c42780 100644
--- a/cpukit/include/rtems/sysinit.h
+++ b/cpukit/include/rtems/sysinit.h
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2015, 2018 embedded brains GmbH. All rights reserved.
+ * Copyright (c) 2015, 2020 embedded brains GmbH.
Re: [PATCH] config: Remove BSP_ZERO_WORKSPACE_AUTOMATICALLY
Why is this being removed? --joel On Tue, Feb 4, 2020 at 6:14 AM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > Update #3863. > --- > cpukit/include/rtems/confdefs.h | 8 +--- > 1 file changed, 1 insertion(+), 7 deletions(-) > > diff --git a/cpukit/include/rtems/confdefs.h > b/cpukit/include/rtems/confdefs.h > index ffb13fd262..0a63dcc461 100644 > --- a/cpukit/include/rtems/confdefs.h > +++ b/cpukit/include/rtems/confdefs.h > @@ -59,7 +59,6 @@ >#undef BSP_INITIAL_EXTENSION >#undef BSP_INTERRUPT_STACK_SIZE >#undef BSP_MAXIMUM_DEVICES > - #undef BSP_ZERO_WORKSPACE_AUTOMATICALLY >#undef CONFIGURE_BSP_PREREQUISITE_DRIVERS >#undef CONFIGURE_MALLOC_BSP_SUPPORTS_SBRK > #else > @@ -1240,12 +1239,7 @@ extern rtems_initialization_tasks_table > Initialization_tasks[]; > * at system start up? > */ > #ifndef CONFIGURE_ZERO_WORKSPACE_AUTOMATICALLY > - #ifdef BSP_ZERO_WORKSPACE_AUTOMATICALLY > -#define CONFIGURE_ZERO_WORKSPACE_AUTOMATICALLY \ > -BSP_ZERO_WORKSPACE_AUTOMATICALLY > - #else > -#define CONFIGURE_ZERO_WORKSPACE_AUTOMATICALLY FALSE > - #endif > + #define CONFIGURE_ZERO_WORKSPACE_AUTOMATICALLY FALSE > #endif > /**@}*/ /* end of add to group Configuration */ > > -- > 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] config: Remove BSP_ZERO_WORKSPACE_AUTOMATICALLY
On 04/02/2020 14:45, Joel Sherrill wrote: Why is this being removed? Please have a look at the ticket: https://devel.rtems.org/ticket/3863 "BSPs had the option to enable the CONFIGURE_ZERO_WORKSPACE_AUTOMATICALLY via the BSP_ZERO_WORKSPACE_AUTOMATICALLY BSP option. There is no BSP which defines this option. In addition, it makes no sense that a BSP can influence this high level system configuration." ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH] config: Add CONFIGURE_DIRTY_MEMORY
Replace the BSP_DIRTY_MEMORY BSP option with a CONFIGURE_DIRTY_MEMORY
configuration option.
Update #3843.
---
bsps/shared/start/bootcard.c| 13
c/src/aclocal/bsp-bootcard-options.m4 | 12 ++-
cpukit/Makefile.am | 1 +
cpukit/include/rtems/confdefs.h | 8 +++
cpukit/include/rtems/score/memory.h | 5 +
cpukit/score/src/memorydirtyfreeareas.c | 37 +
testsuites/sptests/sp54/init.c | 2 ++
7 files changed, 55 insertions(+), 23 deletions(-)
create mode 100644 cpukit/score/src/memorydirtyfreeareas.c
diff --git a/bsps/shared/start/bootcard.c b/bsps/shared/start/bootcard.c
index 2eef1ea710..8f053012ec 100644
--- a/bsps/shared/start/bootcard.c
+++ b/bsps/shared/start/bootcard.c
@@ -24,19 +24,6 @@
*/
const char *bsp_boot_cmdline;
-#if BSP_DIRTY_MEMORY == 1
-static void bsp_dirty_memory(void)
-{
- _Memory_Fill( _Memory_Get(), 0xcf );
-}
-
-RTEMS_SYSINIT_ITEM(
- bsp_dirty_memory,
- RTEMS_SYSINIT_DIRTY_MEMORY,
- RTEMS_SYSINIT_ORDER_MIDDLE
-);
-#endif
-
RTEMS_SYSINIT_ITEM(
bsp_start,
RTEMS_SYSINIT_BSP_START,
diff --git a/c/src/aclocal/bsp-bootcard-options.m4
b/c/src/aclocal/bsp-bootcard-options.m4
index 2454ec5094..b0d25f383c 100644
--- a/c/src/aclocal/bsp-bootcard-options.m4
+++ b/c/src/aclocal/bsp-bootcard-options.m4
@@ -1,17 +1,9 @@
dnl
dnl BSP_BOOTCARD_OPTIONS - some autoconf voodoo to provide each BSPs'
dnl configure script with the standard options supported by boot_card()
-dnl and other required parts of the BSP Framework. Currently, this is
-dnl
-dnl - Can optionally dirty memory at boot time.
+dnl and other required parts of the BSP Framework.
dnl
dnl To be used in bsp-configure scripts
-AC_DEFUN([RTEMS_BSP_BOOTCARD_OPTIONS],[
-RTEMS_BSPOPTS_SET([BSP_DIRTY_MEMORY],[*],[0])
-RTEMS_BSPOPTS_HELP([BSP_DIRTY_MEMORY],
-[If defined, then the BSP Framework will put a non-zero pattern into
- the RTEMS Workspace and C program heap. This should assist in finding
- code that assumes memory starts set to zero.])
-])
+AC_DEFUN([RTEMS_BSP_BOOTCARD_OPTIONS],[])
diff --git a/cpukit/Makefile.am b/cpukit/Makefile.am
index b9ab123b49..9182919558 100644
--- a/cpukit/Makefile.am
+++ b/cpukit/Makefile.am
@@ -853,6 +853,7 @@ librtemscpu_a_SOURCES += score/src/heapiterate.c
librtemscpu_a_SOURCES += score/src/heapgreedy.c
librtemscpu_a_SOURCES += score/src/heapnoextend.c
librtemscpu_a_SOURCES += score/src/memoryallocate.c
+librtemscpu_a_SOURCES += score/src/memorydirtyfreeareas.c
librtemscpu_a_SOURCES += score/src/memoryfill.c
librtemscpu_a_SOURCES += score/src/memoryzerobeforeuse.c
librtemscpu_a_SOURCES += score/src/memoryzerofreeareas.c
diff --git a/cpukit/include/rtems/confdefs.h b/cpukit/include/rtems/confdefs.h
index 982e3ddb56..659fee936f 100644
--- a/cpukit/include/rtems/confdefs.h
+++ b/cpukit/include/rtems/confdefs.h
@@ -2802,6 +2802,14 @@ struct _reent *__getreent(void)
#endif
};
+ #ifdef CONFIGURE_DIRTY_MEMORY
+RTEMS_SYSINIT_ITEM(
+ _Memory_Dirty_free_areas,
+ RTEMS_SYSINIT_DIRTY_MEMORY,
+ RTEMS_SYSINIT_ORDER_MIDDLE
+);
+ #endif
+
#ifdef CONFIGURE_ZERO_WORKSPACE_AUTOMATICALLY
const bool _Memory_Zero_before_use = true;
diff --git a/cpukit/include/rtems/score/memory.h
b/cpukit/include/rtems/score/memory.h
index ffc4897ed5..440a59c793 100644
--- a/cpukit/include/rtems/score/memory.h
+++ b/cpukit/include/rtems/score/memory.h
@@ -344,6 +344,11 @@ extern const bool _Memory_Zero_before_use;
*/
void _Memory_Zero_free_areas( void );
+/**
+ * @brief Dirty all free memory areas of the system.
+ */
+void _Memory_Dirty_free_areas( void );
+
/** @} */
#ifdef __cplusplus
diff --git a/cpukit/score/src/memorydirtyfreeareas.c
b/cpukit/score/src/memorydirtyfreeareas.c
new file mode 100644
index 00..537dff2697
--- /dev/null
+++ b/cpukit/score/src/memorydirtyfreeareas.c
@@ -0,0 +1,37 @@
+/*
+ * SPDX-License-Identifier: BSD-2-Clause
+ *
+ * Copyright (C) 2020 embedded brains GmbH
+ *
+ * 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 OWNER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED
Re: Build FreeBSD: FAILED 6/rtems-arm on x86_64-freebsd12.1 (arm-rtems6-gcc-5bc9d2f5ed4-newlib-ac1ccc29e-x86_64-freebsd12.1-1)
On 04/02/2020 13:19, sebastian.hu...@embedded-brains.de wrote: RTEMS Source Builder - Set Builder, 5 (f81b0a519f36) Host: FreeBSD-12.1-RELEASE-amd64-64bit-ELF FreeBSD Build_FreeBSD12 12.1-RELEASE FreeBSD 12.1-RELEASE r354233 GENERIC amd64 amd64 Build Time: 0:05:29.244192 For reference, this build error is due to: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93543 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 3/3] i386: Port to RTEMS
On 31/01/2020 18:26, Jan Sommer wrote:
diff --git a/freebsd/sys/sys/mbuf.h b/freebsd/sys/sys/mbuf.h
index ba2e1873..95058e36 100644
--- a/freebsd/sys/sys/mbuf.h
+++ b/freebsd/sys/sys/mbuf.h
@@ -348,6 +348,7 @@ struct mbuf_ext_pgs {
vm_paddr_t pa[MBUF_PEXT_MAX_PGS]; /* phys addrs of pages */
charhdr[MBUF_PEXT_HDR_LEN]; /* TLS header */
struct ktls_session *tls; /* TLS session */
+#ifndef __rtems__
#if defined(__i386__) || \
(defined(__powerpc__) && !defined(__powerpc64__) && defined(BOOKE))
/*
@@ -356,6 +357,7 @@ struct mbuf_ext_pgs {
*/
uint32_tpad;
#endif
+#endif /* __rtems__ */
This change also affects other targets. Why is it necessary?
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH] Tester: Added pc386 bsp support
Added pc386 BSP support to rtems-tester.
---
tester/rtems/testing/bsps/pc386.ini | 37 +
1 file changed, 37 insertions(+)
create mode 100644 tester/rtems/testing/bsps/pc386.ini
diff --git a/tester/rtems/testing/bsps/pc386.ini
b/tester/rtems/testing/bsps/pc386.ini
new file mode 100644
index 000..c137342
--- /dev/null
+++ b/tester/rtems/testing/bsps/pc386.ini
@@ -0,0 +1,37 @@
+#
+# RTEMS Tools Project (http://www.rtems.org/)
+# Copyright 2010-2017 Chris Johns (chr...@rtems.org)
+# All rights reserved.
+#
+# This file is part of the RTEMS Tools package in 'rtems-tools'.
+#
+# 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.
+#
+
+[pc386]
+bsp = pc386
+arch = i386
+jobs = 1
+tester= %{_rtscripts}/tftp.cfg
+test_restarts = 3
+requires = bsp_tty_dev, target_on_command, target_off_command,
target_reset_command
--
1.8.3.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
sysinit test failure to link psim
Hi Posting this rather than just fixing since it seems that this test is one we would like to keep building. = $ make -k >/dev/null /home/joel/rtems-work/tools/5/lib/gcc/powerpc-rtems5/7.5.0/../../../../powerpc-rtems5/bin/ld: ./../../cpukit/librtemscpu.a(sysinitverbose.o): the target (_Linker_set__Sysinit__Sysinit_Verbose) of a R_PPC_SDAREL16 relocation is in the wrong output section (.rtemsroset) ./../../cpukit/librtemscpu.a(sysinitverbose.o): in function `_Sysinit_Verbose_is_adjacent': /home/joel/rtems-work/b-psim/powerpc-rtems5/c/psim/cpukit/../../../../../rtems/c/src/../../cpukit/sapi/src/sysinitverbose.c:108:(.text._Sysinit_Verbose_BSP_EARLY+0x2): relocation truncated to fit: R_PPC_SDAREL16 against symbol `_Linker_set__Sysinit__Sysinit_Verbose' defined in .rtemsroset._Sysinit.content.0.0x000100ff section in spsysinit01/spsysinit01-init.o collect2: error: ld returned 1 exit status = --joel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: sysinit test failure to link psim
Found by Buildbot here! https://buildbot.rtems.org/#/builders/19/builds/47 FYI if anyone does want to make a quick check to see if the error is reproducible Buildbot creates a snapshot with bootstrap already run on every build for example for this build: https://buildbot.rtems.org/#/builders/4/builds/814 It's always the 'snapshot-test' and if all the current builds work we get a 'snapshot-stable' which is stable for all builds that have been done. Amar. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Buildbot emails.
If anyone wants an email when Buildbot fails for a commit you have made please let me know. You will get an email when the status changes from Working -> Broken or Broken -> Working. Buildbot should be stable enough now that it doesn't have many of its own errors and we recently caught breakage from a commit made. Currently only Joel, Chris and myself are on this list. If you wish to be added please send me your full email that you use to commit with in the format of: Amar Takhar Otherwise realtime status is available at https://buildbot.rtems.org/ Amar. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: sysinit test failure to link psim
Hello Joel, the lovely small-data area. I will try to fix this. I probably needs an API change in . ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Linker sets alignment change
Hey Sebastian,
On 2/1/2020 9:23 AM, Sebastian Huber wrote:
> Hello Jeff,
>
> - Am 14. Jan 2020 um 17:37 schrieb Jeff Kubascik
> jeff.kubas...@dornerworks.com:
>
>> Hello,
>>
>> I have noticed a change in the linker section ".rtemsrwset" alignment which
>> has
>> affected the zImage header that was added with the arm/xen BSP. The zImage
>> header uses the bsp_section_data_end symbol to determine the end of the
>> image. I
>> was able to track this change to the commit 234d155e linkersets: Revert to
>> zero-length arrays.
>>
>> Here is the readelf output of the ticker.exe application just prior before
>> commit
>>
>> Section Headers:
>> [Nr] Name TypeAddr OffSize ES Flg Lk Inf
>> Al
>> [15] .rtemsstack NOBITS 4010 01358c 001000 00 WA 0 0
>> 64
>> [16] .data PROGBITS40101000 101000 0004e0 00 WA 0 0
>> 8
>> [17] .rtemsrwset PROGBITS401014e0 1014e0 00 00 0 0
>> 1
>>
>> Here is the output with the commit
>>
>> Section Headers:
>> [Nr] Name TypeAddr OffSize ES Flg Lk Inf
>> Al
>> [15] .rtemsstack NOBITS 4010 01358c 001000 00 WA 0 0
>> 64
>> [16] .data PROGBITS40101000 101000 0004e0 00 WA 0 0
>> 8
>> [17] .rtemsrwset PROGBITS40101500 101500 00 00 WA 0 0
>> 64
>>
>> This shows that the alignment of the ".rtemsrwset" section changed from 1
>> byte
>> to 64 bytes. This changes the start address of the section to be aligned,
>> even
>> though the section is empty.
>>
>> The bsp_section_data_end symbol is located at the end of the ".rtemsrwset"
>> section. If the section is empty, the bsp_section_data_end symbol will
>> contain
>> the start address of the section.
>>
>> .data : ALIGN_WITH_INPUT {
>> bsp_section_data_begin = .;
>> *(.data .data.* .gnu.linkonce.d.*)
>> SORT(CONSTRUCTORS)
>> } > REGION_DATA AT > REGION_DATA_LOAD
>> .data1 : ALIGN_WITH_INPUT {
>> *(.data1)
>> } > REGION_DATA AT > REGION_DATA_LOAD
>> .rtemsrwset : ALIGN_WITH_INPUT {
>> KEEP (*(SORT(.rtemsrwset.*)))
>> bsp_section_data_end = .;
>> } > REGION_DATA AT > REGION_DATA_LOAD
>>
>> When I convert the ticker.exe elf to a binary with objcopy, the binary
>> doesn't
>> include the ".rtemsrwset" section, since it's empty. As a result, the length
>> of
>> the binary doesn't match the bsp_section_data_end symbol. This is a problem
>> for
>> some zImage loaders that verify the image length.
>>
>> I'm not certain what would be the best way to fix the zImage header. Is
>> there a
>> different symbol that I should be using to get the end of the image? Maybe
>> this
>> is a bug with the linker script?
>
> there is no bug in the linker script. In wkspace.c there is this linker set
> declared:
>
> RTEMS_LINKER_RWSET(
> _Per_CPU_Data,
> RTEMS_ALIGNED( CPU_CACHE_LINE_BYTES ) char
> );
>
> So, the .rtemsrwset contains an empty _Per_CPU_Data set which is properly
> aligned.
>
> In uniprocessor configuration, the cache alignment is superfluous. I will fix
> this.
If I understand correctly, the plan is to negate/undo the cache alignment change
that was introduced in commit 234d155e for uni-processor configuration? If that
is correct, it should fix the issue.
> Why don't you use the file size of your binary created by objcopy to set the
> image size?
>
This would require that I modify the binary/elf contents manually after linking,
as the size field is stored in the zImage header near the start of the
application.
For development, I was padding the binary blob up to cache alignment match the
expected size in the zImage header. While this worked, it was clunky and
tedious.
Sincerely,
Jeff Kubascik
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: Linker sets alignment change
- Am 4. Feb 2020 um 21:02 schrieb Jeff Kubascik
jeff.kubas...@dornerworks.com:
> Hey Sebastian,
>
> On 2/1/2020 9:23 AM, Sebastian Huber wrote:
>> Hello Jeff,
>>
>> - Am 14. Jan 2020 um 17:37 schrieb Jeff Kubascik
>> jeff.kubas...@dornerworks.com:
>>
>>> Hello,
>>>
>>> I have noticed a change in the linker section ".rtemsrwset" alignment which
>>> has
>>> affected the zImage header that was added with the arm/xen BSP. The zImage
>>> header uses the bsp_section_data_end symbol to determine the end of the
>>> image. I
>>> was able to track this change to the commit 234d155e linkersets: Revert to
>>> zero-length arrays.
>>>
>>> Here is the readelf output of the ticker.exe application just prior before
>>> commit
>>>
>>> Section Headers:
>>> [Nr] Name TypeAddr OffSize ES Flg Lk
>>> Inf Al
>>> [15] .rtemsstack NOBITS 4010 01358c 001000 00 WA 0
>>> 0 64
>>> [16] .data PROGBITS40101000 101000 0004e0 00 WA 0
>>> 0 8
>>> [17] .rtemsrwset PROGBITS401014e0 1014e0 00 00 0
>>> 0 1
>>>
>>> Here is the output with the commit
>>>
>>> Section Headers:
>>> [Nr] Name TypeAddr OffSize ES Flg Lk
>>> Inf Al
>>> [15] .rtemsstack NOBITS 4010 01358c 001000 00 WA 0
>>> 0 64
>>> [16] .data PROGBITS40101000 101000 0004e0 00 WA 0
>>> 0 8
>>> [17] .rtemsrwset PROGBITS40101500 101500 00 00 WA 0
>>> 0 64
>>>
>>> This shows that the alignment of the ".rtemsrwset" section changed from 1
>>> byte
>>> to 64 bytes. This changes the start address of the section to be aligned,
>>> even
>>> though the section is empty.
>>>
>>> The bsp_section_data_end symbol is located at the end of the ".rtemsrwset"
>>> section. If the section is empty, the bsp_section_data_end symbol will
>>> contain
>>> the start address of the section.
>>>
>>> .data : ALIGN_WITH_INPUT {
>>> bsp_section_data_begin = .;
>>> *(.data .data.* .gnu.linkonce.d.*)
>>> SORT(CONSTRUCTORS)
>>> } > REGION_DATA AT > REGION_DATA_LOAD
>>> .data1 : ALIGN_WITH_INPUT {
>>> *(.data1)
>>> } > REGION_DATA AT > REGION_DATA_LOAD
>>> .rtemsrwset : ALIGN_WITH_INPUT {
>>> KEEP (*(SORT(.rtemsrwset.*)))
>>> bsp_section_data_end = .;
>>> } > REGION_DATA AT > REGION_DATA_LOAD
>>>
>>> When I convert the ticker.exe elf to a binary with objcopy, the binary
>>> doesn't
>>> include the ".rtemsrwset" section, since it's empty. As a result, the
>>> length of
>>> the binary doesn't match the bsp_section_data_end symbol. This is a problem
>>> for
>>> some zImage loaders that verify the image length.
>>>
>>> I'm not certain what would be the best way to fix the zImage header. Is
>>> there a
>>> different symbol that I should be using to get the end of the image? Maybe
>>> this
>>> is a bug with the linker script?
>>
>> there is no bug in the linker script. In wkspace.c there is this linker set
>> declared:
>>
>> RTEMS_LINKER_RWSET(
>> _Per_CPU_Data,
>> RTEMS_ALIGNED( CPU_CACHE_LINE_BYTES ) char
>> );
>>
>> So, the .rtemsrwset contains an empty _Per_CPU_Data set which is properly
>> aligned.
>>
>> In uniprocessor configuration, the cache alignment is superfluous. I will fix
>> this.
>
> If I understand correctly, the plan is to negate/undo the cache alignment
> change
> that was introduced in commit 234d155e for uni-processor configuration? If
> that
> is correct, it should fix the issue.
I already fixed this:
https://git.rtems.org/rtems/commit/?id=9e4f21b927e8a81df8044806e88128388911e123
It fixes your problem only in certain cases.
>
>> Why don't you use the file size of your binary created by objcopy to set the
>> image size?
>>
>
> This would require that I modify the binary/elf contents manually after
> linking,
> as the size field is stored in the zImage header near the start of the
> application.
In the ELF file, there is no problem. Why can't you use the file size of the
objcopy output and write this in your zImage header?
>
> For development, I was padding the binary blob up to cache alignment match the
> expected size in the zImage header. While this worked, it was clunky and
> tedious.
Yes.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: Buildbot emails.
On 5/2/20 6:05 am, Amar Takhar wrote: > Buildbot should be stable enough now that it doesn't have many of its own > errors > and we recently caught breakage from a commit made. Many thanks for the buildbot effort and all you do. It is an important part of RTEMS's development. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Buildbot emails.
On 5/2/20 6:05 am, Amar Takhar wrote: > If anyone wants an email when Buildbot fails for a commit you have made > please > let me know. > > You will get an email when the status changes from Working -> Broken or > Broken > -> Working. Should fails be posted to devel? Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GCC Git Conversion Done
On 5/2/20 12:13 am, Sebastian Huber wrote: > Hello, > > it seems GCC finished the Git conversion: > > https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;a=summary > > This means our GCC Git mirror refers to a deprecated Git repository. Is this the mirror on github? Does this mean any RSB reference in it's history breaks with the new repo? Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] Tester: Added pc386 bsp support
On 5/2/20 3:34 am, Lou Woods wrote: > Added pc386 BSP support to rtems-tester. How does this differ from pc.ini? Why is a copy needed? https://git.rtems.org/rtems-tools/tree/tester/rtems/testing/bsps/pc.ini Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Buildbot emails.
On 2020-02-05 10:15 +1100, Chris Johns wrote: > > Many thanks for the buildbot effort and all you do. It is an important part of > RTEMS's development. Thank you. Amar. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Buildbot emails.
On 2020-02-05 10:16 +1100, Chris Johns wrote: > > Should fails be posted to devel? I don't think that's a good idea since it's possible that a commit could break every BSP and then we'll get 1 email per BSP as they each fail. I think it's okay if the developer breaking the build gets those emails. One option is to simply turn the email filtering off and everyone gets an email if their name is in the 'responsible users' list for that commit. Usually the author(s) and committer. Amar. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Rework of Initialization Chapter in BSP Howto
On 4/2/20 8:20 pm, Sebastian Huber wrote: > Hello, > > I reworked the heavily out dated system initialization chapter in the RTEMS > BSP and Driver Guide: > > https://docs.rtems.org/branches/master/bsp-howto/initilization_code.html > > I would be happy if some want to review it. Looks good. I couple of comments ... 1. There is no discuss about boot loaders and the various role they play ... Do all BSPs need a boot loader? Can some BSP run directly from reset? What set up is needed by a bootloader? Should there be some context here to guide a user in the area of boot loaders? 2. Minor edit? and change into normal system mode with multi-threading enabled. to and change into the normal system mode with multi-threading enabled. 3. 5.4 Should we highlight the handling of init errors are a system issue. I think it is important explain RTEMS does not manage system level issues for you and handling init errors is part of the system design. How does a user override a BSP default? Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Buildbot emails.
On 5/2/20 11:41 am, Amar Takhar wrote: > On 2020-02-05 10:16 +1100, Chris Johns wrote: >> >> Should fails be posted to devel? > > I don't think that's a good idea since it's possible that a commit could > break > every BSP and then we'll get 1 email per BSP as they each fail. > > I think it's okay if the developer breaking the build gets those emails. Ah OK. I also see the build list gets the emails which is nice. > One option is to simply turn the email filtering off and everyone gets an > email > if their name is in the 'responsible users' list for that commit. Usually > the > author(s) and committer. I am OK with that. What do others think? Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Buildbot emails.
On 2020-02-05 13:12 +1100, Chris Johns wrote: > I am OK with that. What do others think? For example in the last breakage you can see who was responsible by going here and clicking 'Responsible Users': https://buildbot.rtems.org/#/builders/19/builds/47 These two would have received direct emails about it. Amar. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GCC Git Conversion Done
On 05/02/2020 00:18, Chris Johns wrote: On 5/2/20 12:13 am, Sebastian Huber wrote: Hello, it seems GCC finished the Git conversion: https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;a=summary This means our GCC Git mirror refers to a deprecated Git repository. Is this the mirror on github? GCC use Subversion up to recently. There was an official SVN to Git mirror from GCC and we mirrored this SVN to Git mirror on github. This repository is still there, but it is now deprecated: https://gcc.gnu.org/wiki/GitMirror After long discussions and a complicated conversion from SVN to GIT, GCC uses now Git for further development. They use an entirely new Git repository for this: thttps://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;a=summary Does this mean any RSB reference in it's history breaks with the new repo? Yes, in the new GCC repository is a completely new history. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GCC Git Conversion Done
On 5/2/20 5:12 pm, Sebastian Huber wrote: > On 05/02/2020 00:18, Chris Johns wrote: >> >> Does this mean any RSB reference in it's history breaks with the new repo? > > Yes, in the new GCC repository is a completely new history. > Does this mean we can directly reference the new repo and the mirror we have be labelled old and not updated and for RSB history only? Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GCC Git Conversion Done
On 05/02/2020 07:20, Chris Johns wrote: On 5/2/20 5:12 pm, Sebastian Huber wrote: On 05/02/2020 00:18, Chris Johns wrote: Does this mean any RSB reference in it's history breaks with the new repo? Yes, in the new GCC repository is a completely new history. Does this mean we can directly reference the new repo and the mirror we have be labelled old and not updated and for RSB history only? Yes, we probably have to set up also a new mirror for the new GCC Git repository. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GCC Git Conversion Done
On 5/2/20 5:17 pm, Sebastian Huber wrote: > On 05/02/2020 07:20, Chris Johns wrote: > >> On 5/2/20 5:12 pm, Sebastian Huber wrote: >>> On 05/02/2020 00:18, Chris Johns wrote: Does this mean any RSB reference in it's history breaks with the new repo? >>> Yes, in the new GCC repository is a completely new history. >>> >> Does this mean we can directly reference the new repo and the mirror we have >> be >> labelled old and not updated and for RSB history only? > > Yes, we probably have to set up also a new mirror for the new GCC Git > repository. > I have changed the label for the repo on github. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Rework of Initialization Chapter in BSP Howto
On 05/02/2020 03:09, Chris Johns wrote: On 4/2/20 8:20 pm, Sebastian Huber wrote: Hello, I reworked the heavily out dated system initialization chapter in the RTEMS BSP and Driver Guide: https://docs.rtems.org/branches/master/bsp-howto/initilization_code.html I would be happy if some want to review it. Looks good. I couple of comments ... 1. There is no discuss about boot loaders and the various role they play ... Do all BSPs need a boot loader? Can some BSP run directly from reset? What set up is needed by a bootloader? Should there be some context here to guide a user in the area of boot loaders? I am not sure, this guide is for BSP writers. They should know if there is a boot loader or not and what it does. I just mentioned a boot loader in one sentence: "The low-level system initialization may depend on a platform initialization carried out by a boot loader." How a particular BSP boots should be documented in the user manual. 2. Minor edit? and change into normal system mode with multi-threading enabled. to and change into the normal system mode with multi-threading enabled. I changed it. 3. 5.4 Should we highlight the handling of init errors are a system issue. I think it is important explain RTEMS does not manage system level issues for you and handling init errors is part of the system design. How does a user override a BSP default? I think these questions should be answered by the Classic API Guide. A BSP writer just needs to know that initialization errors are fatal and the BSP should provide a fatal extension and a reset function. The Classic API Guide could be improved to give an answer to "How does a user override a BSP default?": https://docs.rtems.org/branches/master/c-user/fatal_error.html#announcing-a-fatal-error ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Fwd: Buildbot failure in RTEMS on CHECK sparc/erc32 FreeBSD 10.1-STABLE GCC 7.3.0 POSIX
Hello, this looks like Buildbot is using out of date tools. How are tool updates (via RSB) triggered for the Buildbot machines? Forwarded Message Subject: Buildbot failure in RTEMS on CHECK sparc/erc32 FreeBSD 10.1-STABLE GCC 7.3.0 POSIX Date: Tue, 04 Feb 2020 06:08:54 + From: build...@rtems.org To: bu...@rtems.org The Buildbot has detected a failed build on builder CHECK sparc/erc32 FreeBSD 10.1-STABLE GCC 7.3.0 POSIX while building rtems. Full details are available at: https://buildbot.rtems.org/#builders/20/builds/54 Buildbot URL: https://buildbot.rtems.org/ Worker for this Build: build-1 Build Reason: Blamelist: Martin Erik Werner , Sebastian Huber BUILD FAILED: make (failure) Sincerely, -The Buildbot ___ build mailing list bu...@rtems.org http://lists.rtems.org/mailman/listinfo/build ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Buildbot emails.
Hello Amar, thanks for setting up the Buildbot. I will probably receive most of the Working -> Broken emails. If you are subscribed to the bu...@rtems.org mailing list, do you already get all the information? So an extra subscription to the Buildbot emails is not necessary? ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Rework of Initialization Chapter in BSP Howto
On 5/2/20 5:31 pm, Sebastian Huber wrote: > On 05/02/2020 03:09, Chris Johns wrote: > >> On 4/2/20 8:20 pm, Sebastian Huber wrote: >>> Hello, >>> >>> I reworked the heavily out dated system initialization chapter in the RTEMS >>> BSP and Driver Guide: >>> >>> https://docs.rtems.org/branches/master/bsp-howto/initilization_code.html >>> >>> I would be happy if some want to review it. >> Looks good. I couple of comments ... >> >> 1. There is no discuss about boot loaders and the various role they play ... >> >> Do all BSPs need a boot loader? >> Can some BSP run directly from reset? >> What set up is needed by a bootloader? >> >> Should there be some context here to guide a user in the area of boot >> loaders? > > I am not sure, this guide is for BSP writers. They should know if there is a > boot loader or not and what it does. I just mentioned a boot loader in one > sentence: > > "The low-level system initialization may depend on a platform initialization > carried out by a boot loader." > > How a particular BSP boots should be documented in the user manual. Yes and is once the BSP writer has it working. The RTEMS's start entry point cannot accept any state. The state of the MMU, cache, hypervisor mode need to be considered and accounted for. I am not asking the detail is listed and resolved just a note the BSP start up and the bootloader need to agree on a suitable state and hand over. > >> >> 2. Minor edit? >> >> and change into normal system mode with multi-threading enabled. >> >> to >> >> and change into the normal system mode with multi-threading enabled. > I changed it. >> >> 3. 5.4 Should we highlight the handling of init errors are a system issue. I >> think it is important explain RTEMS does not manage system level issues for >> you >> and handling init errors is part of the system design. How does a user >> override >> a BSP default? > > I think these questions should be answered by the Classic API Guide. A BSP > writer just needs to know that initialization errors are fatal and the BSP > should provide a fatal extension and a reset function. > > The Classic API Guide could be improved to give an answer to "How does a user > override a BSP default?": > > https://docs.rtems.org/branches/master/c-user/fatal_error.html#announcing-a-fatal-error > OK. Maybe I am looking this section the wrong way. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
#1977 mq_open lacks support of "mode" argument
Trying to solve ticket https://devel.rtems.org/ticket/1977 The mode parameter sets access permissions for the created message queue. Examples: S_IRUSR 00400 user has read permission S_IWUSR 00200 user has write permission S_IXUSR 00100 user has execute permission Complete list is at: http://man7.org/linux/man-pages/man2/open.2.html https://github.com/RTEMS/rtems/blob/master/cpukit/posix/src/mqueueopen.c#L176 Is this is the place where we need to take care of the mode argument ? I am thinking we would need to store the mode bits in POSIX_Message_queue_Control structure.(Ref: https://github.com/RTEMS/rtems/blob/master/cpukit/include/rtems/posix/mqueue.h#L57) Then every time the created queue is accessed we would use the mode bits to check if the accessor is allowed to access the queue. Please share your thoughts on solving this. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH] score: Fix linker sets on small data area targets
Update #3865.
---
cpukit/include/rtems/linkersets.h | 16 +---
cpukit/include/rtems/score/percpudata.h | 3 +--
2 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/cpukit/include/rtems/linkersets.h
b/cpukit/include/rtems/linkersets.h
index 614670338c..844130f0d4 100644
--- a/cpukit/include/rtems/linkersets.h
+++ b/cpukit/include/rtems/linkersets.h
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2015, 2016 embedded brains GmbH. All rights reserved.
+ * Copyright (c) 2015, 2020 embedded brains GmbH. All rights reserved.
*
* embedded brains GmbH
* Dornierstr. 4
@@ -37,8 +37,13 @@ extern "C" {
type const RTEMS_LINKER_SET_END( set )[ 0 ] \
RTEMS_SECTION( ".rtemsroset." #set ".end" ) RTEMS_USED
+#define RTEMS_LINKER_ROSET_ITEM_ORDERED_DECLARE( set, type, item, order ) \
+ type const _Linker_set_##set##_##item \
+ RTEMS_SECTION( ".rtemsroset." #set ".content.0." RTEMS_XSTRING( order ) )
+
#define RTEMS_LINKER_ROSET_ITEM_DECLARE( set, type, item ) \
- extern type const _Linker_set_##set##_##item
+ extern type const _Linker_set_##set##_##item \
+ RTEMS_SECTION( ".rtemsroset." #set ".content.1" )
#define RTEMS_LINKER_ROSET_ITEM_REFERENCE( set, type, item ) \
static type const * const _Set_reference_##set##_##item \
@@ -68,8 +73,13 @@ extern "C" {
type RTEMS_LINKER_SET_END( set )[ 0 ] \
RTEMS_SECTION( ".rtemsrwset." #set ".end" ) RTEMS_USED
+#define RTEMS_LINKER_RWSET_ITEM_ORDERED_DECLARE( set, type, item, order ) \
+ extern type _Linker_set_##set##_##item \
+ RTEMS_SECTION( ".rtemsrwset." #set ".content.0." RTEMS_XSTRING( order ) )
+
#define RTEMS_LINKER_RWSET_ITEM_DECLARE( set, type, item ) \
- extern type _Linker_set_##set##_##item
+ extern type _Linker_set_##set##_##item \
+ RTEMS_SECTION( ".rtemsrwset." #set ".content.1" )
/*
* The .rtemsroset is here not a typo. We must ensure that the references are
diff --git a/cpukit/include/rtems/score/percpudata.h
b/cpukit/include/rtems/score/percpudata.h
index 1961c323d4..ff6e517d0a 100644
--- a/cpukit/include/rtems/score/percpudata.h
+++ b/cpukit/include/rtems/score/percpudata.h
@@ -57,8 +57,7 @@ RTEMS_LINKER_RWSET_DECLARE( _Per_CPU_Data, char );
* @param item The designator of the item.
*/
#define PER_CPU_DATA_ITEM_DECLARE( type, item ) \
- RTEMS_LINKER_RWSET_ITEM_DECLARE( _Per_CPU_Data, type, item ) \
- RTEMS_SECTION( ".rtemsrwset._Per_CPU_Data.content.1" )
+ RTEMS_LINKER_RWSET_ITEM_DECLARE( _Per_CPU_Data, type, item )
/**
* @brief Defines a per-CPU item of the specified type.
--
2.16.4
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
