[Openocd-development] ETB taps -- imx, s3c, etc

When I was looking at the target.cfg files to strip out bogus "-work-area-virt 0" attributes, I happened to notice strange stuff with ETB support. Example: $ grep -ri b900f0f tcl tcl/target/ti_dm6446.cfg: set _ETB_TAPID 0x2b900f0f tcl/target/ti_dm355.cfg: set _ETB_TAPID 0x2b900f0f tcl/target/

Re: [Openocd-development] 0.3.0 fatal bug

On Saturday 07 November 2009, Zach Welch wrote: > On Sat, 2009-11-07 at 08:36 -0700, David Brownell wrote: > > On Saturday 07 November 2009, Freddie Chopin wrote: > > > David Brownell pisze: > > > > Snapshots are *NOT* releases. Don't do that. Grab release > > > > tarballs from the download page

Re: [Openocd-development] 0.3.0 fatal bug

On Sat, 2009-11-07 at 08:36 -0700, David Brownell wrote: > On Saturday 07 November 2009, Freddie Chopin wrote: > > David Brownell pisze: > > > Snapshots are *NOT* releases. Don't do that. Grab release > > > tarballs from the download page. > > > > Oh. Sorry about that then (; > > It does touch

Re: [Openocd-development] fix a bug in vsllink induced in recent update

I just pushed a fix for this. Thanks. On Sat, 2009-11-07 at 17:33 +0800, simon qian wrote: > Attachment is the patch. > > In Improve jtag command argument parsing patch: > @@ -1443,11 +1445,11 > @@ static int vsllink_handle_usb_bulkout_command(struct command_context_s > *cmd_ctx, >

[Openocd-development] Debug feature of SWD is tested OK on STM32

I tested it under IAR EWARM 5.40KS, with GDB Server debug interface. ARMV7_GDB_HACKS is disabled, vsllink bug(mentioned in my another mail) fixed, and default_mmu returns ERROR_OK. When using JTAG, output will be: Open On-Chip Debugger 0.4.0-dev-00096-g5c602f0-dirty (2009-11-08-00:27) $URL$ For bu

Re: [Openocd-development] Bug: Can't flash STM32

On Saturday 07 November 2009, simon qian wrote: > 0.3.0 has a bug in target_alloc_working_area, and fixed in 0.3.1. > But head version has a problem with default_mmu, which will return > ERROR_FAIL, stm32 doesn't implement mmu, so it uses default_mmu, and will > cause target_alloc_working_area retu

Re: [Openocd-development] Bug: Can't flash STM32

simon qian pisze: > Try attached patch. > Turn default_mmu back to original version. This patch fixes the issue with master's head ( [; ) for me (on both chips that I've tried). 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berl

Re: [Openocd-development] Bug: Can't flash STM32

David Brownell pisze: > I'd suspect a bad build. On the other hand, no matter what's > causing the problem, THIS Me too, but I've built that 3 times, from snapshot and directly with git clone... The build is fine. >>> Error: Not implemented. > > is a really *horrible* diagnostic. *WHAT* is no

Re: [Openocd-development] Bug: Can't flash STM32

Try attached patch. Turn default_mmu back to original version. 2009/11/8 David Brownell > On Saturday 07 November 2009, Freddie Chopin wrote: > > But... The current master in main branch still fails the same way... > > This is extremely strange, because I open the target.c file and it HAS > > th

Re: [Openocd-development] Bug: Can't flash STM32

On Saturday 07 November 2009, Freddie Chopin wrote: > But... The current master in main branch still fails the same way... > This is extremely strange, because I open the target.c file and it HAS > the fix ( (!enabled) ), but still doesn't work... I'd suspect a bad build. On the other hand, no m

Re: [Openocd-development] 0.3.0 fatal bug

On Sat, 7 Nov 2009, David Brownell wrote: > The other is that we really don't have a team of folk set up > to build for different Linux distros, BSDs, MacOS, Windows, etc; > and IMO, we shouldn't. There *are* teams of folk set up to > build for those ... e.g. the Fedora project builds regularly,

Re: [Openocd-development] Bug: Can't flash STM32

0.3.0 has a bug in target_alloc_working_area, and fixed in 0.3.1. But head version has a problem with default_mmu, which will return ERROR_FAIL, stm32 doesn't implement mmu, so it uses default_mmu, and will cause target_alloc_working_area return ERROR_FAIL. 2009/11/7 Freddie Chopin > I've just ch

Re: [Openocd-development] 0.3.0 fatal bug

On Saturday 07 November 2009, Freddie Chopin wrote: > > Finally, the OpenOCD project will no longer distribute binary packages or > > installers. > > http://openocd.berlios.de/web/?p=80 > > I don't think that's a good decision, but I'm not in charge here.think ... There are actually two issues

Re: [Openocd-development] 0.3.0 fatal bug

On Saturday 07 November 2009, Thomas Kindler wrote: > If more people had tried the RCs, the problem might have shown up before > the release. No; the real issue here was slipping a very bad patch in, late in the RC cycle ... *AND* then not extending the test cycle enough to catch it. Either with

Re: [Openocd-development] 0.3.0 fatal bug

On Saturday 07 November 2009, Freddie Chopin wrote: > David Brownell pisze: > > Snapshots are *NOT* releases. Don't do that. Grab release > > tarballs from the download page. > > Oh. Sorry about that then (; It does touch on a release process issue, though. We're still going about creating ve

Re: [Openocd-development] openocd-0.3.0-rc0 bug: Fail to write to Intel NOR Flash on AT91SAM9260

On Monday 02 November 2009, Øyvind Harboe wrote: > While the attached patch tightens things up, I don't think we've > solved it just yet... Looking more closely, this patch intoduced *TWO* bugs: - The one causing the big regression, swapping physical and virtual addresses for the work area:

Re: [Openocd-development] 0.3.0 fatal bug

Dean Glazeski pisze: > I believe there was a discussion about having an installer for Windows > but there was some license issues that came up with distributing ftd2xx > and for some reason libftdi-win32 wasn't a good alternative. Well, you remeber the reason why the 0.1.0 installer was taken do

Re: [Openocd-development] 0.3.0 fatal bug

> > Someone someday decided that there will be no "builds" on the website. > There is no info about the location of the builds neither... If you > don't want to publish the binaries, maybe a small "builds" section with > links to builds? > I believe there was a discussion about having an installer

Re: [Openocd-development] 0.3.0 fatal bug

David Brownell pisze: > Snapshots are *NOT* releases. Don't do that. Grab release > tarballs from the download page. Oh. Sorry about that then (; 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.d

Re: [Openocd-development] Bug: Can't flash STM32

I've just checked the 0.3.1-dev branch and I confirm that it works for me - I can flash STM32 and LPC2103 normally. I've tried this: http://openocd.git.sourceforge.net/git/gitweb.cgi?p=openocd/openocd;a=commit;h=c6ac97cf3b95ad5a9582ad6e6ea159d9d2aa9e1b But... The current master in main branch sti

Re: [Openocd-development] 0.3.0 fatal bug

On Saturday 07 November 2009, Freddie Chopin wrote: > David Brownell pisze: > > Odd. I did a dry run using the .bz2 archive and did not > > need to do that. I'll double check before v0.3.1 comes > > out ... presumably you used the .zip archive? > > Yes - when I click on "snapshot" in the web rep

[Openocd-development] fix a bug in vsllink induced in recent update

Attachment is the patch. In Improve jtag command argument parsing patch: @@ -1443,11 +1445,11

Re: [Openocd-development] 0.3.0 fatal bug

Thomas Kindler pisze: > The problem is especially important on Windows, where building it is a > real PITA. OpenOCD is a direct competitor to lots of the commercial JTAG > tool chains there, and if you want to convince anyone to switch, you > just have to have an install.exe right on the officia

Re: [Openocd-development] 0.3.0 fatal bug

David Brownell pisze: > Odd. I did a dry run using the .bz2 archive and did not > need to do that. I'll double check before v0.3.1 comes > out ... presumably you used the .zip archive? Yes - when I click on "snapshot" in the web repository on SF.net I get a zip file with contents that were not

Re: [Openocd-development] 0.3.0 fatal bug

Freddie Chopin schrieb: > Is anyone actually checking the patches you push? Is anyone checking the > binary produced by the patches? Shouldn't there be a rc(x+1) after some > pathes were made to rc(x)? The 0.3.0 release is seriously broken and I > hope you will produce a bugfix release very soon