We must not load registers (e.g. PSR) from the heir context area before
the heir stopped execution.
With this patch the write to PSR is divided into two steps. We first update
the current window pointer and then we restore the status registers and
enable traps. This allows us to move the first wri
Sorry the off-topic email.
Who is planning to attend the expo at EW, so we could meet?
Thanks,
Daniel.
--
Daniel F. Gutson
Chief Engineering Officer, SPD
San Lorenzo 47, 3rd Floor, Office 5
Córdoba, Argentina
Phone: +54 351 4217888 / +54 351 4218211
Skype:dgutson
LinkedIn: http://a
On Mon, Nov 16, 2015 at 2:31 PM, Sebastian Huber
wrote:
>
>
> - Am 16. Nov 2015 um 17:06 schrieb Gedare Bloom ged...@rtems.org:
>
>> Does this bug have a ticket?
>
> From my point of view we need a ticket, if
>
> 1) a bug cannot be fixed immediately or requires a couple of patches, or
>
> 2) a
- Am 16. Nov 2015 um 17:06 schrieb Gedare Bloom ged...@rtems.org:
> Does this bug have a ticket?
>From my point of view we need a ticket, if
1) a bug cannot be fixed immediately or requires a couple of patches, or
2) a new feature need several patches, accompanying
documentation/reasons
There appears to be problems in the code you copy-pasted, so it is
hard to say for sure what is going on in your actual code. See below
for a few notes.
On Mon, Nov 16, 2015 at 11:28 AM, Inderjit Singh
wrote:
> Hi,
>
> I have a strange behaviour regarding memory access between my user
> applicati
Hi,
I have a strange behaviour regarding memory access between my user application
and the driver i have developed I'd like to get some clarification on.
The development is all used on or1k arch.
On the application side, I have a buffer declared as:
#define PACKET_SIZE 256
volatile uint8_t __at
Does this bug have a ticket?
On Mon, Nov 16, 2015 at 10:05 AM, Daniel Cederman wrote:
> Yes, definitely. Would you mind doing it? Daniel is away from office this
> week and I do not have access.
>
> On 2015-11-16 15:57, Sebastian Huber wrote:
>>
>> Looks good, we should probably apply it to the 4
Yes, definitely. Would you mind doing it? Daniel is away from office
this week and I do not have access.
On 2015-11-16 15:57, Sebastian Huber wrote:
Looks good, we should probably apply it to the 4.11 branch as well.
--
Daniel Cederman
Software Engineer
Cobham Gaisler
___
Looks good, we should probably apply it to the 4.11 branch as well.
--
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
We must not load registers (e.g. PSR) from the heir context area before
the heir stopped execution.
With this patch the write to PSR is divided into two steps. We first update
the current window pointer and then we restore the status registers and
enable traps. This allows us to move the first wri
Ok, then I will remove that line. I like the assert idea and will add
that to the patch. Thank you for your comments and help!
On 2015-11-16 13:52, Sebastian Huber wrote:
On 16/11/15 13:14, Daniel Cederman wrote:
I was unsure if the ET bit was always set or not for newly created
task contexts,
On 16/11/15 13:14, Daniel Cederman wrote:
I was unsure if the ET bit was always set or not for newly created
task contexts, or if this was the first place that traps got enabled
for a new task. If it is always set we can remove that instruction.
The PSR is initialized like this (_CPU_Context_I
I was unsure if the ET bit was always set or not for newly created task
contexts, or if this was the first place that traps got enabled for a
new task. If it is always set we can remove that instruction.
On 2015-11-16 11:27, Sebastian Huber wrote:
On 16/11/15 11:06, Daniel Cederman wrote:
@
On 16/11/15 11:06, Daniel Cederman wrote:
@@ -202,6 +193,13 @@ try_update_is_executing:
! The next load is in a delay slot, which is all right
#endif
+ld [%o1 + PSR_OFFSET], %g1 ! g1 = heir psr
+andn%g1, SPARC_PSR_CWP_MASK, %g1 ! g1 = heir psr w/o
We must not load registers (e.g. PSR) from the heir context area before
the heir stopped execution.
With this patch the write to PSR is divided into two steps. We first update
the current window pointer and then we restore the status registers and
enable traps. This allows us to move the first wri
Hello Daniel,
could you please add comments to the move to PSR which are not followed
by three nops and explain why they are not necessary.
On 16/11/15 10:03, Daniel Cederman wrote:
We must not load registers (e.g. PSR) from the heir context area before
the heir stopped execution.
---
c/src
We must not load registers (e.g. PSR) from the heir context area before
the heir stopped execution.
---
c/src/lib/libbsp/sparc/shared/irq_asm.S | 30 +-
1 file changed, 13 insertions(+), 17 deletions(-)
diff --git a/c/src/lib/libbsp/sparc/shared/irq_asm.S
b/c/src/lib/
17 matches
Mail list logo
