Dirk Behme wrote:
> Hi Magnus!
>
> Magnus Lundin wrote:
>> Hello all Cortex_A8 fans !
>>
>> Please test the following patch that hopefully corrects some insane
>> errors in Thumb state handling.
>> (Yes I wrote it myself, but it seems UBoot for BeagleBoard does not
>> use Thumb Mode)
>
> Same as
>>
>>
> Hi Matt,
>
> It makes me very happy to se active work with this code.
Hi Magnus,
It's all based on you guys great work. :)
I'm just standing on the shoulders of giants. (stealing from
Holger's blog:
http://zecke.blogspot.com/2009/08/standing-on-shoulders-of-giants-fixing.
Matt Hsu wrote:
>>> Also, the programming breakpoints works as well.
>>
>> Could you give some examples how you use this? Giving some logs of how
>> you are testing would help other to reproduce this ;)
>The following is my log of setting up a breakpoint:
Thanks, this helps a lot!
Tried it a
Hi Magnus!
Magnus Lundin wrote:
> Hello all Cortex_A8 fans !
>
> Please test the following patch that hopefully corrects some insane
> errors in Thumb state handling.
> (Yes I wrote it myself, but it seems UBoot for BeagleBoard does not use
> Thumb Mode)
Same as already mentioned with Matt's p
Øyvind Harboe wrote:
> 1 and 3 committed.
>
> Can you let me know when 2 is ready to commit?
>
Hi Øyvind,
I will resend the patch #2 since I think the following code
segment should be merged.
retval = mem_ap_write_atomic_u32(swjdp,
OMAP3530_DEBUG_BASE + CPUDBG_DRC
Øyvind Harboe wrote:
> Why is soft_reset_halt being used in the LPC init sequences?
>
> I've tested LPC2478 and the reset init sequence seems flaky
Tell me about it. We have been using LPC23xx series for some time by now
and it may be just me but I find it a bit tricky to get everything
Matt Hsu wrote:
> David Brownell wrote:
>> Re #1 and #3: I'd combine the "add #defines" and "use #defines"
>> into one patch myself... minor point.
>>
> Hi David,
>It sounds fine to me and makes the description clear.
>I will make v2 patches and submit later.
Please note th
David Brownell wrote:
> Re #1 and #3: I'd combine the "add #defines" and "use #defines"
> into one patch myself... minor point.
>
Hi David,
It sounds fine to me and makes the description clear.
I will make v2 patches and submit later.
Cheers,
Matt
>
> Re #2:
>
> O
>
> Tested-by: Dirk Behme
Hi Dirk,
Thanks for your feedback.
>
> Please apply.
>
>> Also, the programming breakpoints works as well.
>
> Could you give some examples how you use this? Giving some logs of how
> you are testing would help other to reproduce this ;)
The follo
1 and 3 committed.
Can you let me know when 2 is ready to commit?
(I'm not following the details, but there appears to be some
discussion on that change still...)
--
Øyvind Harboe
Embedded software and hardware consulting services
http://www.zylin.com
__
Committed.
Thanks!
--
Øyvind Harboe
Embedded software and hardware consulting services
http://www.zylin.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Anyone feeling like addressing the rest of these?
It's code cleanup, by and large... except that "test
floats for equality" bug.
On Monday 24 August 2009, Steve Grubb wrote:
> Hello,
>
> This is my last set of findings from looking through the code in svn. This set
> mostly concentrates on vari
Cosmetic cleanup to config files: don't use
[format "%s.cpu" $_CHIPNAME]
since it's gratuitously complex; use $_CHIPNAME.cpu instead.
---
tcl/target/aduc702x.cfg |2 +-
tcl/target/at91eb40a.cfg |2 +-
tcl/target/at91r40008.cfg
On Thursday 03 September 2009, David Claffey wrote:
> > Reset to latch PLL settings? Odd. One would expect a reset to
> > re-initialize the PLL configuration too! That's how it's done
> > on every other core I've had occasion to look at. Such odd
> > requirements rate a comment. :)
>
> yes, it
Alain Mouette wrote:
> Hi, I just changed my Cortex-M3 from LS3S6965 to ML3S6611 and it stopped
> working :(
>
> When I start openocd (0.2, Linux, FTD2232) I get:
> Open On-Chip Debugger 0.2.0 (2009-07-15-14:00) Release
> [...]
> 500 kHz
> jtag_nsrst_delay: 100
> jtag_ntrst_delay: 100
> Info : dev
Hi, I just changed my Cortex-M3 from LS3S6965 to ML3S6611 and it stopped
working :(
When I start openocd (0.2, Linux, FTD2232) I get:
Open On-Chip Debugger 0.2.0 (2009-07-15-14:00) Release
[...]
500 kHz
jtag_nsrst_delay: 100
jtag_ntrst_delay: 100
Info : device: 4
Info : deviceID: 67354056
Info :
> Reset to latch PLL settings? Odd. One would expect a reset to
> re-initialize the PLL configuration too! That's how it's done
> on every other core I've had occasion to look at. Such odd
> requirements rate a comment. :)
yes, it's odd. The plls are only reset by power-on reset, not SRST. T
Hello all Cortex_A8 fans !
Please test the following patch that hopefully corrects some insane
errors in Thumb state handling.
(Yes I wrote it myself, but it seems UBoot for BeagleBoard does not use
Thumb Mode)
Best regards
Magnus
Index: src/target/cortex_a8.c
===
On Monday 31 August 2009, Jonas Horberg wrote:
> I think than the board config file is the right place to put speed
> settings. It will benefit the end users if we provide good clock speed
> settings in the scripts that is shipped with OpenOCD.
That's probably the best place to have defaults, or
(
David Brownell wrote:
> On Monday 31 August 2009, Dirk Behme wrote:
>> David Brownell wrote:
>>> On Monday 31 August 2009, Dirk Behme wrote:
+jtag_rclk
+
>>> needs digits ..
>> Hmm, really? Then, jtag_rclk seems to be broken:
>
> I think you're right...
;)
What's about applying a patch
On Monday 31 August 2009, Dirk Behme wrote:
> David Brownell wrote:
> > On Monday 31 August 2009, Dirk Behme wrote:
> >> +jtag_rclk
> >> +
> >
> > needs digits ..
>
> Hmm, really? Then, jtag_rclk seems to be broken:
I think you're right...
>
> jtag_rclk:
>
> -- cut --
> RCLK - adaptive
>
>
On Thursday 03 September 2009, David Claffey wrote:
> David Brownell wrote:
> >> Committed less "init + reset init" which does not belong
> >> in target configuration script.
> >
> > I think the reset-init handler likely belongs in a board
> > init script too ... :)
> >
> > Specifics of DDR and c
On Monday 31 August 2009, Dirk Behme wrote:
> >> Is anything like
> >>
> >> if(omap3) {
> >> /*
> >> * Add a bunch of clocks after TLR entry to force SWD reset (newer
> >> * ARM cores; just in case, ~50 cycles), switch on ICEpick power
> >> * domains (for some TI part
On Thursday 03 September 2009, Magnus Lundin wrote:
> For the Omap353x we set the DSCR[DSCR_HALT_DBG_MODE] bit in the setup
> script, and we then assume that the running application does not
> actively play with the debug settings.
> This can of course be discussed.
Cortex M3 does similar stuff
Matt Hsu wrote:
> Hi all,
>
> This series patches fix the hardware single-step logic mainly.
> With these patches, you can do the step operation on the telnet session.
> Also, the programming breakpoints works as well.
> Cheers,
> Matt
> -
Re #1 and #3: I'd combine the "add #defines" and "use #defines"
into one patch myself... minor point.
Re #2:
On Thursday 03 September 2009, Matt Hsu wrote:
> --- a/src/target/cortex_a8.c
> +++ b/src/target/cortex_a8.c
> @@ -430,6 +430,13 @@ int cortex_a8_halt(target_t *target)
> retval
Matt Hsu wrote:
> Hi all,
>
> This series patches fix the hardware single-step logic mainly.
> With these patches, you can do the step operation on the telnet session.
Applying this patch series to r2663, what I can say from output of
program counter (pc) this seems to work. So:
Tested-by: Dirk
On Thu, Sep 3, 2009 at 3:58 PM, Matt Hsu wrote:
> Hi all,
>
> This series patches fix the hardware single-step logic mainly.
> With these patches, you can do the step operation on the telnet session.
> Also, the programming breakpoints works as well.
> Cheers,
> Matt
Great!
I haven't looked them
Hi all,
This series patches fix the hardware single-step logic mainly.
With these patches, you can do the step operation on the telnet session.
Also, the programming breakpoints works as well.
Cheers,
Matt
>From 8fc6c1839b80447e06c368b0d8948f5feda3e474 Mon Sep 17 00:00:00 2001
From: Matt Hsu
David Brownell wrote:
>> Committed less "init + reset init" which does not belong
>> in target configuration script.
>
> I think the reset-init handler likely belongs in a board
> init script too ... :)
>
> Specifics of DDR and clock setup vary between boards.
> Also, having the "reset init" scri
Committed.
Thanks!
--
Øyvind Harboe
Embedded software and hardware consulting services
http://www.zylin.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Why is soft_reset_halt being used in the LPC init sequences?
I've tested LPC2478 and the reset init sequence seems flaky
When I modify the reset init sequence to use "armv4_5 core_state arm"
and things seems *much* more stable, e.g. I can erase/program flash
without getting spurious error
32 matches
Mail list logo
