Re: [Openocd-development] Adding commands for GDB remote accesses
Hello Julius, Thursday, July 21, 2011, 11:48:17 AM, you wrote: JB I'm looking at adding OpenRISC 1000 support to OpenOCD. [skip] JB One solution is we make our GDB port not use these remote query JB commands and instead rely on the register cache fetched with the g JB RSP command. You can have the most used registers in the G/g packet and use P/p for the rest. If you make an XML description (not sure if OpenOCD supports it, but would be nice), you might even not need to rebuild GDB to make use of it. JB However, I'd really like something which would allow custom RSP JB commands (which can write back to the socket) to be handled. JB The problems I see are that, even though the gdb_put_packet() function JB is declared and could be used by target code, I can't, for the life of JB me, figure out where I could get the right connection* to be putting JB the data out at the right place. Also, the unconditional OK being JB sent isn't great either - perhaps that could be conditional on a JB return value from command_run_line() or something. I'm quite sure you can send a different response for qRcmd - that's how you can use the usual telnet interface from inside GDB. Otherwise have a look at the File-I/O Remote Protocol Extension or qXfer commands. -- WBR, Igormailto:skochin...@mail.ru ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [OpenOCD][MIPS32]Cache non-coherent - sync missing
Hello Drasko, Tuesday, July 5, 2011, 7:01:44 PM, you wrote: DD On Tue, Jul 5, 2011 at 6:17 PM, Spencer Oliver s...@spen-soft.co.uk wrote: I think your patch is ok, but would be better if it checks the arch version and issue a warning about cache writes not supported or something along those lines. DD On the first look, this can be accomplished by reading CP0 PRId DD register, but Revision field is not quite well explained. DD I have no idea how to obtain info if the proc is MIPS32/64 Rev2 compliant. You should use the Config register (CP0 Register 16). AT field (bits 14:13) tells if it's MIPS32 or MIPS64, and AR (12:10) is the release. -- WBR, Igormailto:skochin...@mail.ru ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [OpenOCD][MIPS32]Cache non-coherent - sync missing
Hello Drasko, Wednesday, July 6, 2011, 12:00:11 AM, you wrote: DD On the first look, this can be accomplished by reading CP0 PRId DD register, but Revision field is not quite well explained. DD I have no idea how to obtain info if the proc is MIPS32/64 Rev2 compliant. You should use the Config register (CP0 Register 16). AT field (bits 14:13) tells if it's MIPS32 or MIPS64, and AR (12:10) is the release. DD Hi Igor, DD thanks, I just took a quick look, and I thought that CP0 PRId would be DD more appropriate. I saw that bits 7:0 encode the release, but I did DD not get the codes - they are not well explained in the doc. I would expect that too, but it's not the case, apparently. Bits 7:0 is the manufacturer-specific chip revision ID, not the ISA release. DD Maybe CP0 Config would be a better place to look, though naming is not DD suggestive - Config is used to configure your CPU (it should be RW) DD and ID is where you want to read Read Only information... Actually, most of the fields in Config are read-only. Not very logical but that's how it is. DD I will look tomorrow again, I do not have docs at my disposal now. DD BTW. CP0 Config (reg 16) has 3 selects. Which one did you mention - 0, DD 1 or 2 ? Select 0. See MIPS64 Arch vol 3 for more details. http://mips.com/products/architectures/mips64/#specifications -- WBR, Igormailto:skochin...@mail.ru ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] JTAG blockage
Hi Rick, You don't have to rely on TRST, you should be able to reset the TAP by sending five clocks with TMS high. If you meant to say that you can't enter debug mode without TRST, that's indeed the case for XScale chips (and maybe some others). However, you should still be able to use boundary scan and dump the flash via it (albeit slowly). OpenOCD does not have good support for boundary scan so you might have better luck with UrJTAG. If you have an MCU board with some GPIOs or can control them from PC, you can try my JTAG search program to confirm the pin layout. http://mbed.org/users/igorsk/programs/JTAG_Search/5z843/docs/main_8cpp_source.html It's written for mbed but should be easy to port to anything with some GPIOs. That said, a pull-down resistor should not prevent you from using the pin. You just need to provide some voltage to override it. On Thu, Nov 4, 2010 at 13:40, Rick van Rein r...@openfortress.nl wrote: Hi, I'm reverse engineering a SIP phone so I can reposess it and develop open source firmware for it. I think I found why JTAG was failing. It appears that my TRST is wired to GND through 12 Ohm resistor. As a result, I cannot reset the chip into JTAG mode -- it needs Vtref on TRST to function, AFAIK. Is this a well-known pattern? Any more hints from experience? Thanks, -Rick ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development -- WBR, Igor ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Printing on the GDB Server Output
Semihosting might be simpler to use (and AFAIK it's supported too). On Tue, Oct 26, 2010 at 17:31, Øyvind Harboe oyvind.har...@zylin.com wrote: This is supported by OpenOCD already. Read up on DCC in the manual and look at the DCC stuff in the source code of OpenOCD. -- Ø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 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development -- WBR, Igor ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Someone using OpenOCD with Maxim MAXQ622?
Hello Xiaofan, Friday, March 5, 2010, 2:29:52 AM, you wrote: XC TI seems to have some delivery problems now. Maybe it is due XC to the fab-lite policy of the IDMs. On the analog side, it seems XC that ADI (and even Microchip) is trying to communicate to the XC customers that they can supply TI-compatible parts like OpAmp. Silica releases something they call Trendliner which provides some interesting info even if you don't use them. Here's the one for Feb. http://s107.inxserver.de/inxmail1/html_mail.jsp?id=61576email=mailref=b0cq000o0til http://www.silica.com/fileadmin/Inxmail_Daten/Trendliner/Trendliner_Feb10/Trendliner_complete_2010_02.pdf -- WBR, Igormailto:skochin...@mail.ru ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] FYI -- SWD work
Hello CeDeROM, Thursday, February 18, 2010, 7:18:02 PM, you wrote: C I have an access to the hardware USB2.0 sniffer so it is possible to C fully reverse-engineer the cable commands and modes (I will need to do C it anyway after SWD is impemented and tested on FT2232 cable). I've offered to RE the command set of their Linux driver before but there wasn't much interest. https://lists.berlios.de/pipermail/openocd-development/2009-May/006781.html -- WBR, Igormailto:skochin...@mail.ru ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] JTAG/USB used educational context
Julien, While cheaper, LPCXpresso is currently supported only by code_red and thus only on Windows (and apparently no plans for Linux), so I wouldn't choose that one. LM3S811 kit has several versions which differ by bundled compilers but all of them (even CodeSourcery, I think) run on Windows only. Of course, with it being supported by OpenOCD can work with it on Linux. On thing I like about LM3S811 kit is that it has a couple of peripherals on-board: LCD, a button, a LED and a potentiometer connected to ADC. Thus you can do some interfacing even without extra circuitry. The chip itself is somewhat less capable that NXP's; for example, no USB support. On Thu, Feb 11, 2010 at 17:21, Julien Iguchi-Cartigny julien.carti...@unilim.fr wrote: Hi, Following the replies to my email, i come to some conclusion: = I need an IDE (ideally eclipse) and the software (debug and compilation) must run under Linux without privileged rights. Normally it is going to be easy for this part: - eclipse under Linux: OK - driver ftdi and openocd under linux without privileged rights: OK - compiler: obviously OK My first question: some manufacturers offers plugins for eclipse (code red for instance, saldy only for Windows), is it really interesting or setup the configuration by hand is not too complicated (the problem is not me but the students who use this card on their computer / outside the courses) ? = a Cortex-M3 small board with jtag included (typically ftdi) is definitively the best solution for the price and the reliability of such kind in the hands of unexperimented students ,-) I've seen two boards (from previous replies): LPC Expresso: http://lpcxpresso.code-red-tech.com/LPCXpresso/ Luminary EKT-LM3S811: http://www.luminarymicro.com/products/ekt-lm3s811.html Does anyone has other ideas or advice when choosing one board for such environment (teaching) ? Cheers, Julien. On 02/07/2010 08:13 PM, Julien Iguchi-Cartigny wrote: Hi, We are planing to open a new course for beginners about embedded systems. We would like to use some tiny card (for instance STM32-H103) with a JTAG/USB for debug. I have several questions about it: - at the present time we are using a jtagkey-tiny, low price usb/jtag but with a small problem: it seems this dongle require root rights on the host. Does anyone know if it's possible to use it without root rights (like giving extended rights to use some usb devices) ? - does anyone has some recommendations for a cheap usb/jtag which can run without privileged user on the host ? - in the educational context, what is your recommendations for a cheap ARM cards which work without a glitch (i.e. we are looking for stability, even if the card do not have some extra features) ? Regards, Julien. PS: sorry for this question a bit out-of-scope of this mailing-list... ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development -- Trouble-a-cat limited ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development -- WBR, Igor ___ 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
Hi Spencer, On Tue, Feb 2, 2010 at 11:18, Spencer Oliver s...@spen-soft.co.uk wrote: I have been given all the info for the ST-LINK from ST. http://www.st.com/stonline/products/literature/um/15285.pdf It is accessed using vendor specific mass storage cmds. Again this is a smart dongle, all the jtag/swi is done on the dongle. Currently the simplest way of implementing this is to add the stlink as a actual target, that way it gets access to reset/memory read etc. ideas on integration within openocd would be appreciated as this is the next thing i may look at. Very interesting! It seems it's also included in the STM8S-Discovery board, which costs just $7 - one third to one fourth of the stand-alone adapter. Do you know if JTAG on that board can be used, or it's locked to STM8S SWIM only? -- WBR, Igor ___ 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
Hello Michel, Wednesday, February 3, 2010, 1:57:49 AM, you wrote: MC Le 02/02/2010 05:35, Igor Skochinsky a écrit : Very interesting! It seems it's also included in the STM8S-Discovery board, which costs just $7 - one third to one fourth of the stand-alone adapter. Do you know if JTAG on that board can be used, or it's locked to STM8S SWIM only? MC I just bought two of those for some test before I get my cluster MC hardware. From what I can see it is only SWIM. MC There seem to be pins so you can hook up a jtag programmer, it would be MC possible to reprogram the STM32 to do what you want. MC Unused pin seem to be non connected and not much room to hook stuff up. MC That would be an interesting challenge to put wires there. MC You could steal the bit used for the LED. So you mean the JTAG connector is for reprogramming the STM32, and not for connecting other boards? That does make it somewhat less attractive... I've looked at the schematics more closely, and it seems the pins we'd need to connected are marked T_JTCK, T_JTDO etc. (15 to 19) You could probably solder some thin wires directly to the CPU legs but I don't know if it's worth the trouble... -- WBR, Igormailto:skochin...@mail.ru ___ 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
[reposting to list... I really wish this list had a proper reply-to] Hello David, Monday, February 1, 2010, 11:06:41 PM, you wrote: DB It's come to my attention that at least current versions of NXP's DB LPCXpresso [1] ($US 30) might include a candidate for this. [...] DB One question is whether they've tried to lock down that board DB to blessed firwmare images -- crypto-sealed by someone. DB If they have, this kind of project wouldn't work. I think the DB hardware is designed to support that stuff, so another issue DB would be whether they'd switch to that in the future. The firmwares bundled with LPCXpresso (LPCXpressoXX.enc) are encrypted, and not just with the standard TEA key. I expect that 3154 on the board has an AES key programmed in OTP and won't accept unencrypted firmwares. Also, NXP said that LPC-Link is supposed to be used only with the LPCXpresso IDE: http://knowledgebase.nxp.com/showpost.php?p=250postcount=2 -- WBR, Igormailto:skochin...@mail.ru ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Have the NAND erase function use the nand page command
Hello Dean, Friday, December 18, 2009, 10:00:16 PM, you wrote: DG Alright, GMail was putting my signature above the quoted email DG because of a lab thing I had enabled. It is now disabled so I DG should start to put my responses in a better place. I took a look DG at the archives and it is pretty hard to follow the conversation :). Now you just need to remember to send text, not HTML. -- WBR, Igormailto:skochin...@mail.ru ___ 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
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.
On Wed, Dec 16, 2009 at 14:47, Marcelo Utikawa da Fonseca
marcelo.fons...@tecnequip.com.br wrote:
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:
1) Memory containing correct data:
mdw 0 0x20
0x: e59ff018 e59ff018 e59ff018 e59ff018 e59ff018 b9206e58 e51ff120
e59ff010
0x0020: 0038 1244 1258 121c 1230 126c e59f0198
e321f0db
0x0040: e1a0d000 e244 e321f0d7 e1a0d000 e244 e321f0d1 e1a0d000
e244
0x0060: e321f0d2 e1a0d000 e2400040 e321f0d3 e1a0d000 e2400040 e321f0df
e1a0d000
2) Now I do a erase and show the data again:
flash erase_sector 0 0 0
erased sectors 0 through 0 on flash bank 0 in 0.171872s
mdw 0 0x20
0x:
0x0020:
0x0040:
0x0060:
3) The flash seems to be erased. Now I turn off the board, turn on again and
reconnect the OpenOCD. Here is the result:
halt
target state: halted
target halted in Thumb state due to debug-request, current mode: Supervisor
cpsr: 0xa0f3 pc: 0x7fffe154
mdw 0 0x20
0x: e59f4018 e59f5010 e5946000 e0056006 e5846000 e51ff004 7fffe040
bfff
0x0020: 3fff8000
0x0040:
0x0060:
In the J-Flash software, the command to read back the entire chip shows only
0xff but the J-Link Commander can read exactly the same data:
SEGGER J-Link Commander V3.96d ('?' for help)
Compiled Nov 21 2008 19:00:17
DLL version V3.96d, compiled Nov 21 2008 18:59:52
Firmware: J-Link ARM V6 compiled Jun 30 2009 11:06:04
Hardware: V6.00
S/N : 156002960
OEM : IAR
VTarget = 3.319V
Info: TotalIRLen = 4, IRPrint = 0x01
Found 1 JTAG device, Total IRLen = 4:
Id of device #0: 0x4F1F0F0F
Found ARM with core Id 0x4F1F0F0F (ARM7)
ETM V1.2: 1 pairs addr.comp, 0 data comp, 4 MM decs, 1 counters
RTCK reaction time is approx. 189ns
Using adaptive clocking instead of fixed JTAG speed.
J-Linkmem 0 0x80
= 18 40 9F E5 10 50 9F E5 00 60 94 E5 06 60 05 E0
0010 = 00 60 84 E5 04 F0 1F E5 40 E0 FF 7F FF BF FF FF
0020 = 00 80 FF 3F 00 00 00 00 00 00 00 00 00 00 00 00
0030 = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0040 = FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
0050 = FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
0060 = FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
0070 = FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
J-Link
What can be wrong?
Best regards,
Marcelo Utikawa da Fonseca
Nico Coesel escreveu:
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
Re: [Openocd-development] Problem when tryng to flash LPC2368
Marcelo, The current lpc2000.c mentions this: /* * flash bank lpc2000 base size 0 0 target# lpc_variant cclk [calc_checksum] */ Have you tried adding calc_checksum? On Wed, Dec 16, 2009 at 16:13, Nico Coesel ncoe...@dealogic.nl wrote: -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 -- WBR, Igor ___ 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
Marcelo, Try changing the MEMMAP register (see User Manual for details). On Wed, Dec 16, 2009 at 17:05, Marcelo Utikawa da Fonseca marcelo.fons...@tecnequip.com.br wrote: First of all, thanks for everyone helping me to solve this issue! :-) Igor: I am sorry! Now I found the text about memory map after a reset. The problem regarding the first 64 bytes was solved. Now I just need to know how to disable this memory map... About calc_checksum, I am already using it: flash bank lpc2000 0x0 0x8 0 0 0 lpc2000_v2 12000 calc_checksum Nico: lpc21isp will be a very useful tool! I will try it. thank you very much! I still need OpenOCD to debug software using GDB. When the gdb succesfully write to the flash memory, the program starts and reaches a breakpoint in main. When it fails, the breakpoint is never reached. When I stop gdb, pc is in 0xc address (undefined instruction vector). After gdb write to memory, I run the command: monitor mdw 0 0x20 sometimes it shows the same initial 64 bytes (now I know that this is the mapped memory) and sometimes the correct data. Why sometimes it works and sometimes it do not? How can I disable this memory to be mapped? I will search for this, any news I will send to the list! Thank you very much again! Best regards, Marcelo Utikawa da Fonseca Igor Skochinsky escreveu: Marcelo, The current lpc2000.c mentions this: /* * flash bank lpc2000 base size 0 0 target# lpc_variant cclk [calc_checksum] */ Have you tried adding calc_checksum? On Wed, Dec 16, 2009 at 16:13, Nico Coesel ncoe...@dealogic.nl wrote: -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 - Tecnequip Tecnologia em Equipamentos Endereço/Address: R. Ganges, 557 Cidade/City: São Paulo Estado/State: SP País/Country: Brasil CEP/Postal Code: 03445-030 Fone/Phone: 55-11-20937199 FAX: 55-11-29412289 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development -- WBR, Igor ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Codecheck
Hello Carsten, Wednesday, December 16, 2009, 9:00:58 PM, you 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. CB OK, then i will start to fix all the mallocs CB that are handled not correct yet and where CB i understand what to do if they fail. There is an emerging opinion that checking for malloc failures in application code is counterproductive: 1) it is rarely tested properly, thus almost never works as expected when allocation does fail 2) it bloats the code, in some case substantially, and obscures the real code flow 3) it's very hard to write a proper rollback algorithm for all situations 4) if the system is at the stage where malloc fails, there's little guarantee that your recovery code will work properly 5) many systems just kill the process when the memory is exhausted instead of returning NULL http://article.gmane.org/gmane.comp.audio.jackit/19998 http://log.ometer.com/2008-02.html#4.2 -- WBR, Igormailto:skochin...@mail.ru ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Codecheck
Hello Carsten, Wednesday, December 16, 2009, 11:57:23 PM, you wrote: Just one point. 2) it bloats the code, in some case substantially, and obscures the real code flow CB The real code flow ends in nothing. There are embedded CPU's that have CB no problem with writing to zero. They just do it. So this is really nice CB to search errors. Good luck. here I meant the code flow for someone who is reading the source, not the CPU execution path. Actually, I think a common emalloc() function that (in the unlikely event of malloc failure) prints an error message and exits the app is a better choice than sticking checks everywhere. -- WBR, Igormailto:skochin...@mail.ru ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] basic ARM semihosting support
Hello Nicolas, Thursday, December 3, 2009, 7:58:05 AM, you wrote: NP Semihosting enables code running on an ARM target to use the I/O NP facilities on the host computer. The target application must be linked NP against a library that forwards operation requests by using the SVC NP instruction that is trapped at the SWI vector by the debugger. The hosted NP library version provided with CodeSourcery's Sourcery G++ Lite for ARM EABI NP is one example. NP This is currently available for ARM9 processors, but any ARM variant should NP be able to support this with little additional work. GDB protocol has support for target syscalls: http://sourceware.org/gdb/download/onlinedocs/gdb_37.html#SEC686 Might be worth adding an option to translate semihosting calls into File-I/O requests. I think this should e.g. allow IDEs to print the target output into the Console window. -- WBR, Igormailto:skochin...@mail.ru ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch/rfc] JTAG: simple autoprobing
Hello David, Monday, October 26, 2009, 9:08:47 AM, you wrote: DB There'd potentially be a LOT of those autoconf_$IDCODE things. DB So it might be important to segment them by vendor ID... that DB auto.cfg file looks at the ID and sources auto/arm.cfg or DB whatever. DB But, I'm not sure I could see them replacing the static configs. DB Thing is, IDCODE values aren't especially unique between vendors, DB at least for microcontrollers, and there are a lot of important DB things they can't expose. It might be worth looking at how UrJtag does such things: http://urjtag.svn.sourceforge.net/viewvc/urjtag/trunk/urjtag/data/ See MANUFACTURERS file, then PARTS inside each manufacturer directory. -- WBR, Igormailto:skochin...@mail.ru ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.3 schedule
Hi, On Sat, Oct 24, 2009 at 19:55, Øyvind Harboe oyvind.har...@zylin.com wrote: Yes; we're overdue to close this dev cycle, IMO. I get the feeling Ųyvind is impatient for 0.4.0-dev ... :) One day I'll be able to post messages/email and have my name come out right: Øyvind. See http://www.zylin.com/contact.html. Unless you have a totally braindead browser, you should see my name with the right glyphs. I think you need to fix your client unless some relay server screwed up the message. Here, David's email headers say: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable And the actual string is: I get the feeling =D8yvind is impatient for 0.4.0-dev ... :) D8 is Ø in iso-8859-1, so it was encoded correctly (and shows up fine in Gmail). -- WBR, Igor ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Disassembler?
Hello Colin,
I don't see the point of making an advanced disassembler out of
OpenOCD. I think the main purpose of adding the routine was to do some
spot checks during debugging. In fact, it's probably not really
necessary once gdb interface was implemented, as gdb can do
disassembly itself.
If you need to disassemble a lot of code offline, it's much better
to use specialized tools such as objdump or IDA Pro or whatnot.
On Sun, Oct 25, 2009 at 01:36, Colin Howarth co...@howarth.de wrote:
Hello all,
I'm not entirely sure this is appropriate here, it being an OpenOCD
developer's list and not an ARM developer's list as such :-(
However, I was wondering how many of you actually code in ARM assembler? Do
you avoid it wherever you can, using a high-level language and gcc?
For those that do do assembly code, do you have a Good (TM) disassembler?
The armv4_5 disassemble command is fine, in that it disassembles, but as
I mentioned a while back, it doesn't produce what I would have written as an
assembly code routine :-)
So, I've written a quick 2-pass assembly code post-processor in Perl, and
was wondering if anyone else had any interest in it.
So far, it does this:
a) identifies subroutine calls (ie. BL)
b) identifies returns (e.g. BX R14; LDMFD R13!, {r0, r1, r15}; )
c) identifies labels (e.g BNE 0x1234)
d) identifies PC-relative addressed data
e) locates the definition of the base register (e.g. LDR r0, [r15, #0x18];
... STR r0, [r2] )
It prints out the marked up assembly code on the second pass.
Thus:
0x072c 0xe59f3088 LDR r3, [r15, #0x88]
0x0730 0xe1540003 CMP r4, r3
0x0734 0x1a09 BNE 0x0760
0x0738 0xe3a00501 MOV r0, #0x40
0x073c 0xe3a01001 MOV r1, #0x1
0x0740 0xeb000174 BL 0x0d18
0x0744 0xe3a00501 MOV r0, #0x40
0x0748 0xe3a01000 MOV r1, #0x0
0x074c 0xeb000171 BL 0x0d18
0x0750 0xe3a02000 MOV r2, #0x0
0x0754 0xe59f303c LDR r3, [r15, #0x3c]
0x0758 0xe58320ac STR r2, [r3, #0xac]
0x075c 0xe89da810 LDMIA r13, {r4, r11, r13, r15}
0x0760 0xe59f3058 LDR r3, [r15, #0x58]
0x0764 0xe1540003 CMP r4, r3
0x0768 0x189da810 LDMNEIA r13, {r4, r11, r13, r15}
0x076c 0xe3a00502 MOV r0, #0x80
0x0770 0xe3a01001 MOV r1, #0x1
0x0774 0xeb000167 BL 0x0d18
0x0778 0xe3a00502 MOV r0, #0x80
0x077c 0xe3a01000 MOV r1, #0x0
0x0780 0xeb000164 BL 0x0d18
0x0784 0xe3a02000 MOV r2, #0x0
0x0788 0xe59f3008 LDR r3, [r15, #0x8]
0x078c 0xe58320ac STR r2, [r3, #0xac]
0x0790 0xe89da810 LDMIA r13, {r4, r11, r13, r15}
0x0794 0x58006000 STMPLDA r0, {r13, r14
0x0798 0x5c002000 UNDEFINED INSTRUCTION
0x079c 0x58007000 STMPLDA r0, {r12, r13, r14}
Becomes:
0x072c 0xe59f3088 LDR r3, [r15, #0x88] ; data at
0x07bc: 0x5800e000
0x0730 0xe1540003 CMP r4, r3
0x0734 0x1a09 BNE 0x0760 ; branch to
label_26 at: 0x0760
0x0738 0xe3a00501 MOV r0, #0x40
0x073c 0xe3a01001 MOV r1, #0x1
0x0740 0xeb000174 BL 0x0d18 ; call
subroutine_7 at: 0x0d18
0x0744 0xe3a00501 MOV r0, #0x40
0x0748 0xe3a01000 MOV r1, #0x0
0x074c 0xeb000171 BL 0x0d18 ; call
subroutine_7 at: 0x0d18
0x0750 0xe3a02000 MOV r2, #0x0
0x0754 0xe59f303c LDR r3, [r15, #0x3c] ; data at
0x0798: 0x5c002000
0x0758 0xe58320ac STR r2, [r3, #0xac] ; Base defined at
0x0754
0x075c 0xe89da810 LDMIA r13, {r4, r11, r13, r15} ; Return from
subroutine
label_26:
0x0760 0xe59f3058 LDR r3, [r15, #0x58] ; data at
0x07c0: 0x5800f000
0x0764 0xe1540003 CMP r4, r3
0x0768 0x189da810 LDMNEIA r13, {r4, r11, r13, r15} ; Return from
subroutine
0x076c 0xe3a00502 MOV r0, #0x80
0x0770 0xe3a01001 MOV r1, #0x1
0x0774 0xeb000167 BL 0x0d18 ; call
subroutine_7 at: 0x0d18
0x0778 0xe3a00502 MOV r0, #0x80
0x077c 0xe3a01000 MOV r1, #0x0
0x0780 0xeb000164 BL 0x0d18 ; call
subroutine_7 at: 0x0d18
0x0784 0xe3a02000 MOV r2, #0x0
0x0788 0xe59f3008 LDR r3, [r15, #0x8] ; data at
0x0798: 0x5c002000
0x078c 0xe58320ac STR r2, [r3, #0xac] ; Base defined at
0x0788
0x0790 0xe89da810 LDMIA r13, {r4, r11, r13, r15} ; Return from
subroutine
0x0794 0x58006000 DATA STMPLDA r0, {r13, r14}
0x0798 0x5c002000 DATA UNDEFINED INSTRUCTION
0x079c 0x58007000 DATA STMPLDA r0, {r12, r13, r14}
Which should soon become:
0x072c 0xe59f3088 LDR r3, data_1 0x5800e000 =? non_buffered APB0 +
GPIO_PORT_P8
0x0730 0xe1540003 CMP r4, r3
0x0734 0x1a09 BNE label_26
0x0738 0xe3a00501 MOV r0, #0x40
0x073c
Re: [Openocd-development] [PATCH] cast from long to HANDLER on MinGW-W64
Hello Redirect, Sunday, October 18, 2009, 1:14:20 AM, you wrote: RSN Yeah. The problem here is that HANDLE is typedef'd as void* (in RSN winnt.h), whereas _get_osfhandle() returns a long RSN (http://msdn.microsoft.com/en-us/library/ks2530z6.aspx), and gcc RSN insists on returning a warning when casting a 32 bit long into a RSN 64 bit pointer (cast to pointer from integer of different size). RSN The most elegant way I found to avoid that warning is to do an arithmetic operation first. RSN Of course one has to wonder why a function that is meant to RSN return a handle does not actually return a type HANDLE... RSN The only other way I see to do it is to add idefs for MINGW64 so RSN that we cast _get_osfhandle() to a long long first. Actually, in VC9 it returns intptr_t (MSDN is wrong here): _CRTIMP intptr_t __cdecl _get_osfhandle(_In_ int _FileHandle); (from io.h) So it might be worth it to get mingw people to fix their headers... -- WBR, Igormailto:skochin...@mail.ru ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] SourceForge terms changes
Hello All, FYI, a new version of SF.net terms of use has been posted and is to take effect on the 29th. http://sourceforge.net/apps/trac/sitelegal/wiki/Terms%20of%20Use Not sure if changes affect OpenOCD, but worth checking IMO. -- WBR, Igor mailto:skochin...@mail.ru ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Switch to non-Berlios mailing list
Hello Øyvind, Monday, October 5, 2009, 11:28:45 PM, you wrote: ØH Migrate away from Berlios committe wants an alternative ØH to Berlios mailing lists. ØH Some alternatives so far: ØH - Set up seperate openocd.org server = not going to happen. We ØH don't have the resources and dedication to run it. ØH - sourceforge mailing lists apparently suck more than Berlios ØH mailing lists. I don't know why ØH - Google mailing lists are apparently better but I don't know why ØH - Yahoo is worse than google ØH Can someone do some research on what would be good to ØH use and explain a bit? I guess I'll bite. Some of this can be wrong. 1) SF.net (info is kinda old, haven't been subscribed to any lists recently): software: mailman 2.1 email subscribe/unsubscribe: yes footer added: yes, with ads (?) reply-to: list web archive: yes spam: no idea extras: all SF.net stuff It seems at least some time ago it did callback verification, which doesn't work with some emails: http://it.slashdot.org/article.pl?sid=06/10/04/1324214 OTOH, UrJTAG seems to be doing okay. 2) Yahoo groups: software: custom email subscribe/unsubscribe: yes footer added: usage; sometimes ads(?) reply-to: list web archive: yes extras: file area, calendar, links, database, other crap Used to bounce for me quite often a couple of years ago, doesn't seem to happen anymore. Ads seem to be gone, but the large footer with ML links can be annoying. Not sure if it's configurable. 3) Google groups: software: custom email subscribe/unsubscribe: yes footer added: configurable reply-to: configurable web archive: yes extras: pages, files, rss feeds Can't really say much. Seems to work okay. -- WBR, Igormailto:skochin...@mail.ru ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch/rfc] cleanup TAP ircapture/irmask
Hello David, Saturday, September 26, 2009, 8:11:26 AM, you wrote: DB REQUEST: someone with the IEEE JTAG spec, please verify that DB entry to IR_Capture state is required to load the shift register DB with x01 bits (as I'm told it does). Not the actual spec, but the Boundary-Scan Handbook says this: CAPTURE-IR In this controller state, the shift-register[16] contained in the Instruction Register parallel loads a pattern of fixed logic values on the rising edge of TCK. The two least significant bits[17] are assigned the values 01. Any higher-order bits of the Instruction Register, if they exist, may receive fixed bit values or design specific values. This bit pattern is not necessarily an instruction; it has significance as a test pattern for the integrity of the 1149.1 circuitry as will be seen in Chapters 3 and 5. When the TAP Controller is in CAPTURE-IR, the controller enters either the EXIT1-IR state if TMS is high or the SHIFT-IR state if TMS is low. [16] Registers are constructed with dual ranks, a shiftable part and a hold part to prevent rippling, due to shifting, from being visible to downstream logic. When we say a register is selected or shifted, we mean the shift portion of it which is connected between TDI and TDO. [17] Throughout this book, any pattern of bits will be displayed with the most significant bit on the left, through to the least significant on the right. The least significant bit would be the first bit shifted into TDI or out from TDO. -- WBR, Igormailto:skochin...@mail.ru ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] arm11 single stepping support
On Wed, Aug 26, 2009 at 16:29, Øyvind Harboeoyvind.har...@zylin.com wrote: I've worked on refactoring the arm simulation code to be able to support non-armv4_5 targets. The approach is to define an interface that the caller has to support. See below for example. Thoughts? Objections? I think there is no need to add extra get_xxx pointers since the necesary actions (get registers, read memory etc) should be reachable from target_t*. We also need to think about non-arm targerts. As for ARM, I think arm_simulator.c and arm_disassembler.c should be merged since they share a lot of functionality. -- WBR, Igor ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] arm11 single stepping support
Hi, On Wed, Aug 26, 2009 at 17:58, David Brownelldavi...@pacbell.net wrote: On Wednesday 26 August 2009, Igor Skochinsky wrote: As for ARM, I think arm_simulator.c and arm_disassembler.c should be merged since they share a lot of functionality. They seem kind of separate to me. I can disassemble without wanting to simulate. And vice versa. If anything, they should be *more* separate. Sorry, I did not look closely at the code. I saw some bit manipulation and mistakenly thought that simulator does it to determine the instruction type, operands etc. Now I see that it uses disassembler to parse the instruction, and that's what I meant about merging them. There's no need to actually merge the files, I only wanted to avoid code duplication. The whole simulator bears some thought though. Is the whole point of it just to enable one type of single stepping? I don't recall seeing comments about when/why the simulator would kick in. Right now it seems to be used only for single-stepping. I'm not sure if there are any other uses. -- WBR, Igor ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Adding support for X and F GDB Stop Reply Packets and additional signals
Hello Jon, Tuesday, July 28, 2009, 10:28:37 PM, you wrote: JB I'm porting OpenOCD to a new processor architecture and I've noticed that JB there doesn't appear to be any support for the X and F GDB Stop Reply JB Packets JB (http://sourceware.org/gdb/current/onlinedocs/gdb_34.html#SEC724), JB which are used to indicate that a process has exited (X) or to perform JB system calls on the host (F). You're looking at this from the wrong side. The GDB server in OpenOCD is what is called stub in the documentation. It does not need to support F or X; those need to be implemented on the host side _if_ the stub is going to send them. And I don't see a situation when OpenOCD would send those. (Well, I guess it could send X if it loses connection with the target...) JB Also, there doesn't currently appear to be any support for signals other JB than SIGINT SIGTRAP. I think it would be useful if other common signals JB such as SIGBUS, SIGILL and SIGSEGV could also be passed on, when applicable. Those are all user-mode signals. Since OpenOCD works on the lowest level (JTAG), it doesn't know about processes. It can only report events from hardware (such as breakpoints). I guess one _could_ install a custom prefetch abort handler and convert it to a SIGBUS... but it's much more likely that OpenOCD user is debugging a kernel or an RTOS which has its own handler. JB Looking at server/gdb_server.c, it should be fairly straight forward to do JB by adding a few additional DBG_REASON_s. There shouldn't be any issues for JB targets that don't support them - as the code will not be executed. JB If I create a patch to add support for this, is it likely to be accepted, or JB is there a reason there is no support for this? -- WBR, Igormailto:skochin...@mail.ru ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] ARM document: Writing JTAG Sequences for ARM9 Processors
Hi All, Saw this today on my RSS, might be useful. HTML: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dai0205a/index.html PDF: http://infocenter.arm.com/help/topic/com.arm.doc.dai0205a/DAI0205A_writing_jtag_sequences_for_arm9_processors.pdf -- WBR, Igor ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Ugly fix for J-Link hard power-on
Hello Spencer, Monday, June 1, 2009, 1:07:39 PM, you wrote: SO A few unknown cmds in there, also notice the trash data at the beginning - SO from a previous 01 cmd. I described two here: https://lists.berlios.de/pipermail/openocd-development/2009-May/006781.html Let me know if you need any others. -- WBR, Igormailto:skochin...@mail.ru ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] On Resets
Hello Øyvind, Saturday, May 30, 2009, 9:40:54 AM, you wrote: than just conform to JTAG spec. No problem when docs are available ... but sometimes they aren't. ØH XScale is under Marvell NDA for instance :-) Really? What's this then? http://www.marvell.com/products/cellular/application/PXA27x.jsp http://www.marvell.com/products/cellular/application/PXA3xx_series.jsp Also, Intel still has some XScale docs on their site. E.g. Intel XScale® Core Developer’s Manual: http://download.intel.com/design/intelxscale/27347302.pdf Some others can be found mirrored elsewhere: http://www.penguin.cz/~utx/zaurus/datasheets/CPU/ -- WBR, Igormailto:skochin...@mail.ru ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Listing BSDL files
Hello Alan, Friday, May 29, 2009, 4:38:55 PM, you wrote: ACdA Did I forget other BSDL links? Show me the link ;-) http://www.freelabs.com/~whitis/electronics/jtag/ under Semiconductor Manufacturer's BSDL files -- WBR, Igormailto:skochin...@mail.ru ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD and different versions of J-Link
Hello Xiaofan, Saturday, May 23, 2009, 2:17:33 PM, you wrote: XC On Tue, May 19, 2009 at 8:26 AM, Igor Skochinsky skochin...@mail.ru wrote: What I mean is I could write up a list of missing/underdocumented commands and describe their input/output parameters. I don't have a J-Link so I don't really need the code myself. XC Are you using reverse engineering from the J-Link Windows DLL? libjlinkarm.so from the recently released Linux version. -- WBR, Igormailto:skochin...@mail.ru ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] parallel port reset config with xscale
Hi, On Tue, May 19, 2009 at 12:43, Wookey woo...@wookware.org wrote: But we've been using these dongles for years to program these boards, and so have others, so clearly it can work. Is there some way to make openOCD behave in a sufficiently simple-minded manner to work with old-fashion parallel dongles? Perhaps emitting a 'hit reset manually' message? Would that help? If there is then I'll finish adding support for the lart/jtux device and send it in, but currently I'm stuck. jflash/bflash and such use boundary scan to toggle pins connected to flash chips and program them. AFAIK OpenOCD does not have that ability, it can only use CPU debug mode to access the memory (and thus the flash). XScale is rather tricky to get into debug as it needs some fine timing with srst and trst signals. So I don't think you can get your dumb dongles to work without adding boundary scan option to OpenOCD. I once had to dump a flash from a PXA270 board with a simple 4-wire adapter and was not able to make OpenOCD work. In the end I hacked bflash (I think) to do it with boundary scan (slw but hey, it worked). Another option is [X]SVF files. I don't know much about them, but I think they can be used to program flash via boundary scan too. -- WBR, Igor ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD and different versions of J-Link
Hello Benjamin, Tuesday, May 19, 2009, 12:39:26 AM, you wrote: BS There's this segger closed source linux gdm server tool... BS http://www.segger.com/pub/jlink/JLink_Linux_090202.tar.gz BS It can show the hardware version. Is there a necessity to map missing JLink commands? I could find them out, e.g.: ReadHardwareVersion input: 0xF0 (1 byte) output: version (4 bytes) ReadOTS (OTP Structure) input: 0xE6 (1 byte) output: OTS buffer (256 bytes) +0x00 4 serial no +0x10 16 OEM string +0x20 16 feature string 1 +0x30 16 feature string 2 ... +0x90 16 feature string 8 etc. -- WBR, Igormailto:skochin...@mail.ru ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD and different versions of J-Link
Hello Benjamin, Tuesday, May 19, 2009, 2:48:30 AM, you wrote: BS I think this wouldn't hurt anyone and could be very useful for debugging like BS this. BS But it should definately check via EMU_CMD_GET_CAPS first if command is BS available. At the moment the caps value is read from the device but for BS example the call to EMU_CMD_GET_MAX_MEM_BLOCK is done on my V3 JLink even BS though the caps value says the command is not available. BS This causes a segfault (not exactly sure, at least an error message), because BS the mem block size is set to 0. What I mean is I could write up a list of missing/underdocumented commands and describe their input/output parameters. I don't have a J-Link so I don't really need the code myself. -- WBR, Igormailto:skochin...@mail.ru ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [Tiff] Potential problem in libtiff when compiled in MinGW
Hello Bob, Sunday, May 17, 2009, 6:44:41 PM, you wrote: BF I see. MinGW depends on whatever library happens to be installed so BF %ll may work on some Windows systems (which happen to have an BF updated library) and not on others. None of the MSVC runtime libraries support %ll, you have to use %I64. Since MinGW uses older msvcrt.dll which is unlikely to be updated (API-wise), that situation will probably remain. -- WBR, Igormailto:skochin...@mail.ru ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] The in_handler Incident
Hi All, On Fri, May 8, 2009 at 19:19, Zach Welch z...@superlucidity.net wrote: [...] I apologize for hitting Reply instead of Reply-all (and the for my mailing system for delaying the second message just minutes later). Clearly, I have no intention of shying away from the public eye. Sorry for derailing the thread, but I have been hit by this issue a few times as well. I think this is the only ML I'm subscribed to that doesn't set Reply-To address to the ML address. Is there any reason for that and can the setting be changed? As for the topic, it's nice that Øyvind decided to stop for now, but in the meantime we have broken code in head. I think the best would be to revert to a known working version and Øyvind could try again when he got everything figured out. Also, one big patch for such change would be better than dozens of small ones IMO (yes, I know that it's against the local tradition). -- WBR, Igor ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] MSVC compatibility (Was: [PATCH] CMake)
Hello All, Tuesday, April 28, 2009, 7:29:46 PM, Dick wrote: DH Latest. DH Paaleese commit any time. So I decided to try the legendary CMake compatibility and compile OpenOCD with native Win32 MSVC. The makefile generation went mostly without a hitch, but the actual compilation ran into a lot of issues, mainly because of C99 and GNU-specific features. Main issues: 1) variable declarations not at the start of block 2) designated initializers (.field = value) 3) no unistd.h I've been going through the files trying to fix it up and now have most of it compiling, but I wonder if this will be useful for anyone else? Or C99 will be required for OpenOCD? -- WBR, Igormailto:skochin...@mail.ru ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] MSVC compatibility (Was: [PATCH] CMake)
Hi Dick, On Wed, Apr 29, 2009 at 16:47, Dick Hollenbeck d...@softplc.com wrote: Please always state your build environment. What operating system, and what tool chain is it trying to use? mingw32? cygwin? Just Visual Studio 2005, but I guess the exact version does not matter much. I will assume windows in the discussion below: Then be aware of my remarks that it has not been tested on Windows. There is some massaging required. It would only take about an hour to get it to work on windows, but my Windows days are mostly over. As I said, the makefile generation mostly works out of box (I only had to specifty location of libftd2xx manually). Right now I'm trying nmake makefiles, not VS projects. To deal with your issues, and assuming Windows, I would stick with the GNU compiler as your first attempt, and this means Mingw. So when generating your make files, be sure and use the command line option with tells it to use Mingw, not MS VC. Also make sure all your toolchain commands are in your path, including svn client and gcc. I know that it can be compiled with mingw and have done it myself. What I'm interested in now is making a pure msvc build, with no Unix-specific headers and libraries. But this means getting rid of all C99 and GNU stuff (besides what can be fixes with #defines, like __attribute__). Is that something that can be considered for OpenOCD at all, or completely out of question? The changes required so far are not really substantial, if a bit tedious to do. -- WBR, Igor ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] C99 compatibility (Was: MSVC compatibility (Was: [PATCH] CMake))
Hello Dick, Thursday, April 30, 2009, 4:28:54 AM, you wrote: Due to the lack of prior opposition, I had been debating whether to simply commit a change that adds -std=c99 and seeing how the community reacts (since I can now revert it quickly if it poses a real problem). DH The -std=c99 option is a big positive for me. I like it. There are C DH compilers and there are C++ compilers. In the C compiler realm, it is DH difficult to surpass GNU GCC and mingw and cygwin hosted forms. So I DH have lost all enthusiasm for trying to support another C compiler, DH because it means dumbing down the code. DH In the realm of C++ compilers, there is probably less reason to take DH this stance, since C++ compilers are all pretty capable, and you would DH not have to dumb down the code. DH So this command line option is a very good idea in my opinion. We are DH already programming on our hands and knees by choosing to use C. At DH least this gives us knee pads. Someday maybe we'll actually get up and DH program on our feet. So far the only C99 features I encountered were: 1) variables declared in the middle of a block 2) designated initializers (.field = value in structures) 3) variadic macros 3 is supported by MSVC. 1 can be convenient, but is not used that much in the source so far - most variables are still declared at the start of the block. 2 makes some structure definitions more compact, but really, is it that much harder to write /* name */ cfi, /* register_commands */ cfi_register_commands, /* flash_bank_command */ cfi_flash_bank_command, than .name = cfi, .register_commands = cfi_register_commands, .flash_bank_command = cfi_flash_bank_command, ? What are the _real_ benefits, not conveniences, that that switch can bring? -- WBR, Igormailto:skochin...@mail.ru ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] fix (sometimes) non-working Cortex-M3 breakpoints
Hello All,
This is my first patch, so please let me know if I did anything wrong.
The problem: for Cortex-M3 targets, the FPB unit (Flash Patch and
Breakpoint) was enabled only on reset event. If I connected to already
running code after it's been reset and tried to set some breakpoints,
OpenOCD would write into comparator registers, but the FPB would stay
disabled and breakpoints didn't work. So I added a check in
cortex_m3_set_breakpoint() which enables FPB if necessary.
--
WBR, Igor
Index: src/target/cortex_m3.c
===
--- src/target/cortex_m3.c (revision 1229)
+++ src/target/cortex_m3.c (working copy)
@@ -225,6 +225,7 @@
/* Enable FPB */
target_write_u32(target, FP_CTRL, 3);
+ cortex_m3-fpb_enabled = 1;
/* Restore FPB registers */
for (i = 0; i cortex_m3-fp_num_code + cortex_m3-fp_num_lit; i++)
@@ -869,6 +870,11 @@
comparator_list[fp_num].fpcr_value = (breakpoint-address
0x1FFC) | hilo | 1;
target_write_u32(target, comparator_list[fp_num].fpcr_address,
comparator_list[fp_num].fpcr_value);
LOG_DEBUG(fpc_num %i fpcr_value 0x%x, fp_num,
comparator_list[fp_num].fpcr_value);
+ if (!cortex_m3-fpb_enabled)
+ {
+ LOG_DEBUG(FPB wasn't enabled, do it now);
+ target_write_u32(target, FP_CTRL, 3);
+ }
}
else if (breakpoint-type == BKPT_SOFT)
{
@@ -1401,10 +1407,11 @@
/* Setup FPB */
target_read_u32(target, FP_CTRL, fpcr);
cortex_m3-auto_bp_type = 1;
- cortex_m3-fp_num_code = (fpcr 4) 0xF;
+ cortex_m3-fp_num_code = (fpcr 8) 0x70 | (fpcr 4)
0xF; /* bits [14:12] and [7:4] */
cortex_m3-fp_num_lit = (fpcr 8) 0xF;
cortex_m3-fp_code_available = cortex_m3-fp_num_code;
cortex_m3-fp_comparator_list = calloc(cortex_m3-fp_num_code +
cortex_m3-fp_num_lit, sizeof(cortex_m3_fp_comparator_t));
+ cortex_m3-fpb_enabled = fpcr 1;
for (i = 0; i cortex_m3-fp_num_code + cortex_m3-fp_num_lit;
i++)
{
cortex_m3-fp_comparator_list[i].type = (i
cortex_m3-fp_num_code) ? FPCR_CODE : FPCR_LITERAL;
Index: src/target/cortex_m3.h
===
--- src/target/cortex_m3.h (revision 1229)
+++ src/target/cortex_m3.h (working copy)
@@ -145,14 +145,15 @@
u32 nvic_dfsr; /* Debug Fault Status Register - shows reason for debug
halt */
u32 nvic_icsr; /* Interrupt Control State Register - shows active and
pending IRQ */
- /* Flash Patch and Breakpoint */
+ /* Flash Patch and Breakpoint (FPB) */
int fp_num_lit;
int fp_num_code;
int fp_code_available;
+ int fpb_enabled;
int auto_bp_type;
cortex_m3_fp_comparator_t *fp_comparator_list;
- /* DWT */
+ /* Data Watchpoint and Trace (DWT) */
int dwt_num_comp;
int dwt_comp_available;
cortex_m3_dwt_comparator_t *dwt_comparator_list;
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
