> > > 0xbfffe000? You where talking about the fact that the security
> > > extensions
> > > where not implemented. I was not aware that the different vbar's where
> > > already part of the security stuff?
> >
> > MVBAR is part of the Security extensions. HVBAR is part of the
> > Virtualization extensions. In mainline QEMU we implement neither
> > of those extensions, and so don't implement the associated
> > registers. (Strictly speaking, VBAR is also only in the
> > Security extensions, but we provide it as a workaround for
> > guests that assume our CPUs should implement it.)
>
> Peter beat me to it. None of the VBAR registers should matter in your case
> which coincides with the use of hivecs.
While writing this mail i found out that the integrated debugger is causing
harm in combination with the fiq. So everything below the braces seems to
be related to the this problem. But i still wanted to keep the data points for
reference:
{
Ok, so qemu only implements the SCTLR.V bit to control the memory address of
the interrupt vector. So its either 0 or 0xffff0000. That is fine with me.
Currently i have the problem that a call to set_fiq_handler does not place the
binary stuff loaded at the address where qemu is jumping to which is presumably
0xffff1240. I have checked that SCTLR.V =1 under linux which is fine.
The background info to set_fiq_handler from my understanding is that it copies
the given stuff directly at the address where the FIQ vector is located. This
works as the FIQ is the last entry and thus there is some memory space for a
short interrupt handler. I checked the memory when entering the FIQ with the
integrated gdb:
(gdb) info reg
r0 0x0 0
r1 0x0 0
r2 0x1 1
r3 0x76eb34c8 1995125960
r4 0x76eb34c8 1995125960
r5 0x76f633b8 1995846584
r6 0x2a 42
r7 0x76f4c28c 1995752076
r8 0xf8200100 -132120320
r9 0xe0040000 -536608768
r10 0x60004059 1610629209
r11 0x0 0
r12 0x0 0
sp 0x908be000 0x908be000
lr 0x76dfc108 1994375432
pc 0xffff1240 0xffff1240 <firq_fiq_handler>
cpsr 0x600f01d1 1611596241
(gdb) x 0xffff1240
0xe599b00c
But my firq_fiq_handler starts with 0xee12af10? I know that this works on real
hardware so i suspect that this an error within qemu? Or at least that there
is something amiss in the way the memory is initialized or handled.
Is there a way to instrument the memory below the vector table to get debug
logs if the memory is modified?
}
> It may be worthwhile to put a kernel breakpoint in handle_fiq_as_nmi() just
> to see where it goes. If CONFIG_ARM_GIC is enabled it should take you to
> your handler I suspect. Plus, if you get there then we have likely proven
> that QEMU is getting the kernel to the right place. I set a BP in this
> routine on my A9 run and appear to be hitting it correctly.
So you are talking about the linux kernel, right? CONFIG_ARM_GIC=y check but
i can't find handle_fiq_as_nmi? Even a fuzzier "rgrep nmi * |grep fiq" does not
find anything.
Concerning the fact that qemu is jumping to the right address:
To i have put a breakpoint to 0xffff001c which is the fiq base vector address.
There is an instruction 0xea000480 which seems to be a pc relative branch to
0x1224 which then lands at 0xffff1240.
But the internal debugger gives me some concerns. If i do at the gdb command
line:
hb *0xffff001c
hb *0xffff1240
The debugger only stops at the first breakpoint. If i leave the first
breakpoint
away the debugger stops at 0xffff1240. As i know that at 0xffff01c it should
jump
right to 0xffff1240 i would expect that both breakpoints are triggered.
Then if i reach the breakpoint at 0xffff1240 i know i am at the fiq code. But
(gdb) x 0xffff1240 gives the wrong value. Nevertheless i see now (after
correcting the static map of the GIC) the following debug output of my test
device when single-stepping from PC=0xffff1240:
Taking exception 6 [FIQ]
pml: pml_write: update control flags: 1
pml: pml_update: stop timer
pml: pml_update: lower irq
pml: pml_read: read magic
pml: pml_write: update control flags: 3
pml: pml_update: stop timer
This means that there has been some code executed, most probably my FIQ
handler, but the debugger showed me:
Breakpoint 1, firq_fiq_handler () at fiq.S:26
26 mrc p15, 0, r10, c2, c0, 0 @ read TTBR0 < ok
(gdb) s <- oh my why is it single stepping into the kernel from FIQ?
test_ti_thread_flag (flag=1, ti=0x8f84e000) at include/asm-generic/preempt.h:71
71 return !--*preempt_count_ptr() && tif_need_resched();
(gdb) s <- next step does not look any better...
test_bit (addr=0x8f84e000, nr=1) at include/asm-generic/bitops/non-
atomic.h:105
105 return 1UL & (addr[BIT_WORD(nr)] >> (nr & (BITS_PER_LONG-1)));
The second run is even stranger:
Breakpoint 1, firq_fiq_handler () at fiq.S:26
26 mrc p15, 0, r10, c2, c0, 0 @ read TTBR0
(gdb) s
Cannot access memory at address 0x4
(gdb) c
Continuing.
Cannot access memory at address 0x4
...
qemu seems completly unusable from here on...
I am pretty sure now that my FIQ handler is executed.
I see multiple accesses to my virtual pml test hardware:
arm_gic: Raised pending FIQ 49 (cpu 0)
pml: pml_write: update control flags: 1
pml: pml_update: start timer
pml: pml_update: lower irq
pml: pml_read: read magic
pml: pml_write: update control flags: 3
pml: pml_update: start timer
arm_gic: Enabled IRQ 37
[ OK ] Found device /dev/ttyAMA0.
pml: pml_timer_tick: raise_irq
arm_gic: Raised pending FIQ 49 (cpu 0)
pml: pml_write: update control flags: 1
pml: pml_update: start timer
pml: pml_update: lower irq
pml: pml_read: read magic
pml: pml_write: update control flags: 3
pml: pml_update: start timer
pml: pml_timer_tick: raise_irq
Which seems like normal operation. Especially the log
message shows that other stuff gets executed.
But after a while the interrupts stop and nothing happens
The system is not reacting to keypresses anymore. Not even
Ctrl-A-X. But this seems as if the debug output in the GIC and/or
my pml test driver locked the qemu up?
Also if i connect to the gdb port while the fiq is running the
qemu stops the execution.
But besides the problems with the debugger which set me of course
the qemu seems to happy emulate FIQs, which is really nice :-)
Best regards
Tim
