[Expired for QEMU because there has been no activity for 60 days.]
** Changed in: qemu
Status: Incomplete => Expired
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/657006
Title:
arm v7M - sv
** Tags added: arm
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/657006
Title:
arm v7M - svc insn doesn't trigger PendSV handler
Status in QEMU:
Incomplete
Bug description:
The svc instructio
Triaging old bug tickets... can you still reproduce this issue with the
latest version of QEMU? Or could we close this ticket nowadays?
** Changed in: qemu
Status: New => Incomplete
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QE
I've made an interesting discovery:-
If I instrument the code to record the sequence of code/exceptions and
get a different, and apparently correct result!
If I single step by starting the simulator with the following command
line "qemu-system-arm -M lm3s6965evb -cpu cortex-m3 -kernel hack.bin
-n
I have put together a test program and tried against a vanila copy of
qemu 1.1.1
The SVC wil be completely masked unless I apply patch 0002-target-arm-
Disable-priority_mask-feature.patch, which hacks arm_gic.c to initialise
the gic priority_mask to 0x100 instead of 0xf0. There doesn't appear to
b
ok, I'll double check that backing out the local patches doesn't make a
difference. If it still happens I will try and come up with a reduced
test case.
What do you expect to happen?
Should the SVC exception 11 run immediately?
What should happen if a clock tick interrupt is also pending at level
Yes, I'm not disputing that the SVC exception should be handled
synchronously, I'm asking you to provide a test case demonstrating the
wrong behaviour.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/65
In particular table 2-16 of DUI0552A_Cortex_m3_dgug.pdf states that the
Activation of the SVC exception is Synchronous.
And after the table it states "For an asynchronous exception, other than reset,
the processor can execute another instruction
between when the exception is triggered and when t
OK, I'll re-read the documentation maybe I am wrong!
It does say "synchronous" in the description and I don't understand how it can
work if it is asynchronous because for Cortex the SVC argument is not
transfered to a register and the only way the exception code can access it is
by reading it fr
On 20 August 2012 17:43, Mark Phillips wrote:
> I have been experimenting with Sebastian's patches mentioned earlier
> (http://git.rtems.org/rtems/tree/c/src/lib/libbsp/arm/lm3s69xx?id=e1ebfebf1bffe3e7731ac529409bd2576285467b)
> and think I have found another major issue:-(
>
> My reading of the A
I have been experimenting with Sebastian's patches mentioned earlier
(http://git.rtems.org/rtems/tree/c/src/lib/libbsp/arm/lm3s69xx?id=e1ebfebf1bffe3e7731ac529409bd2576285467b)
and think I have found another major issue:-(
My reading of the ARM documentation is that the SVC opcode should perform a
Thanks for clarification. Now I understood what you there talking about
PopStack pseudocode function.
(4) It is entirely possible that hardware implementations to date ignore
the lsbit in this situation. That doesn't mean that software which
relies on this UNPREDICTABLE behaviour is not buggy.
It
(1) You should be looking at DDI0403D -- revision D of the v7M ARM ARM
included some significant clarifications and corrections as well as
adding documentation of floating point support.
(2) The behaviour of the POP instruction is irrelevant here because the
QEMU function you are proposing to chan
>From the manual
>DDI0403C_arm_architecture_v7m_reference_manual_errata_markup_2_0.pdf
A6.7.97 POP
Pop Multiple Registers loads a subset (or possibly all) of the general-purpose
registers R0-R12 and the PC
or the LR from the stack.
If the registers loaded include the PC, the word loaded for the P
Nope. That code corresponds to the ARM v7M ARM PopStack() pseudocode
which states that it is UNPREDICTABLE if the new PC is not halfword
aligned. The bug is in whatever is filling in that stack frame with a
bit0-set value.
--
You received this bug notification because you are a member of qemu-
de
I had the same problem then was trying to run project based on uC OS2.
So there is no problem in freeRtos or in uCOS and it is better to do
change in helper.c in function:
static void do_v7m_exception_exit(CPUARMState *env)
replace line
env->regs[15] = v7m_pop(env);
with
env->regs[15] = v7m_
Issue "solved".
In freeRtos, for the first "context switch" (launch the first task), the
register pc is written with an adress with le bit0 equal to 1 (thumb).
If I change this and set bit0 to 0 (new_pc = task_to_start_pointer &
0xfffe), it is working well. I do not know yet (i will try next
w
** Summary changed:
- arm - svc instruction
+ arm v7M - svc insn doesn't trigger PendSV handler
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/657006
Title:
arm v7M - svc insn doesn't trigger PendS
18 matches
Mail list logo
