On 5/23/19 7:35 AM, Sebastian Huber wrote:
> On 22/05/2019 22:34, Jiri Gaisler wrote:
>> On 5/22/19 7:43 PM, Jiri Gaisler wrote:
>>> On 5/22/19 9:49 AM, Sebastian Huber wrote:
On 22/05/2019 09:39, Jiri Gaisler wrote:
> On 5/22/19 8:03 AM, Sebastian Huber wrote:
>> Hello,
>>
>>
On 5/23/19 1:47 PM, Sebastian Huber wrote:
> On 22/05/2019 22:34, Jiri Gaisler wrote:
>> Adding a pseudo-random delay of 0 - 15 clocks to each trap/interrupt
>> causes the test to pass on all cpu configurations with the default
>> time slice (50)..! I am not sure what this means - it could be a
>
On 22/05/2019 22:34, Jiri Gaisler wrote:
Adding a pseudo-random delay of 0 - 15 clocks to each trap/interrupt causes the
test to pass on all cpu configurations with the default time slice (50)..! I am
not sure what this means - it could be a hidden race condition, the algorithm
might need some
On 22/05/2019 16:11, Joel Sherrill wrote:
On Wed, May 22, 2019 at 3:37 AM Ting Peng
mailto:ting.p...@embedded-brains.de>>
wrote:
Hello,
As we need to choose one RTEMS software component as an example to
have
an overview of the qualification process, Sebastian Huber suggests
On 23/05/2019 08:44, Chris Johns wrote:
On 23/5/19 3:40 pm, Sebastian Huber wrote:
On 23/05/2019 07:35, Chris Johns wrote:
On 23/5/19 12:25 am, Sebastian Huber wrote:
We definitely need a repository to store the requirements files (Doorstop,
YAML). This is the first thing we have to know. If i
On 23/5/19 3:40 pm, Sebastian Huber wrote:
> On 23/05/2019 07:35, Chris Johns wrote:
>> On 23/5/19 12:25 am, Sebastian Huber wrote:
>>> We definitely need a repository to store the requirements files (Doorstop,
>>> YAML). This is the first thing we have to know. If it later turns out that
>>> the
