Re: [Openocd-development] Programming a PIC32 from an ARM
Marc, I managed to get OpenOCD compiled on a 32 bit MIPS platform. Initially I got some some warnings because of alignment issues but I did post the patches to solve those. IIRC those patches made it into the repository. Regarding your project: I'd use an ARM controller from NXP. These can be programmed over a serial port using lpc21isp (http://sourceforge.net/projects/lpc21isp/) which supports LPC1300, LPC1700 and LPC2100 series. This will probably save you a lot of time. I have succesfully compiled run this program for/on our MIPS platform. Nico Coesel -Original Message- From: openocd-development-boun...@lists.berlios.de [mailto:openocd- development-boun...@lists.berlios.de] On Behalf Of Marc Reilly Sent: vrijdag 23 juli 2010 10:16 To: Openocd-development@lists.berlios.de Subject: [Openocd-development] Programming a PIC32 from an ARM Hi, For an upcoming product we have a system which has a PIC32 as a peripheral processor and an ARM as the main processor (running Linux). We'd like to be able program the PIC32 directly from the ARM- we have enough IO lines to connect to the JTAG port. I remember reading that OpenOCD was capable of doing this.. Looking through the jtag/drivers code I'm guessing I want to implement a bitbang interface like the parport driver, and somehow manipulate by GPIO lines instead of parallel port IO. So, my questions: - Has anyone done this before/ or something similar? - Am I looking in the right place/ on the right track? - Could you kindly direct me to any further reading/code? - Is OpenOCD cross-compile friendly for an ARM host? (I hope to develop this into an OpenEmbedded recipe if that helps) Hints much appreciated! Cheers Marc ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Breakpoint can not been trigged on the MIPS 4KEc core.
On 04/06/2010 10:35, Xiaochen Zhou wrote: It seems some issues in openocd-0.4.0 with MIPS 4KEc core, I did some experiments below: For info the MIPS has been mainly tested on a m4k (aka PIC32). This also means that testing has been on a little endian system, so bugs could be present. Issue 1: In telnet console, I set the breakpoint at 0x8000, when I dump memory in uboot, the SDBBP(software debug breakpoint) in memory is 0x3F70 not 0x703F, so it's endian issue. I modify src/target/mips32.h line 138: #define MIPS32_SDBBP 0x703F -- #define MIPS32_SDBBP 0x3F70 then it's ok in uboot memory dump. target_write_u32 should write to the target in the correct endian. Endianess on MIPS may give a headache. The problem is that only the data is shuffled, the code stays in the same order. If you set OpenOCD to big endian it will shuffle both code and data. Nico Coesel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] build openocd for arm
-Original Message- From: Øyvind Harboe [mailto:oyvind.har...@zylin.com] Sent: dinsdag 27 april 2010 1:32 To: Nico Coesel Cc: openocd-development@lists.berlios.de Subject: Re: [Openocd-development] build openocd for arm This no longer applies against origin/master. Could you update and repost the patches? I'm afraid not. Moving to a new version of OpenOCD would require a lot of work which I don't have time for (blame the Boss). I had to modify some parts of OpenOCD quite heavily to get more speed out of it. Besides that, the apparatus which runs OpenOCD is at the assembly house so I have no means of testing anyway. Did you have to fix *all* those locations in jim.c? For -Werror to shut up: yes. I was almost tempted to turn -Werror off but I felt the 'this variable may be used unitialized' messages where too severe to dismiss :-) Nico Coesel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] build openocd for arm
Øyvind, Yu, I needed the attached patches to get OpenOCD 0.2 to compile for MIPS. Met vriendelijke groet / Best regards, DEA bv ing. Nico Coesel Kweekgrasstraat 18 1313BX Almere tel: +31 (0)36 5343888 fax: +31 (0)36 5342244 e-mail: ncoe...@dealogic.nl www.c-lock.nl www.dealogic.nl (op al onze leveringen van goederen en diensten zijn onze algemene voorwaarden van toepassing zoals gedeponeerd bij de KvK te Lelystad, inschrijfnummer 39046783) -Original Message- From: Øyvind Harboe [mailto:oyvind.har...@zylin.com] Sent: zondag 25 april 2010 18:29 To: Nico Coesel Cc: Yu Li; openocd-development@lists.berlios.de Subject: Re: [Openocd-development] build openocd for arm Please repost the patch if it was simply forgotten. The warning here is actually benign, but there is no way the compiler can know that. -- Meet Zylin at ESC 2010 San Jose April 26 - 30. 2010 http://www.zylin.com/events_esc2010.html Øyvind Harboe US toll free 1-866-980-3434 / International +47 51 63 25 00 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer xscale_typecast.patch Description: xscale_typecast.patch arm_jtag_typecast.patch Description: arm_jtag_typecast.patch at91sam3_init.patch Description: at91sam3_init.patch jim_init.patch Description: jim_init.patch ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] build openocd for arm
Yu, IMHO this has to do with the way arm_jtag.h is doing some obfusticated casts. IIRC I posted a patch to this list a couple of months ago. I ran into the same problem when compiling for MIPS. Nico Coesel -Oorspronkelijk bericht- Van: openocd-development-boun...@lists.berlios.de namens Yu Li Verzonden: za 4/24/10 15:44 Aan: openocd-development@lists.berlios.de Onderwerp: [Openocd-development] build openocd for arm hi, i want to build openocd that can run on arm9. i use, $ CC=arm-linux-gcc ./configure --prefix=/opt/arm-openocd --build=i686-pc-linux-gnu --host=arm-linux --target=arm-linux --enable-parport --enable-maintainer-mode $ make but i got the error arm_jtag.h: 81: error: cast increases required alignment of target type. even though i delete the -Werror option in Makefile, the error still holded. someone help me please. My enviroment gcc v4.3.2 openocd v0.4.0 Vmware kubuntu 9.04 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] GPL violations
-Original Message- From: openocd-development-boun...@lists.berlios.de [mailto:openocd- development-boun...@lists.berlios.de] On Behalf Of freddie_cho...@op.pl Sent: donderdag 8 april 2010 13:02 To: openocd-development@lists.berlios.de Subject: [Openocd-development] GPL violations I've recently wrote that I know of 4 GPL violations (distributing OpenOCD with ftd2xx library). Make that 5 now... Since there are NO activities from the most dedicated GPL-fans, than maybe I'll just post such version on my webpage too? Freddie, IMHO its in everyone's best interest if you describe what and where the GPL violations are. People can then decide whether your findings are GPL violations and what to do about them. Hear no evil - see no evil is not going to work. Nico ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] usb speed with fedora 12 slowed down
-Original Message- From: openocd-development-boun...@lists.berlios.de [mailto:openocd- development-boun...@lists.berlios.de] On Behalf Of Gene Smith Sent: woensdag 17 maart 2010 3:50 To: openocd-development@lists.berlios.de Subject: [Openocd-development] usb speed with fedora 12 slowed down I have been using openocd on an older fedora 8 machine and get OK speeds and responsiveness. Insight debugger indicates a download speed of 11 Kbps when programming to flash (64k). Stepping is reasonably quick even with watch and/or memory windows open. However, I have needed to use the same versions of openocd and Insight on another machine running fedora 12 and it seems noticeably slower even though the processor is faster and it has more memory. The download speed is about 4 Kbps and stepping is very slow and almost painful if there are any watch or memory windows to update between steps. Also, opening the same size watch window (e.g., var with 256 array elements) seems to take quite a bit longer. In other respects the new machine is quite a bit faster, such as general responsiveness and time to compile programs. The new machine claims to have usb 2.0 ports. I should also mention that the new machine is 64bit while the old machine is 32bit. Openocd is compiled for 32bit. In both cases I am using the olimex-arm-usb-ocd device and using libusb and libftdi. I was wondering if anyone can suggest a way to troubleshoot or benchmark the usb ports on this machine to find out why they are slower than the old machine when running openocd. Gene, The first thing to look for is the CPU load during the transfer. This will tell you whether OpenOCD is busy or the machine is waiting for some hardware event. Nico Coesel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Problem when tryng to flash LPC2368
The first 64 bytes must always be erased. Try to use flashmagic instead of OpenOCD. These controllers use flash with ECC therefore you cannot program the flash partially / patch single bytes. Nico Coesel -Original Message- From: openocd-development-boun...@lists.berlios.de [mailto:openocd- development-boun...@lists.berlios.de] On Behalf Of Marcelo Utikawa da Fonseca Sent: woensdag 16 december 2009 13:54 To: openocd-development@lists.berlios.de Subject: Re: [Openocd-development] Problem when tryng to flash LPC2368 Hi again! I am still having problems to write the flahs in an LPC2368. Now I know that the first 64 bytes is never erased. There is always data in this area. 95% of the write errors are caused because the data is not correctly programmed in this area. In the J-Flash software, this area have data after a erase so I think that the data in this area is correct. I am using J-Link in both OpenOCD and J-Flash. I have tried a programmer derivated from axm0432 and I receive the same results... Could this be a bug in OpenOCD? It cannot write in this situation but J-Flash can so the problem is not in the hardware or the programmer because they are the same. Best regards, Marcelo Utikawa da Fonseca Marcelo Utikawa da Fonseca escreveu: Hi! First of all, I am new to this list. My name is Marcelo Fonseca. I work in a Brazilian design house and have experience with LPC21xx and LPC23xx from NXP and i.MX family from Freescale. I am having problems to write an LPC2368 with our custom board. I can write it with a J-Link and J-Flash software from Segger. In OpenOCD all seems to work but many times there are errors when trying to write the flash memory using the GDB. If I run a erase in the J-Flash software I have no error and OpenOCD succesfully write to the flash memory. When I run the flash erase_sector command in OpenOCD, J-Flash says that the flash is blank but I need to run a erase in J-Flash to write the flash using OpenOCD. PS.: sometimes I can write in OpenOCD without having to run a erase in J-Flash... Can anyone help me to solve this issue? Logs: Starting OpenOCD: $ sudo openocd -f jtec.cfg -f lpc2368.cfg [sudo] password for utikawa: Open On-Chip Debugger 0.2.0 (2009-12-14-11:51) Release $URL: http://svn.berlios.de/svnroot/repos/openocd/tags/openocd- 0.2.0/src/openocd.c $ For bug reports, read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS 100 kHz jtag_nsrst_delay: 100 jtag_ntrst_delay: 100 Info : device: 4 Info : deviceID: 67330064 Info : SerialNumber: S6 Info : Description: Dual RS232 A Info : JTAG tap: lpc2368.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4) Info : JTAG Tap/device matched Warn : EmbeddedICE version 7 detected, EmbeddedICE handling might be broken Starting GDB without run erase in J-Flash: arm-elf-gdb -x gdbinit_minilpc.conf GNU gdb 6.8 Copyright (C) 2008 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-elf. Setting up for the Tecnequip MiniLPC. The target is assumed to be little endian The target may not be able to correctly handle a memory-write-packet-size of 1024 bytes. Change the packet size? (y or n) [answered Y; input not from terminal] 0x1a04 in ?? () Loading section startup, size 0x204 lma 0x0 Loading section text, size 0x106f0 lma 0x204 Loading section .data, size 0x878 lma 0x108f4 Start address 0x0, load size 69996 Transfer rate: 3 KB/sec, 972 bytes/write. Breakpoint 1 at 0x234 Note: automatically using hardware breakpoints for read-only addresses. It never reaches main(). Starting GDB after a erase in J-Flash: arm-elf-gdb -x gdbinit_minilpc.conf GNU gdb 6.8 Copyright (C) 2008 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-elf. Setting up for the Tecnequip MiniLPC. The target is assumed to be little endian The target may not be able to correctly handle a memory-write-packet-size of 1024 bytes. Change the packet size? (y or n) [answered Y; input not from terminal] 0x7fffe152 in ?? () Loading section startup, size 0x204 lma 0x0 Loading section text, size 0x106f0 lma 0x204 Loading section .data, size 0x878 lma 0x108f4 Start address 0x0, load size 69996 Transfer rate: 3 KB/sec, 972 bytes/write. Breakpoint 1 at 0x234 Note
Re: [Openocd-development] Problem when tryng to flash LPC2368
Utikawa, There is also a Linux tool called lpc21isp to program lpc2000 devices (http://sourceforge.net/projects/lpc21isp/). Nico Coesel From: openocd-development-boun...@lists.berlios.de [mailto:openocd-development-boun...@lists.berlios.de] On Behalf Of Marcelo Utikawa da Fonseca Sent: woensdag 16 december 2009 14:47 To: openocd-development@lists.berlios.de Subject: Re: [Openocd-development] Problem when tryng to flash LPC2368 Thank you! I will try FlashMagic later because I do not have Windows on my PC. About the data in first 64 bytes I do not understand about them but they are in the flash! Please see the below logs showing this strange behaviour. I am using the telnet to send commands: FAX: 55-11-29412289 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Problem when tryng to flash LPC2368
-Original Message- From: openocd-development-boun...@lists.berlios.de [mailto:openocd- development-boun...@lists.berlios.de] On Behalf Of Igor Skochinsky Sent: woensdag 16 december 2009 16:01 To: Marcelo Utikawa da Fonseca Cc: openocd-development@lists.berlios.de Subject: Re: [Openocd-development] Problem when tryng to flash LPC2368 Hello Marcelo, What you see is bootrom code that gets automatically mapped to 0 if there is no user code or it's invalid. The interrupt vectors residing in the boot block of the on-chip flash memory also become active after reset, i.e., the bottom 64 bytes of the boot block are also visible in the memory region starting from the address 0x . The reset vector contains a jump instruction to the entry point of the flash boot loader software. LDR R4, =0x3FFF8000 0004 LDR R5, =0xBFFF 0008 LDR R6, [R4] 000C AND R6, R5, R6 0010 STR R6, [R4] 0014 LDR PC, =0x7FFFE040 0x7FFFE040 is the bootrom entrypoint. 3.1.1 Criterion for Valid User Code Criterion for valid user code: The reserved ARM interrupt vector location (0x 0014) should contain the 2's complement of the check-sum of the remaining interrupt vectors. This causes the checksum of all of the vectors together to be 0. The boot loader code disables the overlaying of the interrupt vectors from the boot block, then checksums the interrupt vectors in sector 0 of the flash. If the signatures match then the execution control is transferred to the user code by loading the program counter with 0x . Hence the user flash reset vector should contain a jump instruction to the entry point of the user application code. My guess is that FlashMagic automatically patches the checksum to be correct. IIRC OpenOCD should do this or has this function been deleted? I recall some discussion about that but I don't remember the outcome. I can't imagine OpenOCD doesn't calculate the checksum. All compiler / linker tools more or less assume the programming software takes care of creating the checksum. Nico Coesel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Codecheck
-Oorspronkelijk bericht- Van: openocd-development-boun...@lists.berlios.de namens Øyvind Harboe Verzonden: wo 12/16/09 21:43 Aan: Thomas Kindler CC: openocd-development@lists.berlios.de Onderwerp: Re: [Openocd-development] Codecheck On Wed, Dec 16, 2009 at 9:36 PM, Thomas Kindler mail+...@t-kindler.de wrote: Carsten Breuer wrote: The first thing i had to learn was, that it is verry uncommon in OpenOCD to check the result of malloc. This is a known problem where we gladly accept patches to fix each case. OK, then i will start to fix all the mallocs that are handled not correct yet and where i understand what to do if they fail. On a normal, modern operating system, (reasonably sized) mallocs should never fail, as the system will start thrashing and killing off processes long before malloc() fails. (This will be a different story for the Zy1000, of course..) The zy1000 has infinite ram w.r.t. small allocations(32 or 64mBytes depending on revision), so not checking small allocations is *highly unlikely * to cause problems for any embedded host with oodles of ram(megabytes). On Linux you'll get strange effects when a systems runs out of memory due to memory leaks. Google for oom killer and learn Linux keeps working (!) in mysterious ways. It took us a while to figure out what was going on exactly. Nico Coesel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] multiple JTAG interfaces
-Oorspronkelijk bericht- Van: openocd-development-boun...@lists.berlios.de namens Øyvind Harboe Verzonden: di 12/8/09 22:33 Aan: Zach Welch CC: openocd-development Onderwerp: Re: [Openocd-development] multiple JTAG interfaces I'm also concerned about such a major change as introducing support for multiple interfaces where I have yet to hear anybody actually needing to do such a thing in-process. It greatly improves the architecture for sure and the code will be more pleasurable to read work on, important in an open source project in itself. I would put symmetric parallel processing way above it, but I have yet to hear such requests even. Good point. On my programmer project I'm using 8 independent JTAG interfaces simultaneously. I simply have 8 OpenOCD instances running from inittab. The GUI has a telnet connection to each OpenOCD instance and controls programming from there. Having the possibility to connect to multiple JTAG interfaces at the same time may not be necessary. Having the OS deal with time sharing / multitasking is also a good idea. I did some tweaking on the scheduling (sleep calls and less calls to the time checking routines) of OpenOCD to make it consume the least amount of time. Is there a good reason for OpenOCD to be able to connect to multiple JTAG interfaces at the same time? There is a lot of work involved and judging from how OpenOCD is organised now, seperate threads are the easiest way to achieve this. Paying dearly for proper cross platform mutexes, signals and thread creation though. Nico Coesel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Radically improving out of the boxperformance for armX
-Original Message- From: openocd-development-boun...@lists.berlios.de [mailto:openocd- development-boun...@lists.berlios.de] On Behalf Of Øyvind Harboe Sent: vrijdag 27 november 2009 7:59 To: openocd-development@lists.berlios.de Subject: [Openocd-development] Radically improving out of the boxperformance for armX How about enabling fast/DCC memory transfers by default? We could document a requirement that a correct target script would disable fast/DCC memory transfers if necessary. How would that affect users that a new to OpenOCD? If there is a possibility that they run into trouble then it would be better to leave it off and print a message instead OR implement a fall-back scenario that tries to use DCC first and then fall back to the standard transfer method. Otherwise you'll see the same question repeated over and over on the OpenOCD mailing list: 'why isn't it working?'. Nico Coesel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Openocd vrs Commercial jtag dongles
-Original Message- From: openocd-development-boun...@lists.berlios.de [mailto:openocd- development-boun...@lists.berlios.de] On Behalf Of Duane Ellis Sent: zaterdag 21 november 2009 16:42 To: Openocd-Dev Subject: [Openocd-development] Openocd vrs Commercial jtag dongles Recently, I've been using quite a few commercial jtag tools from chip vendors. One thing I've noticed is that they all have implement the design with an small usb-controller + FPGA of some type (typically a xilinx spartan). I can see the real benefit, they download and flash the target at an unbelievable speed, ie: couple seconds for 256K of data. In contrast, non-fpga solutions, (bitbang ftdi, etc) are much slower overall. My guess is they are creating a hugely fast chip specific download engine they just feed data bytes to - and it operates at some hugely fast speed (that probably helps) In theory, the dongle has 2 modes, simple slow bitbang - once the target is determined, download an acceleration engine the fpga. The debugger step-in/over/line/etc rate with these tools is so fast... perhaps they have have implemented some common tasks like step and register dump type sequences in the dongle's fpga. Watch windows are for example very snappy. Sadly, that also requires a lot of engineering expertise to write that fpga code. in the cases I've seen [ie: vendor supplied tools] the chip companies also have a large pool of people who know or understand verilog/vhdl and can write such fpga code. The FPGA isn't that difficult. I've created a similar setup using OpenOCD. The biggest problem I had was that OpenOCD is spending most of its time creating JTAG bit streams. Its not the bit-banging that takes most of the time! On a 333MHz platform it took about 15 minutes to program 180kB into flash (with an FPGA for the JTAG interface!). To get more speed I created pre-defined JTAG commands for memory write and memory read and fill in the blanks (address and data) when necessary (very target specific ofcourse!). This reduced the programming time to a few seconds. I guess the effect will be less on a PC, but I think it might be worth to do some profiling. This could be made into a generic solution if OpenOCD would support a caching mechanism that allows patching existing JTAG bit streams. Nico Coesel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Embedding OpenOCD on low endmicrocontroller.
-Original Message- From: openocd-development-boun...@lists.berlios.de [mailto:openocd- development-boun...@lists.berlios.de] On Behalf Of David Brownell Sent: zaterdag 14 november 2009 20:26 To: openocd-development@lists.berlios.de Subject: Re: [Openocd-development] Embedding OpenOCD on low endmicrocontroller. On Friday 13 November 2009, Martín Sebastián Baudino wrote: But now I'm been asked to look at the code and see if it is possible to actually embed it on an STR7 board, which we use to automatically test other boards. Our goal would be (for now) to just flash another ARM microcontroller with a small program, to test some peripherals like UARTs and SPIs. At first hand, I don't see this as a trivial task, and I'd like to ask for your advice, since you know the code and are surely more experienced with it than I am. I think you'll find that OpenOCD relies on a bunch of other infrastructure, and you'd need to start by finding what parts of that already exist. TCP networking, file system access, and I/O to the JTAG adapter are places to start. As noted already, one trivial solution is to build on top of Linux. You would have a little work to drive the JTAG Linux is the way to go. Altough you might be able to do without. This depends whether your environment is POSIX / BSD sockets compliant. I have created such an environment on an ARM7TDMI and I do manage to get some Linux applications to compile (for example an SSL stack). Stuff like file I/O needs to be disabled or worked around. efficiently -- SPI can give you high speed shift operations, and GPIOs can solve the state changes -- but this is is well within the capabilities of a 32-bit uC once the other software support is resolved. Getting fast JTAG isn't really an issue. I'm using OpenOCD on a 330MHz MIPS platform (together with a fast buffered JTAG interface in an FPGA). It turns out 99% of the time is spend putting the JTAG stream together. If I used bit-banging it wouldn't have made a difference. I solved this by bypassing the OpenOCD JTAG core for most used JTAG operations. Nico Coesel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] CRC check timeout
-Original Message- From: openocd-development-boun...@lists.berlios.de [mailto:openocd- development-boun...@lists.berlios.de] On Behalf Of David Brownell Sent: dinsdag 3 november 2009 21:39 To: openocd-development@lists.berlios.de Cc: Pieter Conradie Subject: Re: [Openocd-development] CRC check timeout On Tuesday 03 November 2009, Øyvind Harboe wrote: Should we include this fix for 0.3? Only if it's updated to comment that it *still* makes an unwise assumption about target clock rate. If it's running with a 32 KHz clock, will that timeout be long enough? How about 8 KHz? Or lower? :) IMHO a timeout which depends on several unknown variables should be implemented otherwise. Perhaps the CRC routine can be modified to reset the time-out for every 1024 bytes/words/dwords. This should give little overhead but absolute certainty a timeout will only occur due to an error. Nico Coesel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Boundry scan (or similar)
I need to find out which pin on my board the chip's uart rx line is connected to. My chip is a s3c2410 (arm920t). I can connect through jtag and execute openocd commands. Is there any way to get some output on a certain pin of the chip through jtag? Something boundry-scan like that I can then probe all the pads I have available to find out which one is the uart rx. How do i go about toggling output on a certain pin (it's pin is k17 - RXD0/GPH3) through openocd? David, You can use the mww (and similar) commands to write to the special function registers from OpenOCD. Nico Coesel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD GUI
-Original Message- From: openocd-development-boun...@lists.berlios.de [mailto:openocd- development-boun...@lists.berlios.de] On Behalf Of Michael Schwingen Sent: dinsdag 20 oktober 2009 8:48 To: openocd-development@lists.berlios.de Subject: Re: [Openocd-development] OpenOCD GUI Dean Glazeski wrote: Another thing of interest is a feature list. I've started a feature list in this email and additions are welcome. I don't see how a GUI will improve my work in any of these areas: 1. OpenOCD server configuration a. Telnet Port b. GDB Port c. TCL Port d. Target Type e. Interface I need to write a custom board config file in most cases. A GUI won't help me set up SDRAM controller registers and other board details. 2. Start and stop OpenOCD with log output to window a. Colored output for errors, info, etc. Reduce the number of printed messages. Those remaining don't need any colouring in order to be understandable. 3. Connect to OpenOCD to issue commands a. Perhaps a list of available commands filtered based on target and interface b. Target status display c. Multiple windows for multiple targets/interfaces How would the GUI know about the target and interface configs I have written? I think xterm+telnet provide everything that is needed in this category. 4. Target flashing/loading of programs I usually add a do_flash procedure to my board scripts - a GUI can't provide much improvement here. I do think GUIs are fine for the right job - eg. for a debugger. A GUI that replaces simple commands with buttons does not provide much merit for me. IMHO a GUI is a good idea but it has to be cross-platform. I have been using WxWidgets for cross platform development for several years and I must say the transfer between Windows and Linux is seemless. I don't think a GUI is usefull for debugging because OpenOCD is a man-in-the-middle. A GUI will be usefull though for testing setups and flash programming. Console commands are fine for pro's but for a beginner a GUI is much easier. Perhaps there should be a log window which shows the commands send to OpenOCD. Nico Coesel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD GUI
-Original Message- From: Øyvind Harboe [mailto:oyvind.har...@zylin.com] Sent: dinsdag 20 oktober 2009 9:33 To: Nico Coesel Cc: openocd-development@lists.berlios.de Subject: Re: [Openocd-development] OpenOCD GUI IMHO a GUI is a good idea but it has to be cross-platform. I have been using WxWidgets for cross platform development for several years and I must say the transfer between Windows and Linux is seemless. Cross platforms w/dependencies during compilation or running is not great either. The GUI doesn't need to be part of OpenOCD. For now the consensus(Duane and I have mostly discussed this in the past) is a built in web server for basic operations and special pages for target specific peripherals. Take the builtin httpd server for a spin. Does the httpd server support PHP, database access, sessions, cookies, etc, etc? Without that the functionality of a builtin webserver is extremely limited because it is very cumbersome to make active web-pages. Nico Coesel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Cross compiler for ARM7 bare metal
Jon, Gnu ld has the option -nostartfiles to stop it from including startup files so you can have your own startup sequence. Next you'll need a really small C library. Forget about uclibc. I've compiled the small C library from MSPGCC (for TI's msp430) for ARM. This should get you executables with a reasonable size. Nico Coesel -Oorspronkelijk bericht- Van: openocd-development-boun...@lists.berlios.de namens Jon Smirl Verzonden: do 10/8/09 23:33 Aan: openocd-development@lists.berlios.de Onderwerp: [Openocd-development] Cross compiler for ARM7 bare metal Can someone help me out and point me to a working cross toolchain for arm7tdmi with uclibc or equivalent on Linux? I've got a working glib setup but it keeps linking in 900KB of run-time code. I've spent all day searching and playing with buildroot and I can't achieve a working environment. -- Jon Smirl jonsm...@gmail.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] GNU savannah
-Original Message- From: Øyvind Harboe [mailto:oyvind.har...@zylin.com] Sent: dinsdag 6 oktober 2009 14:39 To: Nico Coesel Cc: openocd-development@lists.berlios.de Subject: Re: [Openocd-development] GNU savannah The page looks like it has been written by people that have a very limited view on the real world. I'd like OpenOCD to stay open for any OS. Free, dedicated resources w/no advertisement followed up by diligent people powered by enthusiasm. *AND* you don't want them to be nut-jobs? :-) Good luck finding that! I mean nut-jobs in a good sense here and I would proudly count myself amongst them. This part of the terms made my alarm bells to turn on: * No proprietary dependencies: your project * must work on a completely free operating system. Find free replacements for your non-free dependencies. Develop and test your Java applications with IcedTea? (OpenJDK?), and your .Net ones with DotGNU (or other free alternatives). See JavaIssues. * Runs primarily on a free operating system. Proprietary platforms such as Microsoft Windows should be considered as secondary targets, and cannot provide additional features over the ports to free OSes. Terms like these are not good for any open source software project. One of my rules is to stay away from (groups of) people that exclude for no good reason. Nico Coesel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Moving to git
1. Berlios svn will be made read only and the svn head will be deleted, leaving behind only a README w/reference to the openocd project at sourceforge. The entire svn history will remain available on Berlios indefinitely. Question from a dumb-ass: Is the entire repository (including all branches and tags) moved to SF or just head? Nico Coesel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] GNU savannah
-Original Message- From: openocd-development-boun...@lists.berlios.de [mailto:openocd- development-boun...@lists.berlios.de] On Behalf Of Strontium Sent: dinsdag 6 oktober 2009 14:25 Cc: openocd-development@lists.berlios.de Subject: Re: [Openocd-development] GNU savannah As per: https://savannah.gnu.org/maintenance/HowToGetYourProjectApprovedQuickly The page looks like it has been written by people that have a very limited view on the real world. I'd like OpenOCD to stay open for any OS. Nico Coesel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OUT macro redefined under MinGW
From: openocd-development-boun...@lists.berlios.de [mailto:openocd- development-boun...@lists.berlios.de] On Behalf Of David Brownell Sent: dinsdag 29 september 2009 20:44 To: simon qian Cc: openocd-development@lists.berlios.de Subject: Re: [Openocd-development] OUT macro redefined under MinGW On Tuesday 29 September 2009, simon qian wrote: OUTPUT doesn't conflict with system header files. I checked in a fix. But I recommend to use MODULE_X to define a macro, so it will never conflict with anything. After all, IN, OUT, OUTPUT, INPUT and COUNTER are commonly used. The real bug here is that the MinGW system headers (or is it Win32?) chose to pollute global namespaces. Yeah, I know it's unrealistic to expect standard coding discipline from the Win32 system headers. But it's fair to point out the root causes of bugs. ;) OT: In that case the creators of Xfree / tinyx also deserve a kick in the nuts for defining index in the include files. Now I really know how many applications have a variable name called 'index'. Nico Coesel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] A few thoughts on OpenOCD long term goals
-Original Message- From: openocd-development-boun...@lists.berlios.de [mailto:openocd- development-boun...@lists.berlios.de] On Behalf Of Øyvind Harboe Sent: zondag 20 september 2009 19:53 To: openocd-development@lists.berlios.de Subject: [Openocd-development] A few thoughts on OpenOCD long term goals One of my goals w/OpenOCD is that it becomes yet another thing that hardware vendors have to check off on the GCC toolchain list. Not having OpenOCD support should be like not having GDB support. This is a long way off, but it's something to aspire to. Just keep pushing. We are looking for a SoC for a new platform and we are basically saying that only devices with OpenOCD support are considered. It would be nice to have support for other targets than ARM, and we're doing well w/MIPS, but we really need a significantly bigger community or direct support from hardware vendors (the gorillas get things for free, the chimps don't...) to boast equally broad MIPS support as ARM support. Either that or ARM support has to reach a point of maturity where MIPS can start to catch up. Then again ARM is messier I don't know if MIPS is something to give much concern. IMHO MIPS is a dead platform unless the PIC32 is catching on which is unlikely since ARM devices are way ahead. Freescale's Coldfire would be much more interesting. I know Freescale is having a very hard time selling the Coldfire due to lack of Open Source tools support. The price of the devices is right, but the tooling is not. Eventually I hope that we'll be able to identify some killer features that closed source solutions just don't offer and that it will become uneconomical to implement from scratch for each JTAG debugger. I don't really know what those features might be though. Some ideas: - Threads support(e.g. eCos, FreeRTOS, etc. threads) - Profiling support(??) there is profiling support in OpenOCD now, but I haven't heard about anyone using it. - Connect up to other GPL code. We're already connected to GDB as much as we should be... What else? - Killer FPGA soft CPU workflow support(not quite sure what that means yet :-) I think the best feature is that it just works. A lot of software does not have that feature! Nico Coesel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] A few thoughts on OpenOCD long term goals
-Original Message- From: openocd-development-boun...@lists.berlios.de [mailto:openocd- development-boun...@lists.berlios.de] On Behalf Of Øyvind Harboe Sent: maandag 21 september 2009 11:28 To: Jiří Kubias Cc: openocd-development@lists.berlios.de Subject: Re: [Openocd-development] A few thoughts on OpenOCD long term goals I've heard this concern many times, but I guess at the end of the day experienced embedded engineers have an edge Embedded development *is* quite involved... Also tools are quite rough around the edges because any particular MCU has a very narrow audience. True. I always tell people not to debug on embedded targets but test the software on a PC first. A PC will always have superior debugging and functional verification facilities. Nico Coesel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD current SVN regression on s3c6410
-Original Message- From: openocd-development-boun...@lists.berlios.de [mailto:openocd- development-boun...@lists.berlios.de] On Behalf Of Harald Welte Sent: dinsdag 8 september 2009 11:20 To: Øyvind Harboe Cc: openocd-development@lists.berlios.de Subject: Re: [Openocd-development] OpenOCD current SVN regression on s3c6410 On Tue, Sep 08, 2009 at 08:48:58AM +0200, Øyvind Harboe wrote: Does anyone have an s3c6410 PCB out there they could donate to us? unfortunately Openmoko is no longer working on the 6410 based phone, otherwise we could have tried to get one. The SMDK6410 are quite expensive (typical old-fashioned reference boards with expensive connectors and dozens of peripherals), so I think it's unlikely somebody will cough one up. What I would personally contribute is a SmartQ5 device (less than USD 200), but I don't know if people have figured out which test pads or other unpopulated connectors to use for JTAG. If somebody can suggest a relatively inexpensive 6410 based mass-market product tha thas known JTAG locations, I'd donate one to OpenOCD. Harald, I came across these boards. Prices seem reasonable. http://www.developmentboard.net/index.php/productdetail/Development+board/ARM11/SAMSUNG/S3C6410/MINI6410/info/1 Nico Coesel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Enhancement proposal: progress output whenflashing
I'm actually doing this in a GUI application. If you set the debug_level to 2 you'll see the progress. -Original Message- From: openocd-development-boun...@lists.berlios.de [mailto:openocd- development-boun...@lists.berlios.de] On Behalf Of Luca Ottaviano Sent: dinsdag 25 augustus 2009 10:28 To: openocd-development Subject: [Openocd-development] Enhancement proposal: progress output whenflashing Hi all, it would be nice for Openocd to output the progress when flashing a target, something like mplayer does. Two use cases I'm thinking of are command line users, who will see activity report, and other processes (eg. GUIs) which can launch Openocd in background and report progress to the user by parsing Openocd output. What do you think? Best regards, -- Luca Ottaviano lottavi...@develer.com BeRTOS developer - http://dev.bertos.org ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD for Windows issues
I'm seeing the signals as well. People start to complain about the OpenOCD Windows build lacking ftdi support. Just don't shoot the messenger. Nico Coesel -Oorspronkelijk bericht- Van: openocd-development-boun...@lists.berlios.de namens Øyvind Harboe Verzonden: ma 8/24/09 18:16 Aan: Freddie Chopin CC: openocd-development Onderwerp: Re: [Openocd-development] OpenOCD for Windows issues On a more serious note: such build instructions is one of the recommended and acceptable approaches to mitigating the problem. -- Ø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 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] remove gcc warning
I'm not sure it is as simple as changing the casts. I suspect you are *not* compiling for PC? IMHO: The problem is that the buffers may not be aligned on word boundaries. This may result in problems on platforms which have a strict alignment. Another problem is that it may result in code which is very slow because words are read byte by byte. So the other part of the solution is to make sure all buffers are aligned to word boundaries. This is quite a bit of work though. Nico Coesel -Original Message- From: openocd-development-boun...@lists.berlios.de [mailto:openocd- development-boun...@lists.berlios.de] On Behalf Of Hiroshi Ito Sent: dinsdag 18 augustus 2009 13:13 To: openocd-development@lists.berlios.de Subject: [Openocd-development] [PATCH] remove gcc warning arm_jtag.h: In function `arm7flip32': arm_jtag.h:64: warning: cast increases required alignment of target type arm_jtag.h: In function `arm_le_to_h_u32': arm_jtag.h:70: warning: cast increases required alignment of target type ... I made 3 patch files, all warnings are same, but way of fixing are different. patch1: Cast from uint32_t * to uint8_t *. patch2: use union patch3: uint8_t * = ulong = uint32_t * tested with gcc 3.4.5 and 4.4.0. Hiroshi Ito Media Lab. Inc., URL http://www.mlb.co.jp ( Sorry, Japanese only. ) TEL +81-3-5294-7255 FAX +81-3-5294-7256 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] linux console will not out when openocdresume
I don't think this is an openocd issue. The kernel has numerous interrupts running. Generally speaking you can't halt a piece of software that uses interrupts and expect it to resume normally. Nico Coesel -Original Message- From: openocd-development-boun...@lists.berlios.de [mailto:openocd- development-boun...@lists.berlios.de] On Behalf Of loody Sent: donderdag 13 augustus 2009 9:35 To: R.Doss Cc: Openocd-Dev Subject: Re: [Openocd-development] linux console will not out when openocdresume HI: 2009/8/13 R.Doss d...@gmx.de: What do you undersand for linux? The kernel or also all around? You need a bootloader and a rootfilesystem in addition to the kernel. Thanks for your reply. Maybe I need to describe my environment more clearly. I use initramfs as my root file system and use openocd to upload the whole kernel image, include root file system, to dram. Then set the pc to the kernel entry point, then execute. It works fine and I can get the console out. But my problem is if I halt openocd at this time then resume, the console will not get back. Sometimes I need to wait at least 1 min to get the console back, and sometimes it is fail. Is there any setting I need to take care? appreciate your help, miloody ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Jlink MIPS CPU issue
Stephan, This is due to the bug in the Jlink driver I reported earlier! The stableclocks JTAG command is not implemented in the Jlink driver. This can be fixed by copy pasting some code from another driver. Nico Coesel -Oorspronkelijk bericht- Van: openocd-development-boun...@lists.berlios.de namens Stephan Winokur Verzonden: zo 8/9/09 00:44 Aan: openocd-development@lists.berlios.de Onderwerp: [Openocd-development] Jlink MIPS CPU issue Hi there, I'm trying to use a v7 Jlink board with a MIPS based board. I'm seeing an error message when I try to halt it, as shown below. (The board does seem to halt, based on activity stopping on the serial port, but at that point openocd has already exited.) thanks! Debug: 106 9467 target.c:1955 handle_halt_command(): - Debug: 107 9467 mips_m4k.c:223 mips_m4k_halt(): target-state: running Debug: 108 9549 mips_ejtag.c:198 mips_ejtag_enter_debug(): ejtag_ctrl: 0x4004c008 Error: 109 9819 jlink.c:232 jlink_execute_command(): BUG: unknown JTAG command type encountered ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Strange problem with LPC2103
-Original Message- From: openocd-development-boun...@lists.berlios.de [mailto:openocd- development-boun...@lists.berlios.de] On Behalf Of Freddie Chopin Sent: zaterdag 18 juli 2009 16:07 To: openocd-development Subject: Re: [Openocd-development] Strange problem with LPC2103 I found some time to investigate that problem. Nico Coesel pisze: At which frequency is your LPC2103 running and which core voltage? After reset 12MHz and the voltages are standard - 3.3V an 1.8V. After some inits - 72MHz (max). At higher frequencies the chip may show strange behaviour due to the core supply voltage dropping too much (NXP has an errata sheet on this). I've checked that, but my revision of LPC2103 doesn't have that bug. Moreover - the code works perfectly in normal conditions - that failure is there ONLY when debugging. What actually helped was specifically disabling MAM via GDB after reset. The soft_reset_halt doesn't do that, and that was the problem. I need to add: monitor mww 0xE01FC000 0 to a GDB startup commands and then everything is fine. Do you think that disabling MAM should be added in some way to soft_reset_halt procedure? Did you try to relax the MAM timing (more waitstates)? The errate sheet does mention some problems with the MAM without a work around. I don't know if switching off the MAM is something that you want. This slows the device down considerably so you are not debugging the software at it actual speed. Nico Coesel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Strange problem with LPC2103
-Original Message- From: openocd-development-boun...@lists.berlios.de [mailto:openocd- development-boun...@lists.berlios.de] On Behalf Of Freddie Chopin Sent: zaterdag 18 juli 2009 16:07 To: openocd-development Subject: Re: [Openocd-development] Strange problem with LPC2103 I found some time to investigate that problem. Nico Coesel pisze: At which frequency is your LPC2103 running and which core voltage? After reset 12MHz and the voltages are standard - 3.3V an 1.8V. After some inits - 72MHz (max). At higher frequencies the chip may show strange behaviour due to the core supply voltage dropping too much (NXP has an errata sheet on this). I've checked that, but my revision of LPC2103 doesn't have that bug. Moreover - the code works perfectly in normal conditions - that failure is there ONLY when debugging. What actually helped was specifically disabling MAM via GDB after reset. The soft_reset_halt doesn't do that, and that was the problem. I need to add: monitor mww 0xE01FC000 0 to a GDB startup commands and then everything is fine. Do you think that disabling MAM should be added in some way to soft_reset_halt procedure? Freddie, Good question. The errata sheet does mention some problems with the flash and the MAM depending on code location. Did you try to relax the MAM timing? Turning the MAM off reduces the performance considerably. Nico Coesel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Benchmark data for various JTAG debuggers
Some more figures on the parallel port Wiggler interface and the target I'm working with: OpenOCD 0.1.0: Erase: 90 s Program: 651 s OpenOCD 0.2.0: Erase: 79 s Program: 544 s It seems 0.2.0 is at least 10% faster while using the same configuration. Another thing I need to mention is that my 0.1.0 contains some other improvements that make it a few % faster than the vanilla 0.1.0. Nico Coesel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Strange problem with LPC2103
Freddie,
At which frequency is your LPC2103 running and which core voltage? At
higher frequencies the chip may show strange behaviour due to the core
supply voltage dropping too much (NXP has an errata sheet on this). You
can try to reduce the clock frequency to +/- 20MHz and shut down all
unused peripherals as a test.
Nico Coesel
-Original Message-
From: openocd-development-boun...@lists.berlios.de [mailto:openocd-
development-boun...@lists.berlios.de] On Behalf Of Freddie Chopin
Sent: woensdag 8 juli 2009 19:43
To: openocd-development
Subject: [Openocd-development] Strange problem with LPC2103
I have a very simple code which just blinks the LED. The code itself
is
fine.
When I upload the code and just run it everything is fine. When I try
to
debug the same code that I've uploaded before (flash is not modified)
some registers have some funny values which make the code work wrong.
When I close OpenOCD and reset the chip again everything works fine...
WTF?
I've done some investigation and everything is even stranger...
I use GDB Hardware Debugging plugin in Eclipse. I put a breakpoint at
main.
When the core hits the breakpoint I inspect the registers:
reg
(11) r11 (/32): 0x41F9 (dirty: 0, valid: 1)
(13) r13_usr (/32): 0x41EC (dirty: 0, valid: 1)
R11 and SP are the register that miraculously have such strange
values,
because before main there are just three lines that modify them:
0x00e8 main: push {r11, lr}
0x00ec main+4: add r11, sp, #4 ; 0x4
0x00f0 main+8: sub sp, sp, #8; 0x8
(the SP is setup in the startup of course, the value for that is
0x4200. That's pretty easy to count that R11 should be 0x41FC
and SP should be ...1F0.
Now the funny part... When I put my first breakpoint at Reset_Handler
(that's exactly what you think), and then put breakpoint at the first
line that modifies R11 (the first one of the three above) everything
works... The reg dump at the same point as before (3 lines further, at
the beginning of main):
(11) r11 (/32): 0x41FC (dirty: 0, valid: 1)
(13) r13_usr (/32): 0x41F0 (dirty: 0, valid: 1)
When I reset and stop at Reset_Handler, then run to main directly
without that breakpoint in-the-middle - the reg values are wrong /;
I've tried OpenOCD-r2498, 0.1.0 and some revs in between - the same
I've tried GDB from the most recent CodeSourcery and from some older
version of Yagarto - the same.
When I close OpenOCD and reset the chip the code works fine. During
the
whole process the contents of flash were exactly the same...
Any ideas? Any help? Who should I blame?
Thx in advance...
4\/3!!
full register dump at the beginning of main (only R11 and SP are
different...):
WRONG:
(0) r0 (/32): 0x00E8 (dirty: 1, valid: 1)
(1) r1 (/32): 0x4000 (dirty: 1, valid: 1)
(2) r2 (/32): 0x4000 (dirty: 0, valid: 1)
(3) r3 (/32): 0x4000 (dirty: 0, valid: 1)
(4) r4 (/32): 0x (dirty: 0, valid: 1)
(5) r5 (/32): 0x (dirty: 0, valid: 1)
(6) r6 (/32): 0x (dirty: 0, valid: 1)
(7) r7 (/32): 0x (dirty: 0, valid: 1)
(8) r8 (/32): 0x (dirty: 0, valid: 1)
(9) r9 (/32): 0x (dirty: 0, valid: 1)
(10) r10 (/32): 0x (dirty: 0, valid: 1)
(11) r11 (/32): 0x41F5 (dirty: 0, valid: 1)
(12) r12 (/32): 0x (dirty: 0, valid: 1)
(13) r13_usr (/32): 0x41E8 (dirty: 0, valid: 1)
(14) lr_usr (/32): 0x00B0 (dirty: 0, valid: 1)
(15) pc (/32): 0x00F4 (dirty: 1, valid: 1)
(16) r8_fiq (/32): 0x (dirty: 0, valid: 0)
(17) r9_fiq (/32): 0x (dirty: 0, valid: 0)
(18) r10_fiq (/32): 0x (dirty: 0, valid: 0)
(19) r11_fiq (/32): 0x (dirty: 0, valid: 0)
(20) r12_fiq (/32): 0x (dirty: 0, valid: 0)
(21) r13_fiq (/32): 0x (dirty: 0, valid: 0)
(22) lr_fiq (/32): 0x (dirty: 0, valid: 0)
(23) r13_irq (/32): 0x (dirty: 0, valid: 0)
(24) lr_irq (/32): 0x (dirty: 0, valid: 0)
(25) r13_svc (/32): 0x4200 (dirty: 0, valid: 0)
(26) lr_svc (/32): 0x7FFFE35F (dirty: 0, valid: 0)
(27) r13_abt (/32): 0x (dirty: 0, valid: 0)
(28) lr_abt (/32): 0x (dirty: 0, valid: 0)
(29) r13_und (/32): 0x (dirty: 0, valid: 0)
(30) lr_und (/32): 0x (dirty: 0, valid: 0)
(31) cpsr (/32): 0x6010 (dirty: 0, valid: 1)
(32) spsr_fiq (/32): 0x (dirty: 0, valid: 0)
(33) spsr_irq (/32): 0x (dirty: 0, valid: 0)
(34) spsr_svc (/32): 0x0010 (dirty: 0, valid: 0)
(35) spsr_abt (/32): 0x (dirty: 0, valid: 0)
(36) spsr_und (/32): 0x (dirty: 0, valid: 0)
(37) debug_ctrl (/6): 0x05 (dirty: 0, valid: 1)
(38) debug_status (/5): 0x09 (dirty: 0, valid: 0)
(39) comms_ctrl (/32): 0x4000 (dirty: 0, valid: 0)
(40) comms_data (/32): 0x (dirty: 0, valid: 0)
(41) watch 0 addr value (/32): 0x00F4 (dirty: 0, valid: 1)
(42) watch 0 addr mask (/32): 0x0003
Re: [Openocd-development] 0.2.0 release... on hold?
-Original Message- From: openocd-development-boun...@lists.berlios.de [mailto:openocd- development-boun...@lists.berlios.de] On Behalf Of Zach Welch Sent: woensdag 8 juli 2009 0:35 To: Øyvind Harboe Cc: openocd-development@lists.berlios.de Subject: Re: [Openocd-development] 0.2.0 release... on hold? On Wed, 2009-07-08 at 00:14 +0200, Øyvind Harboe wrote: We need to find some balance. Right now, the presses are too heavily biased toward development to the extent that release suffers badly. I definitely want to see a reset of the release timeout counter when we discover such problems as we have seen in the last week. The step bug alone would have made *all* the regression test scripts fail... I wouldn't even want to ask Michael Fischer to run the regression test suite without that one in place... Right, so I do want to make it clear that some of these are entirely legitimate bugs that you are fixing. No dispute about that. In that regard, I am happy to reset the release deadline while we consider the patches. However, there does need to be a limit to the number of resets that we allow for new issues. If I may be very blunt: I don't think we are very close to a 0.2.0 release. It seems (based on bug reports) the recent changes broke some of the existing functionality. That needs to be tested fixed first. IMHO release 0.2.0 should have at least the same functionality that 0.1.0 had. Nico Coesel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Recipe for Releases
-Original Message- From: openocd-development-boun...@lists.berlios.de [mailto:openocd- development-boun...@lists.berlios.de] On Behalf Of David Brownell Sent: donderdag 2 juli 2009 21:33 To: openocd-development@lists.berlios.de Subject: Re: [Openocd-development] Recipe for Releases On Thursday 02 July 2009, Zach Welch wrote: At this point, I will probably finish this release by hand, but I want to have the community check the recipe before I start using it. Have I missed anything important here? Hmm, I think one month between releases puts them kind of into the noise level. Too frequent. Folk barely have time to dive in before the next one is there... I'd remove the commitment to once-a-month and leave it open. Sometimes a month might be right. Sometimes more will be appropriate. I agree. Too frequent releases make it impossible to rely on a release. Also, it might be a good idea to patch bugs both in the svn head and the latest release. This gives a release a longer lifespan. Nico Coesel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Final Fixes for 0.2.0?
-Original Message- From: openocd-development-boun...@lists.berlios.de [mailto:openocd- development-boun...@lists.berlios.de] On Behalf Of Zach Welch Sent: dinsdag 30 juni 2009 12:13 To: openocd-development Subject: [Openocd-development] Final Fixes for 0.2.0? Hi all, We have reached the scheduled release window. Are we ready to jump through it, or do obstacles remain in our path? I would like to release the 0.2.0 Unless there is an unexpected flood of activity, I believe that I could push out a 0.2.0 source release in the next 24-48 hours. Otherwise, does the community know of any reason to hold this countdown? IIRC David Claffey commited a patch to speed up MIPS. I'm not sure whether it has been committed yet. If not I think it is safe to commit it to be included in 0.2.0. Nico Coesel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Creative summary of options for OpenOCDdistros
-Original Message- From: openocd-development-boun...@lists.berlios.de [mailto:openocd- development-boun...@lists.berlios.de] On Behalf Of Freddie Chopin Sent: woensdag 24 juni 2009 18:28 To: openocd-development Subject: [Openocd-development] Creative summary of options for OpenOCDdistros OK - be creative. End the flames, throw some ideas. Here goes another summary of REALISTIC and ACCEPTABLE options, if ftd2xx.dll will still be censored in the distributions. 1. Any kind of network protocol that would talk to driver. PRO - Possibilities to use JTAGs over internet to debug remotely, possibility to use closed-source drivers (for me that's a pro [; ) CONS - latency of the medium, need to run another program on one's PC, someone has to create the program and that has to be more complicated than the one from option 2. Freddy, Talking over de network may not be an option for Windows. A couple of years aho I worked on a portable (Linux / Windows) client - server application that used tcp/ip. On Linux this worked fine but on Windows XP we quickly learned that many short packets takes a lot of CPU power (even when send received on localhost). We ended up using a shared memory signals solution on Windows. A bit more cumbersome to write, but it performed very well. Nico Coesel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] proposed FASTDATA bulk write optimizationfor mips_m4k file transfers
From: openocd-development-boun...@lists.berlios.de [mailto:openocd-development-boun...@lists.berlios.de] On Behalf Of Nico Coesel Sent: woensdag 24 juni 2009 22:28 To: openocd-development@lists.berlios.de Subject: Re: [Openocd-development] proposed FASTDATA bulk write optimizationfor mips_m4k file transfers I'm itching to apply any patches on MIPS4K, but I can't really dive into MIPS support and provide useful feedback I could give the patches a spin on the MIPS platform I'm working with. I just don't know whether 'my' target has the FASTDATA register. I think I could give it a try for programming external flash first thing in the morning. I can't really promise anything though. I gave it a try but it doesn't apply to OpenOCD 0.1.0 (jtag_get_end_state missing). Nico Coesel ___ 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
I *know* there are hardware vendors out there that are aching to use OpenOCD together with closed source target support, and they *would* find any tiny loophole and throw money at lawyers to exploit it. Sorry to hijack this message. The whole situation made me wonder about MySQL several times. The MySQL license says that it is free when GPL is respected but you must pay if you want to use it in a commercial / closed source product. Nico Coesel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] License
-Original Message- From: openocd-development-boun...@lists.berlios.de [mailto:openocd- development-boun...@lists.berlios.de] On Behalf Of Zach Welch Sent: woensdag 24 juni 2009 1:10 To: Rick Altherr Cc: openocd-development@lists.berlios.de Subject: Re: [Openocd-development] License On Tue, 2009-06-23 at 15:45 -0700, Rick Altherr wrote: impact your mortgage or ability to make a living is false. You just seem to have a problem with someone else profiting from your free contribution regardless of what they have done to justify their price. Actually, I did not claim here that I myself am being hurt, merely that all of professional peers like me suffer from these exceptions because they provide a disincentive for the community to demand open solutions. So this is about *forcing* people/companies to pay in order to get open source projects fixed. (This is just a statement for clarification. It is not a judgement in any way!). I have offered my services repeatedly to those who need it to help resolve this situation with technical solutions. Instead, I am being asked to give up my GPL copyright claims on the work that I have done, without any compensation. Are you kidding me? Under what obligation am I required to help others that project from violating the GPL license? I think Magnus has a good point in saying that the exception for the FTDxx is already there. Not everything needs to be in writing in order to make it legal. If you allow something long enough then you are granting an extra right you can't suddenly revoke. I can see this going two ways: 1) adding the tcp/ip / named pipes interface which will allow connection to any closed source driver 2) grant *one* single explicit exception for the FTDxx driver Pick your poison :-))) Nico Coesel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] proposed FASTDATA bulk write optimizationfor mips_m4k file transfers
I'm itching to apply any patches on MIPS4K, but I can't really dive into MIPS support and provide useful feedback Part of my job description in OpenOCD is to be a recruiter and we're desperately short on active MIPS target experts. If the PIC32 catches on you should see more MIPS experts. offtopic anti-PIC rant deleted So if anyone out there have opinions about MIPS target code, you've been warned that I'll give this a cursory look and then commit it if I hear nothing in a day or two. I could give the patches a spin on the MIPS platform I'm working with. I just don't know whether 'my' target has the FASTDATA register. I think I could give it a try for programming external flash first thing in the morning. I can't really promise anything though. Nico Coesel ___ 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
There is the ideal world and the real world. - only 10% use both windows and Linux - about 95% use FTd2xx driver (on windows or linux). Before talking too much about GPL issue ... bla bla bla ... we should ask us some basic questions related to the success of OpenOCD project itself: bla bla bla. You, sir, show a big lack of respect for the license. Normally, I would not bother reading anything else that you have written, since you clearly do not respect the license of the code. I really think the GPL license must be respected , but we are all in the same world. And this world is never IDEAL as we want! It seems fairly clear that you do not want to respect it. You want an exception to it, which is not respect in my book. That's disrespect for it and the free software community in general. Is an Open Source project must be GPL at all? Is OpenOCD installed/used because it is Open Source, because it is GPL, or because it works ! I use and contribute to it because it is GPL. Period. OpenOCD sucks compared to some other tools -- you do realize that, right? I am trying Which tools? Also, the FTD2XX is just an important part of the success of OpenOCD ! Let's ask a more fundamental questions: Why should I care about what you think in these matters? What have you done for the community lately to earn our respect? Almost without exception, I have seen you Since when comes respect with a larger 'thingy'? Lets not get into a pissing contest. Discussions based on smarter, bigger, larger, more, faster, better, etc go nowhere. Lets keep playing the ball. I find these facts shockingly embarrassing for someone selling products and thus profiting from the open source community's work. Personally, I think you should be ashamed of yourself and your behavior; you help show the opposite of what an ideal free software contributor is. Reality does suck for us idealists; that does not mean we are wrong. I agree the JTAG dongle vendors could throw in some joint effort to make OpenOCD work within its license. Look, your past contributions to this project were appreciated, but nothing gives you the right to try to tell other developers how to manage their copyrights for the OpenOCD project. OpenOCD is GPL. That is reality, and you need to suck it up and deal with it. As I have told others, there are viable solutions, but there is absolutely zero chance that I will change my mind on this issue -- and that ends _any_ chances. You might as well be talking to a stone wall. You will change nothing. And here is the exact reason why the JTAG vendors are not going to put effort into OpenOCD. A marriage works both ways! I know I promised to contribute some go-along-the-road driver development documentation. The task of creating a driver for an FPGA JTAG accellerator is on my plate. However at the present I'm not sure if I'm willing to contribute any more. I'd rather contribute to an OpenOCD fork that is geared towards allowing as many people possible to use OpenOCD as conveniently as possible. Nico Coesel ___ 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
-Original Message- From: openocd-development-boun...@lists.berlios.de [mailto:openocd- development-boun...@lists.berlios.de] On Behalf Of Xiaofan Chen Sent: maandag 22 juni 2009 1:59 To: Zach Welch Cc: openocd-development@lists.berlios.de Subject: Re: [Openocd-development] FT2232 Windows - summary of options 2009/6/22 Zach Welch z...@superlucidity.net: On Sun, 2009-06-21 at 13:20 -0700, David Brownell wrote: On Sunday 21 June 2009, Audrius Urmanavičius wrote: I can also second Xiaofan, who offers distribution of .zip file with Cygwin building environment set up, probably with shell script that does `./bootstrap`, `./configure --with-ftd2xx-blahblah` and `make` there, so that Windows users with (almost) no linux experience could build openocd themselves in minutes. I can't see any particular issue with such a build kit. Of course it shouldn't include binaries of any kind. It should however be exactly equivalent to carefully written build instructions that include fetching the source (maybe both release 0.2.0 or SVN-head options) and libraries. Finally!! Someone came up with one of the legal workarounds! A build script can be distributed that automatically fetches every single component (including the compilers, if necessary) and builds all of the source code from scratch. This doesn't sound like a viable option. Way too complicated. Like others said: you really don't want this mailing list flooded with questions about installing OpenOCD. I must say there are very few questions about the installation op OpenOCD. This indicates the current installation process and documentation are fine. Lets not change that. This is simply a matter of doing the work, but I have done this for past projects for exactly these same reasons. This may seem like extra work, but the resulting distribution complies with the terms of the GPL. If we had fully modular drivers, it would even be possible to distribute a build kit that compiles _only_ the FTD2XX driver, which can be installed into OpenOCD's (forthcoming) driver module directory. Glad to heat that build-kit idea is acceptable by GPL and you two. Cygwin is not small. So it is good to distribute is as a zip file. The a shell script to fetch OpenOCD and FTD2XX driver and build OpenOCD can be put in to automatic the job. As far as I can understand the problem is that OpenOCD cannot be distributed as a Windows binary linked against a USB device driver which is non-GPL code. This makes me wonder how the executable is to be run on Windows. Somewhere the code must be linked against Microsoft's APIs which are non-GPL as well. So what is the difference between a non-GPL USB device driver and the Windows APIs? According to Zach the GPL chain extends up and down infinitely but I don't think that is the case. So it seems there are some (practical) boundaries to GPL after all. Nico Coesel ___ 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
Ø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. I am opposed to this as well, for the same reasons. This is why I did not suggest it until someone else suggested it. I want to see libusb and libfdti fixed, and I do not want to open the door to more binary drivers. If I were to implement the TCP/IP interface without pay, I would release it under the GPL to prevent this situation from ever occurring. At this point, I am tempted to implement it simply in order to close this back door to binary drivers. Zach, This sounds very contraproductive to me. You have been doing a lot of great work but if the maintainers of OpenOCD are not open for solutions that just work in a real world you'll find that people (JTAG dongle manufacturors for starters) will start to fork OpenOCD in seperate projects which results in various versions. That would be a waste of your efforts. I really fail to see the real world problem when mixing open and closed source parts. If you contribute to an open source project you know someone will make money with the software you wrote but didn't get paid for. So be it. Perhaps the best way is to link against the closed source driver until there is an open source alternative that works just as well. Closed source drivers are going to be a problem anyhow since getting a 64 bit Windows driver signed is not free. It is also becoming easier to write software that runs on both Linux and Windows. Therefore it is very likely that more open source projects will run into similar problems. So 'closing the door' may actually backfire in worse ways than you can imagine now. Maybe the GPL license has expired. Many bigger projects are published under other licenses like BSD, Mozilla, etc or even have dual licensing like MySQL. GPL 3 has seen a lot of debate before being finalized. Those are the real signs on the wall! Nico Coesel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Nit to pick with recent set of cleanups
-Original Message- From: openocd-development-boun...@lists.berlios.de [mailto:openocd- development-boun...@lists.berlios.de] On Behalf Of Zach Welch Sent: dinsdag 16 juni 2009 1:19 To: open...@duaneellis.com Cc: Openocd-Dev Subject: Re: [Openocd-development] Nit to pick with recent set of cleanups On Sat, 2009-06-13 at 21:14 -0400, Duane Ellis wrote: bool okay = *str !*end ULLONG_MAX != *ul; screaming-rant This fails to demonstrate a mature, professional attitude, but I hope that you can engage in a rational discussion about this topic. I strongly agree with Duane. Source is there to aid programmers. The above statement is completely unreadable. IMHO code should be understandable by people that have very little programming experience. Again, try not to be 3l33t. If you write obscure code you'll find yourself being the only one capable of maintaining a piece of code. Nico Coesel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] mips32 big endian fix
-Original Message- From: David Claffey [mailto:dnclaf...@gmail.com] Sent: vrijdag 12 juni 2009 13:50 To: Nico Coesel Cc: Zach Welch; openocd-development Subject: Re: [Openocd-development] mips32 big endian fix Nico, You are correct, target.c modifies for endianness. This is helpful when I set openocd to -endian big; it sets the word order for mw and md commands to the same endianness as the binary files I want to load. The problem is the mips_m4k target does not adjust for endianness like the xscale target does. My board is a Atheros ar71xx with a MIPS 24Kc hardcore. The cpu endianness cannot be changed and there is no other endianness in the SoC. The special registers read and write correctly when I configure openocd in little endian mode. When I saw the discrepancy I thought, I have a big endian target, why should I not set -endian big. So as a fix, I followed the practice in src/target/xscale.c:xscale_send() where word order is swapped depending on target-endianness. I can now read/write the special registers correctly and download a binary from my toolchain without modification. David, I think the following is happening with your patch applied and OpenOCD in big endian mode: mww command - endian shuffle in target.c - endian shuffle in mips target driver - target binary file - endian shuffle in mips target driver - target I tried to read the SFRs in the AU1100 using the mdb and the mdh command with OpenOCD in little endian mode. It reads the correct values on 4 bytes boundaries while the CPU is in big endian mode. This proofs the EJTAG access port is doing the proper endian conversion. In other words: the binary file should be changed for proper endianess before loading it. The MIPS implementation in OpenOCD doesn't need to be fixed regarding the endianess. Nico Coesel PS: It seems reading data on non 4 byte boundaries needs to be fixed for MIPS targets. Nico Coesel wrote: -Original Message- From: Zach Welch [mailto:z...@superlucidity.net] Sent: vrijdag 12 juni 2009 10:39 To: Nico Coesel Cc: David Claffey; openocd-development Subject: Re: [Openocd-development] mips32 big endian fix On Fri, 2009-06-12 at 09:55 +0200, Nico Coesel wrote: -Original Message- From: openocd-development-boun...@lists.berlios.de [mailto:openocd- development-boun...@lists.berlios.de] On Behalf Of David Claffey Sent: donderdag 11 juni 2009 23:18 To: openocd-development Subject: [Openocd-development] mips32 big endian fix A patch is needed for MIPS big endian (elf32-tradbigmips) targets. Perhaps I'm the first to test trunk with a MIPS big endian target. If -endian big is not set in target create, the endianess defaults to little. mw and md commands will still work, but binary file loads will have the incorrect word order loaded into memory. The EJTAG processor access data register (PrAcc) is little endian regardless of the CPU endianness; it is always loaded LSB first. This is confirmed by the fact that mips_ejtag_drscan_32() uses buf_set_u32() to load the scan field; buf_set_u32() is a little-endian formatter. For big endian targets, data buffers have to be modified so the LSB of each u32 or u16 is at the lower (first) memory location. The attached patch for src/target/mips_m4k.c fixes the problem. Included is a patch for src/target/mips_ejtag.c that fixes the case of a big endian host. Again it is related to PrAcc. If the drscan out_value word order is set using buf_set_u32() then it makes sense to also fixup the in_value with buf_get_u32(); a symmetry argument. This has no affect on little endian hosts. David, I strongly doubt your patch is required. AFAIK OpenOCD already modifies the loaded data for correct endianess at a higher level. Secondly I think endianess conversions should not be done inside a target specific file. I'm using OpenOCD with a MIPS target (AU1100) as well which is also big endian. I've configured OpenOCD to use little endian mode and that seems to be the proper setting. A thing to look out for is that the MIPS EJTAG interface may do the endian conversion for you. Is the order of the special function registers correct when OpenOCD is in little endian mode? This the case with 'my' AU1100 target. You might want to check that first. If the special function registers read correctly in little endian mode then you'll need to modify the endianess of the binary file before loading it with OpenOCD. There are tools to do that. If I'm correct the bootloader Yamon comes with a tool called 'smunge' which can be used to modify the endianess of a file. As you probably noticed, I already committed these changes, but they will be trivial to revert. Please let me know if I should remove them. That said, why require an external tool manage the conversion? Can OpenOCD reasonably
Re: [Openocd-development] mips32 big endian fix
-Original Message- From: openocd-development-boun...@lists.berlios.de [mailto:openocd- development-boun...@lists.berlios.de] On Behalf Of David Claffey Sent: donderdag 11 juni 2009 23:18 To: openocd-development Subject: [Openocd-development] mips32 big endian fix A patch is needed for MIPS big endian (elf32-tradbigmips) targets. Perhaps I'm the first to test trunk with a MIPS big endian target. If -endian big is not set in target create, the endianess defaults to little. mw and md commands will still work, but binary file loads will have the incorrect word order loaded into memory. The EJTAG processor access data register (PrAcc) is little endian regardless of the CPU endianness; it is always loaded LSB first. This is confirmed by the fact that mips_ejtag_drscan_32() uses buf_set_u32() to load the scan field; buf_set_u32() is a little-endian formatter. For big endian targets, data buffers have to be modified so the LSB of each u32 or u16 is at the lower (first) memory location. The attached patch for src/target/mips_m4k.c fixes the problem. Included is a patch for src/target/mips_ejtag.c that fixes the case of a big endian host. Again it is related to PrAcc. If the drscan out_value word order is set using buf_set_u32() then it makes sense to also fixup the in_value with buf_get_u32(); a symmetry argument. This has no affect on little endian hosts. David, I strongly doubt your patch is required. AFAIK OpenOCD already modifies the loaded data for correct endianess at a higher level. Secondly I think endianess conversions should not be done inside a target specific file. I'm using OpenOCD with a MIPS target (AU1100) as well which is also big endian. I've configured OpenOCD to use little endian mode and that seems to be the proper setting. A thing to look out for is that the MIPS EJTAG interface may do the endian conversion for you. Is the order of the special function registers correct when OpenOCD is in little endian mode? This the case with 'my' AU1100 target. You might want to check that first. If the special function registers read correctly in little endian mode then you'll need to modify the endianess of the binary file before loading it with OpenOCD. There are tools to do that. If I'm correct the bootloader Yamon comes with a tool called 'smunge' which can be used to modify the endianess of a file. Nico Coesel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] mips32 big endian fix
-Original Message- From: Zach Welch [mailto:z...@superlucidity.net] Sent: vrijdag 12 juni 2009 10:39 To: Nico Coesel Cc: David Claffey; openocd-development Subject: Re: [Openocd-development] mips32 big endian fix On Fri, 2009-06-12 at 09:55 +0200, Nico Coesel wrote: -Original Message- From: openocd-development-boun...@lists.berlios.de [mailto:openocd- development-boun...@lists.berlios.de] On Behalf Of David Claffey Sent: donderdag 11 juni 2009 23:18 To: openocd-development Subject: [Openocd-development] mips32 big endian fix A patch is needed for MIPS big endian (elf32-tradbigmips) targets. Perhaps I'm the first to test trunk with a MIPS big endian target. If -endian big is not set in target create, the endianess defaults to little. mw and md commands will still work, but binary file loads will have the incorrect word order loaded into memory. The EJTAG processor access data register (PrAcc) is little endian regardless of the CPU endianness; it is always loaded LSB first. This is confirmed by the fact that mips_ejtag_drscan_32() uses buf_set_u32() to load the scan field; buf_set_u32() is a little-endian formatter. For big endian targets, data buffers have to be modified so the LSB of each u32 or u16 is at the lower (first) memory location. The attached patch for src/target/mips_m4k.c fixes the problem. Included is a patch for src/target/mips_ejtag.c that fixes the case of a big endian host. Again it is related to PrAcc. If the drscan out_value word order is set using buf_set_u32() then it makes sense to also fixup the in_value with buf_get_u32(); a symmetry argument. This has no affect on little endian hosts. David, I strongly doubt your patch is required. AFAIK OpenOCD already modifies the loaded data for correct endianess at a higher level. Secondly I think endianess conversions should not be done inside a target specific file. I'm using OpenOCD with a MIPS target (AU1100) as well which is also big endian. I've configured OpenOCD to use little endian mode and that seems to be the proper setting. A thing to look out for is that the MIPS EJTAG interface may do the endian conversion for you. Is the order of the special function registers correct when OpenOCD is in little endian mode? This the case with 'my' AU1100 target. You might want to check that first. If the special function registers read correctly in little endian mode then you'll need to modify the endianess of the binary file before loading it with OpenOCD. There are tools to do that. If I'm correct the bootloader Yamon comes with a tool called 'smunge' which can be used to modify the endianess of a file. As you probably noticed, I already committed these changes, but they will be trivial to revert. Please let me know if I should remove them. That said, why require an external tool manage the conversion? Can OpenOCD reasonably offer such support built-in? Zach, In case of the AU1100 the answer is no. The AU1100 SOC is a complete endian mess. For starters: the MIPS core starts in big endian but the external memory controller starts in little endian. This would imply endian conversion depending on the address. Way too complicated. Anyway when I use OpenOCD I can load the binary file (bootloader) without need for byte shuffling. If I use the MacGraigor software I need to shuffle the data first. I would like to hear from David first before a final judgement about his patches is made. I'm curious about the target he is working on. Nico Coesel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] NEC V850 Core
-Oorspronkelijk bericht- Van: openocd-development-boun...@lists.berlios.de [mailto:openocd-development-boun...@lists.berlios.de] Namens Michel Catudal Verzonden: donderdag 28 mei 2009 5:33 Aan: Duane Ellis; openocd-development Onderwerp: Re: [Openocd-development] NEC V850 Core Duane Ellis a écrit : **THIS*IS*OFF*LIST** The context switching in the NEC devices has no match. Really, I'd like to see how you do this, in a pre-empt context switch there are lots of registers to save, do you have a *specific* NEC support group you work with? I'd like a name or two, local guys here are clue-less. Factory guy came in 5 months ago, gave us a training session about PM Plus not able to answer questions I had. This is not something a salesman is telling me but actual data from NEC where they compare the AR7TDMI, Cortex-M3 and V850ES According to their chart, an interrupt takes 24 cycles for ARM7TDMI, 12 for Cortex-M3 and 4 for their new V850ES. I don't understand why there is so much emphasis on the number of cycles it takes to get into an interrupt. Sounds more like a sales pitch to me. If your software and hardware is designed well, the number of interrupts is few and a lot is done inside an interrupt routine. In other words: the number of cycles to get into an interrupt is usually neglegible compared against the number of cycles it takes to actually execute the interrupt service routine. Also, it is very hard to have a fixed time between the interrupt and entering the interrupt service routine. Other interrupts may be pending or some instructions may take longer. The hardware should allow for delayed interrupts without going up in smoke. Hence, the number of cycles it takes to enter the interrupt service routine becomes less relevant anyway. I did a design with an LPC2000 series controller (ARM7TDMI) from NXP in which I used a 300kHz timer interrupt to implement a DC-DC converter in software (voltage control and cycle-by-cycle current limitting). I didn't need to use the FIQ (fast interrupt) or assembly code. The timing isn't really critical because the LPC2000 has some really nifty features in its hardware. Heck, its all ARM 16 bit thumb code too. Anyway, just get as much mips as you can. The V850 sounds like a hard to get part to me if you're not buying large quantities. I'd stick with an ARM controller. There is a lot of choice and moving to another manufacturer doesn't require to learn a whole new toolchain and CPU. Nico Coesel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch 0/3] openocd.texi updates
On Thursday 28 May 2009, Spencer Oliver wrote: One point i would make - you have added a comment that the mass_erase cmds are pointless. Ttue the same thing can be acheived using erase_address or erase_sector but you need to know the flash info. mass_erase enables the whole device to be erased without knowing this kind of information. perhaps we can add a feature that will erase the whole bank, eg. flash erase_all bank number or modify one the of the existing erase functions. True, there's no flash erase command that accepts a bank; they all use addresses. That's another example of the command set not being orthogonal. ;) I agree that having the bank-address commands offer the same functionality as the target-address ones would be good. An 'erase all' command would be nice. A complete erase is often required. It is a big plus for automated programming. One thing less to detect. Nico Coesel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] support avr32
-Oorspronkelijk bericht- Van: openocd-development-boun...@lists.berlios.de [mailto:openocd-development-boun...@lists.berlios.de] Namens Xiaofan Chen Verzonden: maandag 25 mei 2009 10:54 Aan: openocd-development@lists.berlios.de Onderwerp: Re: [Openocd-development] support avr32 On Mon, May 25, 2009 at 11:28 AM, Xiaofan Chen xiaof...@gmail.com wrote: There are many 16/32bit MCUs which will benefit from OpenOCD if they are supported. Most popular non-ARM ones I can think of are Renesas M16C/32C, H8/H8S/H8SX, Infineon XC166/XE166, TI MSP430. Just look at this chart for top 10 MCU vendors. http://www.eetasia.com/STATIC/ARTICLE_IMAGES/200904/EEOL_2009APR17_CTR LD_NT_01.gif Within theses chips and ColdFire, Infineon XE166 does not seem to have gcc support. So even though they have free DAS FYI: Coldfire = 68000 Codesourcery offers precompiled GCC with Coldfire support. Maybe Freescale can be persuaded to donate some hardware. They are losing designs because they are currently forcing their customers to use Codewarrior. The Renesas controllers are another story. Turning the code read protection on requires an NDA so OpenOCD is not likely to be able to support code read protection on Renesas chips. Nico Coesel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] milestone strategy [3 of 4]
-Oorspronkelijk bericht- Van: openocd-development-boun...@lists.berlios.de [mailto:openocd-development-boun...@lists.berlios.de] Namens Zach Welch Verzonden: dinsdag 19 mei 2009 7:49 Aan: openocd-development Onderwerp: [Openocd-development] milestone strategy [3 of 4] Hi all, In tandem to perpetual tactical quality-improvement release goals, the OpenOCD community will be pursuing strategic development goals that lead to special milestone releases. As this indicates, I think such planning should be decoupled from the release process, in so far as we should be able to allow up to N intermediate releases to be produced for each of the M milestones that may fall out of The List. Thus, this takes less precedence over the release process itself for the short term. Nevertheless, I hope this thread can be used by someone as the launching pad for identifying the strategic goals that we should be thinking about for 0.3.0 (which I consider the next major release). Short note from the marketing department: shouldn't 0.2.0 be released as 1.0? The 0.2.0 version number may scare potential users away thinking OpenOCD is not ready for any serious work. Nico Coesel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] PIC32 openocd status
-Oorspronkelijk bericht- Van: openocd-development-boun...@lists.berlios.de [mailto:openocd-development-boun...@lists.berlios.de] Namens Strontium Verzonden: maandag 18 mei 2009 4:06 Aan: Xiaofan Chen CC: openocd-development@lists.berlios.de Onderwerp: Re: [Openocd-development] PIC32 openocd status This is wrong. ICSP is Microchip's proprietory protocol for programming and debugging. The ICSP module is independent from the EJTAG module in PIC32. You can read Chapter 33 of the PIC32MX Family Manual for more information. I didn't make it up. I read it. PIC32MX Flash Programming Specification 61145D.pdf : Section 5: EJTAG is designed for debugging. However that same functionality can be used to allow programming. PIC do not need to re-specify EJTAG, as that is available from MIPS. I have found no suggestion that the PIC32 does not implement a compliant EJTAG core, and as ICSP is just de-multiplexed into 4 wire jtag internally, there is no reason why EJTAG operations will not operate as expected over ICSP. There are lots of MIPS chips that have an EJTAG core. An EJTAG implementation in OpenOCD would be awesome. PIC32 is a nice cheap platform to develop and test this with. Gentlemen, AFAIK EJTAG is already implemented in OpenOCD (I'm using it for another MIPS based SOC to program external flash). I just don't know how complete it is in respect to debugging/single stepping. The flash programming routines for PIC32 are also available in OpenOCD. So I guess everything is available in OpenOCD to program a PIC32. Slighty off-topic: I think the MIPS GCC compiler from Codesourcery can be used for PIC32 straight away. It is based on GCC 4.x (not the old 3.x GCC), has newlib support and isn't crippled! The C library from mspgcc (GCC for TI's MSP430 series) is a usefull replacement for newlib because it is really really small. I had little problems compiling it for ARM. Nico Coesel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] CFI driver chip/bus width.
-Oorspronkelijk bericht- Van: David Brownell [mailto:davi...@pacbell.net] Verzonden: donderdag 14 mei 2009 23:02 Aan: Nico Coesel CC: openocd-development@lists.berlios.de; Raúl Sánchez Siles Onderwerp: Re: [Openocd-development] CFI driver chip/bus width. On Thursday 14 May 2009, Nico Coesel wrote: Anyway, if your flash is 8 bit, then your bus must be 8 bits wide. Not true; there *is* support, e.g. in Linux, for hooking up two 8-bit NOR chips in parallel. I think one of the ideas is to improve the read/write bandwidth. Two 8 bit flash chips in parallel won't be faster than 1 16 bit flash chip. Anyway, Linux won't care where the data is coming from. What does matter is that an 8 bit device must be connected to an 8 bit data path. So if your data path is 16 bits wide you need to have two 8 bit flashes in parallel otherwise your data will be corrupted (8 bits missing). It is not clear whether you have two 8 bit flashes in parallel to form a 16 bit flash. Two 8-bits in parallel is different from one 16-bit chip. That is exactly what I was trying to type :-) Nico Coesel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] resubmit lost works!
-Oorspronkelijk bericht- Van: openocd-development-boun...@lists.berlios.de [mailto:openocd-development-boun...@lists.berlios.de] Namens Øyvind Harboe Verzonden: vrijdag 15 mei 2009 15:15 Aan: Jonathan Dumaresq CC: openocd-development Onderwerp: Re: [Openocd-development] resubmit lost works! Generally this is where a bug tracking system comes into play. Of course, as a community, we seem to be against that idea. This is something that we like to use too keep track of issues. It's easy to use and at least, outsider don't have to read all the last years of email to know what's work and what don't ! Do we allow anybody to register bugs? Perhaps we should require all bugs to be discussed in this mailing list first? It's no good to have a million bugs in a database and have nobody read that database either. Its always good to have a list with open issues. Look at other projects: most have a million bugs open! Seriously, a bug tracker can also be used to post preliminary patches. A while ago I found a bug in uClibc and attached my patch to the ticket. Some maintainer may pick it up and apply the patch, otherwise people may use the patch at their own risk / if they need it. Nico ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] jtag driver tutorial (was RE: doxygen update)
-Oorspronkelijk bericht- Van: Zach Welch [mailto:z...@superlucidity.net] Verzonden: woensdag 13 mei 2009 13:17 Aan: Nico Coesel CC: openocd-development Onderwerp: jtag driver tutorial (was RE: [Openocd-development] doxygen update) On Tue, 2009-05-12 at 00:19 +0200, Nico Coesel wrote: [snip] Allright! I need to write a driver somewhere in the next couple of weeks/months (when the JTAG programmer hardware arrives). Perhaps I can sketch/write some outlines on putting a driver together. I just don't know how this would work with the current version of OpenOCD. A lot seems to be happening lately (which is good!) but I'm not sure the current driver model is still the same as version 0.1.0. Excellent. :) We definitely need more documentation writers! I recommend writing documentation for the current trunk. I just added doc/manual/ in r1771 to provide the basic skeleton for OpenOCD's high-level doxygen documentation (which others can flesh out over time). I think what you describe should be a stand-alone document that reads more like a tutorial that a reference, and I have realized the need for more of such works by incorporating a Technical Primers section in the doxygen output. Please consider writing it iteratively and incrementally as you develop the driver, posting revisions for community to review just as you might the code. I think this work could produce common driver standards and then catalyze development to clean-up the existing drivers to meet them. I would suggest starting the file, doc/manual/primer/jtag-driver.txt. Write a doxygen comment block to contain the tutorial, similar to the skeleton files now in the tree. Using doxygen's own documentation, you should be able to make your content appear in the proper section of the new OpenOCD Technical Primers page. Zach, I have two issues with that: First the document will probably in Word (.doc) format to include both text and pictures. Plain text is just too limited. I suppose I can provide the images in a different format as well. Text is easy to extract / Word documents can be read by OpenOffice. My document layout doesn't contain fancy stuff anyway. Secondly I'm planning to use version 0.1.0 with the patches I made. I need to push 'my' JTAG programmer project forward as fast as possible. I don't want to skip documentation, but I can't spend time on debugging OpenOCD at this moment. I'm willing to give r1771 a try (or any other revision that is 'guaranteed' to work), but if it doesn't work from the box I have to stick with version 0.1.0. Nico ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] CFI driver chip/bus width.
Raúl, I posted a patch that does take the bus and chip width into account a short while ago. Anyway, if your flash is 8 bit, then your bus must be 8 bits wide. It is not clear whether you have two 8 bit flashes in parallel to form a 16 bit flash. Nico Hello all: I have noticed some issues on CFI flash driver related to chip and bus width affecting read and writes. The system I'm dealing with is based on a Vitesse switch chip which embeds an ARM926ejs processor. It additionally provides RAM and flash controller. In this case we are using an spansion S29GL128 16MB flash chip, using a 8bit width data bus layout, so on each read/write cycle we can only retrieve 1byte at once. The flash chip data bus width is 16bit. I declare the flash like this: flash bank cfi 0x8000 0x100 1 2 0 = 1st problem (writing): This clashes somehow with the current CFI driver operations as designed now. I have discovered that when the connected flash is 8 bit, only byte writes will be performed correctly so even this call: target-type-write_memory(target, address, 4, 1, value_buf) will succeed, the operation isn't carried out correctly. I got to workaround the problem for just cfi flash probe. See attached cfi- write-width.diff What I do there is using chip width instead of bus width for each write. This works in my case but I'm not sure it's the general way to go. This effect expands to larger write operations, for instance in target_write_u32 (cfi.c:1220) you would need to repeat a byte write operation 4 times. = 2nd problem (reading) But writing is not the only problem. In reading, when chip width is 8bit whereas bus width is 16bit, single byte operation could be acceptable, whereas this is no longer valid for halfword or word operations, 16bit and 32bit, respectively. When you call, for example cfi_query_u16, expected return is 0xAABB, where 0xAA is the MSB and 0xBB is the LSB. Current return is always 0x. Similar problem for cfi_query_u32 The solution is iterating the necessary times for a 1byte read and then aggregate each iteration result properly. See attached cfi-read_iteration.diff I guess the x16_as_x8 option defined but not used should be aimed at handling this, but this is unimplemented currently. I would like to write a patch addressing this issues, but I thought that I'd rather bring the topic to the list so I can directly go for a ultimate solution and not workarounds as I'm using right now. Comments are welcome. Regards, -- Raúl Sánchez Siles Departamento de Montaje INFOGLOBAL, S. A. * C/ Virgilio, 2. Ciudad de la Imagen. 28223 Pozuelo de Alarcón (Madrid), España * T: +34 91 506 40 00 * F: +34 91 506 40 01 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] doxygen update
Zach, I'm a little concerned here. I've seen many doxygen generated API 'reference' manuals. Most of them are useless because they don't describe why a certain function is there and what its relation is to other functions. Doxygen is a fine tool to get a list of functions and their parameters but the same information can be obtained by importing the source into an IDE like Eclipse or Visual Studio. I have been digging around in other peoples software a lot. The biggest question is always: how does the data flow through the software and why is it structured the way it is. Unfortunately, most doxygen generated documents don't contain this information. A diagram which shows the logical blocks / layers of the software and some text on how they interact is very very useful. Nico Coesel -Oorspronkelijk bericht- Van: openocd-development-boun...@lists.berlios.de [mailto:openocd-development-boun...@lists.berlios.de] Namens Zach Welch Verzonden: maandag 11 mei 2009 9:30 Aan: openocd-development Onderwerp: [Openocd-development] doxygen update Hi all, As a consequence of my recent clean-up work, I turned on some of the basic GraphViz features in doxygen. This feature can be turned off by change the HAVE_DOT Doxyfile setting from YES to NO. Its file dependency graphs are now much more insightful than before I started my clean-up, so I think they should be referenced by as many developers as possible. Further, I would like to improve the doxygen output until it provides a fairly complete API reference manual. Patches that move us toward that goal would be most welcome. Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] doxygen update
On Mon, 2009-05-11 at 10:08 +0200, Nico Coesel wrote: Zach, I'm a little concerned here. I've seen many doxygen generated API 'reference' manuals. Most of them are useless because they don't describe why a certain function is there and what its relation is to other functions. Doxygen is a fine tool to get a list of functions and their parameters but the same information can be obtained by importing the source into an IDE like Eclipse or Visual Studio. I have been digging around in other peoples software a lot. The biggest question is always: how does the data flow through the software and why is it structured the way it is. Unfortunately, most doxygen generated documents don't contain this information. A diagram which shows the logical blocks / layers of the software and some text on how they interact is very very useful. I agree that there are different levels to the documentation, and I think that doxygen does a great job for API reference. It can also provides function call graphs, which begins to provide some of the code-flow insight that you describe. However, you are right in saying that we need additional documentation that describes the architecture at higher levels. Such text and figures could also be integrated into the doxygen manual, allowing the texinfo document to focus on high-level usage and TCL script documentation. How does that plan sound? Allright! I need to write a driver somewhere in the next couple of weeks/months (when the JTAG programmer hardware arrives). Perhaps I can sketch/write some outlines on putting a driver together. I just don't know how this would work with the current version of OpenOCD. A lot seems to be happening lately (which is good!) but I'm not sure the current driver model is still the same as version 0.1.0. Nico Coesel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Fix build errors in SVN on x86_64
-Oorspronkelijk bericht- Van: openocd-development-boun...@lists.berlios.de [mailto:openocd-development-boun...@lists.berlios.de] Namens Albert Cahalan Verzonden: maandag 27 april 2009 8:49 Aan: Øyvind Harboe CC: openocd-development@lists.berlios.de Onderwerp: Re: [Openocd-development] [PATCH] Fix build errors in SVN on x86_64 On Mon, Apr 27, 2009 at 1:41 AM, Øyvind Harboe oyvind.har...@zylin.com wrote: What's wrong with this code? long long then=timeval_ms(); while ((timeval_ms()-then)duration) This appears many places in the code. comparision will work unless the difference is greater than 31/63 bits in signed mode... Assuming nothing is unsigned long long or bigger, it should all promote to long long. That's 63 bits at minimum, not counting the sign bit. Even if it were 31-bit, you'd have: 24 days, 20 hours, 31 minutes, 23 seconds, 647 milliseconds That's quite the marathon debug session. If the 'long long' is changed into 'unsigned long long', the code will always work even in wrap-around situations. Perhaps it is a better idea to specify (typedef) a timer type as unsigned long long for this purpose. Nico Coesel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Fix build errors in SVN on x86_64
-Oorspronkelijk bericht- Van: Philippe Vachon [mailto:phili...@cowpig.ca] Verzonden: maandag 27 april 2009 13:10 Aan: Øyvind Harboe CC: Nico Coesel; openocd-development@lists.berlios.de Onderwerp: Re: [Openocd-development] [PATCH] Fix build errors in SVN on x86_64 Hi, On Mon, Apr 27, 2009 at 08:58:37AM +0200, Øyvind Harboe wrote: If the 'long long' is changed into 'unsigned long long', the code will always work even in wrap-around situations. Perhaps it is a better idea to specify (typedef) a timer type as unsigned long long for this purpose. I don't understand. Subtraction is identical for signed and unsigned in two's complement representation(I don't care about CPUs that don't user two's complement! :-) As a rule, comparisons between a signed and an unsigned value are a bit... risky. When you build with -Werror and compile on x86_64, gcc will complain at you. That's the problem. The wraparound case works with signed and unsigned. I'm no more worried about the wraparound case than I am for, say 345623623-235423145. :-) Realistically, you're correct. I'd argue that nobody would probably need more than 2^32 ms anyways, so why not just make it a u32 and be done with it. ;-) Timeval returns the current time which consists of the UTC time and a microseconds counter. So you will need to have more than 32 bits for a comparison. I still think using unsigned math is cleaner otherwise you'll have negative times at some point in the future (after 2038) and I'm not sure what will happen since the seconds counter will become less negative (from -(2^31) towards -1) but the microseconds counter will continue to count up. The fix for the Unix epoch in 2038 will probably be making time_t unsigned if isn't defined/working that way already. If we are going to change anything here, then *all* places should be fixed and we should have the reasoning right in the first place. There are a few things I would recommend changing: 1) in types.h u32 is badly defined for non-IA32. unsigned long is 8 bytes on x86_64. There is a standarized C include which defines types which have a platform independend bit width. I think its types.h but I'm not sure. Nico Coesel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Introduction
-Oorspronkelijk bericht- Van: openocd-development-boun...@lists.berlios.de [mailto:openocd-development-boun...@lists.berlios.de] Namens Strontium Verzonden: maandag 27 april 2009 14:07 Aan: openocd-development@lists.berlios.de Onderwerp: [Openocd-development] Introduction Hello, I have been lurking on the list for a while, I am interested in contribution to the Cortex A8 support, so I thought I would introduce myself. I have been involved with a number of OCD products in the past, Mainly Freescale MPC860 Background Debug Mode (Which isn't JTAG based) and ARM 7 Jtag (Specifically as it applied to a OKI ARM chip). I am also familiar with MIPS JTAG debug interface but haven't actually used it. All of my work was on internal tools used in my former company. I am very familiar with GDB, and the GDB Remote Protocol. I am considering developing an add on for the beagle board so it can be used as a high speed, intelligent and cheap OCD Tool. (Basically put some isolation on the expansion header and bit bash it from the OMAP processor.) You may want to investigate the speed you can get from bit-banging first. It may not be as much as you expect. I/O goes around the CPU's cache so the performance hit is huge. I'm currently working on a gang programmer. I've put an FPGA on it to provide several fast (20MHz) JTAG interfaces. Nico Coesel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] The problem with testing target hardware
Please scroll down... Zach Welch Verzonden: woensdag 22 april 2009 22:28 Aan: Dick Hollenbeck CC: OpenOCD Development Onderwerp: Re: [Openocd-development] The problem with testing target hardware On Wed, 2009-04-22 at 14:31 -0500, Dick Hollenbeck wrote: Zach Welch wrote: On Wed, 2009-04-22 at 11:07 -0700, Rick Altherr wrote: [snip] This is an interesting idea, but I think it skips an important step. There seem to be a number of problems solely within the JTAG and interface layers. It would be great if someone constructed some infrastructure for a regression suite that looked at just those layers. That way we could verify those layers are functioning properly across the board and do so in a way where people with the correct equipment could quickly run the test periodically. I don't know why I forgot it myself, but a test suite is now on The List with numerous bullets beneath it. Yes, this is an FPGA with a serial port on it?The is your universal JTAG TAP emulator, which gives feedback about the path than an actual TAP is traversing. Without a device to connect to, one that gives responses back, how do you verify success? Functional unit testing could be a start. We could exercise a ton of code without ever needing to talk to the hardware. That was what I was thinking when I added the items to The List. A device like you describe could definitely be used for deeper testing, and it's not a particularly bad idea. I have been meaning to get into synthesizing my own FPGAs, and this sounds like a fairly easy and useful starter project. It is now on The List as well, unless you are now going to tell me why my child-like ignorance has led me astray. You may have well just tempted me with Pandora's box. I must know more. I'm not sure whether this is a good idea. There are many combinations of JTAG dongles and processors. The JTAG TAP interface is least of the problems when dealing with JTAG. The problem is always in the layers behind the JTAG interface. If you want to develop a test suite you'll need to simulate all the supported CPUs, flashes, etc. Worse, a simulator is never 100% like the real thing. More worse, JTAG seems to be the last thing on the list to implement on a chip so implementations often contain bugs and other undocumented mayhem which may be different between devices in the same family and/or steppings (device revisions). In others words: nothing beats testing with a real target and there will always be new devices that require some patching. Another item for the list: With some imagination it would be possible to simulate a UART or an SPI interface using the JTAG dongle. Maybe even bit I/O using the RST en TRST pins. This would allow extending OpenOCD into a universal programmer for microcontrollers. Nico Coesel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] my tech proposal
Zach, There are a few things missing on your list which I think are important: - Coldfire support (which is basically an enhanced 68000 core) would be nice. There is no open source solution out there to program Coldfire controllers which is a shame because the Coldfire controllers are actually quite nice and reasonably priced. Freescale thinks their customers should use Codewarrior or take their business somewhere else. - Completing ARM Cortex A8 support. I see CFI is on your list as well. I have a slightly improved version of cfi.c which some speed enhancements. Shall I mail it to you to have a look at it? I agree the cfi code is not very clean; a lot of code which basically does the same is duplicated. Also the bus width / chip width handling is not fully implemented yet. IMHO vendor specific code could be just a bunch of functions called through function pointers from cfi.c. I just hope people are not put off by the high frequency of changes which causes their patches to fail. I think its best to concentrate on one area at a time and finish it first before moving to another area. This reduces the chance two (or more) people are working on the same code. Nico Coesel -Oorspronkelijk bericht- Van: openocd-development-boun...@lists.berlios.de [mailto:openocd-development-boun...@lists.berlios.de] Namens Zach Welch Verzonden: woensdag 22 april 2009 4:56 Aan: Openocd-Dev Onderwerp: [Openocd-development] my tech proposal Hi all, This message follows my sentiments about the human side of OpenOCD with a more technically focused perspective. First off: if you had conflicts that prevent a clean 'svn diff' patch, you should be able to copy your original pre-merged files (the .mine files) into a fresh working copy of the older revision (along with changes to any other files that did merge okay) and extract the clean patch therein. Let me know if this advice is not as helpful as I think it should be; if all else fails, send me your entire working copy and I will deal with the mess that I caused. Anyway, here is my current list of outstanding tasks, where '+' items have a current patch and '-' items do not. This is not a milestone task list; I am leaving that as someone else's responsibility. * FT2232 driver: + integrate FTD2XX High-Speed Device Patch (Joern Kaipf + ZW) +? remove non-A types (Uwe Hermann) (does this patch still apply?) - fix segfault from long scan chains (observed by Dick Hollenbeck) - fix non-recoverability of cable connect/reconnect - cure buggy madness (others might try to break this into pieces) * J-Link driver (w/ yellow hardware) - integrate Jeff and Duane's pending changes - cure buggy madness (this is my own poorly qualified TODO item) - test on known targets * MC1322x target support - integrate and test support from Jeff and Duane - get working with a known good interface (i.e. not today's jlink) * TAP changes: - use tap_set_state everywhere to allow logging TAP state transitions - add new TAP state table provided by Jeff Williams - update tap_get_tms_path API as suggested by Duane Ellis - slow boat: add tap_get_tms_path2 and allow both for a while - convert drivers that use old API over to the new one - remove old tap_get_tms_path - other changes work picking out of Jeff/Duane's patches * CFI: - factor vendor-specific code into separate source files - investigate adding new interface to those bits? * Architectural Upgrades - Allow N:M:P mapping of servers, targets, and interfaces * ARM: - better alignment with ARM technical documentation (Jeff W.) * Miscellaneous: - continue to improve state and system debugging (Jeff W.) - overhaul use of types to improve 32/64-bit portability - factor drivers to improve re-use If I do not include something important to you, it was not intentional; simply follow-up with a your items and I will add them to the next version. I am not interested in keep track of what goes in (the repo log does that), so I will simply drop items when that happens for them. I hope that -- by maintaining this list and posting it here -- everyone will take away the idea that I care about the project's architecture. I seriously considered writing a competing implementation, because I _knew_ there would be this kind of resistance to change. I see the potential massive changes that would benefit the system, such as the list item for OpenOCD to allow heterogeneous configurations of servers, targets, and interfaces (N:M:P). Admittedly, this was suggested by others recently (though I can't find the exact thread at the moment), but it is the kind of task that I might find entertaining. I see other potential in the code, but I still have not been able to get my head around the nature of everything needs to be done. There a lot. If I could afford to play in this sandbox
Re: [Openocd-development] [PATCH] improve Linux ftd2xx configure-timesupport
I didn't look at the patch but is there a way to force the directory to aid cross-compiling? Nico Coesel -Oorspronkelijk bericht- Van: openocd-development-boun...@lists.berlios.de [mailto:openocd-development-boun...@lists.berlios.de] Namens Zach Welch Verzonden: dinsdag 21 april 2009 9:59 Aan: openocd-development Onderwerp: [Openocd-development] [PATCH] improve Linux ftd2xx configure-timesupport Hi all, The attached patch rewrites the configure script section that handles detecting the Linux FTD2XX libraries. It no longer assumes anything, so it may cause breakage on some distributions. I tested it against installed copies of 0.4.13 and 0.4.16 on Gentoo, along with both static and shared options under --with-ftd2xx-linux-tardir. In truth, I do not think this can do any real harm, as it makes the same kinds of assumptions as were made previously. It simply verifies that the files are actually there, so anyone that had it working before now will have already been setting up the proper LDFLAGS or other magic. It also changes the output to be more configure-like. Please apply. Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] MIPS32 speedup patches
Hello all, Attached some patches to speed up (external) flash programming on MIPS platforms. I optimized some of the assembly code in mips32_pracc.c. While using a parallel port Wiggler I went from 1000+ seconds programming time to 649 seconds. Thats a 35% speed increase. I've added some background information on the optimisations in the source so others should understand what is going on. This patch includes my previous patch to add 5 JTAG clocks! I also hacked flash/cfi.c a bit more. The original version uses the toggle bit to determine whether a flash operation is ready. This is OK for erasing but when using a slow interface like the wiggler the programming is probably done when the next read operation is performed. When using toggle detection during programming, at least 2 read cycles are required to detect the absense of the toggling. I added a new function that detects whether the programmed value is being read from the device. If yes then the programming is done. This hack doesn't add a whole lot of speed improvement so I didn't care to make it work for any bus width / flash width. Its definitely not patch-worthy. If someone cares to takes it a step further I can mail my version of cfi.c. Nico Coesel mips32_pracc.h.speedup.patch Description: mips32_pracc.h.speedup.patch mips32.h.speedup.patch Description: mips32.h.speedup.patch mips32_pracc.c.speedup.patch Description: mips32_pracc.c.speedup.patch ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Cmake part 2
Here is another grazy idea regarding build tools: how about adding Eclipse project definitions? From experience I know that Eclipse projects can be transferred between Windows and Linux without problems. I agree the autotools aren't ideal especially when cross-compiling. When cross compiling software the biggest problem usually is getting the configure script to work right. A lot of programmers seem to completely forget about cross compiling at all. Even openocd doesn't cross compile out of the box. -Oorspronkelijk bericht- Van: openocd-development-boun...@lists.berlios.de [mailto:openocd-development-boun...@lists.berlios.de] Namens Dick Hollenbeck Verzonden: dinsdag 14 april 2009 14:02 Aan: Openocd-Dev Onderwerp: [Openocd-development] [PATCH] Cmake part 2 This adds config.h.cmake which was missing in the first patch. It seems that I will need help getting this committed. CMake fans please step forward and make your voices heard. CMake has been accused of being off the beaten path. From my perspective, those that take the autotools path are the ones being beaten. It is not a problem to support two build tools for an indefinite period in time. The space in the repository is free. Dick ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Chip width / bus width bug in cfi driver
Hello again, I think I discovered a bug in the cfi driver. The board I'm working with has 2 16 bit flash chips connected to a 32 bit bus. I configured the flash bank as following: flash bank cfi 0xbe00 0x200 2 4 0 The chip-width is 2 and the bus width is 4. The flashes have a 32 byte fast programming page. When debugging the programming I noticed the flash was programmed in 64 byte chunks (which is correct 2 times 32 bytes) but the address was incremented by 32. This means that the flash is programmed twice. I made some changes to cfi.c to take the bus-width and chip-width into account. Nico Coesel cfi.c_bus_chip_width.patch Description: cfi.c_bus_chip_width.patch ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] AU1100 (MIPS) problems Fixed!
Fab, The AU1100 is 32 bits. I guess the 32 versus 36 bit issue could be solved in a generic way by adding a 'variant' option. Van: Fab Clement [mailto:clement@gmail.com] Verzonden: vrijdag 10 april 2009 13:40 Aan: Nico Coesel CC: openocd-development@lists.berlios.de Onderwerp: Re: [Openocd-development] AU1100 (MIPS) problems Fixed! Hi I add the same problem with an AU1200 and an Amontec that I also solved with a polling without being satisfied. At least it worked enough to flash a bricked box. The AU1200 has a 36 bits ADDRESS width. What about the AU1100? Could it be an explaination for these 5 added clocks? Best Regards Fab On Fri, Apr 10, 2009 at 11:46 AM, Nico Coesel ncoe...@dealogic.nl wrote: Another update on the AU1100 troubles. Adding 5 clocks after clearing the Pracc bit solved the problem. The patch is attached to this e-mail. Met vriendelijke groet / Best regards, DEA bv ing. Nico Coesel Kweekgrasstraat 18 1313BX Almere tel: +31 (0)36 5343888 fax: +31 (0)36 5342244 e-mail: ncoe...@dealogic.nl www.c-lock.nl www.dealogic.nl (op al onze leveringen van goederen en diensten zijn onze algemene voorwaarden van toepassing zoals gedeponeerd bij de KvK te Lelystad, inschrijfnummer 39046783) -Oorspronkelijk bericht- Van: openocd-development-boun...@lists.berlios.de [mailto:openocd-development-boun...@lists.berlios.de] Namens Nico Coesel Verzonden: donderdag 9 april 2009 12:15 Aan: John McCarthy CC: openocd-development@lists.berlios.de Onderwerp: Re: [Openocd-development] AU1100 (MIPS) problems Fixed! John, Polling in wait_for_pracc_rw() doesn't work. The way I understand it is that read/write are used to catch a memory fetch/write that the processor. After that the Pracc bit is cleared to 0 to allow the processor to 'process' the fetch. I suspect the AU1100 is not updating this register properly and needs extra TCK clocks. So my loop is actually clocking the CPU / EJTAG into the next command. A safer way to do this is using jtag_add_clocks/jtag_execute_command. Toggling TCK in the idle state doesn't hurt anything and it seems to work. I added 5 extra clocks after clearing the Pracc bit. The documentation is very unclear at this point; there is some clock domain synchronisation going on between the CPU clock and TCK. Met vriendelijke groet / Best regards, DEA bv ing. Nico Coesel Kweekgrasstraat 18 1313BX Almere tel: +31 (0)36 5343888 fax: +31 (0)36 5342244 e-mail: ncoe...@dealogic.nl www.c-lock.nl www.dealogic.nl (op al onze leveringen van goederen en diensten zijn onze algemene voorwaarden van toepassing zoals gedeponeerd bij de KvK te Lelystad, inschrijfnummer 39046783) -Oorspronkelijk bericht- Van: John McCarthy [mailto:jg...@magma.ca] Verzonden: donderdag 9 april 2009 4:00 Aan: Nico Coesel CC: openocd-development@lists.berlios.de Onderwerp: Re: [Openocd-development] AU1100 (MIPS) problems Fixed! Hi Nico, On Wed, 2009-04-08 at 13:12 +0200, Nico Coesel wrote: I did some debugging and found that the Pracc flag needs to be polled for the AU1100 device to work properly. I've attached a patch against mips32_pracc.c. I assume the (minor) changes do not affect other MIPS targets. Hmm, but your patch does more than poll. It loops clearing PRACC each time through the loop till it reads clear. This will miss processor
Re: [Openocd-development] AU1100 (MIPS) problems Fixed!
John, Polling in wait_for_pracc_rw() doesn't work. The way I understand it is that read/write are used to catch a memory fetch/write that the processor. After that the Pracc bit is cleared to 0 to allow the processor to 'process' the fetch. I suspect the AU1100 is not updating this register properly and needs extra TCK clocks. So my loop is actually clocking the CPU / EJTAG into the next command. A safer way to do this is using jtag_add_clocks/jtag_execute_command. Toggling TCK in the idle state doesn't hurt anything and it seems to work. I added 5 extra clocks after clearing the Pracc bit. The documentation is very unclear at this point; there is some clock domain synchronisation going on between the CPU clock and TCK. Met vriendelijke groet / Best regards, DEA bv ing. Nico Coesel Kweekgrasstraat 18 1313BX Almere tel: +31 (0)36 5343888 fax: +31 (0)36 5342244 e-mail: ncoe...@dealogic.nl www.c-lock.nl www.dealogic.nl (op al onze leveringen van goederen en diensten zijn onze algemene voorwaarden van toepassing zoals gedeponeerd bij de KvK te Lelystad, inschrijfnummer 39046783) -Oorspronkelijk bericht- Van: John McCarthy [mailto:jg...@magma.ca] Verzonden: donderdag 9 april 2009 4:00 Aan: Nico Coesel CC: openocd-development@lists.berlios.de Onderwerp: Re: [Openocd-development] AU1100 (MIPS) problems Fixed! Hi Nico, On Wed, 2009-04-08 at 13:12 +0200, Nico Coesel wrote: I did some debugging and found that the Pracc flag needs to be polled for the AU1100 device to work properly. I've attached a patch against mips32_pracc.c. I assume the (minor) changes do not affect other MIPS targets. Hmm, but your patch does more than poll. It loops clearing PRACC each time through the loop till it reads clear. This will miss processor accesses after the access your trying to process. When mips32_pracc_exec_read/write() is called, the PRACC bit is supposed to be already set. PRACC set means the CPU is waiting for a read or write from the the EJTAG debug memory region. If the AU1100 needs polling then you should do it in wait_for_pracc_rw(), waiting from PRACC to become set. Once PRACC is set then the original code in mips32_pracc_exec_read/write() should work fine. PRACC should always be clear on return (it just releases the CPU to perform another instruction). Setting PRACC is a no-op, only clearing it has an effect and only when it was set by an active CPU access to the EJTAG debug region. Can you try polling in wait_for_pracc_rw() with the original code in mips32_pracc_exec_read/write()? The code in your patch would not work on other MIPS targets and I'm surprised it works on the AU1100. Cheers, John McCarthy. Nico Coesel -Oorspronkelijk bericht- Van: Nico Coesel Verzonden: dinsdag 7 april 2009 17:00 Aan: 'openocd-development@lists.berlios.de' Onderwerp: AU1100 (MIPS) problems Hello all, I'm trying to get Openocd + a wiggler interface working with an AU1100 MIPS based SOC. It seems the chip is recognized correctly (the JTAG interface is working) but I can't access the memory. When I try to read or write data the debug shows 'No memory access in progress!'. Anyone has some suggestions on where to start looking? I've included the output from OpenOCD below: Debug: 7 0 command.c:91 script_command(): script_command - reset_config Debug: 8 0 command.c:108 script_command(): script_command - reset_config, argv[0]=ocd_reset_config Debug: 9 0 command.c:108 script_command(): script_command - reset_config, argv[1]=trst_and_srst Debug: 11 0 command.c:91 script_command(): script_command - interface Debug: 12 0 command.c:108 script_command(): script_command - interface, argv[0]=ocd_interface Debug: 13 0 command.c:108 script_command(): script_command - interface, argv[1]=parport Debug: 15 0 command.c:91 script_command(): script_command - parport_port Debug: 16 0 command.c:108 script_command(): script_command - parport_port, argv[0]=ocd_parport_port Debug: 17 0 command.c:108 script_command(): script_command - parport_port, argv[1]=0x378 Debug: 19 0 command.c:91 script_command(): script_command - parport_cable Debug: 20 0 command.c:108 script_command(): script_command - parport_cable, argv[0]=ocd_parport_cable Debug: 21 0 command.c:108 script_command(): script_command - parport_cable, argv[1]=wiggler2 Debug: 23 0 command.c:91 script_command(): script_command - jtag_nsrst_delay Debug: 24 0 command.c:108 script_command(): script_command - jtag_nsrst_delay, argv[0]=ocd_jtag_nsrst_delay Debug: 25 0 command.c:108 script_command(): script_command - jtag_nsrst_delay, argv[1]=100 Debug: 27 0 command.c:91 script_command(): script_command - jtag_ntrst_delay Debug: 28 0 command.c:108 script_command(): script_command - jtag_ntrst_delay, argv[0]=ocd_jtag_ntrst_delay Debug: 29 0 command.c:108
