Re: [rtems-bsp-builder] 2018-07-03 11:41:43: Profile(s): everything
On 04/07/18 02:33, j...@rtems.org wrote: RTEMS Tools Project - RTEMS Kernel BSP Builder, 5 (b762312fae67) Please use the tools from the latest RSB. -- 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: [GSOC - Tracing] Status Update
On 03/07/18 14:50, Vidushi Vashishth wrote: Hi! > Ok, thanks, but why did you remove the RTEMS application? This is the first step. The repository should contain a sample application with a Makefile (or waf or whatever, but no manual steps) to generate a sample trace raw data. I was testing everything on the fileio sample test case which is already a part of the rtems repository. I have written the instructions to generate the trace in the readme file for this testcase. I could create a new application and add its makefile too if this seems too lengthy. Yes, please add an example application which generates some trace data and outputs this to the console. Please add also a simple Makefile to build it. > Could you please integrate the content of this blog post in the repository and automate the manual steps in it. Yes I am working on it. > You can communicate via sockets on some simulator BSPs, however, in the scope and state of the current project, I think this is not feasible. Alright I will stick to what you proposed. I however also have to work on transportation mechanisms to transfer trace buffers from the target/capture engine to the host. I can begin working on the socket approach after I am done with CTF? We should get first the prototype ready. The prototype should look like this from my point of view: sample application -> trace output > convert -> display in Trace Compass. Once we have this prototype we can decide what can be made better within the scope of the project. You don't have to output plain text data to the console, you may also output XML, some binary format, an uuencoded binary or whatever. If the current output makes it difficult for you, then you can change its format. This should be discussed on the mailing list. This may end up in some RTEMS patches. > Before you implement anything, could you please first outline what you want to do. The general flow of this approach will be as follows: 1. Generation of RTEMS trace. 2. Transportation of the generated trace to the host machine. 3. Conversion of transported traces to CTF using babeltrace scripts. 4. Viewing the converted output (CTF). I had documented this in the readme of the Tracing repository also. Does this seem okay? The steps are all right. Please add also some content to the steps, e.g. * alternatives * pros and cons * what works and what doesn't * lessons learnt * tools used in the step * limitations * etc. -- 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
Epiphany ICE when building mongoose
Hi I think all the build failures from the BSP builder on epiphany are due to a GCC ICE building mongoose. Any thoughts? --joel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH v3] coverage : Add support to run coverage in supported bsp without extra options
Close #3440
---
tester/rt/test.py| 21 ++---
tester/rtems/testing/bsps/leon3-qemu-cov.ini | 1 +
2 files changed, 15 insertions(+), 7 deletions(-)
diff --git a/tester/rt/test.py b/tester/rt/test.py
index 9214ad6..5d25d82 100644
--- a/tester/rt/test.py
+++ b/tester/rt/test.py
@@ -232,7 +232,7 @@ def run(command_path = None):
'--filter': 'Glob that executables must match to
run (default: ' +
default_exefilter + ')',
'--stacktrace': 'Dump a stack trace on a user
termination (^C)',
-'--coverage': 'Perform coverage analysis of test
executables.'}
+'--coverage-sets': 'Perform coverage analysis for
specific sets.'}
mailer.append_options(optargs)
opts = options.load(sys.argv,
optargs = optargs,
@@ -283,14 +283,21 @@ def run(command_path = None):
raise error.general('RTEMS BSP not provided or an invalid option')
bsp = config.load(bsp[1], opts)
bsp_config = opts.defaults.expand(opts.defaults['tester'])
-coverage_enabled = opts.find_arg('--coverage')
+coverage_sets = opts.find_arg('--coverage-sets')
+try:
+coverage_enabled = opts.defaults.get('coverage')
+except:
+coverage_enabled = False
if coverage_enabled:
cov_trace = 'cov' in debug_trace.split(',')
-if len(coverage_enabled) == 2:
-coverage_runner = coverage.coverage_run(opts.defaults,
-executables,
-symbol_set =
coverage_enabled[1],
-trace = cov_trace)
+if coverage_sets:
+if len(coverage_sets) != 2:
+raise error.general('No sets provided in --coverage-sets')
+else:
+coverage_runner = coverage.coverage_run(opts.defaults,
+executables,
+symbol_set =
coverage_sets[1],
+trace = cov_trace)
else:
coverage_runner = coverage.coverage_run(opts.defaults,
executables,
diff --git a/tester/rtems/testing/bsps/leon3-qemu-cov.ini
b/tester/rtems/testing/bsps/leon3-qemu-cov.ini
index 2f89117..6462448 100644
--- a/tester/rtems/testing/bsps/leon3-qemu-cov.ini
+++ b/tester/rtems/testing/bsps/leon3-qemu-cov.ini
@@ -38,3 +38,4 @@ target= sparc-rtems5
tester= %{_rtscripts}/qemu.cfg
bsp_qemu_opts = %{qemu_opts_base} -M leon3_generic
bsp_qemu_cov_opts = -exec-trace %{test_executable}.cov
+coverage = True
--
2.14.4
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Documentation in A4/US letter
Hi As Dannie is wrapping up the Release Notes, I wanted to start a discussion to make sure that all our docs were printable nicely on A4 and US letter. Gedare thinks it is just a matter of margins. Anyone have thoughts on how to produce one set of PDFs that look good on both sizes of paper? Also I experimented with using Amazon print on demand with the old format documentation. It worked well but I wanted a nicer cover. I would like to do this with the new documentation so let's keep that in mind. --joel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
BSP Builder Failures
Hi Looks like some BSP variants disappeared and weren't accounted for in rtems-bsp-tiers.ini. + realview_pbx_a9_qemu_smp + altcycv_devkit_smp Then a lot of epiphany failures which must be something else. Should those be dropped from the tiers file? --joel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC IRC Meeting reschedule: 7/4 to 7/3
Hi! I am sorry for the late update. I might not be able to make it due to a prescheduled doctor's appointment. I will try to get in on the go. I will update the progress on the wiki page as well. I will send a separate progress mail on the mailing list if need be. Thanks On Mon, Jul 2, 2018 at 10:51 PM, Gedare Bloom wrote: > Hello All, > > We will hold the weekly IRC meeting on Tuesday 7/3 (tomorrow!) instead > of 7/4 at the same usual time (10am Eastern Daylight Time) due to the > US holiday on 7/4. Joel will likely lead the meeting. > > Gedare > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH] posix: Check for new prototypes
Update #3342.
Update #3343.
---
cpukit/configure.ac | 23 +++
cpukit/include/rtems/posix/pthreadimpl.h | 2 +-
cpukit/posix/src/mutexgetprioceiling.c | 10 +++---
cpukit/posix/src/psxtransschedparam.c| 2 +-
cpukit/posix/src/pthreadsetschedparam.c | 12
5 files changed, 40 insertions(+), 9 deletions(-)
diff --git a/cpukit/configure.ac b/cpukit/configure.ac
index 235241643e..0361128e1d 100644
--- a/cpukit/configure.ac
+++ b/cpukit/configure.ac
@@ -115,6 +115,29 @@ RTEMS_CHECK_FUNC([pthread_getattr_np],[
#define _GNU_SOURCE
#include ])
+AC_LANG_PUSH(C)
+AC_MSG_CHECKING([for pthread_mutex_getprioceiling(const pthread_mutex_t *,
...)])
+AC_COMPILE_IFELSE([AC_LANG_SOURCE([
+#include
+int pthread_mutex_getprioceiling(const pthread_mutex_t *__restrict, int *);
+])],[
+AC_MSG_RESULT([yes])
+AC_DEFINE(HAVE_PTHREAD_MUTEX_GETCEILING_CONST, [],
[pthread_mutex_getprioceiling(const pthread_mutex_t *, ...)])
+],[
+AC_MSG_RESULT([no])
+])
+AC_MSG_CHECKING([for pthread_setschedparam(..., const struct sched_param *)])
+AC_COMPILE_IFELSE([AC_LANG_SOURCE([
+#include
+int pthread_setschedparam(pthread_t, int, const struct sched_param *);
+])],[
+AC_MSG_RESULT([yes])
+AC_DEFINE(HAVE_PTHREAD_SETSCHEDPARAM_CONST, [], [pthread_setschedparam(...,
const struct sched_param *)])
+],[
+AC_MSG_RESULT([no])
+])
+AC_LANG_POP(C)
+
# Mandated by POSIX, not declared in some versions of newlib.
AC_CHECK_DECLS([getrusage],,,[#include sys/resource.h])
diff --git a/cpukit/include/rtems/posix/pthreadimpl.h
b/cpukit/include/rtems/posix/pthreadimpl.h
index 3e2351e57e..e6ed1b8990 100644
--- a/cpukit/include/rtems/posix/pthreadimpl.h
+++ b/cpukit/include/rtems/posix/pthreadimpl.h
@@ -97,7 +97,7 @@ int _POSIX_Thread_Translate_to_sched_policy(
*/
int _POSIX_Thread_Translate_sched_param(
int policy,
- struct sched_param *param,
+ const struct sched_param*param,
Thread_CPU_budget_algorithms*budget_algorithm,
Thread_CPU_budget_algorithm_callout *budget_callout
);
diff --git a/cpukit/posix/src/mutexgetprioceiling.c
b/cpukit/posix/src/mutexgetprioceiling.c
index 544c8fbf33..3ac90d888e 100644
--- a/cpukit/posix/src/mutexgetprioceiling.c
+++ b/cpukit/posix/src/mutexgetprioceiling.c
@@ -26,8 +26,12 @@
*/
int pthread_mutex_getprioceiling(
- pthread_mutex_t *mutex,
- int *prioceiling
+#ifdef HAVE_PTHREAD_MUTEX_GETCEILING_CONST
+ const pthread_mutex_t *mutex,
+#else
+ pthread_mutex_t *mutex,
+#endif
+ int *prioceiling
)
{
POSIX_Mutex_Control *the_mutex;
@@ -38,7 +42,7 @@ int pthread_mutex_getprioceiling(
return EINVAL;
}
- the_mutex = _POSIX_Mutex_Get( mutex );
+ the_mutex = _POSIX_Mutex_Get( RTEMS_DECONST( pthread_mutex_t *, mutex ) );
POSIX_MUTEX_VALIDATE_OBJECT( the_mutex, flags );
_POSIX_Mutex_Acquire( the_mutex, _context );
diff --git a/cpukit/posix/src/psxtransschedparam.c
b/cpukit/posix/src/psxtransschedparam.c
index 86d8ff0894..0b4ce2823e 100644
--- a/cpukit/posix/src/psxtransschedparam.c
+++ b/cpukit/posix/src/psxtransschedparam.c
@@ -42,7 +42,7 @@ int _POSIX_Thread_Translate_to_sched_policy(
int _POSIX_Thread_Translate_sched_param(
int policy,
- struct sched_param *param,
+ const struct sched_param*param,
Thread_CPU_budget_algorithms*budget_algorithm,
Thread_CPU_budget_algorithm_callout *budget_callout
)
diff --git a/cpukit/posix/src/pthreadsetschedparam.c
b/cpukit/posix/src/pthreadsetschedparam.c
index b6854a080c..7c5b6f109d 100644
--- a/cpukit/posix/src/pthreadsetschedparam.c
+++ b/cpukit/posix/src/pthreadsetschedparam.c
@@ -33,7 +33,7 @@
static int _POSIX_Set_sched_param(
Thread_Control *the_thread,
int policy,
- struct sched_param *param,
+ const struct sched_param *param,
Thread_CPU_budget_algorithms budget_algorithm,
Thread_CPU_budget_algorithm_callout budget_callout,
Thread_queue_Context *queue_context
@@ -113,9 +113,13 @@ static int _POSIX_Set_sched_param(
}
int pthread_setschedparam(
- pthread_t thread,
- int policy,
- struct sched_param *param
+ pthread_t thread,
+ int policy,
+#ifdef HAVE_PTHREAD_SETSCHEDPARAM_CONST
+ const struct sched_param *param
+#else
+ struct sched_param *param
+#endif
)
{
Thread_CPU_budget_algorithms budget_algorithm;
--
2.13.7
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC IRC Meeting reschedule: 7/4 to 7/3
On 03/07/18 11:01, Amaan Cheval wrote:
- Rebase with master and fix misc. issues that cropped up (commit -
https://github.com/AmaanC/rtems-gsoc18/commit/a28badd8df1904496c27b262ae515d22da544713)
This looks good.
I would place the
.rtemsstack (NOLOAD) :
{
*(SORT(.rtemsstack.*))
}
WorkAreaBase = .;
before the debug sections in the linker command file.
--
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: GSoC IRC Meeting reschedule: 7/4 to 7/3
Hey! Sorry, I totally forgot we meant to reschedule this week's meeting - I have another conflicting commitment at that time. I'll try to pop in for a bit if possible. I'll update the wiki page with this week's work, but here's the update I'd have sent on IRC: - Got basic UART/console driver working using RTEMS' existing NS16550 driver code - Rebase with master and fix misc. issues that cropped up (commit - https://github.com/AmaanC/rtems-gsoc18/commit/a28badd8df1904496c27b262ae515d22da544713) - WIP: Misc. clean up (cpu.h primarily for now, but a lot of things that _work_ but may not be in their ideal state (for eg. CPU_Context_switch)) Up next: - Finish clean up for port and send a v1 patch for review to devel@ (estimate: done end of this week or early next week) - Document method of using FreeBSD's bootloader in the user BSP documentation (and on my blog) - Document current state of BSP in the user BSP documentation No blockers at the moment. I haven't blogged my progress because I've been putting those status updates on the mailing list - it didn't feel like it deserved a blog post (since it would be so highly context-specific, it wouldn't stand on its own). Let me know if you'd still prefer to have those blog posts, even if only in summarizing updates/decisions made on the mailing list. Have a good fourth of July! On Mon, Jul 2, 2018 at 11:29 PM, Dannie Huang wrote: > Got it! Enjoy the break. > > On Mon, Jul 2, 2018 at 12:21 PM, Gedare Bloom wrote: >> >> Hello All, >> >> We will hold the weekly IRC meeting on Tuesday 7/3 (tomorrow!) instead >> of 7/4 at the same usual time (10am Eastern Daylight Time) due to the >> US holiday on 7/4. Joel will likely lead the meeting. >> >> Gedare > > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
