Re: [Openocd-development] Gerrit mail subject
openocd-development-boun...@lists.berlios.de wrote: Mathias K. wrote: can you remove the magic incomplete number too? In this case the 1533d9d. This number is useless in the subject: I disagree. This is an abbreviated commit hash, which identifies the commit that was pushed. There's also Gerrit's identifiers, but losing the commit hash would be impractical. Having the abbreviated hash in the email makes sense, but at the start of the subject is just noise and a waste of space, IMO. I like the [REVIEW] idea, and don't see any need for openocd to be a string in the subject at all. There are headers for sorting and the To: and From: make it pretty clear what project the patch is for. So [Openocd-development] New openocd patch: hash123 subsys: desc I would reduce to [REVIEW] subsys: desc Much faster to get what I need for an eyeball scan, which is what I use Subject: for. -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Gerrit mail subject
openocd-development-boun...@lists.berlios.de wrote: is there any chance to reduce the gerrit subject line to a normal length with more information at the beginning? Currently the subject consist of 50% static text at the beginning. [Openocd-development] New patch to review for openocd: XXX bugfixes: I agree. maybe one or two characters of the commit-id are all I see before the subject gets chopped off on my display. In fact I would get rid of [Openocd-development] too. There are headers for sorting mail, other mailing lists I use don't have this, and are more usable for that IMO. -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Unused variables
openocd-development-boun...@lists.berlios.de wrote: Jon Povey wrote: this additional barrier to contributing does put me and others off contributing in future. Using Git is also a barrier for some, perhaps even for many. Gerrit is new, so sure there will be resistance. Maybe sometime it will be just as common as Git itself. I think the learning curve for Git is much steeper than for Gerrit. For sure. But I've had to learn git already for other reasons :) Please look at the updated HACKING file, or my previous email, for an overview of the quick and simple steps to use Gerrit: You need an OpenID from somewhere (let me know if you want one from me) You need to register on a web page and pick a username You need to set an HTTP password or upload a public SSH key The above takes not two minutes. A bit of a simplification, you also need to do the git-side setup, and have the general slowdown of fumbling around a bit until you get the idea of the new workflow. But not a huge amount of work, I agree. An interesting fact is that in the project where I've seen Gerrit introduced there were several new contributors sending commits, who had previously never been seen on the mailing list. I was surprised, but in a good way! There will be new contributors coming along to projects all the time, of course.. Though I suppose maybe the gerrit way of doing things could be preferable to some as it involves less human interaction and discussion on mailing lists, maybe for people who are wary of getting flamed for incorrect email setup (or signatures - sorry!) or who are not confident in their English. Great if gerrit works well for OpenOCD, I hope it does. I just wanted to make the point that it does involve some extra hassle to get started contributing, and that extra barrier and possible negative effects did not seem to have been mentioned. Most of the discussion seemed to be maintainers or energetic contributors enthusing about how jazzy gerrit was going to be. -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Unused variables
Øyvind Harboe wrote: If you want to spend the time taking other people's patches and pushing them to Gerrit so they don't have to, go right ahead. Obviously not if I am not in a hurry to take the time to setup for gerrit even for myself. Don't think the sarcasm was helpful there. We're starting to gather data that we're getting *more* and *better* patches submitted to the Git repository. We also see that the less active maintainers are now reviewing and submitting to the repository. That's great if it ends up being a good thing for the project when hindsight becomes available. I hope it does. -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] clang static analyzer
openocd-development-boun...@lists.berlios.de wrote: Cool! I agree, it looks cool. I'd like to see patches having to pass clang static analyzer unscathed before they're ready for review :-) I had a quick look at that output, interesting. Some looked like real bugs, but others it seems clang was getting it wrong.. like if (ptr == NULL) checks which it thought failed, but then it complained about a null ptr dereference. It seemed to get if (!ptr) right though, which I think is preferred linux kernel style. -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Trouble enabling TAPs on DM365
Using OpenOCD on TI DM365, something goes wrong when trying to enable extra TAPs using the JRC; it claims they are enabled, but has trouble getting the version of the EmbeddedICE, and the halt command times out and doesn't work. If I set the EMU0/1 pins so that the extra TAPs are always routed in, then things work OK. I have previously used OpenOCD with DM355, the predecessor SoC, which had the same TAP enable by JRC scheme (which works fine). Any clues on this? I think David Brownell would have been the guy. Good output with TAPs fixed as enabled (EMU pins low): Open On-Chip Debugger 0.6.0-dev-00128-g36e3009-dirty (2011-10-19-20:05) ... trst_only separate trst_push_pull CS0 NAND Info : RCLK (adaptive clock speed) not supported - fallback to 1500 kHz Info : JTAG tap: dm365.etb tap/device found: 0x2b900f0f (mfg: 0x787, part: 0xb900, ver: 0x2) Info : JTAG tap: dm365.arm tap/device found: 0x0792602f (mfg: 0x017, part: 0x7926, ver: 0x0) Info : JTAG tap: dm365.jrc tap/device found: 0x0b83e02f (mfg: 0x017, part: 0xb83e, ver: 0x0) Info : Embedded ICE version 6 Info : dm365.arm: hardware has 2 breakpoint/watchpoint units Info : ETM v1.3 halt target state: halted target halted in ARM state due to debug-request, current mode: Supervisor cpsr: 0x80d3 pc: 0xb888 MMU: disabled, D-Cache: disabled, I-Cache: disabled --- Bad output with EMU pins high (default) Open On-Chip Debugger 0.6.0-dev-00128-g36e3009-dirty (2011-10-19-20:05) ... trst_only separate trst_push_pull CS0 NAND Info : RCLK (adaptive clock speed) not supported - fallback to 1500 kHz Info : JTAG tap: dm365.jrc tap/device found: 0x0b83e02f (mfg: 0x017, part: 0xb83e, ver: 0x0) Info : JTAG tap: dm365.etb enabled Info : JTAG tap: dm365.arm enabled Info : Embedded ICE version 0 Error: unknown EmbeddedICE version (comms ctrl: 0x) Info : dm365.arm: hardware has 2 breakpoint/watchpoint units Info : ETM v1.0 halt Info : Halt timed out, wake up GDB. Error: timed out while waiting for target halted in procedure 'halt' Holding the EMU pins low is a possibility but means PCB mods to our board, so it would be nice to get this working.. Happy to hack and submit a patch if someone can give me clues to get started. -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Unused variables
openocd-development-boun...@lists.berlios.de wrote: If you don't have time to work on OpenOCD, then I don't have any problems with that. The world is full of smart people who could have, but don't have time to, contribute to OpenOCD. [...] If this means that we loose those contributors who can't or won't take time time to learn Git and how to configure and us Gerrit, then that's really a non-issue, because maintainers are not going to spend their time to save the contributors this effort. This is an interesting point of view. I have no doubt that gerrit makes life easier for the maintainers, but there is the barrier of new thing to learn and setup hassle for a new contributor, vs the old system used by many projects of sending patches to a mailing list. You will lose some valuable contributions and contributors because of this. Also the apparent attitude of screw you, we don't care if it's hard, it makes our life easy is offputting. I have a few patches in OpenOCD and one bug I found the other day that I was thinking about working on and sending a patch for. But honestly, having to set up for gerrit workflow makes me less likely to do either. If OpenOCD suffers from a lack of maintainer time and effort but is overrun with enthusastic contributors, then the gerrit thing seems like a good idea. If on the other hand the maintainers are active and keen to encourage new contributors, and the project is suffering from lack of contributor effort, then it seems like it will not be good for project health. I suspect the truth lies somewhere between the two. This is intended to be an objective bit of third-party insight, I am not anti-gerrit - it seems like a nice tool. certainly I am a fan of CI. I apprecite OpenOCD, I'd like to see the project grow in scope and maturity, but this additional barrier to contributing does put me and others off contributing in future. -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Does OpenOCD suppor the Embedded TraceMacrocell (ETM) Registers?
openocd-development-boun...@lists.berlios.de wrote: Does anyone know if users of OpenOCD can access the ETM Regisiters? There is code in there that's supposed to do it, I tried using it once but didn't get anywhere. Lack of documentation etc. Not too helpful, sorry. -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] DM365 EVM, OpenOCD
Hi Thomas (and list), I have just been trying to use OpenOCD on a TI DM365 EVM. It doesn't work very well, sounds a bit like the problems you were having last year, starting with this: http://lists.berlios.de/pipermail/openocd-development/2010-April/015436.html Did you ever manage to get things working well? I see the dm365evm.cfg hasn't been touched since DB's intial version, and sadly he is no longer around to ask :/ FWIW I get one good startup of OpenOCD after a power-cycle, then: Open On-Chip Debugger 0.5.0-dev-00950-g898dd3a (2011-07-11-18:58) Licensed under GNU GPL v2 For bug reports, read http://openocd.berlios.de/doc/doxygen/bugs.html Info : only one transport option; autoselect 'jtag' RCLK - adaptive fast memory access is enabled dcc downloads are enabled trst_only separate trst_push_pull WARNING: CS0 configuration not known dm365evm_init Info : RCLK (adaptive clock speed) not supported - fallback to 1500 kHz Error: JTAG scan chain interrogation failed: all ones Error: Check JTAG interface, timings, target power, etc. Error: Trying to use configured scan chain anyway... Error: dm365.jrc: IR capture error; saw 0x3f not 0x01 Warn : Bypassing JTAG setup events due to errors -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] RFC Release Cycle
Øyvind Harboe wrote: I am struggling a bit following the above, but I think we agree: - development goes on in master like it always has done - you create a fork at the openocd mirror and create a release branch there. You pick whatever you want from the master branch or whatever patches posted that you think should go in and generally run the release cycle. - once you're done with the release, I pull it from you and push it to the official openocd repository. Just my 2 cents: This sounds like a bad idea to me if I understand right. It means the release versions will always be in branches that either do, or don't, get merged back into master. If they don't get merged back in, then future releases are not direct descendants of older releases. That is not good for history review or trying to understand where a bug comes in, you can't bisect between version n and n+1. If they do get merged in then you end up with messy history and again difficult to bisect and isolate problems if something breaks when merging in the release version. I would suggest better would be to do all releases from master in a linear fashion, going into feature freeze as needed. At the close of a merge window new development would continue on another branch, next or staging or whatever. After tagging and releasing, the development branch would be rebased onto the master, giving a linear history. I think this is more or less how other projects including Linux do it. It takes a bit more thought and familiarity with git but results in a much cleaner more usable history. -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Fwd: mourning the loss of David Brownell
openocd-development-boun...@lists.berlios.de wrote: Linux has lost a great developer with the passing of David Brownell recently and he will be greatly missed. Thank you for reposting this. Often it seems every bit of code I need to work on turns out to have been written by DB. His code has inspired and taught me a lot, I'm sure it will continue to do so. -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] New warnings about ftdi read buffer
Since 6ddcee7d20ee873f1c214736c22f29d9781dded4 When I try to read memory, I get read buffer size looks to high (I suppose that should be too instead of to) e.g. amontec jtagkey, TI DM355 (ARM926EJ-S) mdb 0 64 read buffer size looks to high read buffer size looks to high read buffer size looks to high 0x: fe 1f 00 ea fd 1f 00 ea fc 1f 00 ea 04 f0 5e e2 08 f0 5e e2 f9 1f 00 ea f8 1f 00 ea e0 27 00 ea 0x0020: 29 0b 00 00 00 00 00 00 31 0f 09 ee 11 0f 19 ee 38 00 9f e5 1d 00 80 e3 11 0f 09 ee 34 00 9f e5 As a user, how am I supposed to react to this message? It's rather opaque. And things still seem to work. So far just noticed it on longish memory dumps. -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] ft2232: fix log message and changelog output to debug
openocd-development-boun...@lists.berlios.de wrote: this patch fix the log message and change the log output to debug. That looks like an improvement but is a very long line, wants wrapping. Someone may have said this, but inline patches are better.. Thanks, -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Error and then segfault with svf
openocd-development-boun...@lists.berlios.de wrote: Has anyone used the SVF support recently? I've tried to use svf, but it doesn't work in my case. I sent two small patches to SVF in early January based on 0136977c40e41cdaab5d775c4e370763006ad99c With those patches I used SVF to program a Lattice MachXO with an Amontek JTAGKey-Tiny, using an SVF generated by Lattice software. The patches just added a feature and cleanup, so SVF at least worked a bit at that time. -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Error and then segfault with svf
Øyvind Harboe wrote: Could you repost the patches? Oh, they got merged. d356034f03eb60fd4e8b3537bd979d9e7e5e25f8 and the one before. -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] NAND Flash Bad Block Density - What is reasonable?
jamwyatt wrote: The downside is that uboot, as provided from Marvell, is relatively particular at the use and management of the first 1M partition. I believe that it can not survive more than one bad block in that partition. Then it must be fixed. NAND has errors. If you want to use NAND reliably you have to deal with it all properly; ECC, periodic rewrite after many reads, wear levelling, bad block retirement. It's a pain in the arse, that's why eMMC is looking attractive to me.. -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] NAND Flash Bad Block Density - What isreasonable?
openocd-development-boun...@lists.berlios.de wrote: I was asking the ODM to ensure that no more than 2 bad blocks occur in any 4M range of the flash as a requirement. You have a pretty good chance of hitting that ime. Anyone have any place to get something official about bad block density? I suspect that in practice, 2 BB in 4M is reasonable and unlikely to cause issues, but without empirical documentation, I can't make a requirement. with 2KB page 512MB NAND flash if I remember rightly quite a few of the chips we buy in would fail your 4M requirement. More than 1-2% I think. My statistics are not hot enough to give you the formula, but 512M into 4M buckets is 128 buckets, assuming 128KB blocks is 4096 blocks, let's say 1% are bad is around 41, ideally randomly distributed - this gives a very high probability that two will be in the same bucket. Not sure the probability for 3, but I think it is also high. Also I think (fuzzy memory, sorry) that bad blocks tend to appear close together more often than even random distribution would suggest. In a 512M NAND flash, setting aside +40M in sloppy partitioning seems very wasteful. Thoughts/Comments? That is what UBI is for if I understand it correctly. It manages internal virtual partitions where the actual wear levelling and bad block tolerance takes place across the whole physical NAND shared by the UBI partitions. -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 2/2] svf: implement sleep for RUNTEST min_time
Andrew Leech wrote: For what its worth I just reprogrammed my actel FPGA just fine with your svf_implement_sleep_for_RUNTEST_min_time patch compiled in, so you've got no complaints from me. Belated thanks. Does that qualify as a Tested-by:, an Acked-by:, or just a slight nod of the head? :) -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Any patches that have fallen between thecracks out there?
openocd-development-boun...@lists.berlios.de wrote: Are there any patches that are not committed yet that anyone would have expected to be committed by now? How about my [PATCH 2/2] svf: implement sleep for RUNTEST min_time Sent to list 02/1/2011 Didn't get much response, last comment by Andrew Leech 12/01/2011 Let me know if you want me to re-send. -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 2/2] svf: implement sleep for RUNTEST min_time
Andrew Leech wrote: On 06/01/2011, at 3:12 PM, Jon Povey wrote: Ping. I never delved much into the actual SVF commands, so can't comment on the basic logic of it, however if the new functionality is correct the old stuff blocked out by #if 1/0 should be removed before committing upstream as it's just dead code and messy. I didn't know why that was in there. If someone knows it should be removed I think that should be a separate patch. Unfortunately I can't check that your updated version works on my (actel) hardware for at least another week or so at this rate, but if the logic's right I can't see why it wouldn't be fine. OK, just trying not to let it get forgotten. Can you think of anyone else I should look for an ACK from before getting Oyvind to pull his itchy merge trigger finger? :) -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Cable madness
openocd-development-boun...@lists.berlios.de wrote: They didn't have any 0.05 pre-crimped solutions that I could find. Crimping your own is not hard with something solid to push down with (bit of wood or such). It seems like everybody is doing something different Throw in that a lot of application PCBs don't have anything resembling a normal JTAG 0.1 or 0.05 connector and then you're off to the hw engineer on the project to have him put something together... imo basic soldering / electrical skills are part of being an embedded engineer, if you want to play around trying to fit square pegs in round holes. To abuse a famous quote; give a man a vendor cable and he can program one board. Teach him to fabricate his own cables.. -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Cable madness
openocd-development-boun...@lists.berlios.de wrote: There are lots of 0.1 10/14/20 connectors out there with the signal pins reordered(TI, ARM, MIPS, etc.). Here is something promising: create your own cable relatively easily and at least reasonably robust. I'm just a humble country software engineer so if any hardware engineers out there would care to correct comment that would be welcome! http://www.pololu.com/picture/view/0J1708 http://www.pololu.com/catalog/category/70 Looks quite nice and easy to use. I have made some of my own using ribbon cable, crimp headers and 0.1x2 pin strip. (And hot glue, love that stuff..) I'm not a hardware engineer but I think you might be a little susceptible to noise and clock speed limitation with separated wires, and them being so long. Also depending on the board / test device wiring you might want to short together all the grounds at one end or the other to help your signal. -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 2/2] svf: implement sleep for RUNTEST min_time
Jon Povey wrote: Signed-off-by: Jon Povey jon.po...@racelogic.co.uk min_time was effectively ignored, I needed it to program a Lattice MachXO which uses a RUNTEST to wait for an erase operation, amongst other things. With this patch pauses happen and I can program the device with an SVF generated in LSC ispVM (with Rev D Standard checked to suppress nonstandard LOOP statements) --- src/svf/svf.c | 58 +++- 1 files changed, 28 insertions(+), 30 deletions(-) Ping. CC'ing some likely interested parties this time. -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 1/2] svf: fix USAGE andrelatederror reporting
openocd-development-boun...@lists.berlios.de wrote: Jon Povey wrote: Signed-off-by: Jon Povey jon.po...@racelogic.co.uk --- Pretty trivial, was just printing svf USAGE, macro bugs. NAK!!! This patch fixes the problem in the completely wrong way. =( Any hints on the right way? -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH 1/2] svf: fix USAGE and related error reporting
Signed-off-by: Jon Povey jon.po...@racelogic.co.uk
---
Pretty trivial, was just printing svf USAGE, macro bugs.
src/svf/svf.c | 13 -
1 files changed, 4 insertions(+), 9 deletions(-)
diff --git a/src/svf/svf.c b/src/svf/svf.c
index a015e3c..a6f2f6f 100644
--- a/src/svf/svf.c
+++ b/src/svf/svf.c
@@ -315,8 +315,6 @@ COMMAND_HANDLER(handle_svf_command)
{
#define SVF_MIN_NUM_OF_OPTIONS 1
#define SVF_MAX_NUM_OF_OPTIONS 5
-#define USAGE [-tap device.tap] file [quiet] [progress]
-#define PRINT_USAGEcommand_print(CMD_CTX, svf USAGE)
int command_num = 0;
int ret = ERROR_OK;
long long time_measure_ms;
@@ -330,8 +328,7 @@ COMMAND_HANDLER(handle_svf_command)
if ((CMD_ARGC SVF_MIN_NUM_OF_OPTIONS) || (CMD_ARGC
SVF_MAX_NUM_OF_OPTIONS))
{
- PRINT_USAGE;
- return ERROR_FAIL;
+ return ERROR_COMMAND_SYNTAX_ERROR;
}
// parse command line
@@ -359,10 +356,9 @@ COMMAND_HANDLER(handle_svf_command)
else if ((svf_fd = fopen(CMD_ARGV[i], r)) == NULL)
{
int err = errno;
- PRINT_USAGE;
command_print(CMD_CTX, open(\%s\): %s, CMD_ARGV[i],
strerror(err));
// no need to free anything now
- return ERROR_FAIL;
+ return ERROR_COMMAND_SYNTAX_ERROR;
}
else
{
@@ -372,8 +368,7 @@ COMMAND_HANDLER(handle_svf_command)
if (svf_fd == NULL)
{
- PRINT_USAGE;
- return ERROR_FAIL;
+ return ERROR_COMMAND_SYNTAX_ERROR;
}
// get time
@@ -1712,7 +1707,7 @@ static const struct command_registration
svf_command_handlers[] = {
.handler = handle_svf_command,
.mode = COMMAND_EXEC,
.help = Runs a SVF file.,
- .usage = USAGE,
+ .usage = svf [-tap device.tap] file [quiet] [progress],
},
COMMAND_REGISTRATION_DONE
};
--
1.6.3.3
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH 2/2] svf: implement sleep for RUNTEST min_time
Signed-off-by: Jon Povey jon.po...@racelogic.co.uk
min_time was effectively ignored, I needed it to program a Lattice MachXO
which uses a RUNTEST to wait for an erase operation, amongst other things.
With this patch pauses happen and I can program the device with an SVF
generated in LSC ispVM (with Rev D Standard checked to suppress
nonstandard LOOP statements)
---
src/svf/svf.c | 58 +++-
1 files changed, 28 insertions(+), 30 deletions(-)
diff --git a/src/svf/svf.c b/src/svf/svf.c
index a6f2f6f..53994a2 100644
--- a/src/svf/svf.c
+++ b/src/svf/svf.c
@@ -1478,47 +1478,45 @@ static int svf_run_command(struct command_context
*cmd_ctx, char *cmd_str)
}
i += 2;
}
- // calculate run_count
- if ((0 == run_count) (min_time 0))
- {
- run_count = min_time * svf_para.frequency;
- }
+
// all parameter should be parsed
if (i == num_of_argu)
{
- if (run_count 0)
- {
- // run_state and end_state is checked to be
stable state
- // TODO: do runtest
#if 1
- /* FIXME handle statemove failures */
- int retval;
+ /* FIXME handle statemove failures */
+ int retval;
+ uint32_t min_usec = 100 * min_time;
- // enter into run_state if necessary
- if (cmd_queue_cur_state !=
svf_para.runtest_run_state)
- {
- retval =
svf_add_statemove(svf_para.runtest_run_state);
- }
+ // enter into run_state if necessary
+ if (cmd_queue_cur_state != svf_para.runtest_run_state)
+ {
+ retval =
svf_add_statemove(svf_para.runtest_run_state);
+ }
- // call jtag_add_clocks
+ // add clocks and/or min wait
+ if (run_count 0) {
jtag_add_clocks(run_count);
+ }
- // move to end_state if necessary
- if (svf_para.runtest_end_state !=
svf_para.runtest_run_state)
- {
- retval =
svf_add_statemove(svf_para.runtest_end_state);
- }
+ if (min_usec 0) {
+ jtag_add_sleep(min_usec);
+ }
+
+ // move to end_state if necessary
+ if (svf_para.runtest_end_state !=
svf_para.runtest_run_state)
+ {
+ retval =
svf_add_statemove(svf_para.runtest_end_state);
+ }
#else
- if (svf_para.runtest_run_state != TAP_IDLE)
- {
- LOG_ERROR(cannot runtest in %s state,
-
tap_state_name(svf_para.runtest_run_state));
- return ERROR_FAIL;
- }
+ if (svf_para.runtest_run_state != TAP_IDLE)
+ {
+ LOG_ERROR(cannot runtest in %s state,
+
tap_state_name(svf_para.runtest_run_state));
+ return ERROR_FAIL;
+ }
- jtag_add_runtest(run_count,
svf_para.runtest_end_state);
+ jtag_add_runtest(run_count, svf_para.runtest_end_state);
#endif
- }
}
else
{
--
1.6.3.3
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [RFC, PATCH 2/2] ft2232: simplify ft2232_read_scan
David Brownell wrote: It has gotten positive testing feedback so far, I'd like clarification on that: there were two patches. This #2/2 was more invasive, and is presumably what was tested. But both cleanups should likely get merged. For my part, I applied both patches and tested. Didn't test only after one patch, though. -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [RFC, PATCH 2/2] ft2232: simplify ft2232_read_scan
David Brownell wrote: These read OK, I thought, but I'm not in a position right now to review (in detail) or verify either patch. Could someone with an FTDI-based adapter please try these out and verify them? Then maybe have a committer commit them, if they ideed check out? Works for me on Amontek JTAGKey-Tiny against TI DM355. Tested-by: Jon Povey jon.po...@racelogic.co.uk -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] DM36x: pll clock setup
thomas.koel...@baslerweb.com wrote: Added a function 'pll_v03_setup' to set up PLLs and clock dividers on DM365 and DM368. Nice.. Do you also have a patch for board/dm365evm.cfg? -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] DM36x: pll clock setup
Thomas Koeller wrote: On Tuesday 15 June 2010 11:03:38 Jon Povey wrote: thomas.koel...@baslerweb.com wrote: Added a function 'pll_v03_setup' to set up PLLs and clock dividers on DM365 and DM368. Nice.. Do you also have a patch for board/dm365evm.cfg? The patch resulted from my work on a new board..Unfortunately, I have no time to step out of my way, however, changing board/dm365evm should be straightforward. OK. I might have to do this in the next couple of weeks.. if I do, I will send a patch. Thanks for your work. -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] -c command line switch not working?
Andreas Fritiofson wrote: On Mon, Jun 14, 2010 at 1:23 PM, Jon Povey jon.po...@racelogic.co.uk wrote: The -c switch is not working for me, for any command I throw at it. Am I missing something obvious? You have to have -c init as the first command on the command line, to switch from configuration mode to .. well, the other one. It's all rather obvious from the helpful error message, don't you think? Well, quite. Thanks for that, I managed to get it working with that clue. Also had to specify the config file with -f, it didn't pick it up automatically like it does when I start with no arguments. Anyway, got it to do what I wanted it to. Thanks again. -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] -c command line switch not working?
The -c switch is not working for me, for any command I throw at it. Am I missing something obvious? I tried a quick bit of gdb but it disappears into the TCL code and I got scared. $ openocd -c halt Open On-Chip Debugger 0.5.0-dev-00274-ge212cf3 (2010-05-31-11:58) Licensed under GNU GPL v2 For bug reports, read http://openocd.berlios.de/doc/doxygen/bugs.html Runtime error, file command.c, line 654: invalid command name halt -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] stm32 : improv e unlock procedure for massţrase
Michael Schwingen wrote: freddie_cho...@op.pl wrote: Maybe unlock_mass_erase would be a better name? That sounds like it unlocks the mass_erase function - that command name does not make clear that it *performs* a mass erase. How about unlock_and_mass_erase? Command name is getting longer and more unwieldy.. I don't use these commands, but how about adding a force or unlock optional argument to mass_erase instead, which does the erase-or-unlock logic Andreas suggested. That would cut down a little on command list growth and seems a good fit as an enhancement to the existing mass_erase. -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] etm: print something when trace buffer empty
Øyvind Harboe wrote: What tool would you want to feed this trace data into btw? I was thinking it would be possible to modify the gdb server to allow stepping through trace data. I don't know.. some kind of gdb hookup might be nice for its symbol resolution, not sure how that would work. Really though, I just had a weird crash bug, since tracked down by other means, and was hoping to use the ETM to tell me where it came from. I don't know much at all about using the ETM, I'm just some poor sap who tried to and failed :) -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32 JTAG-DP STICKY ERROR
Andreas Fritiofson wrote: On Mon, May 31, 2010 at 3:13 PM, Kenan Özdemir gla...@hotmail.de wrote: target remote localhost: monitor reset halt This looks a bit strange. Nowadays, 'reset init' seems to be preferred over 'reset halt'. I don't really know the difference but feel it works better. AFAIK the difference is that 'reset init' does the same as 'reset halt', then runs the reset-init event handler, which may be defined for your board to do things like setup PLLs, DRAM controller, pin muxing, etc. like a basic bootloader. This is helper stuff as out of reset off-chip DRAM is probably inaccessible. -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Trying to use ETM/ETB
Øyvind Harboe wrote: Does the todo.txt contain any entries on the obvious deficiencies of ETB/ETM? A patch to todo.txt w/known problems and things to fix would be welcome! It has a couple of warning shots along the lines of seems not well used yet and that there are no TCL helpers to set up common scenarios. I couldn't get it to produce a trace, but I have never touched an ETM/ETB before so maybe I was doing something wrong. I don't feel qualified enough to make any documentation/TODO patches. -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] etm: print something when trace buffer empty
ETM analyze produced no output when the trace buffer was empty.
This patch provides users with a clue.
Signed-off-by: Jon Povey jon.po...@racelogic.co.uk
---
src/target/etm.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/src/target/etm.c b/src/target/etm.c
index 4f4bf9a..61ee99a 100644
--- a/src/target/etm.c
+++ b/src/target/etm.c
@@ -882,6 +882,11 @@ static int etmv1_analyze_trace(struct etm_context *ctx,
struct command_context *
if (ctx-trace_depth == 0)
ctx-capture_driver-read_trace(ctx);
+ if (ctx-trace_depth == 0) {
+ command_print(cmd_ctx, Trace is empty.);
+ return ERROR_OK;
+ }
+
/* start at the beginning of the captured trace */
ctx-pipe_index = 0;
ctx-data_index = 0;
--
1.6.3.3
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] debugging linux kernel on arm926ejs targetvia openocd-0.4.0
f. achkar wrote: is there a good reference on how to properly debug the linux kernel via openocd/gdb for an arm target on a linux hot machine? I have been debugging with this kind of setup over the past few days. I don't think you can just load your image like you are doing: it is loading at 0xc... which is a virtual address and the MMU hasn't been setup yet. Instead try doing your steps 1-6 but instead of load do: hbreak start_kernel cont then in u-boot boot the kernel from uImage over TFTP or from flash. Your debugger will break near the start of kernel execution and you can debug from there using software breakpoints (MMU will be on). If you need to debug the early stuff before MMU is on try hbreak 0x80008000 instead of start_kernel and have a look at arm-none-linux-gnueabi objdump -S arch/arm/boot/compressed/head.o -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Trying to use ETM/ETB
I've been trying to get a trace out of my DM355 with ETM v1.3 and ETB; I've been reading ARM IHI0014O and the OOCD source code but struggling to get a trace out. ETM is configured in target/ti_dm355.cfg and I try to setup a trace as follows: # (power board on) reset init # setup trace to always-on ref IHI0014O p. 3-41 Tracing all memory reg ETM_trace_resource_ctrl 0 reg ETM_trace_en_ctrl1 0x100 reg ETM_trace_en_ctrl2 0 reg ETM_trace_en_event 0x6f etm start resume etm status reg ETM_status If I understand the datasheet correctly I want to see ETM_status bit 2 set (Trace stop/start status bit). etm status always shows etb: idle. Whatever I do, etm analyze always comes back empty. I added a print which shows me that ctx-trace_depth is always 0. I have also tried setting the trigger like this (inside a small idle loop in u-boot) reg ETM_trig_event 0 reg ETM_addr_1_comparator_value 0x8108a7ec reg ETM_addr_1_access_type 0x19 but that has no obvious effect. Anyone who has successfully used the ETM/ETB with OpenOCD I'd love to hear any recipies, online documentation, etc. etm info reports: etm info ETM v1.3 pairs of address comparators: 4 data comparators: 2 memory map decoders: 8 number of counters: 2 sequencer present number of ext. inputs: 4 number of ext. outputs: 1 FIFO full present protocol version: 7 max. port size: 16 half-rate clocking not supported full-rate clocking supported normal trace format supported multiplex trace format not supported demultiplex trace format not supported FIFO full supported Thanks, -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] board: dm355evm.cfg SDTIMR0/1 minor naming fix
Register name fix; ref. TI document sprueh7d
Signed-off-by: Jon Povey jon.po...@racelogic.co.uk
---
tcl/board/dm355evm.cfg |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/tcl/board/dm355evm.cfg b/tcl/board/dm355evm.cfg
index db47b8d..02c4c86 100644
--- a/tcl/board/dm355evm.cfg
+++ b/tcl/board/dm355evm.cfg
@@ -117,7 +117,7 @@ proc dm355evm_init {} {
mmw [expr $addr + 0x08] 0x0080 0
mmw [expr $addr + 0x08] 0x0013c632 0x03870fff
- # SDTIMR, SDTIMR2
+ # SDTIMR0, SDTIMR1
mww [expr $addr + 0x10] 0x2a923249
mww [expr $addr + 0x14] 0x4c17c763
--
1.6.3.3
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Trying to dig my way out of Abort mode on ARM..
My ARM board doesn't have SRST wired up, so I am using a software reset (watchdog timer). This works most of the time but just failed with the core in Abort mode, and immediately after I got a lot of Address translation failure. Is there something I should do in my software reset routine to make it more robust? Explicitly set the processor mode perhaps? I looked in the docs but couldn't see how to do that. My reset routine just calls halt at the moment then starts trying to set the WDT with mww phys calls. Some output when things went wrong: watchdog_reset called target state: halted target halted in ARM state due to debug-request, current mode: Abort cpsr: 0x20d7 pc: 0x000c MMU: enabled, D-Cache: enabled, I-Cache: enabled watchdog_reset done target state: halted target halted in ARM state due to debug-request, current mode: Abort cpsr: 0x20d7 pc: 0x035c MMU: enabled, D-Cache: enabled, I-Cache: enabled Initialize Video VBOX RCLK not supported - fallback to 1000 kHz Address translation failure Address translation failure Address translation failure Address translation failure Address translation failure Address translation failure Address translation failure Address translation failure Address translation failure Address translation failure Address translation failure Address translation failure Address translation failure Address translation failure Address translation failure When things go right (although the pc usually shows 0x20, not sure what happened this time..) watchdog_reset called target state: halted target halted in ARM state due to debug-request, current mode: Supervisor cpsr: 0x8013 pc: 0x9860 MMU: disabled, D-Cache: disabled, I-Cache: disabled watchdog_reset done target state: halted target halted in ARM state due to debug-request, current mode: Supervisor cpsr: 0x8013 pc: 0x9bb0 MMU: disabled, D-Cache: disabled, I-Cache: disabled -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Trying to dig my way out of Abort mode onARM..
Jon Povey wrote: [3x disclaimers] Sorry about that, someone is having fun with our mail server at the moment, I will give them a slap. -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] NAND: catch read errors when building BBT
nand_build_bbt() was ignoring the return value from nand_read_page() and
blindly continuing.
It now passes the return value up to the caller if the read fails.
Signed-off-by: Jon Povey jon.po...@racelogic.co.uk
---
src/flash/nand/core.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/src/flash/nand/core.c b/src/flash/nand/core.c
index 44b13ce..b3220e2 100644
--- a/src/flash/nand/core.c
+++ b/src/flash/nand/core.c
@@ -226,6 +226,7 @@ int nand_build_bbt(struct nand_device *nand, int first, int
last)
int i;
int pages_per_block = (nand-erase_size / nand-page_size);
uint8_t oob[6];
+ int ret;
if ((first 0) || (first = nand-num_blocks))
first = 0;
@@ -236,7 +237,9 @@ int nand_build_bbt(struct nand_device *nand, int first, int
last)
page = first * pages_per_block;
for (i = first; i = last; i++)
{
- nand_read_page(nand, page, NULL, 0, oob, 6);
+ ret = nand_read_page(nand, page, NULL, 0, oob, 6);
+ if (ret != ERROR_OK)
+ return ret;
if (((nand-device-options NAND_BUSWIDTH_16) ((oob[0]
oob[1]) != 0xff))
|| (((nand-page_size == 512) (oob[5] != 0xff)) ||
--
1.6.3.3
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH/RFC] NAND/davinci: Fix segfault for hwecc4_infix reads
Page reads using hwecc4_infix layout segfaulted for check_bad_blocks because
the read assumed a valid data buffer, which check_bad_blocks does not use
(it only passes a 6 byte buffer for the start of OOB).
This version copes with undersized or missing data or oob buffers and uses
random read commands within the page to skip unwanted areas of data/OOB for
speed.
NOTE: Running check_bad_blocks with this layout will be reading infix
OOB locations, not manufacturer bad block markers. This means that if you
check blocks written in infix layout they will appear good, but manufacturer-
marked bad blocks may also appear good.
If you want to scan for manufactuer-marked bad blocks, you need to enable
raw_access before running check_bad_blocks, or use the non-infix layout.
Signed-off-by: Jon Povey jon.po...@racelogic.co.uk
CC: David Brownell dbrown...@users.sourceforge.net
---
Infix reads were broken before, but this fix raises questions about the bad
block scanning. I think this is probably the right way to go about it and
users need to beware (see NOTE above), but maybe some documentation change
or warning message would be a good idea?
Further NOTE: blocks written in non-infix correct layout will (probably)
appear bad in this mode.
Also all manufacturer bad blocks I have seen so far are actually all-zeros
so will be detected as bad regardless of OOB layout.
The read function could maybe be more elegant, suggestions welcome. I didn't
want to go too nuts on refactoring.
Tested on DM355 + Micron 12F16G08FAA NAND (2KB page / 128KB block)
src/flash/nand/davinci.c | 74 ++---
1 files changed, 62 insertions(+), 12 deletions(-)
diff --git a/src/flash/nand/davinci.c b/src/flash/nand/davinci.c
index 96cbfea..90219c6 100644
--- a/src/flash/nand/davinci.c
+++ b/src/flash/nand/davinci.c
@@ -338,6 +338,27 @@ static void davinci_write_pagecmd(struct nand_device
*nand, uint8_t cmd, uint32_
target_write_u8(target, info-addr, page 24);
}
+static int davinci_seek_column(struct nand_device *nand, uint16_t column)
+{
+ struct davinci_nand *info = nand-controller_priv;
+ struct target *target = info-target;
+
+ /* Random read, we must have issued a page read already */
+ target_write_u8(target, info-cmd, NAND_CMD_RNDOUT);
+
+ target_write_u8(target, info-addr, column);
+
+ if (nand-page_size 512) {
+ target_write_u8(target, info-addr, column 8);
+ target_write_u8(target, info-cmd, NAND_CMD_RNDOUTSTART);
+ }
+
+ if (!davinci_nand_ready(nand, 100))
+ return ERROR_NAND_OPERATION_TIMEOUT;
+
+ return ERROR_OK;
+}
+
static int davinci_writepage_tail(struct nand_device *nand,
uint8_t *oob, uint32_t oob_size)
{
@@ -599,6 +620,10 @@ static int davinci_write_page_ecc4infix(struct nand_device
*nand, uint32_t page,
static int davinci_read_page_ecc4infix(struct nand_device *nand, uint32_t page,
uint8_t *data, uint32_t data_size, uint8_t *oob, uint32_t
oob_size)
{
+ int read_size;
+ int want_col, at_col;
+ int ret;
+
davinci_write_pagecmd(nand, NAND_CMD_READ0, page);
/* large page devices need a start command */
@@ -610,18 +635,43 @@ static int davinci_read_page_ecc4infix(struct nand_device
*nand, uint32_t page,
/* NOTE: not bothering to compute and use ECC data for now */
- do {
- /* write 512 bytes */
- davinci_read_block_data(nand, data, 512);
- data += 512;
- data_size -= 512;
-
- /* read this out-of-band data -- infix */
- davinci_read_block_data(nand, oob, 16);
- oob += 16;
- oob_size -= 16;
- } while (data_size);
-
+ want_col = 0;
+ at_col = 0;
+ while ((data data_size) || (oob oob_size)) {
+
+ if (data data_size) {
+ if (want_col != at_col) {
+ /* Reads are slow, so seek past them when we
can */
+ ret = davinci_seek_column(nand, want_col);
+ if (ret != ERROR_OK)
+ return ret;
+ at_col = want_col;
+ }
+ /* read 512 bytes or data_size, whichever is smaller*/
+ read_size = data_size 512 ? 512 : data_size;
+ davinci_read_block_data(nand, data, read_size);
+ data += read_size;
+ data_size -= read_size;
+ at_col += read_size;
+ }
+ want_col += 512;
+
+ if (oob oob_size) {
+ if (want_col != at_col) {
+ ret = davinci_seek_column(nand, want_col);
+ if (ret != ERROR_OK
[Openocd-development] NAND erase reporting wrong?
I think the reporting of blocks for nand erase is wrong, anyone have any comments before I work on a fix? Here's me erasing one block: nand erase 0 0x1e 0x2 erased blocks 15 to 16 on NAND flash device #0 'NAND 1GiB 3,3V 8-bit' I think this should report Erased block 15 on NAND... (block 16 was NOT erased). Also here erasing the top two blocks (BBT): nand erase 0 0x3ffc 0x4 erased blocks 8190 to 8192 on NAND flash device #0 'NAND 1GiB 3,3V 8-bit' There is no block 8192. 8191 is the highest block number. -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH v2] Change kb/s to KiB/s in messages about kibibytes
Xiaofan Chen wrote: On Thu, May 13, 2010 at 2:18 PM, Øyvind Harboe oyvind.har...@zylin.com wrote: I think the general public uses kilobytes, not kibibytes. http://en.wikipedia.org/wiki/Kibibyte So at that point duaration_kpbs() should be fixed to calculate kilobytes in your opinion? It actually does not matter to me. But I feel strange to use kibibytes, which is used by very few people. http://en.wikipedia.org/wiki/Kibibyte It states In most cases the kilobyte continues to be used to refer to a power of ten as well as a power of two. Yeah, most people SAY kilobyte but they MEAN 1024 Bytes (kibibyte). I have always used kilobyte to mean 1024 bytes (a kibibyte). Using kilobyte to mean 1000 bytes is unusual; hard drive manufacturers trying to make their drives sound bigger for example. Especially in the case of OpenOCD I can see no reason for changing to use units of 1000 bytes. We are computer programmers. We want powers of 2. -- Jon Povey jon.po...@racelogic.co.uk ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH v2] Change kb/s to KiB/s in messages about kibibytes
Michael Schwingen wrote: Jon Povey wrote: Yeah, most people SAY kilobyte but they MEAN 1024 Bytes (kibibyte). I have always used kilobyte to mean 1024 bytes (a kibibyte). Using kilobyte to mean 1000 bytes is unusual; hard drive manufacturers trying to make their drives sound bigger for example. Especially in the case of OpenOCD I can see no reason for changing to use units of 1000 bytes. We are computer programmers. We want powers of 2. Then don't use kilo as a prefix. kilo has a standardized meaning of 1000 - if you want 1024, call it something different. I am not suggesting that kilobyte should be used for 1024. Just that I and many others have done so for years, before this kibi thing started showing up. If you look at the patch, I am trying to make things more correct.. -- Jon Povey jon.po...@racelogic.co.uk ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH 2/2] NAND: fix first and last handling in nand_build_bbt
Last block was being skipped, fix by changing the loop test from to =
First block argument was ignored, always started from block 0 (and counted
the wrong blocks as bad if first was nonzero). Now we use it.
Signed-off-by: Jon Povey jon.po...@racelogic.co.uk
---
src/flash/nand/core.c |8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/src/flash/nand/core.c b/src/flash/nand/core.c
index e763491..44b13ce 100644
--- a/src/flash/nand/core.c
+++ b/src/flash/nand/core.c
@@ -222,8 +222,9 @@ COMMAND_HELPER(nand_command_get_device, unsigned name_index,
int nand_build_bbt(struct nand_device *nand, int first, int last)
{
- uint32_t page = 0x0;
+ uint32_t page;
int i;
+ int pages_per_block = (nand-erase_size / nand-page_size);
uint8_t oob[6];
if ((first 0) || (first = nand-num_blocks))
@@ -232,7 +233,8 @@ int nand_build_bbt(struct nand_device *nand, int first, int
last)
if ((last = nand-num_blocks) || (last == -1))
last = nand-num_blocks - 1;
- for (i = first; i last; i++)
+ page = first * pages_per_block;
+ for (i = first; i = last; i++)
{
nand_read_page(nand, page, NULL, 0, oob, 6);
@@ -248,7 +250,7 @@ int nand_build_bbt(struct nand_device *nand, int first, int
last)
nand-blocks[i].is_bad = 0;
}
- page += (nand-erase_size / nand-page_size);
+ page += pages_per_block;
}
return ERROR_OK;
--
1.6.3.3
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH 1/2] NAND: fix off-by-one error in erase command argument range
The last_block argument to nand_erase() is checked against nand-num_blocks, but the highest valid block number is (total - 1), the test for invalid should be = rather than . Signed-off-by: Jon Povey jon.po...@racelogic.co.uk --- src/flash/nand/core.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/flash/nand/core.c b/src/flash/nand/core.c index 9013812..e763491 100644 --- a/src/flash/nand/core.c +++ b/src/flash/nand/core.c @@ -528,7 +528,7 @@ int nand_erase(struct nand_device *nand, int first_block, int last_block) if (!nand-device) return ERROR_NAND_DEVICE_NOT_PROBED; - if ((first_block 0) || (last_block nand-num_blocks)) + if ((first_block 0) || (last_block = nand-num_blocks)) return ERROR_INVALID_ARGUMENTS; /* make sure we know if a block is bad before erasing it */ -- 1.6.3.3 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH v2] Change kb/s to KiB/s inmessages about kibibytes
Xiaofan Chen wrote: On Thu, May 13, 2010 at 6:07 PM, Michael Schwingen rincew...@discworld.dascon.de wrote: No. kB (wirh lower-case k) is wrong unless you calculate based on 1000. You are of course right. But in reality kB/KB is also used to refer to 1024 in the context of for example Windows File Size. The convention I understood was small k for 1000, big K for 1024. But that was discussed and seemed ambiguous. KiB/s is clearly 1024. Very few people use KiB. Yeah, I have seen it around here and there.. But it does seem to be correct. I think I have to accept that I'm used to a common but incorrect usage (KB = 1024) I am fine with either using KiB and 1024, or kB and 1000. 1000 is commonly used in communication environments - for example, a 64kB/s ISDN line transports 64000 bits/s, not 65536. I think in the business of transferring binary images we want to think in 1024-units. If I program a 500KB (ok, KiB) image and it takes 10s, I expect to see something like 10s (50KiB/s). If I saw 10s (51.2KB/s) my immediate reaction would be to think someone had done their maths wrong. -- Jon Povey jon.po...@racelogic.co.uk ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH v2] Change kb/s to KiB/s in messages about kibibytes
Øyvind Harboe wrote: Did you consider modifying duration_kbs() to calculate kilobytes instead of kibibytes? No, I would find reporting transfers in 1000-byte K units surprising and counterintuitive. That kind of change would be a whole different kettle of fish, my patch just fixes the unit label on the current figure (which I think is fine). -- Jon Povey jon.po...@racelogic.co.uk ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH v2] Change kb/s to KiB/s in messages about kibibytes
Change download rate messages about kibibytes from kb/s to KiB/s units.
See: http://en.wikipedia.org/wiki/Data_rate_units
Signed-off-by: Jon Povey jon.po...@racelogic.co.uk
---
This was discussed a bit on the list but no clear resolution.
According to wikipedia KiB/s is correct, I think with the mixed case it should
be clear enough now without having to write some made-up verbose thing like
KiByte/s or kibibyte/s.
Also rebased against master since last patch.
src/flash/nand/tcl.c |6 +++---
src/flash/nor/tcl.c |8
src/target/target.c |8
3 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/src/flash/nand/tcl.c b/src/flash/nand/tcl.c
index 86dbd67..1272bf6 100644
--- a/src/flash/nand/tcl.c
+++ b/src/flash/nand/tcl.c
@@ -309,7 +309,7 @@ COMMAND_HANDLER(handle_nand_write_command)
if (nand_fileio_finish(s))
{
command_print(CMD_CTX, wrote file %s to NAND flash %s up to
- offset 0x%8.8 PRIx32 in %fs (%0.3f kb/s),
+ offset 0x%8.8 PRIx32 in %fs (%0.3f KiB/s),
CMD_ARGV[1], CMD_ARGV[0], s.address,
duration_elapsed(s.bench),
duration_kbps(s.bench, total_bytes));
}
@@ -369,7 +369,7 @@ COMMAND_HANDLER(handle_nand_verify_command)
if (nand_fileio_finish(file) == ERROR_OK)
{
command_print(CMD_CTX, verified file %s in NAND flash %s
- up to offset 0x%8.8 PRIx32 in %fs (%0.3f
kb/s),
+ up to offset 0x%8.8 PRIx32 in %fs (%0.3f
KiB/s),
CMD_ARGV[1], CMD_ARGV[0], dev.address,
duration_elapsed(file.bench),
duration_kbps(file.bench, dev.size));
}
@@ -409,7 +409,7 @@ COMMAND_HANDLER(handle_nand_dump_command)
if (nand_fileio_finish(s) == ERROR_OK)
{
- command_print(CMD_CTX, dumped %ld bytes in %fs (%0.3f kb/s),
+ command_print(CMD_CTX, dumped %ld bytes in %fs (%0.3f KiB/s),
(long)s.fileio.size, duration_elapsed(s.bench),
duration_kbps(s.bench, s.fileio.size));
}
diff --git a/src/flash/nor/tcl.c b/src/flash/nor/tcl.c
index 17c6e91..3a72c78 100644
--- a/src/flash/nor/tcl.c
+++ b/src/flash/nor/tcl.c
@@ -264,7 +264,7 @@ COMMAND_HANDLER(handle_flash_erase_address_command)
if ((ERROR_OK == retval) (duration_measure(bench) == ERROR_OK))
{
command_print(CMD_CTX, erased address 0x%8.8x (length %i)
-in %fs (%0.3f kb/s), address, length,
+in %fs (%0.3f KiB/s), address, length,
duration_elapsed(bench), duration_kbps(bench,
length));
}
@@ -451,7 +451,7 @@ COMMAND_HANDLER(handle_flash_write_image_command)
if ((ERROR_OK == retval) (duration_measure(bench) == ERROR_OK))
{
command_print(CMD_CTX, wrote % PRIu32 bytes from file %s
- in %fs (%0.3f kb/s), written, CMD_ARGV[0],
+ in %fs (%0.3f KiB/s), written, CMD_ARGV[0],
duration_elapsed(bench), duration_kbps(bench,
written));
}
@@ -585,7 +585,7 @@ COMMAND_HANDLER(handle_flash_fill_command)
if (duration_measure(bench) == ERROR_OK)
{
command_print(CMD_CTX, wrote % PRIu32 bytes to 0x%8.8
PRIx32
-in %fs (%0.3f kb/s), wrote, address,
+in %fs (%0.3f KiB/s), wrote, address,
duration_elapsed(bench), duration_kbps(bench,
wrote));
}
@@ -637,7 +637,7 @@ COMMAND_HANDLER(handle_flash_write_bank_command)
if ((ERROR_OK == retval) (duration_measure(bench) == ERROR_OK))
{
command_print(CMD_CTX, wrote %ld bytes from file %s to flash
bank %u
-at offset 0x%8.8 PRIx32 in %fs (%0.3f
kb/s),
+at offset 0x%8.8 PRIx32 in %fs (%0.3f
KiB/s),
(long)fileio.size, CMD_ARGV[1], p-bank_number,
offset,
duration_elapsed(bench), duration_kbps(bench,
fileio.size));
}
diff --git a/src/target/target.c b/src/target/target.c
index 37e515a..c8c1012 100644
--- a/src/target/target.c
+++ b/src/target/target.c
@@ -2560,7 +2560,7 @@ COMMAND_HANDLER(handle_load_image_command)
if ((ERROR_OK == retval) (duration_measure(bench) == ERROR_OK))
{
command_print(CMD_CTX, downloaded % PRIu32 bytes
- in %fs (%0.3f kb/s), image_size,
+ in %fs (%0.3f KiB/s), image_size,
duration_elapsed(bench), duration_kbps(bench,
image_size));
}
@@ -2626,7
Re: [Openocd-development] More problems with basic communication, DM355 + Amontec JTAGKey-Tiny
Jon Povey wrote: Since then I have also tested the latest GIT version under (virtual) linux, and also the latest git version build with FTDI's drivers instead of libftdi. All combinations show the same random errors. Also tried at a range of different JTAG clock speeds, makes no difference. I am looking through documentation for other tuneables I can try fiddling with, and I have a logic analyer/scope arriving next week which might be of use. If anyone was curious, this seems (touch wood) to be OK now after building a new 14-20pin JTAG adapter ribbon with GND lines properly earthed at both ends, and reducing jtag_khz to 1000. 1500 gets intermittent faults. I notice on the scope the TCK is really slow to rise, very slopey at 1MHZ, where RTCK is fairly nice and square. Not why, I'm not a hardware guy. Maybe the JTAGKey-Tiny is struggling to drive this board with an extra chip on the chain compared with the DM355EVM. -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Change kb/s to KB/s in messages rďering to kibibytes
freddie_cho...@op.pl wrote: I'm for using the binary prefixes ( http://en.wikipedia.org/wiki/Binary_prefix ) in the form of x/s so e.g. KiB/s My 2 pence: KB/s is correct as far as I understand, but obviously there is still ambiguity. Some poor souls might still confuse KiB/s to be bits instead of bytes. kibibyte/s removes all ambiguity, but is slightly.. Verbose. -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Change kb/s to KB/s in messages rdering to kibibytes
Michael Schwingen wrote: Jon Povey wrote: My 2 pence: KB/s is correct as far as I understand, but obviously there is still ambiguity. Some poor souls might still confuse KiB/s to be bits instead of bytes. Nope. The SI prefix for kilo(1000) is a lower-case k, so kB/s, would be correkt - let's use correct teminology, please. k for kilo = 1000 K for kibi = 1024 So KB/s. Capital K, capital B. I'm talking common accepted usage rather than SI units. It seems the standard should be for KiB/s, but I have never seen that. But obviously there are plenty of people who disagree, so it looks like it needs to be written out in full. -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Atmel AT91SAM9XXX NAND Flash
Gary Carlson wrote: I wanted to see if anyone has any experience trying to upload the AT91Bootstrap code into NAND flash for any of the AT91SAM9XXX parts (i.e. AT91SAM9260, AT91SAM9G20, etc.) using OpenOCD? ... At this point, I would be happy if someone has marched down this path before and can chime in with some advice. I have spent several days trying to attack this problem without much success. At least on the surface it does not seem like this should be that difficult. Not on this platform, but I have done things with NAND on another platform. Maybe suggesting the obvious, but do you have any other way to program the NAND flash on this board, or a reference board (EVM?) with a known good flash image? If you do, get that booting then read the flash back with OpenOCD and compare with what you managed to do, get so you can recreate it. Also double-check boot config pin settings and all that other good hardware stuff. Other than that, you can try debugging the bootloader that's trying to access the NAND flash (using OpenOCD + gdb). Good luck with that. -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] SEGV and possibly other bugs with nand check_bad_blocks
I have a SEGV when trying to use nand check_bad_blocks on a DaVinci DM355 , OpenOCD version cc5f3c85de7632a32f41b435c54b83487a3aa622 and 4-bit infix ECC layout. This is because nand_build_bbt() calls nand_read_page() with NULL, 0 for data pointer and size, the davinci nand code doesn't like that; gdb: Program received signal SIGSEGV, Segmentation fault. 0x00451a1a in davinci_read_block_data ( nand=value optimized out, data=0x0, data_size=512) at davinci.c:199 199 data[0] = tmp; (gdb) bt 4 #0 0x00451a1a in davinci_read_block_data ( nand=value optimized out, data=0x0, data_size=512) at davinci.c:199 #1 0x00451e90 in davinci_read_page_ecc4infix (nand=0x75a2e0, page=value optimized out, data=0x0, data_size=0, oob=0x7fffd090 , oob_size=value optimized out) at davinci.c:615 #2 0x0041a68f in nand_build_bbt (nand=0x75a2e0, first=value optimized out, last=8191) at core.c:237 #3 0x0041003a in handle_nand_check_bad_blocks_command ( cmd=0x7fffd140) at tcl.c:257 Looking at nand_read_page_raw() for inspiration though, I see that it does this: if (data) nand_read_data_page(nand, data, data_size); if (oob) nand_read_data_page(nand, oob, oob_size); Maybe I'm missing something, but doesn't that mean when called from nand_build_bbt(), the data read will be skipped completely and oob will actually contain the first data from the page? Shouldn't it do a dummy read instead? Seems like at the moment it will be mis-identifying bad blocks based on in-band rather than OOB data. Mailed to list earlier for comments, but meanwhile I am going to continue code spelunking and maybe come up with patches. I need to understand davinci NAND stuff thoroughly and make sure it's all working with OpenOCD. -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] Change kb/s to KB/s in messages refering to kibibytes
bytes in %fs (%0.3f KB/s),
(long)fileio.size,
duration_elapsed(bench), duration_kbps(bench,
fileio.size));
}
@@ -2771,7 +2771,7 @@ done:
if ((ERROR_OK == retval) (duration_measure(bench) == ERROR_OK))
{
command_print(CMD_CTX, verified % PRIu32 bytes
- in %fs (%0.3f kb/s), image_size,
+ in %fs (%0.3f KB/s), image_size,
duration_elapsed(bench), duration_kbps(bench,
image_size));
}
@@ -4950,7 +4950,7 @@ COMMAND_HANDLER(handle_fast_load_image_command)
if ((ERROR_OK == retval) (duration_measure(bench) == ERROR_OK))
{
command_print(CMD_CTX, Loaded % PRIu32 bytes
- in %fs (%0.3f kb/s), image_size,
+ in %fs (%0.3f KB/s), image_size,
duration_elapsed(bench), duration_kbps(bench,
image_size));
command_print(CMD_CTX,
--
1.6.3.3
--
Jon Povey
jon.po...@racelogic.co.uk
Racelogic is a limited company registered in England. Registered number 2743719
.
Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks,
MK18 1TB .
The information contained in this electronic mail transmission is intended by
Racelogic Ltd for the use of the named individual or entity to which it is
directed and may contain information that is confidential or privileged. If you
have received this electronic mail transmission in error, please delete it from
your system without copying or forwarding it, and notify the sender of the
error by reply email so that the sender's address records can be corrected. The
views expressed by the sender of this communication do not necessarily
represent those of Racelogic Ltd. Please note that Racelogic reserves the right
to monitor e-mail communications passing through its network
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] More problems with basic communication, DM355 + Amontec JTAGKey-Tiny
Xiaofan Chen wrote: On Thu, Apr 22, 2010 at 6:38 PM, Jon Povey jon.po...@racelogic.co.uk wrote: I have switched from running OpenOCD on Linux inside VirtualBox, to running it natively on XP. I have not been able to reproduce the situation that needed the JTAGKey-Tiny to be replugged, but I still get random communication errors. Ah ha, so VirtualBox does play a part. Well, not obviously. To be clearer: I only ever saw the needing-replug sitution happen ONCE, on virtualbox linux, but I was banging pretty hard on it for a couple of days. I have however seen these random errors consistently on both platforms. Since then I have also tested the latest GIT version under (virtual) linux, and also the latest git version build with FTDI's drivers instead of libftdi. All combinations show the same random errors. Also tried at a range of different JTAG clock speeds, makes no difference. I am looking through documentation for other tuneables I can try fiddling with, and I have a logic analyer/scope arriving next week which might be of use. Should also get the DM355EVM before too long for comparison. I am wondering things like: - might it be some kind of earth problem? I am in Japan, the computer and DUT are all running off 2-pin power, no earths. - some noise / inadequate power limitation of the JTAGKey-Tiny? Maybe I need a more manly JTAG adapter? That one's a bit of a stretch.. Just a shame I don't have an alternative here for comparison. Pressin' and guessin', -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Libftdi or JTAGKey-Tiny hang?
Laurent Gauch wrote: Hi Jon, I really think it is not related to OS kernel nor to kernel driver nor Virtual Machine. But really coming from something in the OpenOCD code itself. Also, it should be related to *HOW* OpenOCD is closing the Amontec JTAGkey (and or the JTAGkey-2 ), specially regarding TRST and SRST. If I found time today, I will provide a patch to try. Thank you, but I haven't been able to reproduce this yet, so please don't spend time on it. When it happened though, I could quit openocd completely (ctrl-C), run it again and it would give the same error output. It only became OK when I replugged the JTAGKey. -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] More problems with basic communication, DM355 + Amontec JTAGKey-Tiny
your JTAG setup (interface, speed, missing TAPs, ...) error: -100 Assertation failed! Program: C:\Program Files\OpenOCD\0.4.0\bin\openocd.exe File: ../../../../src/jtag/drivers/driver.c, Line 345 Expression: target_tap_match This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Getting OpenOCD working on DM355 without SRST
Jon Povey wrote:
At the moment I am looking into triggering a watchdog reset with a
reset-assert handler.. Be good if I can avoid soldering.
I am not having too much joy with this approach so far, maybe I don't know
enough about ARM processor states. I had this trigger a reset once, but not
reproduced since. My routine is below if anyone is interested.
The DM355 datasheet suggests there is an IcePick command to do the same reset
as the watchdog; from sprufb3 10.3.3:
To initiate max reset, the WDT expires (indicating a runaway condition) or the
ARM emulator initiates a max reset command via the IcePick emulation module.
This suggests that I might be able to give the IcePick a command to reset the
SoC?
Googling around I don't find too much information about the IcePick; there is
this page on TI's wiki: http://processors.wiki.ti.com/index.php/ICEPICK
I noted the interesting comment by a db - David Brownell?
If anyone has information about using the IcePick to reset the DM355 I'd be
very interested.
My work-in-progress watchdog reset:
$_TARGETNAME configure -event reset-assert { vidbox_reset }
proc vidbox_reset {} {
puts vidbox_reset called
halt
wait_halt
# disable mmu?
# reset via watchdog timer
set wdt_base 0x01C21C00
set tgcr [expr $wdt_base + 0x24]
set wdtcr [expr $wdt_base + 0x28]
#TGCR.TIMMODE = 2h, TIM12RS = 1, TIM34RS = 1
mww $tgcr 0xB
#WDTCR.WDEN = 1
#WDKEY = A5C6, DA7E, (trigger watchdog reset)
mww $wdtcr 0xA5C64000
mww $wdtcr 0xDA7E4000
mww $wdtcr 0x4000
}
--
Jon Povey
jon.po...@racelogic.co.uk
Racelogic is a limited company registered in England. Registered number 2743719
.
Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks,
MK18 1TB .
The information contained in this electronic mail transmission is intended by
Racelogic Ltd for the use of the named individual or entity to which it is
directed and may contain information that is confidential or privileged. If you
have received this electronic mail transmission in error, please delete it from
your system without copying or forwarding it, and notify the sender of the
error by reply email so that the sender's address records can be corrected. The
views expressed by the sender of this communication do not necessarily
represent those of Racelogic Ltd. Please note that Racelogic reserves the right
to monitor e-mail communications passing through its network
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Libftdi or JTAGKey-Tiny hang?
In the course of my fooling around lately it seems I am able to wedge something, libftdi or the JTAGKey-Tiny, I got it into a state where OpenOCD would only produce this on startup, even after power cycling the target: Error: JTAG scan chain interrogation failed: all ones Error: Check JTAG interface, timings, target power, etc. Error: JTAG scan chain interrogation failed: all ones Error: Check JTAG interface, timings, target power, etc. Command handler execution failed Warn : jtag initialization failed; try 'jtag init' again. Leaving the target powered I replugged the JTAGKey-Tiny and on next start of OpenOCD it found things: Info : RCLK (adaptive clock speed) not supported - fallback to 100 kHz Info : JTAG tap: penta.tap tap/device found: 0x04040009 (mfg: 0x004, part: 0x4040, ver: 0x0) Info : JTAG tap: dm355.jrc tap/device found: 0x0b73b02f (mfg: 0x017, part: 0xb73b, ver: 0x0) Info : JTAG tap: dm355.etb enabled Info : JTAG tap: dm355.arm enabled Info : Embedded ICE version 6 Info : dm355.arm: hardware has 2 breakpoint/watchpoint units Info : ETM v1.3 Note: I am running OpenOCD on Linux inside VirtualBox hosted on Windows, using VirtualBox's USB capture features. If this is of interest to anyone please let me know if there is something you'd like me to try / information to capture next time. -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Getting OpenOCD working on DM355 without SRST
Jon Povey wrote: If anyone has information about using the IcePick to reset the DM355 I'd be very interested. Oh, I just found this: http://www.mail-archive.com/openocd-development@lists.berlios.de/msg12916.html Which suggests that TI won't give out the information needed to use the IcePick, and I am maybe on the best possible track with my WDT based reset attempt. Will keep struggling and post back here and on the TI Davinci wiki if I get something usable. Will also ask our TI FAE for the IcePick info.. But not hold my breath. Thanks, -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Getting OpenOCD working on DM355 without SRST
-- BROKEN! invalid mode value encountered 0 Jazelle state handling is BROKEN! What is these? watchdog resets? Thanks, -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
