On 16 October 2015 at 18:57, Ilya Lipnitskiy <ilya.lipnits...@gmail.com> wrote: > On Fri, Oct 16, 2015 at 10:37 AM, Peter Maydell > <peter.mayd...@linaro.org> wrote: >> It would be helpful if you said what the abort actually was >> (ie what instruction do we abort on, what are the fault status/ >> fault address registers if applicable, etc). > I should have been more specific. Running trunk qemu on the patched > zImage with qemu-system-arm -M vexpress-a9 -kernel > linux/arch/arm/boot/zImage -serial stdio -dtb > linux/arch/arm/boot/dts/vexpress-v2p-ca9.dtb -s -S then attaching gdb > generates the following information. I haven't nailed the actual > instruction causing the abort yet. Is it obvious from the registers? > > (gdb) target remote :1234 > Remote debugging using :1234 > 0x60000000 in ?? () > (gdb) c > Continuing. > ^C > Program received signal SIGINT, Interrupt. > __vectors_start () at arch/arm/kernel/entry-armv.S:1240 > 1240 W(b) vector_pabt
This doesn't really provide enough information to say, because what will happen is that we take a fault for some reason, and then because the vectors start at 0 and are empty we will typically take another fault trying to execute at the vector for the first fault, and then sit in a loop faulting indefinitely. You might find it helpful to turn on QEMU's debug logging (see the -d and -D options). Chances are that some insn in your new code is faulting (probably UNDEFing). thanks -- PMM
