[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 -
** 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
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
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
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
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.
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
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
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
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
On 20 August 2012 17:43, Mark Phillips mark.phill...@csr.com 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
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] =
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-
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 PC
(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
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.
** 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
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
week)
18 matches
Mail list logo
