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
On Friday 02 October 2009, David Brownell wrote:
> My previous proposal here is twofold:
>
> 1 - First, to make sure the TAP will have been
> enabled! Add a new "post-verify" method to
> kick in after the scan chain verification,
> which can "jtag tapenable $TAPNAME".
And for th
Very good comments from Dave, I will think about them, do some testing
on vector catch and the state after reset.
For now I have commited but the omap3_reset function is removed, since
this is handled by "reset halt"
Regards,
Magnus
___
Openocd-develo
On Wednesday 30 September 2009, 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
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
Øyvind Harboe wrote:
> Remove these, they probably *slow down* if anything...
>
> # Increase the packet size to improve download speed.
> set remote memory-write-packet-size 1024
> set remote memory-write-packet-size fixed
Thanks for the hint, done:
http://elinux.org/BeagleBoardOpenOCD#LED_blink
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
Remove these, they probably *slow down* if anything...
# Increase the packet size to improve download speed.
set remote memory-write-packet-size 1024
set remote memory-write-packet-size fixed
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flas
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
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
David Brownell wrote:
> On Tuesday 29 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 wi
On Tuesday 29 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 TAP, which
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 shou
>>>
>> 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 nee
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.
>>
>> Somethi
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 h
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
17 matches
Mail list logo
