On Mon, Dec 13, 2010 at 5:40 PM, Drasko DRASKOVIC
<[email protected]> wrote:
> Hi all,
> I have a setup on ARM946E that works well for loading and booting
> uClinux, and during the boot phase I can stop and single-step kernel.
>
> But once booted, when it gives prompt, pressing CTRL-C in GDB can not
> halt the board :
>
> ^CHalt timed out, wake up GDB.
>
> Program received signal SIGINT, Interrupt.
> stext () at arch/arm/kernel/head-nommu.S:40
> 40 ldr r1, =machine_arch_type
> @ find the machine type
> (gdb)
>
> And messages from OpenOCD are these :
>
> Info : Halt timed out, wake up GDB.
> Warn : target not halted
> Warn : ThumbEE -- incomplete support
Hi all,
I have found an issue and will post here for the future reference.
I am using ARM946E, uClinux kerenel 2.6.
In arch/arm/kernel/process.c I can see that default_idle() function is
calling arch_idle(), which is defined in include/asm/arch/system.h and
is basically call to a architecture specific cpu_arm946_do_idle()
which is defined in arch/arm/mm/proc-arm946.S and represents CP15
manipulation to implement "wait for interrupt" operation.
What is suprising, is the comment in arch_idle() function :
/*
* Set the processor (CP15) into 'Wait for Interrupt' mode.
* Unlike disabling the processor clock via the PMC (above)
* this allows the processor to be woken via JTAG.
*/
but this does not seem to be true at all. Once entered WFI, my ARM
will not respond HALT requests send by OpenOCD.
Commenting out code which does "wait for interrupt" operation solves
the problem.
Please feel free to discuss on this strange behaviour and WFI
problematic, i.e. why neither OpenOCD or Lauterbach (tried this also)
can not force ARM to DEBUG, when the manual (2.3.10 Register 7, Cache
Operations Register, Wait for interrupt) clearly says :
This stalls the processor from the time that this instruction is
executed until either nFIQ,
nIRQ, or EDBGRQ are asserted. Also, if the debugger sets the debug
request bit in the
EmbeddedICE-RT logic control register then this causes the wait for
interrupt condition
to terminate.
Best regards,
Drasko
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development
