Re: API to convert priorities to/from POSIX from/to Classic?

On 31/07/2018 04:03, Sebastian Huber wrote: > > rtems_status_code rtems_task_priority_posix_to_classic(rtems_id scheduler_id, > int posix_priority, rtems_task_priority *classic_priority) > rtems_status_code rtems_task_priority_classic_to_posix(rtems_id scheduler_id, > rtems_task_priority

Re: [GSoC - x86_64] Clock driver - which hardware source to support primarily?

Cool, that's the plan. Yes, I believe it will limit the accessible RAM since page-faults never occur (due to the repetitive mapping), and we never map anything beyond the first 1 GiB of physical memory. I think the simplest paging scheme later will be identity mapping virtual to physical

Re: [GSoC - x86_64] Clock driver - which hardware source to support primarily?

On Mon, Jul 30, 2018, 2:27 PM Amaan Cheval wrote: > Quick status update: in working on the APIC timer, as a prerequisite, > I've had to setup access to the Interrupt Descriptor Table (which is > great because it helps us have the basic interrupt support we need at > least). > > Another minor

Re: [GSoC - x86_64] Clock driver - which hardware source to support primarily?

Quick status update: in working on the APIC timer, as a prerequisite, I've had to setup access to the Interrupt Descriptor Table (which is great because it helps us have the basic interrupt support we need at least). Another minor issue I've run into is the fact that the APIC is located at

Re: API to convert priorities to/from POSIX from/to Classic?

Solves the easiest part of the problem. Full mapping for scheduling attributes between the two APIs is a different matter. --joel On Mon, Jul 30, 2018 at 1:58 PM, Gedare Bloom wrote: > I can get on board with extending the classic API to include > converters to/from posix priorities

Re: API to convert priorities to/from POSIX from/to Classic?

On Mon, Jul 30, 2018 at 1:03 PM, Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > - Am 30. Jul 2018 um 18:29 schrieb Gedare Bloom ged...@rtems.org: > > > On Mon, Jul 30, 2018 at 11:23 AM, Joel Sherrill wrote: > >> > >> > >> On Mon, Jul 30, 2018 at 7:43 AM, Sebastian Huber > >>

Re: Many ARM Test Build Failures

- Am 30. Jul 2018 um 18:38 schrieb joel j...@rtems.org: > As of this morning, it looks like the failures I was seeing are still > present. Yes, I sent the patches for review today. ___ devel mailing list devel@rtems.org

Re: API to convert priorities to/from POSIX from/to Classic?

- Am 30. Jul 2018 um 18:29 schrieb Gedare Bloom ged...@rtems.org: > On Mon, Jul 30, 2018 at 11:23 AM, Joel Sherrill wrote: >> >> >> On Mon, Jul 30, 2018 at 7:43 AM, Sebastian Huber >> wrote: >>> >>> On 30/07/18 14:25, Joel Sherrill wrote: On Mon, Jul 30, 2018, 6:26 AM

[PATCH v2] Coverage: Add support to generate separate reports for each symbol-set

Invoke covoar multiple times from the script to generate separate reports for each symbol-set. --- tester/rt/coverage.py | 38 ++ 1 file changed, 18 insertions(+), 20 deletions(-) diff --git a/tester/rt/coverage.py b/tester/rt/coverage.py index

Re: [PATCH v4] Coverage: Add support to generate separate reports for each symbol-set

Please send this as -v2 for "final" review On Mon, Jul 30, 2018 at 12:40 PM, Vijay Kumar Banerjee wrote: > Invoke covoar multiple times from the script to generate separate > reports for each symbol-set. > --- > tester/rt/coverage.py | 38 ++ > 1 file

[PATCH v4] Coverage: Add support to generate separate reports for each symbol-set

Invoke covoar multiple times from the script to generate separate reports for each symbol-set. --- tester/rt/coverage.py | 38 ++ 1 file changed, 18 insertions(+), 20 deletions(-) diff --git a/tester/rt/coverage.py b/tester/rt/coverage.py index

Re: Many ARM Test Build Failures

As of this morning, it looks like the failures I was seeing are still present. >From arm/csb336: /data/home/joel/rtems-work/tools/5/bin/../lib/gcc/arm-rtems5/7.3.0/../../../../arm-rtems5/bin/ld: sptimecounter02.exe section `.rtemsstack' will not fit in region `SRAM'

Re: [PATCH] Coverage: Add support to generate separate reports for each symbol-set

On 30 July 2018 at 21:54, Gedare Bloom wrote: > On Mon, Jul 30, 2018 at 3:30 AM, Vijay Kumar Banerjee > wrote: > > Invoke covoar multiple times from the script to generate separate > > reports for each symbol-set. > > --- > > tester/rt/coverage.py | 32 +++- > > 1

Re: API to convert priorities to/from POSIX from/to Classic?

On Mon, Jul 30, 2018 at 11:23 AM, Joel Sherrill wrote: > > > On Mon, Jul 30, 2018 at 7:43 AM, Sebastian Huber > wrote: >> >> On 30/07/18 14:25, Joel Sherrill wrote: >>> >>> >>> >>> On Mon, Jul 30, 2018, 6:26 AM Sebastian Huber >>> >> > wrote: >>> >>>

Re: [PATCH] Coverage: Add support to generate separate reports for each symbol-set

On Mon, Jul 30, 2018 at 3:30 AM, Vijay Kumar Banerjee wrote: > Invoke covoar multiple times from the script to generate separate > reports for each symbol-set. > --- > tester/rt/coverage.py | 32 +++- > 1 file changed, 15 insertions(+), 17 deletions(-) > > diff --git

Re: API to convert priorities to/from POSIX from/to Classic?

On Mon, Jul 30, 2018 at 7:43 AM, Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > On 30/07/18 14:25, Joel Sherrill wrote: > >> >> >> On Mon, Jul 30, 2018, 6:26 AM Sebastian Huber < >> sebastian.hu...@embedded-brains.de > ed-brains.de>> wrote: >> >>

Re: API to convert priorities to/from POSIX from/to Classic?

On 30/07/18 14:25, Joel Sherrill wrote: On Mon, Jul 30, 2018, 6:26 AM Sebastian Huber > wrote: Hello, is there a standard API to convert priorities to/from POSIX from/to Classic? If not, I think we should add something. There is not

Re: API to convert priorities to/from POSIX from/to Classic?

On Mon, Jul 30, 2018, 6:26 AM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > Hello, > > is there a standard API to convert priorities to/from POSIX from/to > Classic? If not, I think we should add something. > There is not a public API for this. There are some internal helpers

API to convert priorities to/from POSIX from/to Classic?

Hello, is there a standard API to convert priorities to/from POSIX from/to Classic? If not, I think we should add something. -- 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 :

Re: RTEMS 5 tool chain update

On 27/07/18 13:23, Sebastian Huber wrote: On 24/07/18 09:51, Sebastian Huber wrote: Hello, I updated the tool chain (RSB) to use the latest Newlib snapshot (3.0.0.20180720) and Binutils 2.31.1. An immediate update from the previous tools based on Newlib 3.0.0 is not necessary. I merged the

Re: Severe bug in libbsd

On 30/07/18 08:59, Chris Johns wrote: On 30/07/2018 15:13, Sebastian Huber wrote: On 30/07/18 02:49, Chris Johns wrote: On 27/07/2018 23:01, Sebastian Huber wrote: On 27/07/18 14:53, Sebastian Huber wrote: On 27/07/18 14:49, Gedare Bloom wrote: OK. Should this kind of announcement go to

[PATCH] Coverage: Add support to generate separate reports for each symbol-set

Invoke covoar multiple times from the script to generate separate reports for each symbol-set. --- tester/rt/coverage.py | 32 +++- 1 file changed, 15 insertions(+), 17 deletions(-) diff --git a/tester/rt/coverage.py b/tester/rt/coverage.py index 7dd5002..99342e1

Re: Severe bug in libbsd

On 30/07/2018 15:13, Sebastian Huber wrote: > On 30/07/18 02:49, Chris Johns wrote: >> On 27/07/2018 23:01, Sebastian Huber wrote: >>> On 27/07/18 14:53, Sebastian Huber wrote: On 27/07/18 14:49, Gedare Bloom wrote: > OK. Should this kind of announcement go to users@? RTEMS 5 will be

[PATCH] libtests: Use CONFIGURE_INIT_TASK_TABLE_SIZE

Using CONFIGURE_MINIMUM_TASK_STACK_SIZE increases also the interrupt stack size. This is an issue on some BSPs. Use CONFIGURE_INIT_TASK_TABLE_SIZE instead. Update #3433. --- testsuites/libtests/dl01/init.c| 6 ++ testsuites/libtests/dl02/init.c| 7 +++

Re: [PATCH] confdefs: Fix uniprocessor configuration

On 30/07/18 07:39, Sebastian Huber wrote: -#ifndef CONFIGURE_MAXIMUM_PROCESSORS - #define CONFIGURE_MAXIMUM_PROCESSORS 1 +/* Ensure that _CONFIGURE_MAXIMUM_PROCESSORS > 1 only in SMP configurations */ +#if !defined(CONFIGURE_MAXIMUM_PROCESSORS) && defined(RTEMS_SMP) + #define