Re: [Openocd-development] [PATCH] Updated omap3530 .cfg with improved reset handling

2009-10-08 Thread David Brownell
On Wednesday 30 September 2009, Magnus Lundin wrote: +omap3.cpu configure -event reset-start omap3.cpu mww $PRM_RSTCTRL 2 +omap3.cpu configure -event reset-end omap3_dbginit     Isn't there a chicken/egg thing having omap3.cpu mww ... do its thing without having forcibly enabled the

Re: [Openocd-development] [PATCH] Updated omap3530.cfg with improved reset handling

2009-10-01 Thread Dirk Behme
Magnus Lundin wrote: David Brownell wrote: I think that's not quite following the model which the code in the src/helper/startup.tcl file is expecting ... a closer match would use reset-assert-pre (or maybe post) not reset-start. I have done some more testing and trying to understand the

Re: [Openocd-development] [PATCH] Updated omap3530.cfg with improved reset handling

2009-09-30 Thread Magnus Lundin
We can, and sometimes we want to, write to memory while the CortexA8 core is running, but for gbd to load a program and the i-caches to be cleared to core must be halted. So I think there must be a monitor halt after the monitor omap3_dbginit No. I just do arm-none-linux-gnueabi-gdb

Re: [Openocd-development] [PATCH] Updated omap3530.cfg with improved reset handling

2009-09-30 Thread Dirk Behme
Magnus Lundin wrote: We can, and sometimes we want to, write to memory while the CortexA8 core is running, but for gbd to load a program and the i-caches to be cleared to core must be halted. Yes, thanks! Attachment now gives me: -- cut -- arm-none-linux-gnueabi-gdb GNU gdb 6.8 Copyright

Re: [Openocd-development] [PATCH] Updated omap3530.cfg with improved reset handling

2009-09-30 Thread Magnus Lundin
David Brownell wrote: I think that's not quite following the model which the code in the src/helper/startup.tcl file is expecting ... a closer match would use reset-assert-pre (or maybe post) not reset-start. I have done some more testing and trying to understand the reset handling in

[Openocd-development] [PATCH] Updated omap3530.cfg with improved reset handling

2009-09-29 Thread Magnus Lundin
For testing and comments: Uses the OMAP3530 global software reset and defines corresponding reset-start and reset-end event handlers. Best regards, Magnus === . . # FIXME much of this should be in reset event handlers proc omap3_dbginit { } { poll off

Re: [Openocd-development] [PATCH] Updated omap3530.cfg with improved reset handling

2009-09-29 Thread Magnus Lundin
Well, some days our work is a bit more confused then other days. Dirk Behme wrote: Magnus Lundin wrote: For testing and comments: Uses the OMAP3530 global software reset and defines corresponding reset-start and reset-end event handlers. Something is wrong with the patch in attachment? It

Re: [Openocd-development] [PATCH] Updated omap3530.cfg with improved reset handling

2009-09-29 Thread Dirk Behme
Magnus Lundin wrote: Well, some days our work is a bit more confused then other days. Dirk Behme wrote: Magnus Lundin wrote: For testing and comments: Uses the OMAP3530 global software reset and defines corresponding reset-start and reset-end event handlers. Something is wrong with the

Re: [Openocd-development] [PATCH] Updated omap3530.cfg with improved reset handling

2009-09-29 Thread Magnus Lundin
At the end of the reset handling we reinitialise the tap and the debug interface with omap3_dbginit omap3_reset is really reset+reinit+halt and you call it if you want to debug the loading of u-boot by the X-Loader Do you mean omap3_reset should be called 'manually' if needed, same

Re: [Openocd-development] [PATCH] Updated omap3530.cfg with improved reset handling

2009-09-29 Thread Dirk Behme
Magnus Lundin wrote: At the end of the reset handling we reinitialise the tap and the debug interface with omap3_dbginit omap3_reset is really reset+reinit+halt and you call it if you want to debug the loading of u-boot by the X-Loader Do you mean omap3_reset should be called