Re: [Openocd-development] [PATCH 1/2] add " cortex m3 reset config= = = ..." to stm32.cfg
"David Brownell" napisał(a): > I think Freddie's comment (that it does have > something to do with it) made confusion, then. Which comment? > That would be explained by my trusting Freddie's > comment to be accurate, i while it was instead > ncorrect at the levels I was commenting on. ? 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] remove srst pulls trst from LPC2xxx t= arget scripts
"David Brownell" napisał(a): > Which ones are useless? Which are wrong? And > for the latter , why haven't we seen specific bug reports, followed by > trivial patches? C'mon - we both know that everyone thinks srst_pulls_trst is mandatory for LPC parts and my findings https://lists.berlios.de/pipermail/openocd-development/2010-December/017405.html as well as Peter Stuge's findings http://openocd.git.sourceforge.net/git/gitweb.cgi?p=openocd/openocd;a=commit;h=8772355bbd507f4cd191d589d7ab5060b97c1818 show that it's not true. Of course LPCs work with srst_pulls_trst - they will probably work with many (all?) combinations of reset_config, but these configs should show the best possible configuration, not something that barely works. Generally see my previous post about reasons to remove this option. > The first sane example of that option which I > ever herd was for some LPC chip where it was > described as a silicon work-around (and thus it > made sense to be in a target file). I've browsed through erratas for LPC2103, LPC2148 and LPC2478 - no mention about such limitation. > I think everyone agrees that when board wiring > calls for that option, it belongs in a board > config file rather than elsewhere. As I've said on Saturday - I've just removed srst_pulls_trst - nothing else. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] remove srst pulls trst from LPC2xxx t= arget scripts
"Rolf Meeser" napisał(a): > On 12/05/2010 11:00 PM, Freddie Chopin wrote: > > So how about this idea of removing useless and wrong occurences of > > srst_pulls_trst from lpc config files? > > > Are you sure this is correct? > > Copy protection of LPC controllers relies on the fact that it is not > possible to halt the processor right after reset. > If your findings were correct, you would have discovered an easy way to > circumvent NXP's security mechanism. Well, I cannot check all LPCs, because at the moment I only have LPC2103, but this small experiment seems to show that srst_pulls_trst is not necessary https://lists.berlios.de/pipermail/openocd-development/2010-December/017405.html Actually this was suggested by Peter Stuge in August http://openocd.git.sourceforge.net/git/gitweb.cgi?p=openocd/openocd;a=commit;h=8772355bbd507f4cd191d589d7ab5060b97c1818 Not having srst_pulls_trst is very convenient, as sometimes this code that could run for a brief moment before halt could make things like disable JTAG, start PLL with wrong values, etc. Generally without that option debugging LPCs is much more reliable. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] remove srst_pulls_trst from LPC2xxx target scripts
On Mon, Dec 6, 2010 at 12:35 AM, Rolf Meeser wrote: > On 12/05/2010 11:00 PM, Freddie Chopin wrote: >> So how about this idea of removing useless and wrong occurences of >> srst_pulls_trst from lpc config files? > > If your findings were correct, you would have discovered an easy way to > circumvent NXP's security mechanism. Here in Poland, 2010 is the Chopin's year hahah! They knew the right person to select! Congratulations Freddie! :D -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] remove srst_pulls_trst from LPC2xxx target scripts
--- On Sun, 12/5/10, Freddie Chopin wrote: > So how about this idea of removing > useless and wrong occurences of srst_pulls_trst from lpc config files? Which ones are useless? Which are wrong? And for the latter , why haven't we seen specific bug reports, followed by trivial patches? The first sane example of that option which I ever herd was for some LPC chip where it was described as a silicon work-around (and thus it made sense to be in a target file). I think everyone agrees that when board wiring calls for that option, it belongs in a board config file rather than elsewhere. - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] jimtcl build on freebsd
On Sun, Dec 5, 2010 at 10:38 PM, Steve Bennett wrote: > tclsh is used during building. jimsh isn't used because of the > chicken-and-egg problem. > > Actually, in the normal case it isn't even needed. You could > replace 'tclsh' with 'echo' as a workaround if you don't want to > install Tcl. > > In any case, I've pushed a fix to the Jim Tcl git repository. Thank you Steve! I have replaced the "tclsh" with "cat" in the Makefile and it worked! The git seems not to propagate yet, but the "cat fix" seems to be good solution because it drops unnecessary dependecies and is working fine :-) Greetz 6.66V! -- 0110001101100100 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] remove srst_pulls_trst from LPC2xxx target scripts
On 12/05/2010 11:00 PM, Freddie Chopin wrote: So how about this idea of removing useless and wrong occurences of srst_pulls_trst from lpc config files? Are you sure this is correct? Copy protection of LPC controllers relies on the fact that it is not possible to halt the processor right after reset. If your findings were correct, you would have discovered an easy way to circumvent NXP's security mechanism. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] remove srst_pulls_trst from LPC2xxx target scripts
So how about this idea of removing useless and wrong occurences of srst_pulls_trst from lpc config files? 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] jimtcl build on freebsd
On 05/12/2010, at 11:36 PM, 1 0 wrote: > Hello, > > I gotta problem with building GIT version of OpenOCD on my FreeBSD box > - there is some error with JimTcl and tclsh (should come from > jimtcl?): > > tclsh .././jimtcl/parse-unidata.tcl .././jimtcl/UnicodeData.txt >> unicode_mapping.c > tclsh: not found > > Here is the full build output: http://pastebin.com/cN1rPNcp > > # whereis tclsh > tclsh: > > Please advise, tclsh is used during building. jimsh isn't used because of the chicken-and-egg problem. Actually, in the normal case it isn't even needed. You could replace 'tclsh' with 'echo' as a workaround if you don't want to install Tcl. In any case, I've pushed a fix to the Jim Tcl git repository. Cheers, Steve > > -- > 0110001101100100 > ___ > Openocd-development mailing list > Openocd-development@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/openocd-development > -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: 0434 921 300 E: ste...@workware.net.au F: 07 3102 9221 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Getting rid of default jtag clock rate
> > --- On Sun, 12/5/10, Øyvind Harboe > wrote: > > > >> Does anyone have any objections to > >> getting rid of the > >> concept of a default JTAG clock rate? > > > > NO. But let's see a proposed patch ... :) > > Could you clarify a bit what you are against? I'll know it if I see it. :) My comment is mostly about being cautious and complete. ISTR seeing defaults get snuck in by several channels (not just drivers). Catching all the side channels may be tricky, but leaving a few could make other changes error-prone... > > A script which has no opinions or references to > a JTAG clock is broken and needs user action? That's a good start; we'd need to fix such scripts (if they're in our GIT tree) before changing current behavior. Also, at which point does the runtime code check to see if a rate was set? best would be a "late" check, shortly before e.g. a JTAG operation needs to rely on a clock rate. An *early* test would inadvisable; e.g. potentially preventing prep or setup that didn't need to use the debug bus. - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Getting rid of default jtag clock rate
More generally, if there is something that user must specify that he hasn't and the script is working by chance, then it would be great if we could robustly detect this situation and require the user to specify that option. -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 63 25 00 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Getting rid of default jtag clock rate
On Sun, Dec 5, 2010 at 5:43 PM, David Brownell wrote: > > > --- On Sun, 12/5/10, Øyvind Harboe wrote: > >> Does anyone have any objections to >> getting rid of the >> concept of a default JTAG clock rate? > > NO. But let's see a proposed patch ... :) Could you clarify a bit what you are against? A script which has no opinions or references to a JTAG clock is broken and needs user action? -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 63 25 00 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Getting rid of default jtag clock rate
--- On Sun, 12/5/10, Øyvind Harboe wrote: > Does anyone have any objections to > getting rid of the > concept of a default JTAG clock rate? NO. But let's see a proposed patch ... :) I recall some discussions a while back about how JTAGKEY2 was broken because its driver was embedding a default clock rate assumption, which broke on some hardware. There have also been related parport issues. > > Basically, I'd like OpenOCD to refuse to start until the script defines the > clock rate. Script is the right place, yes. Not *ANY* of the adapter drivers, or embedded in OpenOCD framework code either. > The actual mechanism needs a bit of thought, because it > is possible to set jtag clock rate in reset-start and in > my > book that counts as not using the default clock rate. Right. Reset sequences may need to re-clock, and that's a key hook. Changing SoC clocks tendds to imply a need to update debug adapter clocks (be they JTAG or something else). Fancy reset sequences may end up initializing PLLs and so forth. Fixed clocks are going to break. - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Getting rid of default jtag clock rate
On 12/05/2010 01:45 PM, Øyvind Harboe wrote: > Does anyone have any objections to getting rid of the > concept of a default JTAG clock rate? > > Basically, I'd like OpenOCD to refuse to start until the > script defines the clock rate. Sounds good to me. cu Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] (patch) Change target script for LPC2478
On 2010-12-05 14:46, Øyvind Harboe wrote: Try with the currently committed stuff: openocd -c "set CCLK 12345; source [find target/lpc2478.cfg]" Well, it works, but I can't say that it's convenient to run OpenOCD this way, when one "global CCLK" makes it easier. I prefer to do it "the normal way" openocd -c "set CCLK 12345" -f target/lpc2478.cfg 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] (patch) Change target script for LPC2478
Try with the currently committed stuff: openocd -c "set CCLK 12345; source [find target/lpc2478.cfg]" -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 63 25 00 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] jimtcl build on freebsd
Hello, I gotta problem with building GIT version of OpenOCD on my FreeBSD box - there is some error with JimTcl and tclsh (should come from jimtcl?): tclsh .././jimtcl/parse-unidata.tcl .././jimtcl/UnicodeData.txt >unicode_mapping.c tclsh: not found Here is the full build output: http://pastebin.com/cN1rPNcp # whereis tclsh tclsh: Please advise, -- 0110001101100100 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] (patch) Change target script for LPC2478
OK, now I have something that will probably reunite us all.
This patch allows OpenOCD to be run with this target script but define
CCLK via command line:
openocd -c "set CCLK 12345" -f target/lpc2478.cfg
It has only one downside, as I've noticed that OpenOCD prints the
value... The more funny thing:
openocd -c "set X 100; set Y 12345; set Z 0x" -c "set A 1; set B 2; set C 3"
Open On-Chip Debugger 0.5.0-dev (2010-06-13-00:09)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.berlios.de/doc/doxygen/bugs.html
0x
3
Error: Debug Adapter has to be specified, see "interface" command
Command handler execution failed
...
So, as you see, the last value from each "-c" is printed. I don't know
why. Adding semicolon at the end changes nothing.
This way, when in script usage of this value is preceded with "global
VAR_NAME" it can be used this way. That's the only change I've made to
the original patch.
4\/3!!
From bdf7b41321ef512d38be2d060ea20f0585534295 Mon Sep 17 00:00:00 2001
From: Rolf Meeser
Date: Fri, 3 Dec 2010 14:10:40 +0100
Subject: [PATCH] lpc2478 target config: CCLK as (mandatory) parameter
Differences to original patch: CCLK is "imported" to script, so it works when
CCLK is supplied via command line (openocd -c "set CCLK 12345" -f
target/lpc2478.cfg)
Originally by: Rolf Meeser
Signed-off-by: Freddie Chopin
---
tcl/target/lpc2478.cfg | 15 ++-
1 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/tcl/target/lpc2478.cfg b/tcl/target/lpc2478.cfg
index 99c8ce9..3e02fbe 100644
--- a/tcl/target/lpc2478.cfg
+++ b/tcl/target/lpc2478.cfg
@@ -12,6 +12,15 @@ if { [info exists CPUTAPID ] } {
set _CPUTAPID 0x4f1f0f0f
}
+#import CCLK if supplied via commandline
+global CCLK
+
+if { [info exists CCLK ] } {
+ set _CCLK $CCLK
+} else {
+error "You must specify the CCLK that will be used for flash programming!"
+}
+
#delays on reset lines
adapter_nsrst_delay 100
jtag_ntrst_delay 100
@@ -34,10 +43,6 @@ $_TARGETNAME configure -event reset-init {
}
# LPC2378 has 512kB of FLASH, but upper 8kB are occupied by bootloader.
-# After reset the chip uses its internal 4MHz RC oscillator.
# flash bank lpc2000 0 0
[calc checksum]
set _FLASHNAME $_CHIPNAME.flash
-flash bank $_FLASHNAME lpc2000 0x0 0x7D000 0 0 $_TARGETNAME lpc2000_v2 4000
calc_checksum
-
-# Try to use RCLK, if RCLK is not available use "normal" mode. 4MHz / 6 =
666kHz, so use 500.
-jtag_rclk 500
+flash bank $_FLASHNAME lpc2000 0x0 0x7E000 0 0 $_TARGETNAME lpc2000_v2 $_CCLK
calc_checksum
--
1.6.5.1.1367.gcd48
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Getting rid of default jtag clock rate
Does anyone have any objections to getting rid of the concept of a default JTAG clock rate? Basically, I'd like OpenOCD to refuse to start until the script defines the clock rate. The actual mechanism needs a bit of though, because it is possible to set jtag clock rate in reset-start and in my book that counts as not using the default clock rate. -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 63 25 00 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Programming external flash with OpenOCD fails
On Sun, Dec 5, 2010 at 6:42 PM, Starkeeper wrote: > Just to let you know, I still have the problem, that I can not program the > external flash ;) > > I am wondering that most of the other non cfi flash drivers require the > correct clock rate as parameter. How does the cfi driver computes the > timings without knowledge of the current clock? As far as I know, CFI driver issues commands to flash and waits the flash itself replies that the command is completed. There isn't any clock nor specific time tick. Only concept of time is for timeout; if flash does not reply after a specific timeout, the operation is aborted. Best Regards Antonio ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] (patch) Change target script for LPC2478
Merged. I like the concept of mandatory instead of default values for target scripts. A default value that works everywhere is great, but it doesn't exist for this LPC chip. I've actually been thinking about modifying OpenOCD to complain if a board + target script does not define a JTAG clock frequency. There is no "default clock frequency" for JTAG/OpenOCD. That's another topic that I have been loathe to get into though. To use a default clock rate that works some of the time, can *really* suck up time. What's worse(so I've heard), it can even cause a flash programming + verify to succeed and then the flash to fail later. I have not read 100 pages of discussion here. I did notice Freddie's patch that had default values. I'd rather have the system fail with an error message early on, than to lead me onto wild goose chases. If someone was in any doubt: robust and fast programming(in that order) is a design goal for OpenOCD. Someone has to decide how to move forward on this one, otherwise the situation deteriorates to 100's of posts and no patch in sight. Let's see how things work out when that someone is you ;-) I very much appreciate the effort that you put into answering all the questions that came up to this patch. -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 63 25 00 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] SVF chain handling patch
> I'm happy with the previous set of patches I submitted (nov 30), > it's been working well for me for the past couple of weeks > with no issues. I had to make some fixes to make it compile. Could you read over the patch now and write up a commit comment? To create a patch, try: git add . git commit --author="Andrew Leech " => type commit comment git format-patch HEAD^ -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 63 25 00 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer From 708c04f66d957cd32c226ce291dc61b35685de60 Mon Sep 17 00:00:00 2001 From: Andrew Leech Date: Tue, 30 Nov 2010 10:13:38 +1100 Subject: [PATCH] SVF Chain Handling (was: lpc3131 and Actel FPGA chain programming) On Wed, Nov 24, 2010 at 12:10 AM, Wookey wrote: > +++ Andrew Leech [2010-11-17 14:02 +1100]: >> >> Yep I rewrote the command line parser, so the usage is now: >> "usage: svf [-tap device.tap] [-quiet] " >> >> Arguments are checked in a loop so it will accept switches and >> in any order. quiet or -quiet are both recognised. And of course, -tap >> is optional. As such it is now back compatible, much nicer and more >> flexible. There's also a help switch that simply prints usage in case >> anyone tries it. > > As someone who has previously used svf and xsvf functionality with > chained devices I'd like to add another 'yes please this is great' > vote, and thank andrew for his work (I'm glad someone understands > this stuff :-) > > Oddly I have previously found that xsvf files would work even when > they were generated single but used in a chain (or maybe it was the > other way round). I was quite suprised about this and assumed that > openocd was already doing something clever equivalent to the > functionality this patch provides. But obviously that was just dumb > luck. > > And yes the above syntax is the right way tto do this. Breaking > existing scripts is something we should work hard to avoid as it can > make openocd updates in production environments very awkward.. > > Wookey Yeah I'm much happier allowing previous syntax to work fine without modification. I haven't looked at the xsvf module at all, while it would be neater to bring it in line with this one, or even roll both of them rolled together, I don't have any xilinx parts or software so haven't had any call to use it. The xsvf parser or format may very well have chain functionality built into it, I'm not sure. Well I've made a whole heap more updates, and eventually realised I should be splitting them up into separate patches, as many of them are (or should be) somewhat independent. That was a bit of a hassle, but it's neater this way as well as being openocd policy from what I've read. svf_chain_cmd_parser.patch : Main patch, chain tap handling and updated command parser, mostly the same as earlier submitted patch. svf_file_handling.patch: converts file handling from open to fopen etc. Also input files are read as whole lines before parsing. Debatable whether this is neater code, but it does result in 10% speed improvement for me, and should be more portable. svf_progress_indicator.patch: Adds progress indicator (xx% readout) when (-)progress flag added to command line. this works in both quiet and non-quiet modes. This patch is dependent on svf_file_handling.patch being previously applied. svf_time_output_format.patch: time taken readout at end of svf operation converted from direct ms output to minutes-seconds-ms output for better readability. I've used this newer version to program my a3p125 and a3p060 parts on identical chains with lpc3131 multiple times with different flags and haven't had any problems. One significant finding is the time difference when non-quiet (default) mode is used, particularly on windows the verbose output slows the overall operation down a _lot_. I'm talking 1mins 19sec for quiet compared to 6mins 40sec on verbose. The time difference on linux was much much less severe but I haven't tested it with the full length file, but but on a much shorter test file it was a difference of 8 seconds to 14 seconds. The programming works fine either way, just printing the lines takes some time. This slow file is ~290,000 lines of svf, so not surprising that it takes some time to print all this to console. Andrew --- src/svf/svf.c | 369 + 1 files changed, 291 insertions(+), 78 deletions(-) diff --git a/src/svf/svf.c b/src/svf/svf.c index 62e2324..054413a 100644 --- a/src/svf/svf.c +++ b/src/svf/svf.c @@ -206,21 +206,33 @@ struct svf_check_tdo_para static struct svf_check_tdo_para *svf_check_tdo_para = NULL; static int svf_check_tdo_para_index = 0; -static int svf_read_command_from_file(int fd); +static int svf_read_command_from_file(FILE * fd); static int svf_check_tdo(void); static int svf_add_check_para(uint8_t enabled, int buffer_offset, int bit_len);
Re: [Openocd-development] Marvell Armada Support
Paul Richards writes:
> Are there any plans to add support for the Marvell Armada processor
> family to Open OCD? (A hybrid of Feroceon and XScale processors from
> what I understand).
>
> I've had a little success customising scripts to communicate with an
> Armada PXA168 target via a FT4232 interface, though I believe code
> additions will be required. Although new to OpenOCD I'm willing to
> contribute what I can if no similar activities are already underway.
Base operations are already possible by
---
jtag newtap $_CHIPNAME aux -irlen 1 -ircapture 0x1 -irmask 0x01 -disable
jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 0x1 -irmask 0x0f -disable
jtag newtap $_CHIPNAME bs -irlen 9 -ircapture 0x1 -irmask 0x1ff -expected-id
$_CPUTAPID
set _TARGETNAME $_CHIPNAME.cpu
jtag configure $_CHIPNAME.aux -event tap-enable {}
jtag configure $_CHIPNAME.cpu -event tap-disable "
irscan $_CHIPNAME.bs 0x98
drscan $_CHIPNAME.bs 16 0x00
jtag tapdisable $_CHIPNAME.aux
"
jtag configure $_CHIPNAME.cpu -event tap-enable "
jtag tapenable $_CHIPNAME.aux
irscan $_CHIPNAME.bs 0x98
drscan $_CHIPNAME.bs 16 0x0a
"
jtag configure $_CHIPNAME.bs -event setup "
jtag tapenable $_CHIPNAME.cpu
"
target create $_TARGETNAME dragonite -endian $_ENDIAN -chain-position
$_TARGETNAME
---
see [1] for full configuration. The trick is the first dummy TAP which
is mentioned in some errata entry (an extra TDO is shifted in concatening
mode).
I wrote a NAND driver for the PXA168 (see [2]; PXA320 should be very
similar btw) but it is very slow and although I intended to keep it as
general as possible, I ended with hardcoding certain values of the used
NAND chip. Bad block management is missing too.
Enrico
Footnotes:
[1] http://www.cvg.de/people/ensc/trizeps6.conf
[2] https://github.com/ensc/openocd/commits/master
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Programming external flash with OpenOCD fails
Just to let you know, I still have the problem, that I can not program the external flash ;) I am wondering that most of the other non cfi flash drivers require the correct clock rate as parameter. How does the cfi driver computes the timings without knowledge of the current clock? -Ursprüngliche Nachricht- Von: openocd-development-boun...@lists.berlios.de [mailto:openocd-development-boun...@lists.berlios.de] Im Auftrag von Michael Schwingen Gesendet: Donnerstag, 2. Dezember 2010 00:20 An: openocd-development@lists.berlios.de Betreff: Re: [Openocd-development] Programming external flash with OpenOCD fails On 11/30/2010 08:36 PM, Starkeeper wrote: > Indeed it works without the wokring area! OK. That means at least the flash is working, and the bus setup is probably also OK. OpenOCD tried to download code + data to RAM on the target, and something in that process goes wrong. I don't know the LPC internals, so I can't check if the memory setup really enables working RAM at 0x4000. cu Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] (patch) Change target script for LPC2478
Oh - another solution is creating a board file that defines all that is necessary. Such board file could also define some default values of reset_config, adapter_khz etc. I'm starting to like that idea (; The only problem is the amount of new files that would be created this way... 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] (patch) Change target script for LPC2478
On 2010-12-05 10:13, Andrew Leech wrote: On 05/12/2010, at 7:49 PM, Freddie Chopin wrote: On 2010-12-04 19:29, Michael Schwingen wrote: Just because the current files are hard-wired in a way that suits you does not mean they work fine for everyone. Have you considered opposite approach? Just because the need of creating another file suits you does not mean this is fine for everyone. Just to throw in a suggestion, would it simply be better to have a hardwired default that can be overridden in the config file? For me that solves the issue discussed in this thread - I've even created a modification of this patch that has a default value: https://lists.berlios.de/pipermail/openocd-development/2010-December/017408.html 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] (patch) Change target script for LPC2478
On 05/12/2010, at 7:49 PM, Freddie Chopin wrote: > On 2010-12-04 19:29, Michael Schwingen wrote: >> Just because the current files are hard-wired in a way that suits you >> does not mean they work fine for everyone. > > Have you considered opposite approach? Just because the need of creating > another file suits you does not mean this is fine for everyone. > Just to throw in a suggestion, would it simply be better to have a hardwired default that can be overridden in the config file? Andrew ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] (patch) Change target script for LPC2478
On 2010-12-04 19:29, Michael Schwingen wrote: Just because the current files are hard-wired in a way that suits you does not mean they work fine for everyone. Have you considered opposite approach? Just because the need of creating another file suits you does not mean this is fine for everyone. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
