This adds back the capability for the BSP to configure an
initial extension that is specific to itself. The parameter
BSP_INITIAL_EXTENSION was taken over by having a standard
fatal extension installed using the same name.
---
cpukit/include/rtems/confdefs.h | 3 +++
1 file changed, 3 insertions(+
---
cpukit/headers.am | 1 +
1 file changed, 1 insertion(+)
diff --git a/cpukit/headers.am b/cpukit/headers.am
index 3386f77..e9d266d 100644
--- a/cpukit/headers.am
+++ b/cpukit/headers.am
@@ -183,6 +183,7 @@ include_rtems_HEADERS += include/rtems/userenv.h
include_rtems_HEADERS += include/rtems
This hook is only enabled when paravirtualized. It allows
the application running on RTEMS in a paravirtualized
environment to have its set time operations impact
the hosting environment. This requires support specific
to the paravirtualized environment. The hosting environment
may refuse to let th
Hi
This is a collection of odds and ends that have been gathering dust.
0001-rtems-confdefs.h-add-another-initial-extension-set.patch
While working on the paravirtualized RTEMS on Deos, we discovered
that the addition of the default extension used the BSP_INITIAL_EXTENSION
configuration paramete
On 4/10/19 8:08 am, Joel Sherrill wrote:
> This hook is only enabled when paravirtualized. It allows
> the application running on RTEMS in a paravirtualized
> environment to have its set time operations impact
> the hosting environment. This requires support specific
> to the paravirtualized enviro
On 04/10/2019 00:08, Joel Sherrill wrote:
This adds back the capability for the BSP to configure an
initial extension that is specific to itself. The parameter
BSP_INITIAL_EXTENSION was taken over by having a standard
fatal extension installed using the same name.
---
cpukit/include/rtems/confd
On 04/10/2019 04:44, Chris Johns wrote:
Is this only useful for virtual BSPs and is it always a requirement to implement
this call in those environments?
Would this call be useful to a non-virtual BSP, for example one with a battery
backed RTC device?
Would a hook API along the lines of
t
On 03/10/2019 04:38, Chris Johns wrote:
On 2/10/19 9:21 pm, Sebastian Huber wrote:
the waf build prototype contains no examples for building Ada objects, libraries
and executables.
https://git.rtems.org/amar/waf-old.git/
Searching the internet revealed also nothing. It would be great to have
On 02/10/2019 19:48, Gedare Bloom wrote:
On Tue, Oct 1, 2019 at 10:52 PM Sebastian Huber
wrote:
On 01/10/2019 23:40, Gedare Bloom wrote:
+/*
+ * SPDX-License-Identifier: BSD-2-Clause
+ * SPDX-License-Identifier: CC-BY-SA-4.0
+ *
+ * Copyright (C) 2018, 2019 embedded brains GmbH
+ *
+ * Redist
On 4/10/19 3:10 pm, Sebastian Huber wrote:
> On 04/10/2019 04:44, Chris Johns wrote:
>> Is this only useful for virtual BSPs and is it always a requirement to
>> implement
>> this call in those environments?
>>
>> Would this call be useful to a non-virtual BSP, for example one with a
>> battery
>
On 4/10/19 3:17 pm, Sebastian Huber wrote:
> On 03/10/2019 04:38, Chris Johns wrote:
>> On 2/10/19 9:21 pm, Sebastian Huber wrote:
>>>
>>> the waf build prototype contains no examples for building Ada objects,
>>> libraries
>>> and executables.
>>>
>>> https://git.rtems.org/amar/waf-old.git/
>>>
>
On 03/10/2019 04:32, Chris Johns wrote:
On 3/10/19 3:30 am, Gedare Bloom wrote:
On Wed, Oct 2, 2019 at 5:12 AM Sebastian Huber
wrote:
On 30/09/2019 15:14, Sebastian Huber wrote:
Hello,
I would like to work on a new build system prototype. The idea is to use
specification items maintained by
On 04/10/2019 08:08, Chris Johns wrote:
On 4/10/19 3:17 pm, Sebastian Huber wrote:
On 03/10/2019 04:38, Chris Johns wrote:
On 2/10/19 9:21 pm, Sebastian Huber wrote:
the waf build prototype contains no examples for building Ada objects, libraries
and executables.
https://git.rtems.org/amar/wa
On 04/10/2019 08:06, Chris Johns wrote:
On 4/10/19 3:10 pm, Sebastian Huber wrote:
On 04/10/2019 04:44, Chris Johns wrote:
Is this only useful for virtual BSPs and is it always a requirement to implement
this call in those environments?
Would this call be useful to a non-virtual BSP, for examp
On 02/10/2019 19:44, Gedare Bloom wrote:
On Wed, Oct 2, 2019 at 1:28 AM Sebastian Huber
wrote:
Hello,
the interrupt extension API implementation is already quite complex and
not covered by the test suite:
https://git.rtems.org/rtems/tree/bsps/shared/irq
In order to write generic tests for t
On 03/10/2019 07:44, Chris Johns wrote:
On 2/10/19 5:28 pm, Sebastian Huber wrote:
the interrupt extension API implementation is already quite complex and not
covered by the test suite:
https://git.rtems.org/rtems/tree/bsps/shared/irq
In order to write generic tests for this we have to know
16 matches
Mail list logo