[Openocd-development] Fix for target_read/write_buffer
Commited. The patch below fixes a bug in target/target.c that causes errors on reads/writes that access the end of the address space (0x). Regards, Dominic Index: src/target/target.c === --- src/target/target.c (revision 956) +++ src/target/target.c (working copy) @@ -870,7 +870,7 @@ return ERROR_FAIL; } - if (address+sizehttps://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Cleaning up breakpoints a bit
Just found this post when I was looking for arm7_9 force_hw_bkpts. - How is one supposed to force the use of hardware breakpoints, for example when debugging via insight? - How are software breakpoints handled in the absence of the arm7_9 sw_bkpts command? The old behaviour was to disable software breakpoints by default on targets that required the use of a watchpoint unit (ARMv4, e.g. ARM7TDMI) and enable them on hardware supporting the BKPT instruction (ARMv5, e.g. ARM926EJ-S). Maybe it would have been better to discuss these changes after the list was up again, to give people actually a chance to send feedback... Regards, Dominic On Thursday 14 August 2008 16:35:57 Øyvind Harboe wrote: > Committed. > > The mailing list has been out so there are various other things > that have been fixed as well. > > On Wed, Aug 13, 2008 at 5:29 PM, Øyvind Harboe <[EMAIL PROTECTED]> wrote: > > These days GDB will have a much better idea of what sort > > of breakpoints to ask OpenOCD to set. > > > > E.g. if the memory map is set up, then GDB will ask GDB to > > use hardware breakpoints. > > > > In ARM7/9 there is currently some code that promotes hardware/software > > breakpoints to hardware or software breakpoints according to > > some more or less nebulous rules. > > > > This promotion belongs in gdb_server.c and not in the target. > > > > Additionally there is a problem with breakpoints not being set up > > correctly because it is unclear when the embedded ice watch > > registers should be set up. > > > > The attached patch will: > > > > - clear the watchpoint registers before the first breakpoint is > > added(gdb_server does this upon every step/resume) and > > after the last breakpoint has been removed. > > - retires the arm7_9 sw/hw breakpoint configuration commands. If > > breakpoint type promotion is to be added back, it belongs in > > gdb_server.c. - there is much less conditional code w.r.t. assumptions > > about what the state of the watch registers is on the target > > > > > > The patch is not done yet, but I'd appreciate any feedback. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] How to disable MMU in OpenOCD?
On Friday 05 September 2008 11:17:15 Øyvind Harboe wrote:
> 2008/9/5 dswei <[EMAIL PROTECTED]>:
> > Thank you, vind_Harboe.
> > I don't exactly know what is "srst_pulls_trst" 's mean, but I can disable
> > MMU now, that is enough for my urgent task now.
>
> Would you care to check the datasheets?
>
> Basically some CPUs have, internally, srst tied to trst. This makes it
> impossible
> to reset the CPU without also resetting the embedded ice registers, making
> reset directly into the halted mode impossible.
>
> > I run the openocd command "arm920t cp15 2 0", "step", "poll", then the
> > MMU is diabled. But now I have another question:
> > 1. The "help cp15" is:
> > arm920t cp15idisplay/modify cp15 (interpreted access)
> > [value] [address]
> > arm920t cp15display/modify cp15 register [value]
> >
> > 2. the format of ARM instruction mcr and mrc are:
> >
> > MCR/MRC{cond} P15,opcode_1,Rd,CRn,CRm,opcode_2
> >
> > 3128 27 26 25 24 23 21 20 19 16 1512 11 10 9 87
> >5 4 30
> >
> > | Cond | 1 1 1 0 | opcode1 | L |CRn |Rd| 1 1 1 1 |
> > | opcode2 | 1 | CRm |
> >
> > What is the relation beteen "arm920t cp15" and ARM instruction mcr and
> > mrc? I try "arm920t cp15 0", "arm920t cp15 1", "arm920t cp15 2", and so
> > on, to read the cp15; and then know that "arm920t cp15 2" is for MMU. Are
> > there some exact relations between "MCR/MRC{cond}
> > P15,opcode_1,Rd,CRn,CRm,opcode_2" and "arm920t cp15", ""arm920t cp15i"?
>
> Could you investigate and post an explanation?
Check the ARM920t TRM - only certain combinations are possible, and they're
all listed in the TRM.
Regards,
Dominic
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] How to debug a program not run at it'sruntime address
On Tuesday 30 September 2008 08:22:20 Øyvind Harboe wrote: > On Tue, Sep 30, 2008 at 6:14 AM, dswei <[EMAIL PROTECTED]> wrote: > > Thank you, Duane Ellis, > > > >Yes, set the HARDWARE instruction break point may be more easy for > > this question. But I can't still set the break point by double click on > > the source code. For example, I have to disassemble the linux kernel > > 'vmlinux', and find the virtual address of 'turn_on_mmu', > > calculate the corresponding physical address. After that, I can set the > > 'HARDWARE instruction break point'. > > ??? > > I thought hardware breakpoints used the logical address?? They do, but the code at the beginning of turn_on_mmu is executing with the MMU turned off - after all it's that code's job to turn it on. Duane most likely meant to place a breakpoint at some point within turn_on_mmu /after/ the MMU is turned on. > >Can I debug the program by click buttons, double click on the source > > code , even if it's location has a constant offset to it's runtime > > address? > > I don't understand this question. I suppose he means if there's a way to tell Eclipse, DDD or Insight to automatically do what has to be done. I'm not sure if Eclipse supports placement of hardware breakpoints. The need to calculate the address using a constant virtual->physical offset disappears if an address that executes with the MMU turned on gets used. Regards, Dominic ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD Faraday FA526 support
On Tuesday 07 October 2008 14:57:37 John McCarthy wrote: > On Mon, 2008-10-06 at 18:58 -0400, Duane Ellis wrote: > > John McCarthy wrote: > > > Hi, > > > > > > has anyone got OpenOCD working with a Faraday FA526 processor (actually > > > a Raritan Kira100 which uses a FA526 processor)? It appears to be an > > > ARM926 variant but apparently not exactly. Does this require target > > > specific support or am I just missing some configuration? > > > > I doubt it is an ARM926 - I think it is an ARM920. > > > > ARM926 = uses ARMv6 instruction set. > > > > This page: > > > > > > http://www.faraday-tech.com/html/products/IP/processor/fa5_series.html > > > > Says it is an "ARMV4T" instruction set which would imply - ARM920 ... > > Unfortunately, the arm20t behaves even worse that the arm926 target: > > [... snip ...] > > I'm sure I read somewhere (I think it was for the WinBond BMC which also > uses a Faraday FA526) that it is an ARM926ejs but I'd need to recheck my > facts to be sure. In either case, OpenOCD is currently not happy using > either arm920t or arm926ejs with the Kira100. I'll see if the WinBond > behaves any better (though I'm not too hopeful). > > > Cheers, > John McCarthy. I believe Faraday is one of the few architecture licensees, like Intel or Marvell, i.e. they're producing processors based on cores they developed themselves, rather than integrating one of the existing cores in a SOC. Did you try plain arm7tdmi? The arm920t and arm926ejs targets try to talk to the system coprocessor, which is a lot more implementation specific. Someone from Faraday contacted me earlier this year, but apparently he never sent his patches to the list. I'll see if I can contact him, maybe he's willing to send the patches to one of you for integration in the current OpenOCD code (his work was based on some 100+ revision...). Regards, Dominic ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Is JTAG really required to start up the daemons?
On Wednesday 26 November 2008 13:19:03 Duane Ellis wrote: > And - it should have an immediate console rather then then a console via > telnet only. > > -Duane. That would be nice, but when I decided to go with a telnet console it wasn't exactly easy finding a cross-platform compatible console. Do you have something particular in mind? Regards, Dominic ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Fwd: openocd-0.1.0.mci
Hi list, not sure who created the 0.1.0 binaries, but I suppose "mci" means the Windows "MSI" installer format. Maybe someone with a windows machine can look into this? Regards, Dominic -- Forwarded Message -- Subject: openocd-0.1.0.mci Date: Thursday 19 February 2009 From: as...@bat.berlios.de To: dominic.r...@gmx.net Please! What happened with openocd-0.1.0.mci ? MD5 of this file not equal to declared in openocd-0.1.0.mci.md5 ! And trying install openocd-0.1.0.mci I receive ERROR-massage. --- Please! What happened with openocd-0.1.0.mci ? MD5 of this file not equal to declared in openocd-0.1.0.mci.md5 ! And trying install openocd-0.1.0.mci I receive ERROR-massage. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Converge towards 0.2?
The original idea behind the 7-clocks table and the stable states for which it was defined was that it shouldn't matter how the state machine moves from one stable state to another, as long as some constraints are met like not passing through Test-Logic-Reset or Run-Test/Idle unless ordered to. The magic number seven comes from the Raven parallel port JTAG interface that only allowed TMS moves of exactly 7 cycles. Seeing that there were JTAG interfaces that came with such restrictions I decided that it was better if the upper layers made no assumptions about how a state is entered. Later when I added XScale and XSVF support I realized that there are targets that place additional constraints on the path that should be used, so I ended up adding the path move. I never examined how the xscale requirements could be met with only 7-cycle TMS moves, but as the Raven supports xscale it's apparently possible. Maybe this background helps you understand why the code looks like what it is now. Regards, Dominic ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Command to disable jtag_check_value_mask()
On Saturday 09 May 2009 12:19:24 Magnus Lundin wrote: > Øyvind Harboe wrote: > > On Sat, May 9, 2009 at 11:45 AM, Magnus Lundin wrote: > >> Řyvind Harboe wrote: > >>> Does anyone have any objections to adding a command > >>> to disable jtag_check_value_mask()? > >>> > >>> This is along the lines of the existing verify_ircapture and > >>> could speed things up. > >>> > >>> Checking would be on by default just like verify_ircapture. > >>> > >>> Such a command would serve two purposes(just like > >>> verify_ircapture): > >>> > >>> - measure performance impact of these checks The performance impact of IR scan checks should be minimal, unless reading back individual bits is an expensive operation, e.g. parallel port, where each IN8 takes 1+ microseconds. That is unless doing the check requires an extra roundtrip because of "you know what"... For the FT2232 based devices it merely increases the amount of data that's read back, but this isn't that much of a problem for USB. I remember reading something about a bug with the FT2232 TX buffer (FT->PC) growing full without being read back - not sure what percentage of the TX buffer the IR scan code uses for typical scans, but this can either be measure or calculated. > >>> - during development when things are stable, it > >>> could speed things up > >> > >> Is this not exactly the same as the verify_ircapture flag for dr scans, > >> so it would be verify_drcapture. ? > >> > >> Good for me. > > > > If I put the check inside jtag_check_value_mask() today, then > > the new option would disable verify_ircapture too. > > > > Any objections to making having only one "jtag_verify" and do > > away with verify_ircapture? > > > > What makes verify_ircapture special? Why would we want to > > be able to disable that verification specifically? Are there other > > verification sites that we would want to disable specifically? > > > > I'm kinda leaning towards a single jtag_verify unless someone > > feels strongly about verify_ircapture specifically... > > This is because we use verification of ir capture to check that the jtag > scan chain is working as expected, ir scans have much more predictable > results, so this is on by default. And this really cannot be done in > taget space. The IR check can be disabled because usually, the IR values are just fine, i.e. it's a pretty abnormal situation for an IR scan not to return b...01. Still, correctness of the debugger output should be paramount, so the check is on by default. > We use verification of theck the actual (dr)data, this is not of > interest for the jtag layer, but this is a service the jtag layer does > for the upper layers, this functionality can be placed in ktag as a > service and/or be done in target space. This is useful when the > scanchain contains a bot pure datafields, 32bit words, for target layer > and extra bits for low level debug communications. This is not a > hypothetical scenario. > > So they should be idependently controllable for every scan field. And > then there can be a global on/off flag used very sparingly, perhaps only > for debug. Now this has previously been done by checking the fields > in in the scan structure, and I still beleive this a very clean method > where we put everything controlling this process in one place, instead > of adding a lot of global on off flags. > > Clean up and instrumentation for profiling is good, but be very careful > with removals, it is usually not dead code, just slightly confused code. If the fast_memory_access isn't set, the DBGACK and SYSCOMP bits are checked for each access (14 register * 4 bytes), limiting performance to 56 bytes / roundtrip-time (>=2 ms for FT2232). The arm7_9 memory read code contains an option to defer this check to allow unlimited queing of memory read commands. This greatly improves performance when using USB devices. The fast memory access is safe unless the target is running from a extremely slow clock (like a 32kHz crystal), but the check verifies integrity of the received data. This is an example of "idependently controllable for every scan field", only achieved at a more explicit level - the code requests a readback of these bits, it might defer the check to the jtag layer, or it might simply ignore the bits. To me, IR check and DR check are thus two very distinct things, because the impact of a failed check usually can't be determined at a global level. > Regards > Magnus Regards, Dominic ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] adding a "fast on/off" proc
On Saturday 09 May 2009 12:36:56 Øyvind Harboe wrote: > > Will this increase the number of help mails or decrease them ? > > > > It is not a bad idea, but may I suggest that the speed command also > > prints the > > name and value of all config settings used, or do we use speed info for > > that ? > > The idea about this tcl proc is that the target script can contain > documentation and pointers in the right direction for optimizing > performance of openocd for that target, while providing a > simple way to enable those optimisations. > > A good implementation would then provide both help & sensible > output when setting speed and querying the current speed > settings. > > Precise names/syntax tbd... Except for the usual eye-bleeding I get from looking at tcl code (or rather the thought of having to look at tcl, in this case), that might be a good idea, if the speed->option mapping is done right. Especially having a "speed 0" that disables any optimization might be nice, as it's easier to tell a user with problems to try that option first. > the default implementation will disable ircapture and > jtag verify at speed 2. The decision whether disabling the checks is a good idea should be based on profiling results of a revision from before slaughtering (sorry, that's the way I feel here) the JTAG layer. See my other mail on the difference between IR and DR verification. Regards, Dominic ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] FT2232 & Windows - summary of options
Hi List, there has been some speculation about my original intents so I thought I might chime in here. I'm all in favor of enforcing the GPL where it achieves anything for the user. In case of FTD2XX I decided to go the pragmatic way instead of the idealist's way. Why do we want to link against compatibly licensed libraries only? Because we want to ensure the user's freedom to use our software and his hardware on whatever platform he sees fit. Back then there was libftdi, which allowed FTD2XX based interfaces to be used on Linux, *BSD and so on. And we had FTD2XX which allowed the FTD2XX based interface to be used on Windows, and which offered a significant performance improvement on Linux (this has been solved? I remember reading something about it on the list...). My point of view was that we weren't restricting a user's freedom by allowing the use of FTD2XX. Instead it made the OpenOCD accessible to a much greater audience. As long as libftdi /could/ be made to do the same thing that FTD2XX does, using information publicly available, I don't see an immediate need to enforce seemingly arbitrary restrictions over our users. I wasn't aware of the possibility or need for license exceptions, and I thought (IANAL... how I hate that acronym...) that if anyone, it would take me to enforce the GPL terms. As I had no intend to enforce the GPL over someone who linked against FTD2XX I figured everything would be fine (I think I explicitly wrote that to Michael Fischer some years ago). This may not have been the wisest of decisions but that's how it is or rather was. Øyvind mentioned the idea of wrapping the JTAG API in TCP/IP. Aside from performance implications I think this would require some significant development efforts with little immediate benefits. Even worse, it would encourage other JTAG interface vendors to implement their JTAG interface layer as a binary only driver that talks to the OpenOCD via TCP/IP layer, too. Best Regards, Dominic ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] License
Dear List, 1) I wont support any action against someone who distributes OpenOCD binaries linked against FTD2XX as long as there's no viable alternative. When I wrote the OpenOCD the liberties of potential users were paramount, and this hasn't changed. There is no viable alternative to FTD2XX on Windows, and from what I've read this is going to get worse with Vista and Windows 7. Could actually be funny to watch a GPL case where the original copyright holder states that he sees no problem in linking his GPL licensed code with a proprietary library that is clearly no derivative work of his code... that doesn't even sound too unreasonable... even the GPL FAQ says that linking proprietary libraries "may" impose legal issues (http://www.gnu.org/licenses/gpl-faq.html#FSWithNFLibs) 2) The OpenOCD project itself released binaries linked against FTD2XX on its Berlios page, for example openocd-cygwin-ftd2xx-20060213.tar.gz. I don't think it's totally unreasonable to extrapolate some right of distributing OpenOCD+FTD2XX based on this... 3) I would be willing to add a license exception that allows linking with the FTD2XX library and I invite other major contributors to do the same. The result may not be a OpenOCD rev. 2000+ that's accompanied with this exception, but I suppose we might find some revision where we can formally grant our users a right they have been executing for almost four years. Regards, Dominic ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] openocd, ftd2xx
Hello Zach, thank you for this posting. I was just formulating a reply to some of your last emails, but it's probably better if what I had to say remains in the privacy of my harddrive. On Wednesday 24 June 2009 18:30:09 Zach Welch wrote: > Hi all, > > Here is the full list of GPL-compliant solutions for libftd2xx GPL > compliance, after further review, consideration, and enumeration: > > 1) Documentation: build it yourself! > 2) Build-Kit: automate the build on users' machines I fear those aren't options for the average Windows user of the OpenOCD. Michael's packages were extremely popular because they were very easy to use. > 3) XXX: to be revealed, if legal Is this some particular solution or a placeholder for things we haven't yet thought of? > 4) libftdi-ftd2xx: ABI compatible with libftdi, wraps ftd2xx How would ftd2xx be linked here? Via LoadLibrary (dlopen) and friends? I'd volunteer to create such a solution. > 5) sockets: separate ftd2xx into their own process space I dislike this idea, and I seem to remember that you disliked it, too, because it opens doors for all kinds of GPL circumventions that we don't want. We may not be able to prevent someone from creating such a solution, but we can deny its upstream inclusion. > 6) libusb+libftdi: The Right Thing To Do ;) Is this something that's future proof with Microsoft's signed-drivers-only policy coming up? > I have lost track of who is doing what. Please check in here. :) > > Furthermore, I had originally hoped to make some money by volunteering > here, then finding sponsors for further work. I now have serious doubt. > > I will not take any money for the current compliance effort. Sadly, I > no longer think it would be safe to accept any compensation for such > work, even if it were going to be offered to me. Sorry. Such could > only aid others in baseless accusations of "extortive" motives being > part of my intentions for enforcing the GPL at this juncture. That is > simply not true, and I would point out that I did not even raise the > original issue. Still, I will fall on my sword to do the right thing. > > To reiterate, I am now no longer willing to accept offers to do the work > that I actually need to survive, to demonstrate that my motives here > have no profit in them anymore. All previous offers for me to do paid > work are now off the table, until all hostilities from the community > have been ameliorated. I hope this action helps resolve some tensions. This is for you to decide. I'd actually appreciate if you were to rethink your position, because a developer whose able to make at least part of his living out of the project is definitely going to provide high qualtiy contributions. Best Regards, Dominic ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] License
On Wednesday 24 June 2009 19:04:37 Zach Welch wrote: > Are you any of those things, today? Is he contributing, today? > > > Please respect MR. Dominic Rath. He is the CREATOR of OpenOCD 2004 (with > > 1-2 years or more of intensive coding) > > I do want to be clear that I do value and respect his contributions and > his copyrights, and I welcome both of you to continue contributing to > the OpenOCD community in the future. > > However, neither he nor you have contributed much constructive lately, > which means you have effectively abdicated your authority in the > community. In an open source community, that authority derives from > being a responsible and active contributor. Does this seem reasonable? The OpenOCD was and always will be my project. I'm constantly following the list, although I'm not able to read each and every post, especially when the number of messages explodes like it did recently. I'm voicing my concerns when I see changes that interfere with some key design ideas that were part of the original code I released. The last issue was the removal of the asynchronous in handlers, which were then reinstalled in a different way but achieving essentially the same goal which was fine with me. I do think it is important to point out how I wanted some things to be used when this isn't clear from the code. I saw speculations about what I might have intended which is when I first responded to the current issue. Being the one who followed the project from its very beginning I believe I do know some things that others may have missed or never heard about. Regards, Dominic ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] ftd2xx -> libftdi
On Friday 26 June 2009 17:15:12 Duane Ellis wrote: > Zach Welch wrote: > > Only libusb+libftdi serves our long-term interests. > > Wrong. > > "libusb" is a *blocking* issue that we cannot control, fix, nor > whatever. LIBUSB is not supported by *newer* windows platforms. Unless > and until it is supported it becomes a dead end solution, period, end of > story. > > I believe the "WinUSB" solution is a solution, that for some reason > keeps being left off your list. > > http://msdn.microsoft.com/en-us/library/aa476426.aspx > > -duane. I've been investigating the Windows USB mess a little yesterday. Maybe someone can help fill in the uncertainties, here's what I have collected so far. o libusb-win32 is API compatible with libusb 0.1, but is capable of somethings that libusb 0.1 can't o libftdi apparently works with libusb-win32's API (see for example Freddie's post) o libusb-win32 comes with 3 (maybe 4) backends - a libusb driver and a libusb filter driver (not sure if this differenciation is still correct) - a HID backend (I've seen something like that with Keil's ULINK I guess, which looks like a HID to Windows, and thus needs no driver) - a WinUSB backend o libusb-win32's drivers are supposed to be a dead end because they wont work with 64-bit windows (and probably not with Windows 7), but they do work for older versions that don't have WinUSB support (particularly 2000... leaving 98/ME behind doesn't sound overly disturbing to me) o the FTDI chips are not HID, so the HID backend is dead for our purposes o the WinUSB backend brings a WHQL signed driver, which is good, because it runs on all windows versions that required signed drivers (Vista 64-bit, Windows 7) o The WinUSB How-To says that you need to get the whole driver package including the .inf file signed. Some postings to newsgroups suggest that this is not necessary. It might be that you get a warning, which shouldn't be that much of a problem. o libusb-win32's development seems sporadic if not stalled Conclusions + libusb-win32 would be good, because it works on all present windows platforms, and because it's supposed to work on upcoming versions, too + libusb-win32 would be good, because it allows us to use libftdi, which implements all the FTDI-chip specific USB communication. Using the information available in libftdi wouldn't be much of a problem, but it's certainly a lot of coding work that is mostly unrelated to OpenOCD - I have no idea about how stable and reliable libusb-win32 is o (Re-)writing libftdi with plain WinUSB should be possible and would remove the uncertainties of libusb-win32, but would burden the OpenOCD project with the task of keeping it stable and up to date. It would also leave out Windows 2000 and before. Best Regards, Dominic ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] ftd2xx -> libftdi
tty heavy burden on the Windows packagers. > If possible, some people with Windows knowledge can look > at the libusb-win32 1.0 branch to judge how mature (or im-mature) > it is. > > WinUSB is a good solution with or without libusb-win32. If libusb-win32's > WinUSB backend can be made to work, it is of course better since it > will benefit other open source projects as well. But a WinUSB based > solution specific to OpenOCD (for FTDI) device may be easier. Regards, Dominic ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] ftd2xx -> libftdi
On Friday 26 June 2009 19:26:38 Xiaofan Chen wrote: > Hope this helps. It does. Thanks a lot for your patience and your valuable information. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] ftd2xx -> libftdi
On Saturday 27 June 2009 08:58:00 Freddie Chopin wrote: > David Brownell pisze: > >> There may be people who run Linux and Mac OS X and want > >> to use the FTDI D2XX library due to the perceived performance > >> reasons. > > > > Which, by latest reports, are at best marginal. > > Where are those reports? It seems that I have missed another thing here... I remember reading about it multiple times, e.g. here: http://lists.berlios.de/pipermail/openocd-development/2009-June/008050.html and here (last paragraph): http://lists.berlios.de/pipermail/openocd-development/2009-June/008779.html Pavel's explanation matches with what I remember about this issue. I'm preparing a test setup to verify the numbers just now. Regards, Dominic ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] packaging OpenOCD for 0.2.0
On Saturday 27 June 2009 10:10:16 Freddie Chopin wrote: > David Brownell pisze: > > For the record, why don't we label r2403 as "RC1"? > > Maybe because that fails to build of Windows without two patches I > submitted 2 days ago, that weren't accepted yet? Øyvind replied to your posting with a patch that removes alloca all together (there's only one occurrence). I'm not sure about the strtok_r issue. As I see it strtok_r usage in this case isn't about thread-safety but about being able to call strtok multiple times with different strings. The note on this MSDN page says this isn't safe (and it can't be, seeing it lacks strtok_r's extra context holding pointer): http://msdn.microsoft.com/en-us/library/2c8d19sb(VS.80).aspx Maybe Duane should comment on this, it's his code. Regards, Dominic ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] ftd2xx -> libftdi
On Saturday 27 June 2009 11:30:07 David Brownell wrote: > > Pavel's explanation matches with what I remember about this issue. I'm > > preparing a test setup to verify the numbers just now. > > ISTR Nicolas Pitre reported almost-the-same-speed too. > > At least, on Linux. I believe MS-Windows does have a > speed difference, but that's not at issue here. > > - Dave Here are my test results: Target: AT91SAM9260 on a Olimex SAM9-L9260 (ARM926EJ-S) JTAG: Amontec JTAG-Key OS: (K)Ubuntu 9.04 Host: Core2Duo @ 2.6 GHz OpenOCD: SVN 2405, built just an hour ago libftdi: /usr/lib/libftdi.so.1.13.0 (9.04 stock version) > dump_image /home/vmaster/test.img 0x2000 1048576 > dumped 1048576 byte in 43.130390s (24.311 KB/s) > arm7_9 fast_memory_access enable fast memory access is enabled > dump_image /home/vmaster/test.img 0x2000 1048576 dumped 1048576 byte in 33.895313s (30.935 KB/s) > load_image /home/vmaster/test.img 0x2000 bin 1048576 byte written at address 0x2000 downloaded 1048576 byte in 12.915277s (81.188 KB/s) > arm7_9 dcc_downloads enable dcc downloads are enabled > load_image /home/vmaster/test.img 0x2000 bin 1048576 byte written at address 0x2000 downloaded 1048576 byte in 4.363197s (204.322 KB/s) libftdi: /usr/local/lib/libftdi.so.1.16.0 (--with-async-mode) - > dump_image /home/vmaster/test.img 0x2000 1048576 dumped 1048576 byte in 43.382168s (24.170 KB/s) > arm7_9 fast_memory_access enable fast memory access is enabled > dump_image /home/vmaster/test.img 0x2000 1048576 dumped 1048576 byte in 34.004364s (30.836 KB/s) > load_image /home/vmaster/test.img 0x2000 bin 1048576 byte written at address 0x2000 downloaded 1048576 byte in 12.834919s (81.697 KB/s) > arm7_9 dcc_downloads enable dcc downloads are enabled > load_image /home/vmaster/test.img 0x2000 bin 1048576 byte written at address 0x2000 downloaded 1048576 byte in 4.368081s (240.054 KB/s) FTD2XX: /usr/local/lib/libftd2xx.so.0.4.13 -- > dump_image /home/vmaster/test.img 0x2000 1048576 dumped 1048576 byte in 41.470509s (25.284 KB/s) > arm7_9 fast_memory_access enable fast memory access is enabled > dump_image /home/vmaster/test.img 0x2000 1048576 dumped 1048576 byte in 31.890425s (32.880 KB/s) > load_image /home/vmaster/test.img 0x2000 bin 1048576 byte written at address 0x2000 downloaded 1048576 byte in 14.818524s (70.761 KB/s) > arm7_9 dcc_downloads enable dcc downloads are enabled > load_image /home/vmaster/test.img 0x2000 bin 1048576 byte written at address 0x2000 downloaded 1048576 byte in 5.044282s (207.874 KB/s) These tests show libftdi ahead of ftd2xx or only very slightly behind. This is by no means a complete performance evaluation and the devil might be in the details, but I think it shows that these days libftdi is on par with ftd2xx, at least on Linux. The libftdi 1.13 that comes with (K)Ubuntu 9.04 is already compiled --with-- async-mode. I don't have an older version that lacks this feature lying around. Regards, Dominic ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch] dynamic loading of ftd2xx.dll for windows in ft2232.c
On Sunday 28 June 2009 11:06:27 Freddie Chopin wrote: > Zach Welch pisze: > > You cannot have both libftdi and FTD2XX support in > > the same FT2232 driver binary, so this patch not even allowing testing > > them both using the same openocd binary (presumably by adding/removing > > the OS drivers between tests). > > Why is that so impossible? init() will try to load one of the libraries, > and in case of failure will try using libftdi. The order is just because > ftd2xx.dll is available as library, whereas libftdi is not. Yesterday > I've thought about that issue a bit and come to conclusion, that I'd > have to modify libftdi code so that it would load libusb0.dll dynamically. It isn't possible with the current ft2232.c code because it uses conditional compilation to compile either with libftdi or FTD2XX. While offering basically the same functionality there are not only syntactical but also semantical differences. If ft2232.c was to support both libraries in one binary there would be some rework required. I'm not sure if that effort is worth it since ftd2xx might eventually go away in the not too distant future. > > Personally, I think that I have failed to see the value of this patch, > > but maybe I have missed something. In contrast to the strategic > > solution, what problems does this current patch solve for OpenOCD users, > > today? Without a clear answer to this, I am not sure why we want it. > > To compile openocd you need to specify dozens of options for configure, > because some of them are exclusive (like support for libftdi and > ftd2xx). I think that it would be possible to modify the code in a way > that ALL possible interfaces would be enabled. It's easier to compile > with "bootstrap, configure, make" than browsing through docs to find all > required configure options... Of course I cannot do that alone, as I'm > not a skilled and experienced developer. A user who compiles the OpenOCD for his personal use is normally going to use only one or maybe two different JTAG interfaces. The available options can be looked up with ./configure --help. Packagers building OpenOCD for a Linux distribution, Windows, or some other software platform (as opposed to packagers building for a particular JTAG interface) are a different story. I suppose they're interested in being able to build for the widest variety of interfaces. Building is always going to require the library headers to be present. If all interface drivers were to be built unconditionally you'd have to have all headers present on the build system, which isn't good imho. Hence the off-by- default convention. > When there would be a binary release it could have just the executable, > without any libraries attached. Now when you do a binary release with > maximum number of interfaces enabled you need to attach some libraries > to it. For example compiling support for rlink makes libusb0.dll > required, even if the end-user uses Wiggler. He doesn't need the library > for use, but OpenOCD won't start without it. Exactly - but that's not related to the configure options. Being able to produce a OpenOCD binary that _could_ use all possible JTAG interfaces, but doesn't require installation of all prerequisite libraries would be nice. Regards, Dominic ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch] dynamic loading of ftd2xx.dll for windows in ft2232.c
On Sunday 28 June 2009 11:07:56 Freddie Chopin wrote: > Martin Panter pisze: > > So why loading libusb rather than libftdi? Is it because libftdi is > > only built (or linked to) as a static library on Windows but still > > needs the libusb DLL? > > libftdi is not a .dll, but it's code statically links to libusb0.dll, so > I guess I'd have to modify libusb sources... Don't know whether that > would work, but it should. How is libftdi, and more specifically OpenOCD with libftdi support build on Windows? OpenOCD ft2232.o references symbols from libftdi which references symbols from libusb0. On Linux, libftdi and libusb are shared objects that get dynamically linked. You say libftdi isn't a dll? Is it a static library (.a) that gets statically linked to the OpenOCD? You further say libftdi's code _statically_ links to libusb0.dll - do you mean it dynamically links it (since it's a dll I assume that), but doesn't dynamically load it at runtime (via LoadLibrary)? Regards, Dominic ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch] dynamic loading of ftd2xx.dll for windows in ft2232.c
On Sunday 28 June 2009 12:54:26 Freddie Chopin wrote: > Everything would be easier if libftdi would be a dll <: Now I'd have to > change and recompile libftdi <: Heh, that's exactly where I was heading with my questions ;). Regards, Dominic ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] arm926ejs & i.MX27 testers out there
On Monday 06 July 2009 16:57:24 Øyvind Harboe wrote: > On Mon, Jul 6, 2009 at 4:25 PM, Dominic Rath wrote: > > I can run some tests later today when I get home (~2 hours from now). > > I have a arm926ejs board. > > That would be great! > > It would be especially helpful if you could also read over > arm926ejs.c/arm926ejs_examine_debug_reason() w.r.t. interpretation > of unknown/undocumented MOE values. Any examples of sequences that should fail? SVN 2483 with AT91SAM9260 and JTAGKEY is working here, including the "reset run" + halt you mentioned in your other post. Regards, Dominic ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] arm926ejs unknown cpsr mode for i.MX27
On Monday 06 July 2009 17:41:40 Øyvind Harboe wrote: > Does anyone have an idea what mode 19 from cpsr would > mean when passed into armv4_5_number_to_mode()? Mode 19 decimal or hex? I've never seen 0x19, but 19d is 0x13 which is supervisor mode. > Any good links anyone? > > Is this "Jazelle"/Java Byte Code interpretation mode? Jazelle has a dedciated J bit in the xPSR. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] arm926ejs unknown cpsr mode for i.MX27
On Monday 06 July 2009 20:21:03 Øyvind Harboe wrote: > On Mon, Jul 6, 2009 at 7:10 PM, Dominic wrote: > > On Monday 06 July 2009 17:41:40 Øyvind Harboe wrote: > >> Does anyone have an idea what mode 19 from cpsr would > >> mean when passed into armv4_5_number_to_mode()? > > > > Mode 19 decimal or hex? I've never seen 0x19, but 19d is 0x13 which is > > supervisor mode. > > 19 decimal. > > Why does armv4_5_number_to_mode() not translate *all* 31 possible > modes? Because only those numbers that are translated were valid at the time I wrote the original code. The other modes are translated to -1 because they indicate a bug or a communication error. We could add 0x16 (22) as ARMV4_5_MODE_SEC (or ..._SEC_MO(N)), for the secure monitor mode as documented for example in the ARM1176JZF-S TRM. Not sure what we would do if we ever encountered that mode... > >> Any good links anyone? > >> > >> Is this "Jazelle"/Java Byte Code interpretation mode? > > > > Jazelle has a dedciated J bit in the xPSR. > > Where can I find documentation of CPSR? In most (all?) of the TRMs, and the architecture reference manuals. DDI-0100I (the latest version of the "ARM ARM" architecture reference manual that I could fine) lists the J bit, but lacks secure monitor mode. Regards, Dominic ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] arm926ejs unknown cpsr mode for i.MX27
On Monday 06 July 2009 20:43:41 Øyvind Harboe wrote:
> How about if we changed the way this "mode" is handled to
> get out of the dire straits we're in...
>
> We need a couple of operations at least:
>
> - set known mode (handled today)
> - save & restore mode (can be handled w/unknown mode I think)
I really think there shouldn't be any unknown modes. If there is one, we've
lost already, and should print an error.
The mode affects the processors view of its register file, e.g. system aliases
to user registers, both lack a SPSR. Only r13 and r14 are distinct for most
modes, but FIQ has its own r8 to r12.
> - try to interpret mode to user text (here unknown modes are trivially
> handlled)
>
> Others?
>
>
> I was thinking about replacing the mode enum with a structure:
>
> struct translated_mode
> {
> int saved_mode;
> enum translated_mode mode;
> };
>
> that way we would get type checking too and can more easily
> catch the type bugs I spotted today...
I don't understand what bug you've spotted - mode 19 is supervisor, and is
documented and handled in the code.
Regards,
Dominic
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] arm926ejs & i.MX27 testers out there
On Monday 06 July 2009 20:19:54 Øyvind Harboe wrote: > On Mon, Jul 6, 2009 at 7:06 PM, Dominic wrote: > > On Monday 06 July 2009 16:57:24 Øyvind Harboe wrote: > >> On Mon, Jul 6, 2009 at 4:25 PM, Dominic Rath wrote: > >> > I can run some tests later today when I get home (~2 hours from now). > >> > I have a arm926ejs board. > >> > >> That would be great! > >> > >> It would be especially helpful if you could also read over > >> arm926ejs.c/arm926ejs_examine_debug_reason() w.r.t. interpretation > >> of unknown/undocumented MOE values. > > > > Any examples of sequences that should fail? > > I get MOE=0xe upon "reset run" of i.MX27. "reset run" works just fine here, but "reset halt" fails, and only a power cycle gets the target in a cooperative state after this. The target halt times out, and JTAG communication is obviously broken afterwards. Halting isn't possible, and I get a bogus debug reason (MOE) 0xf. -- > reset halt JTAG tap: at91sam9260.cpu tap/device found: 0x0792603f (mfg: 0x01f, part: 0x7926, ver: 0x0) JTAG Tap/device matched timed out while waiting for target halted Runtime error, file "embedded:startup.tcl", line 226: expected return code but got 'TARGET: at91sam9260.cpu - Not halted' in procedure 'ocd_process_reset' called at file "embedded:startup.tcl", line 208 called at file "embedded:startup.tcl", line 209 called at file "embedded:startup.tcl", line 225 Runtime error, file "command.c", line 469: -- Regards, Dominic ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Fix for arm926ejs strange MOE values handling
On Monday 06 July 2009 21:55:18 Øyvind Harboe wrote: > On Mon, Jul 6, 2009 at 9:42 PM, David Brownell wrote: > > On Monday 06 July 2009, Ųyvind Harboe wrote: > >> I have never used the dbgrq option. It's currently > >> only used by ti parts in the scripts that ship w/OpenOCD. > >> The dm6446 is an arm926ejs part. > > > > Isn't dbgrq actually turned on by default on all arm926 parts? > > Via arm926ejs_init_arch_info() ... > > It is... > > Which makes MOE interpretation more important than ever... > > The known missing interpretation from arm926ejs is MOE=0xe... Is this confirmed to be the real content of the debug status register? Or could this be a subsequent error that results from some other bug, or maybe a communication problem like the one I'm seeing with "reset halt". Regards, Dominic ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] arm926ejs & i.MX27 testers out there
On Monday 06 July 2009 21:22:14 Øyvind Harboe wrote: > MOE=0xf would be a result of receiving all '1's > > Any chance of a bisection on when this broke? 2483: fails, debug reason 0xf etc. 1606: fails, debug reason 0xf etc. 1167: fails, debug reason 0xf etc. 948: fails, debug reason 0xf etc. 838: fails, debug reason 0xf etc. 783: won't start: vmas...@milliways:~/Development/OpenOCD/OpenOCD-783$ sudo ./src/openocd -f src/target/interface/jtagkey.cfg -f src/target/target/at91sam9260.cfg Open On-Chip Debugger 1.0 (2009-07-06-22:11) svn:783 $URL: https://dr...@svn.berlios.de/svnroot/repos/openocd/trunk/src/openocd.c $ Info:options.c:50 configuration_output_handler(): Runtime error, file "?", line 1: Info:options.c:50 configuration_output_handler(): invalid command name "script" Info:options.c:50 configuration_output_handler(): Runtime error, file "?", line 1: Info:options.c:50 configuration_output_handler(): invalid command name "script" 729: works Regards, Dominic ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] arm926ejs & i.MX27 testers out there
On Monday 06 July 2009 23:31:47 Øyvind Harboe wrote: > Hmmm > > 838 - 729 covers a *lot* of changes but nothing > that stands out as a suspect. > > If you have time to narrow this down further then that would be > *great*. > > 788 has the startup tcl script embedded. That could be > the problem you are seing in 783. You were right, 788 worked again - but not with "reset halt" debugging though. I hope to be able to run some more tests or maybe read up on the failing code this evening Regards, Dominic ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] arm926ejs & i.MX27 testers out there
On Wednesday 08 July 2009 08:42:23 Øyvind Harboe wrote: > On Tue, Jul 7, 2009 at 8:57 AM, Dominic wrote: > > On Monday 06 July 2009 23:31:47 Øyvind Harboe wrote: > >> Hmmm > >> > >> 838 - 729 covers a *lot* of changes but nothing > >> that stands out as a suspect. > >> > >> If you have time to narrow this down further then that would be > >> *great*. > >> > >> 788 has the startup tcl script embedded. That could be > >> the problem you are seing in 783. > > > > You were right, 788 worked again - but not with "reset halt" debugging > > though. > > > > I hope to be able to run some more tests or maybe read up on the failing > > code this evening > > Could you be seing a srst_pulls_trst problem too? > > It solved all the i.MX27 ailments... R729 works just fine, without srst_pulls_trst. If the target required srst_pulls_trst reset halt wouldn't work at all. I had a brief look at the i.MX27 manual - are you sure it really requires srst_pulls_trst? To me it looks like only POR (power on reset) pulls TRST, but HRESET shouldn't affect TRST. I haven't had time to work on this yesterday, maybe today gets better... Regadrds, Dominic ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Jim TCL
Hi List, unfortunately I don't have nearly enough time to follow all the changes going on in the OpenOCD SVN repository, but I'd like to make some comments here: - Some people have raised concerns about the direction of OpenOCD development. The use of TCL for integral parts of the OpenOCD seems unnecessary to me. Personally, I don't care about TCL. My language of choice is C. The use of TCL and code like nameObjPtr = Jim_NewStringObj(interp, namebuf, -1); doesn't look very c-ish... I would prefer an approach where the TCL interface exposed access to the OpenOCD's API (e.g. target_t functions), but limited use of TCL to "comfort" functions, like fancy scripts (that's how it started - the desire for better scripting). - One user told me how things like the target library seemed to be over-engineered to him. That's exactly my feeling. - This started out as "some hooks to experiment" and resulted in Jim* being introduced in jtag.c to implement the drscan command, in an implementation completely different from all other functions in jtag.c. - I just looked at "openocd.c", seeing how it grew to three times its size in a few weeks. Is this file really the place for functions like "Jim_Command_mem2array"? It would be nice if the code could be cleaned up a bit once the rate of changes slows down a bit... - Jim is licensed under Apache license V2, which is listed as being incompatible with GPLv2 on the FSF page. Large parts of the OpenOCD are licensed under the terms of GPLv2 or later. Best regards, Dominic ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Jim TCL
On Monday 14 July 2008 19:34:06 you wrote: > This is work in progress. Development happens on trunk and we'll > have to cut stable branches if need be. > > There is a great need to synchronize work because many people are > involved. Both "scripting" people and C people. > > Once the dust settles(give it a month or two), the concerns you raised > should be addressed. Some of the concerns are already being adressed. > We're trying to keep OpenOCD in C and allow for a scripting interface > for higher level fn's. > > Some of the code has ended up in the wrong files and is being split > out / moved as things settle down. > > The actual amount of code, in the end, will not be very great and > the lower level stuff will have some quirks sorted out, but otherwise > be unchanged. Allright, that would be fine. > > - One user told me how things like the target library seemed to be > > over-engineered to him. That's exactly my feeling. > > I'm looking forward to more detailed explanations of such concerns > in this mailing list. The above is too general to comment usefully. Also > a little bit non sequitor for the scripting topic. It was mentioned when we talked about the tcl stuff, that's why I included it in my mail. My own concerns are the same as always - while trying to be smarter than the user things get unnecessarily complex. > > - Jim is licensed under Apache license V2, which is listed as being > > incompatible with GPLv2 on the FSF page. Large parts of the OpenOCD are > > licensed under the terms of GPLv2 or later. > > jifl on ecos-discuss is looking into this, so it will get sorted > one way or another or we can switch to a different scripting engine. > > The eCos guys are pretty paranoid + FSF holds the copyright for > FSF, so this will get *thorough* attention, but it may take some time. :-) > > If a single OpenOCD executable would do, then that would be nice, but > we're also looking into ways of allowing the scripting be handled outside > OpenOCD. I'm looking forward to the outcome of this. Regards, Dominic ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Make "reset run" default?
Original-Nachricht > Datum: Fri, 18 Jul 2008 09:56:34 +0200 > Von: "Øyvind Harboe" <[EMAIL PROTECTED]> > An: "openocd-development@lists.berlios.de" > > Betreff: [Openocd-development] Make "reset run" default? > Any objections? > > I'd like to make "reset run" the behaviour of "reset" without arguments. > > Pavel(willingly or not :-) convinced me that this is the right thing to > do. > > The reason is simply that a target in a halted state after a reset > raises a lot of questions: is the target initialized or not? Did it run > part of the startup code? > > "reset run" is unambigious. > > The target was reset and it is currently running. If it is halted, then > it was because the application hit a breakpoint/exception and it > has nothing to do with the configuration. > > reset still takes init/halt/run_and_halt/run_and_init as arguments > and they always do what the argument says. Do we still have a "daemon_startup" setting? If we do, we need the reset_mode as well. Otherwise there's no way of specifying what that "daemon_startup reset" is supposed to do. I really have no idea what happend during all the changes to the reset/startup stuff. Another question that comes to my mind is this - do we really need "reset"? Apparently different people expect it to do different things, so maybe we should drop it? One comment regarding the use of TCL in this discussion: I completely dislike the idea of having to write TCL code to be able to conserve functionality that used to work before. Scripting isn't everyone's favourite hobby... so please - keep TCL out of the OpenOCD. Offer it as an interface /to/, but don't make it an integral part. Regards, Dominic -- -- Dominic Rath <[EMAIL PROTECTED]> ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Make "reset run" default?
Original-Nachricht > The goal is to make the end users life tcl free. > > Of course the ultimate in configuration is a programming language(c or > other > programming language). > > But the goal is to keep the end users life tcl free. I suppose your end user is someone who doesn't write config scripts, but merely uses your target library, right? -- -- Dominic Rath <[EMAIL PROTECTED]> ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Make "reset run" default?
Original-Nachricht > >> The goal is to make the end users life tcl free. > >> > >> Of course the ultimate in configuration is a programming language(c or > >> other > >> programming language). > >> > >> But the goal is to keep the end users life tcl free. > > > > I suppose your end user is someone who doesn't write config scripts, > > but merely uses your target library, right? > > I want to keep tcl out of the face of end users who writes config > scripts too. Okay, so who's going to see TCL? -- -- Dominic Rath <[EMAIL PROTECTED]> ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Demystifying reset a bit
On Sunday 20 July 2008 19:25:07 Øyvind Harboe wrote: > I've got some thoughts on defining a crisper interface between the > target_process_reset() and the target. > > - the idea is to let the target be ignorant of reset modes. Reset > modesrun, init, > halt, run_and_init, etc. is something that is built on top of the target > reset support. > - a target is told to assert reset into the halted or into the running > state. - a target may fail to reset a target into the halted state, in > which case it is running. Why it fails to do so isn't important. > - the target_process_reset() will detect that the target is running > instead of halted and issue a halt if approperiate > - since reset is now asynchronous, reduce usage of event callbacks > and wait for halt + synchronous function calls more. This will make > it clearer what happens when. > - from a scripting api point of view, there will only be two types of reset > that can be issued: reset run or reset halt. init scripts is built on top > of the latter. from a scripting point of view there is no need to > distinguish between a failed target reset+halt and reset+run&halt. Some points to consider: - from the (knowing) user's point of view, there is a difference between a failed reset+halt and a reset+run&halt, especially when a target is supposed to support reset+halt. At a minimum the user needs to be informed about a failed reset+halt. - multiple targets on a single chain make reset a lot more difficult - not sure how this works these days, but if you're going to rework reset anyway, this might be worth some extra care. Best regards, Dominic ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] TCL and incomplete commands
Hi list, and especially the TCL gurus, I just tried the current SVN head a bit, and quickly realized that incomplete commands didn't work anymore. I remember reading something about this in one of the recent mails, but can't find it right now. Is that functionality only temporarily gone, or is this a necessity that comes with the TCL support? It was rather convenient being able to shortcut things like "shutdown" with "shut". Regards, Dominic ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] keep_alive()
Hi list, while working with the OpenOCD's telnet interface for a bit I got several of these messages: keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet not sent! (1258) I had the jtag_speed set to a very high value (1400), because the target is an ARM926EJ-S core running at the 32kHz slow clock. Would it be possible to limit that warning to GDB connections? Regards, Dominic ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] keep_alive()
On Sunday 20 July 2008 20:15:38 you wrote: > On Sun, Jul 20, 2008 at 7:51 PM, Dominic Rath <[EMAIL PROTECTED]> wrote: > > Hi list, > > > > while working with the OpenOCD's telnet interface for a bit I got several > > of these messages: > > > > keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet > > not sent! (1258) > > > > I had the jtag_speed set to a very high value (1400), because the target > > is an ARM926EJ-S core running at the 32kHz slow clock. > > > > Would it be possible to limit that warning to GDB connections? > > The problem is that we need to catch & fix these problems. I fully agree with you here - take it as a bug report: even the most simple JTAG operation (halt in my case) could possibly take several seconds if the target is running from a very slow clock. > Even if it works for you in a telnet session, it will break when > doing the same from GDB. > > Perhaps it should be prefixed with "BUG:" ? I think so. To me, the warning suggested there was something wrong with my setup. BUG makes it clear that this is something in the OpenOCD that needs to be fixed. In that case it's of course fine to keep the message enabled on the telnet interface, too. Regards, Dominic ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] OpenOCD SVN /trunk and GDB not showing the correct PC
Hi list, is it possible that GDB support in OpenOCD is currently at least partially broken? Are there known bugs that came with TCL, is this something unrelated, but known, or is this something new? I let the OpenOCD attach to a running target (AT91SAM9260, currently executing u-boot), poll the state via telnet, and then attach a GDB connection: -telnet--telnet--telnet--telnet- Open On-Chip Debugger > poll target state: running accepting 'gdb' connection from 0 acknowledgment received, but no packet pending target not halted target not halted target not halted target state: halted target halted in ARM state due to debug request, current mode: Supervisor cpsr: 0x40d3 pc: 0x23f09764 MMU: disabled, D-Cache: disabled, I-Cache: enabled > -telnet--telnet--telnet--telnet- -gdb-gdb-gdb-gdb [EMAIL PROTECTED]:~/arm$ ntoarm-gdb /home/vmaster/arm/qnx/workspace/sam9_l9260/Images/startup-at91sam9263ek.sym GNU gdb 6.7 Copyright (C) 2007 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "--host=i686-pc-linux-gnu --target=arm-unknown-nto-qnx6.3.0"... (no debugging symbols found) (gdb) target remote localhost: Remote debugging using localhost: warning: while parsing target memory map (at line 2): Required element is missing 0x in ?? () (gdb) -gdb-gdb-gdb-gdb As you can see, GDB's idea of the current PC is wrong. I'm not completely sure where GDB gets the wrong address from, but a "continue", "ctrl-c" sequence gets me the correct address: -gdb-gdb-gdb-gdb (gdb) c Continuing. target state: halted target halted in ARM state due to debug request, current mode: Supervisor cpsr: 0x40d3 pc: 0x23f09764 MMU: disabled, D-Cache: disabled, I-Cache: enabled Program received signal SIGINT, Interrupt. 0x23f09764 in ?? () (gdb) c Continuing. target state: halted target halted in ARM state due to debug request, current mode: Supervisor cpsr: 0x40d3 pc: 0x23f09764 MMU: disabled, D-Cache: disabled, I-Cache: enabled -gdb-gdb-gdb-gdb I've also had problems with breakpoints not taken by GDB, but these problems were not reproduceable so far. I've tested both the GDB that came with QNX Momentics 6.3.2 and the version from Code Sourcery's 2007q3 release. Attached is the config file I've used. There was no GDB init script involved. Best regards, Dominic #daemon configuration telnet_port gdb_port gdb_report_data_abort enable #interface interface ft2232 #ft2232_device_desc "Olimex OpenOCD JTAG" #ft2232_layout olimex-jtag #ft2232_vid_pid 0x15ba 0x0003 ft2232_device_desc "Amontec JTAGkey" ft2232_serial AMTJKV31 #ft2232_serial T1P3S2W8 ft2232_layout jtagkey ft2232_vid_pid 0x0403 0xcff8 jtag_speed 1400 #use combined on interfaces or targets that can't set TRST/SRST separately reset_config trst_and_srst separate #jtag scan chain #format L IRC IRCM IDCODE (Length, IR Capture, IR Capture Mask, IDCODE) jtag_device 4 0x1 0xf 0xe jtag_nsrst_delay 300 jtag_ntrst_delay 300 #target configuration #target target arm926ejs little 0 #target_script 0 reset csb337_init.script working_area 0 0x0020 0x1000 nobackup ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD SVN /trunk and GDB not showing the correct PC
On Tuesday 22 July 2008 22:15:08 you wrote: > > -gdb-gdb-gdb-gdb- > >--- [EMAIL PROTECTED]:~/arm$ > > ntoarm-gdb > > /home/vmaster/arm/qnx/workspace/sam9_l9260/Images/startup-at91sam9263ek.s > >ym GNU gdb 6.7 > > Copyright (C) 2007 Free Software Foundation, Inc. > > License GPLv3+: GNU GPL version 3 or later > > <http://gnu.org/licenses/gpl.html> This is free software: you are free to > > change and redistribute it. There is NO WARRANTY, to the extent permitted > > by law. Type "show copying" and "show warranty" for details. > > This GDB was configured > > as "--host=i686-pc-linux-gnu --target=arm-unknown-nto-qnx6.3.0"... > > (no debugging symbols found) > > (gdb) target remote localhost: > > Remote debugging using localhost: > > warning: while parsing target memory map (at line 2): Required element > > is missing > > 0x in ?? () > > (gdb) > > -gdb-gdb-gdb-gdb- > >--- > > > > As you can see, GDB's idea of the current PC is wrong. > > Actually, I think this is a white lie at work. > > OpenOCD allows GDB connections to a powered down target. > > However, GDB will fail to connect if we don't reply to the 'g' > packets(registers). > > A little white lie, in replying a 'g' packets with dummy values, fixes > this. > > This is a *great* feature because it allows setting up the target > via monitor commands from a GDB init script. > > Now you didn't include the log, so I don't know why fetching the > registers didn't work. > > Possibly this is related to, or you are seing a second problem with > the memory map. > > > I'm not completely sure > > where GDB gets the wrong address from, but a "continue", "ctrl-c" > > sequence gets me the correct address: > > > > -gdb-gdb-gdb-gdb- > >--- (gdb) c > > Continuing. > > target state: halted > > target halted in ARM state due to debug request, current mode: Supervisor > > cpsr: 0x40d3 pc: 0x23f09764 > > MMU: disabled, D-Cache: disabled, I-Cache: enabled > > > > Program received signal SIGINT, Interrupt. > > 0x23f09764 in ?? () > > (gdb) c > > Continuing. > > target state: halted > > target halted in ARM state due to debug request, current mode: Supervisor > > cpsr: 0x40d3 pc: 0x23f09764 > > MMU: disabled, D-Cache: disabled, I-Cache: enabled > > -gdb-gdb-gdb-gdb- > >--- > > This matches the white-lie 'g' packet upon connection phenomena. > > > I've also had problems with breakpoints not taken by GDB, but these > > problems were not reproduceable so far. I've tested both the GDB that > > came with QNX Momentics 6.3.2 and the version from Code Sourcery's 2007q3 > > release. > > > > Attached is the config file I've used. There was no GDB init script > > involved. > > -d3 log? Attached is the -d3 log. Looks like the 'g' packet (and several others) is answered before the target is halted. The patch you mentioned in your other mail didn't fix the problem. Regards, Dominic Open On-Chip Debugger 1.0 (2008-07-22-18:41) svn:858M $URL: https://[EMAIL PROTECTED]/svnroot/repos/openocd/trunk/src/openocd.c $ Debug: 4 1 configuration.c:85 find_file(): found olimex_sam9_l9260.cfg Debug: 6 1 command.c:72 script_command(): script_command - telnet_port Debug: 7 1 command.c:85 script_command(): script_command - telnet_port, argv[0]=ocd_telnet_port Debug: 8 1 command.c:85 script_command(): script_command - telnet_port, argv[1]= Debug: 10 1 command.c:72 script_command(): script_command - gdb_port Debug: 11 1 command.c:85 script_command(): script_command - gdb_port, argv[0]=ocd_gdb_port Debug: 12 1 command.c:85 script_command(): script_command - gdb_port, argv[1]= Debug: 14 1 command.c:72 script_command(): script_command - gdb_report_data_abort Debug: 15 1 command.c:85 script_command(): script_command - gdb_report_data_abort, argv[0]=ocd_gdb_report_data_abort Debug: 16 1 command.c:85 script_command(): script_command - gdb_report_data_abort, argv[1]=enable Debug: 18 1 command.c:72 script_command(): script_command - interface Debug: 19 1 command.c:85 script_command(): script_command - interface, argv[0]=ocd_interface Debug: 20 1 command.c:85 script_command(): script_command - interface, argv[1]=ft2232 Debug: 22 2 command.c:72 script_command(): script_command -
Re: [Openocd-development] OpenOCD SVN /trunk and GDB not showing the correct PC
On Tuesday 22 July 2008 23:17:40 you wrote: > Take #2 > > Perhaps poll() has not been invoked? That didn't fix it either. The situation is actually worse than just a bogus 0x0 which can be easily identified. [EMAIL PROTECTED]:~/arm$ ntoarm-gdb /home/vmaster/arm/qnx/workspace/sam9_l9260/Images/startup-at91sam9263ek.sym GNU gdb 6.7 Copyright (C) 2007 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "--host=i686-pc-linux-gnu --target=arm-unknown-nto-qnx6.3.0"... (no debugging symbols found) (gdb) target remote localhost: Remote debugging using localhost: 0x23f1c8b4 in ?? () (gdb) poll Undefined command: "poll". Try "help". (gdb) mon reg pc pc (/32): 0x23f1a8f8 Here GDB showed the PC from when the _previous_ GDB session last entered debug state. The comments from gdb_server.c seems to indicate this is actually desired behaviour?! /* a gdb session just attached, try to put the target in halt mode. * * DANGER * * If the halt fails(e.g. target needs a reset, JTAG communication not * working, etc.), then the GDB connect will succeed as * the get_gdb_reg_list() will lie and return a register list with * dummy values. * * This allows GDB monitor commands to be run from a GDB init script to * initialize the target * * Also, since the halt() is asynchronous target connect will be * instantaneous and thus avoiding annoying timeout problems during * connect. */ The above comment means that OpenOCD knowingly replies with stale data, even if there's absolutely no reason for doing so... Best regards, Dominic ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD SVN /trunk and GDB not showing the correct PC
On Wednesday 23 July 2008 21:19:50 you wrote: > I've committed the fix for " is missing" problem. Thanks. > > * Also, since the halt() is asynchronous target connect will be > > * instantaneous and thus avoiding annoying timeout problems during > > * connect. > > */ > > > > The above comment means that OpenOCD knowingly replies with stale data, > > even if there's absolutely no reason for doing so... > > could you explain what you mean by "absolutely no reason"? When I found the bug - my target was running - the OpenOCD was running - I realized that my application was locked, i.e. it must have crashed somewhere, or entered some infinite loop - I wanted to know where my application was, and possibly examine some data, registers etc. In that case, there's absolutely no reason why starting GDB and connecting to the OpenOCD should result in stale/bogus data being presented to the user. The halt might take a while (~1s with jtag_speed 1400), but the target can easily enter debug state, and by the time it is halted we have reliable data. > Do you specifically mean that the target should be halted, if possible, > before replying to the register packet? Well, that's what GDB expects, isn't it? Upon connection, GDB believes the target is halted, and queries its current state (e.g. 'g' packet). > There are a couple of things that need to line up just right: > > - we need to allow GDB connections to dead or unresponsive targets. This > is to allow users to have monitor commands in the GDB init script to set > things up. > - we need to respond immediately to the connect, or we get weird error > messages that are pretty much impossible to deduce anything from, it > just looks like OpenOCD or GDB is broken) You forgot: - we must not reply with bogus/stale data. if we absolutely must reply with bogus data we should at least inform the user... > You didn't include a -d3 log, so I don't know much about what happened > in your debug session. I've already sent the -d3 log last night: https://lists.berlios.de/pipermail/openocd-development/2008-July/002756.html > Perhaps we can get rid of the white lie upon connect, but for > now it seems like the best option. > > Perhaps waiting 500ms for the halted state will do the trick? Thanks a lot, looks like that worked. Do you know how much time we have here? Would it be possible to keep GDB going with the empty reply packets we send in keep_alive? > If this fails, then I'd like to see the -d3 log. See above. Let me know if you still want a -d3 log. Regards, Dominic ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Need pointers getting FT2232 JTAG interface for AMD Elan SC520
On Thursday 24 July 2008 21:37:41 Brian Hutchinson wrote: > Hi, > > Could someone point me in the right direction so I don't go in the weeds > too far? > > I know this is mostly for ARM but I would really like to take a interface > line the Amontec JAGKey Tiny and make an adaptor to match the pinouts of an > AMD Elan SC520 (Soekris net4526 board to be more specific). > > I'd like to know how to take the BSDL file I have for the SC520 and what > all I would need to do to get a JTAG interface working with it and what I > would need to do in order to use OpenOCD tools with it. Boundary scan does not offer any debugging features. It gives you control over the external pins of the device. > I would also like to use GDB in order to debug the target so would looking > at the ARM GDB Server be a start to figure out how to port such a thing to > the SC520? Debugging requires support from dedicated on-chip debug circuitry. Apparently the Elan SC520 has something they call "AMDebug", which probably does what you want, but I'm not sure if the necessary information is publicly available. > I've always been a user of commercial JTAG products and now want to learn > how this all really works so I can tinker with boards at home on a low cost > basis. > > Thank you! > > Brian Best regards, Dominic ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Need pointers getting FT2232 JTAG interface for AMD Elan SC520
On Friday 25 July 2008 19:20:08 you wrote: > I've used commercial debuggers that use the 4 JTAG signals in order to > establish a debugging session Have you debugged x86 targets that way? Is is possible for e.g. ARM (though without reset signals you're rather limited). > and I know the ARM guys have gdbserver going > so I know it is possible ... I just don't know how to go about learning it. gdbserver uses the debug functionality provided by the underlying platform, e.g. Linux. When talking to bare metal, you need that debug functionality in the hardware. For ARM (7, 9, ...), that's the EmbeddedICE macrocell. > That is why I'm posting ... so you guys can "show me the way". > > Right now I would be just happy being able to flash the Soekris board I'm > using as I would like to port a different bios to it but I would like to > learn how to get gdb to work over the jtag link in the future. It is possible to flash via boundary scan, but it is generally not possible to debug that way. > > Debugging requires support from dedicated on-chip debug circuitry. > > Apparently > > the Elan SC520 has something they call "AMDebug", which probably does > > what you want, but I'm not sure if the necessary information is publicly > > available. > > AMDebug is a propritery AMD thing that I'm not interested in. You'll probably have to look for another platform then. PowerPCs come with a debug interface, but there's little or no documentation to get hold off. MIPS support is still in an early state afaik, as Øyvind suggested it would be great if someone looked after the code in the MIPS branch. The Atmel controllers provide debug support, too, the AVR32 for example might be a nice target. Regards, Dominic ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Need pointers getting FT2232 JTAG interface for AMD Elan SC520
On Friday 25 July 2008 20:21:02 Kishore wrote: > On Friday 25 Jul 2008 11:16:57 pm Dominic Rath wrote: > > You'll probably have to look for another platform then. PowerPCs come > > with a debug interface, but there's little or no documentation to get > > hold off. MIPS support is still in an early state afaik, as Øyvind > > suggested it would be great if someone looked after the code in the MIPS > > branch. The Atmel controllers provide debug support, too, the AVR32 for > > example might be a nice target > > Hi. Sorry for going off topic in here. I have been following this list > though not in great detail and i seem to have lost track somewhere. Is > openocd tending towards being universal tool for all processor types rather > than just ARM? Could one expect that one day it would support AVR[32] > through the JTAGICE-MKII (and maybe others) and replacing the current > avarice? I have nothing against this and would definitely appreciate the > ability of one tool that aids in working with all embedded platforms that i > work with. Just curious! ;) Heh, world domination is of course the ultimate goal... the limitation to ARM comes from ARM being easily available, relatively simple, supported by rich documentation, etc. PowerPC for example would be great, but the devices are a lot more expensive, and documentation is impossible to get. It would be great if we could get support for other processors as well. Regards, Dominic ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] retire reset "run_and_halt" and "run_and_init"
On Saturday 26 July 2008 10:55:43 Øyvind Harboe wrote: > I'd like to retire reset "run_and_halt" and "run_and_init", > they are completely redundant. > > This simplifies the target_process_reset code and also makes > the documentation of reset less noisy. > > > This would leave us with three atomic reset modes: > > - reset run > - reset halt > - reset init > > the final one is really just a convention. > > reset run_and_halt can easily be synthesized from e.g. GDB: > > monitor reset run > monitor sleep 100 > monitor halt > > > Additionally we're going in the direction of target configuration > scripts being able to override reset to a greater degree, so > the operations run, halt and init can be implemented pretty > much in any way that the target configuration script defines. Three lines, or alternatively using a script, isn't really a user-friendly replacement for a "reset run_and_halt". You once mentioned that you'd like "reset halt" to be synthesized by requesting halt if the target didn't enter debug state within a certain timeout. That would at least take care of e.g. LPC2000 targets, i.e. a user would just do a "reset halt" instead of "reset run_and_halt". But on targets that are able to "reset halt" it would be a lot more effort if "reset run_and_halt" is the desired behaviour (e.g. because the startup code is known-good to set up the clocks, sdram etc.). Regards, Dominic ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] retire reset "run_and_halt" and "run_and_init"
On Sunday 27 July 2008 11:18:30 you wrote: > On Sun, Jul 27, 2008 at 11:09 AM, Dominic Rath <[EMAIL PROTECTED]> wrote: > > On Saturday 26 July 2008 10:55:43 Øyvind Harboe wrote: > >> I'd like to retire reset "run_and_halt" and "run_and_init", > >> they are completely redundant. > >> > >> This simplifies the target_process_reset code and also makes > >> the documentation of reset less noisy. > >> > >> > >> This would leave us with three atomic reset modes: > >> > >> - reset run > >> - reset halt > >> - reset init > >> > >> the final one is really just a convention. > >> > >> reset run_and_halt can easily be synthesized from e.g. GDB: > >> > >> monitor reset run > >> monitor sleep 100 > >> monitor halt > >> > >> > >> Additionally we're going in the direction of target configuration > >> scripts being able to override reset to a greater degree, so > >> the operations run, halt and init can be implemented pretty > >> much in any way that the target configuration script defines. > > > > Three lines, or alternatively using a script, isn't really a > > user-friendly replacement for a "reset run_and_halt". > > > > You once mentioned that you'd like "reset halt" to be synthesized by > > requesting halt if the target didn't enter debug state within a certain > > timeout. > > Already in there. > > > That would at least take care of e.g. LPC2000 targets, i.e. a user > > would just do a "reset halt" instead of "reset run_and_halt". > > > > But on targets that are able to "reset halt" it would be a lot more > > effort if "reset run_and_halt" is the desired behaviour (e.g. because the > > startup code is known-good to set up the clocks, sdram etc.). > > Just like we have "init" script/event today, we could have a corresponding > run/halt/init scripts. > > This would remove the raison d'etre for run_and_halt/run_and_init? > > > i.e.: > > target_wait_state(target, TARGET_HALTED, 5000); > if (reset_mode == RESET_INIT) > target_invoke_script(cmd_ctx, target, "post_reset"); > if (reset_mode == RESET_HALT) > target_invoke_script(cmd_ctx, target, > "post_reset_halt"); > if (reset_mode == RESET_RUN) > target_invoke_script(cmd_ctx, target, "post_reset_run"); Not really. The script that would have to be used is "post_reset_run", I guess. Overriding this with something that does a "run_and_halt" would prevent the same config from doing a plain "reset_run", wouldn't it? Regards, Dominic ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] gdbserver rle support
Original-Nachricht > One idea that came to me is that packets smaller than 512 > bytes or so will probably be slower. There are many small > packets. The ethernet hardware has a lower limit to the > packet length for ethernet, so it makes no sense to try > to compress those packets. > > Also the operating system will have a lot of TCP/IP optimisations. Ethernet minimum is 64 bytes, of which 18 bytes are already in use by the ethernet frame itself. Minimum payload size is thus 46. IP header takes 20 bytes, TCP header another 20 bytes, leaving us with 6 bytes of minimum payload... I honstely doubt RLE has any negative effect because of packet lengths... Regards, Dominic -- -- Dominic Rath <[EMAIL PROTECTED]> ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] arm7_9 sw_bkpts enable
Original-Nachricht > Datum: Fri, 1 Aug 2008 13:20:10 +0200 > Von: "Øyvind Harboe" <[EMAIL PROTECTED]> > An: "Magnus Lundin" <[EMAIL PROTECTED]> > CC: Openocd-Dev > Betreff: Re: [Openocd-development] arm7_9 sw_bkpts enable > On Fri, Aug 1, 2008 at 1:16 PM, Magnus Lundin <[EMAIL PROTECTED]> wrote: > > Øyvind Harboe wrote: > >>> We can with no ill effects, I hope, add breakpoints with the target > >>> running, both swbk and hwbk. > >>> > >> > >> It must also work with a powered down target. > >> > >> I.e. configuration of breakpoints must be strictly seperated from the > activation > >> of breakpoints. > >> > >> > > If we do not check the halt state when adding a breakpoint then this is > > true. The check comes > > on resume, and resume is meaningless for a powered down target. Removal > > we have to think about. > > > > What is the reported state of a powered down target ? > > Upon a powered down target you will not get a reliable result, only > failed communication in general. > > I guess I want(like gdb?) to add all breakpoints on resume and remove them > upon detected halt. > > Configuration of breakpoints should not touch the hardware. That would slow down single-step or halt/resume operation. -- -- Dominic Rath <[EMAIL PROTECTED]> ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Patch(es) to the example configuration for Olimex ARM-USB-TINY
Hello Christian, On Thursday 07 August 2008 04:06:53 Christian Jaeger wrote: > I had been using (amongst a few other settings) this config at first: > > interface ft2232 > ft2232_device_desc "Olimex OpenOCD JTAG TINY" > ft2232_layout olimex-jtag > > where the desc was taken from /sys/bus/usb/devices/*/product, but it > wasn't clear from the example that ft2232_vid_pid is mandatory (*and* > ft2232_device_desc needs to be correct at the same time). The problem is with the Windows version of the FTD2XX driver - on Windows you don't need the vid/pid at all, because the driver registers itself for a particular vid/pid combination. Additionally, you need the " A" appended on Windows, because that's how the Windows driver detects the difference between channel A (the one that does JTAG) and channel B (limited to RS232 or GPIO). On Linux you need the vid/pid, unless your device uses the FTDI default combinations. The driver probes the default plus any combination listed in the config file (could be more than just one). Additionally you need the device description (or serial number, which takes precedence over description). > (BTW turns out, by looking at the output from the -d option and a > quick look at the sources, that it was looking for the default(?) vid > / pid numbers which are hard coded (0x0403 / 0x6010).) > > In the following two mails I post patches to fix the example config > file, first I rename it to drop the -a (maybe I just don't see what > this was about), then the relevant changes. (These are formatted by > git format-patch, tell me if you're not happy with that sort of > patches.) It's probably not much use fixing the config files, because they're not really broken. A patch that adds some comments would be highly welcomed of course. Regards, Dominic ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Patch(es) to the example configuration for Olimex ARM-USB-TINY
Original-Nachricht > I believe this would be a better solution. > > Why not > > (1) rename the orginal ".cfg" file I submitted to: > >olimex-jtag-tiny-windows-libftd2xxcfg > > (2) create another one - appropriately named... > Not sure what that name might be but for example: > >olimex-jtag-tiny-linux-libusb.cfg > > (3) And of course - cut/paste snippits of Dominic's email into the cfg > file as comment. We would end up with quite a few config files. The FT2232 is used in many devices, all of which would need a WIN+FTD2XX and a *NIX+libftdi (I've got to think a bit more if there are differences between *nix+libftdi and *nix+FTD2XX - in that case we'd have a third alternative...). Any way - I'm fine with either of the options. Regards, Dominic -- -- Dominic Rath <[EMAIL PROTECTED]> ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] programming AT91SAM9260 with openocd
Hello Stefan, Original-Nachricht > Datum: Thu, 07 Aug 2008 13:46:20 +0200 > Von: Stefan Schoenleitner <[EMAIL PROTECTED]> > An: openocd-development@lists.berlios.de > Betreff: [Openocd-development] programming AT91SAM9260 with openocd > Hi, > > I read the (rather outdated) openocd documentation at > http://openfacts.berlios.de/index-en.phtml?title=Open_On-Chip_Debugger > more than once. > Unfortunately, I still can't program anything with it. The WIKI is completely outdated, but unfortunately none of the pages can be edited. > > * How can I program the boot memory of my AT91SAM9260 at address 0x0 ? What board do you use, or rather what memories does your board have? > > Until now I tried the following: > > > add flash bank in the openocd configuration: > -- > flash bank cfi 0x 0x10 2 2 0 > -- That will only work if you have NOR flash connected to the static memory controller. > I'm not sure if the CFI driver is correct. Anyway, it did not work. > Since the AT91SAM9 is similar to the AT91SAM7 I also tried the following > -- > flash bank at91sam7 0 0 0 0 0 > -- > with no success as well. AFAIK there's no internal flash in the AT91SAM9. > > I also tried writing to the address with no flash bank configured which > seemed to work at first. > However, after device reset (by pressing the reset button on the board) > all changes are gone and the overwritten memory region is as it was > before the writing. Looks like you had the internal SRAM mapped to 0x0 at that point. Check the processors user's manual for information about its internal memories and mappings. > Also, writing to the connected NAND flash doesn't work. > I added a flash bank for it: > -- > flash bank cfi 0x400 0x1000 2 2 0 > -- CFI (and the whole "flash" subsystem) is for NOR flash. NAND flash has completely different characteristics, e.g. it isn't memory mapped. > I'm using the current svn version "Open On-Chip Debugger 1.0 > (2008-08-08-18:57) svn:895". > > Is there any openocd documentation that is not outdated ? > I've been trying to use openocd with my AT91SAM9260 board for two days > now. > Although I can connect to the board now, dump memory, halt and resume > the cpu, programming and resetting the cpu still does not work. You'll need a much lower JTAG frequency for reliable reset-halt operation with the AT91SAM9. My config file uses jtag_speed 1400. Only after the bootloader initialized everything, I switch to jtag_speed 2. > ft2232_layout "jtagkey" seems wrong, too. IIRC there's a layout specifically for the Olimex JTAG interface. > * Should I use an older svn revision ? > > * Is there any other ARM SAM9 compatible programmer that works under linux > ? > > * What are your suggestions with the at91sam9 controllers ? > > > I would really appreciate any help that brings me forward. > > sincerly, > stefan Regards, Dominic -- -- Dominic Rath <[EMAIL PROTECTED]> ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] programming AT91SAM9260 with openocd
Hi, the OpenOCD contains support for some controllers with NAND interfaces, but the AT91SAM9260 isn't currently supported. I looked into this once, but SAM-BA is so easy to use, I didn't bother working on OpenOCD support for the SAM9s. There's a Linux version of SAM-BA (I never used the Windows version, but the screenshots look similar): http://www.linux4sam.org/twiki/bin/view/Linux4SAM/SoftwareTools#SAM_BA_Linux_initiative I managed to erase the NAND flash (didn't have anything to put in it, but I guess loading would work, too) and I'm regularly programming the serial data flash. Regards, Dominic On Thursday 07 August 2008 23:01:12 Stefan Schoenleitner wrote: > Hello, > > > Looks like you had the internal SRAM mapped to 0x0 at that point. Check > > the processors user's manual for information about its internal memories > > and mappings. > > I had a closer look at the at91sam9260 datasheet. > On my board the code at the beginning of the NAND flash is loaded (thus > copied) to the internal SRAM at 0x30. > Once the code has been loaded, the internal SRAM gets remapped to > address 0x0 and the CPU core can start to boot. > For this reason I was able to replace the code at this address region > (SRAM instead of NAND flash) and it's clear now why the changes to this > region were only temporary. > > Therefore, to be able to actually program the board, I would need write > access to NAND memory. > > The problem is, like you already said, that NAND isn't memory mapped: > > NAND flash has completely different characteristics, e.g. it isn't memory > > mapped. > > So, is there a possibility to write to the NAND flash on my board ? > > According to the datasheet, "the NAND flash logic is driven by the > Static Memory Controller on the NCS3 address space. ... > Access to an external NANDFlash device is then > made by accessing the address space reserved to NCS3 (i.e., between > 0x4000 and 0x4FFF > )." > > Thus, in my understanding, if the at91sam9260 is initialized so that the > according output pins are used for NAND flash, the whole NAND flash > memory should be memory mapped by the static memory controller. > For this reason all I would have to do is to write to this memory region > provided that the at91sam9260 is initialized with NAND flash support. > > After reading through some examples, I found out that I can actually > create scripts which are executed after reset. > For this reason, I could initialize the memory controller so that it > memory maps the NAND flash. > After that I could write to NAND, true ? > > > Besides openocd, there is an atmel programming tool that can do flash > programming with the SMA-BA boot agent residing in the cores ROM. > However, the tool only runs on windows which would be kind of cumbersome > for me since my whole development environment runs under linux. > > Do you know of any other (linux) solution I could use to program the > NAND flash ? > > Like I said, the at91sam9260 has boot code in ROM (SAM-BA) that can be > used to write to memory regions. > But since SAM-BA doesn't know that there's NAND flash attached, I'm > pretty sure that it doesn't initialize the memory controller. > According to the datasheet, one can upload files over the serial/USB > port using the xmodem protocol. > But if the memory controller is not initialized to support NAND flash, > that won't be of much help either. > > How do you guys program your ARM based boards ? > They most possibly also have their code in NAND flash, haven't they ? > > stefan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Is LPC2148 ARM/Thumb mode detection broken?
The LPC2000 ROM code is (mostly?) written in Thumb. Regards, Dominic Original-Nachricht > Datum: Thu, 14 Aug 2008 16:59:15 +0200 > Von: "Øyvind Harboe" <[EMAIL PROTECTED]> > An: Openocd-Dev > Betreff: [Openocd-development] Is LPC2148 ARM/Thumb mode detection broken? > Using openocd/testing/examples/LPC2148Test/test_rom.elf, I'm > wondering if Thumb/ARM state detection is broken. > > I've tried the below using latest OpenOCD and svn 729, same result... > > I would have expected it to halt in ARM mode?? > > > > reset run > JTAG device found: 0x4f1f0f0f (Manufacturer: 0x787, Part: 0xf1f0, Version: > 0x4) > > halt > target state: halted > target halted in Thumb state due to debug request, current mode: > Supervisor > cpsr: 0xa0f3 pc: 0x7fffd2da > > > > -- > Øyvind Harboe > http://www.zylin.com/zy1000.html > ARM7 ARM9 XScale Cortex > JTAG debugger and flash programmer > ___ > Openocd-development mailing list > Openocd-development@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/openocd-development -- -- Dominic Rath <[EMAIL PROTECTED]> ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] arm926ejs & i.MX27 testers out there
I can run some tests later today when I get home (~2 hours from now). I have a arm926ejs board. Regards, Dominic Original-Nachricht > Datum: Mon, 6 Jul 2009 16:19:46 +0200 > Von: "Øyvind Harboe" > An: openocd-development@lists.berlios.de > Betreff: [Openocd-development] arm926ejs & i.MX27 testers out there > Are there any arm926ejs and/or i.MX27 testers out there? > > > > -- > Øyvind Harboe > Embedded software and hardware consulting services > http://www.zylin.com > ___ > Openocd-development mailing list > Openocd-development@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/openocd-development -- -- Dominic Rath ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] arm926ejs & i.MX27 testers out there
I've U-Boot running on the board. I attach the OpenOCD, the target is validated fine and continues running. I connect via telnet and issue a "reset halt" - the target fails to halt, and communication is broken afterwards. It's a SAM9L9260 board from Olimex. Regards, Dominic Original-Nachricht > Datum: Tue, 7 Jul 2009 08:58:19 +0200 > Von: "Øyvind Harboe" > An: Dominic > CC: openocd-development@lists.berlios.de > Betreff: Re: [Openocd-development] arm926ejs & i.MX27 testers out there > On Tue, Jul 7, 2009 at 8:57 AM, Dominic wrote: > > On Monday 06 July 2009 23:31:47 Øyvind Harboe wrote: > >> Hmmm > >> > >> 838 - 729 covers a *lot* of changes but nothing > >> that stands out as a suspect. > >> > >> If you have time to narrow this down further then that would be > >> *great*. > >> > >> 788 has the startup tcl script embedded. That could be > >> the problem you are seing in 783. > > > > You were right, 788 worked again - but not with "reset halt" debugging > > though. > > Which means the bug is between 788 - 729... > > If you give me the precise test procedure you use, I've got > two arm926ejs targets I can test on here. > > -- > Øyvind Harboe > Embedded software and hardware consulting services > http://www.zylin.com -- -- Dominic Rath ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
