Short answer: I don't know.
I thought I could safely remove the "old" driver after
nobody complained about the "new" driver since it
had months of testing.
Obviously that wasn't correct, but I'll have to look into this
more next week.
--
Øyvind Harboe
Embedded software and hardware consultin
Hello Øyvind,
you have changed the name from the new driver, here
you have removed the "_new"?
In this case the cfg files with the old driver name will
work with the new driver. But the new driver had other
parametes, could it be?
Have you change the cfg files too?
I found the following info in
On Sat, May 16, 2009 at 4:49 PM, Dean Glazeski wrote:
> Hey all,
>
> Just tried to connect up with my AT91SAM7 dev board from Atmel using the
> default target config for the controller (target/sam7x256.cfg) but it
> the flash driver is not available (at91sam7). It appears the name has
> been chan
Hey all,
Just tried to connect up with my AT91SAM7 dev board from Atmel using the
default target config for the controller (target/sam7x256.cfg) but it
the flash driver is not available (at91sam7). It appears the name has
been changed to at91sam7_new in src/flash/at91sam7.c. Should this line
> Great approach & good work!
>
> Committed.
>
> Once testing results are in and all quirks are weeded out the
> old driver will be retired.
>
I have reformated/commited this patch to replace any lf's with tabs.
Cheers
Spen
___
Openocd-development
On Fri, Sep 26, 2008 at 7:45 PM, Gheorghe Guran <[EMAIL PROTECTED]> wrote:
> Hi,
>
> New patch is finalized. Everything it's in attachment.
> To make the switch to the new driver more simple, I have updated
> and renamed the old driver, but keeping the same command name.
>
> The new driver can be u
> Are you doing some special pre-processing before passing it to TCL so that
> openocd-specific commands don't need the semicolon (to maintain backward
> compatibility?)
Essentially. Though *after* I get it back from Tcl and before I pass it to the
openocd commands, I strip all args after the arg
>
> > My old command-line from r717:
> >
> > ./openocd -f interface/olimex-arm-usb-ocd.cfg -f target/sam7x256.cfg -c
> init
> > -c reset
> >
> > This quits. If I leave off the "-c reset", the program stays alive and I
> can
> > telnet to it. This is different than how r717 behaved. I'm not sure why
> I would have kept the sam7s config files since all variants can use this
> base configuration.
>
On secong thought, I would rename it just sam7 or at91sam7 because all of
the following can share the same config file:
at91sam7S
at91sam7SE
at91sam7X
at91sam7XC
at91sam7A
at91sam7L
The flash look
I noticed you are using the AT91SAM7 -
You might want to check out some of the things I wrote for the SAM7 also.
https://lists.berlios.de/pipermail/openocd-development/2008-July/002378.html
try this from GDB [from the above email]
Step 1:
(gdb) mon source [find tcl/chip/atmel/at91/at91sam
Jason Gallicchio wrote: [lots of comments about tcl ish things]
First, remember this: OpenOCD uses JIM TCL - which is not "Main Stream
Tcl/Tk".
JimTCL can be embedded in a "rom" target - something main stream Tcl/TK
cannot do.
This 'embedded feature' is some what helpful for some users of OpenO
>
> > The sam7x and sam7s configurations are identical except for calling
> > different reset scripts. But the reset scripts are identical except for
> > extra
> > spaces at the end of some lines (violating your style rules.)
>
> I've deleted the sam7s files from subversion.
>
This may have been t
>
> > Comments at the end of lines do not work in telnet, which makes
> > pasting pieces of .cfg files in difficult.
>
> OpenOCD uses TCL now, but I did add support for # comments
> at the end of openocd commands a while back.
>
> Which subversion version are you running?
>
> If you add "; # commen
Answering some of your questions here. Please keep tabs on your problems
and keep sending patches/bringing them up one by one :-)
There was a lot of good feedback in this email, but of course with so
many things in a single posting, there is the danger(certainty actually)
that some things will dr
I'm new to OpenOCD and had it debugging out of RAM beautifully. I've
been getting sporadic errors verifying binary images I write to flash. This
got me interested in OpenOCD and its code. The rest of this email is a
long list of issues I encountered, some of which are probably due to
my own misunde
15 matches
Mail list logo
