[Openocd-development] ARM IDLE mode and JTAG scan chain interrogation failed
Hi, I'm working with an LPC2388 (arm7tdmi-s core). I use the "IDLE" power mode to stop the arm core to reduce power consumption. All IT and peripheral are still ON in this mode, only the arm core is sleeping. The problem is when we want to use our probe (Olimex ARM-USB-OCD) with OpenOCD (0.5.0 from git 2011-05-20) we obtain an error message if the software already running on the board is using the IDLE mode : JTAG scan chain interrogation failed: all zeroes Check JTAG interface, timings, target power, etc. Trying to use configured scan chain anyway... Bypassing JTAG setup events due to errors I the software running on the CPU doesn't use the power reduction mode (arm core is still ON in this case) then I have no problem with the jtag. The problem seams to be related only to the power mode. Whatever the openocd command I use (reset, halt, soft_reset_halt, resume 0x00) openocd error is like : "Halt timed out, wake up GDB. timed out while waiting for target halted in procedure 'halt'" If I try to directly write to the CPU register to disable the IDLE mode, i get (a normal error message): "Target not halted" So I can not disable the IDLE mode with my jtag. I have to use the CPU integrated bootloader to reload a software with no IDLE mode through the RS232 link before I can use my Jtag again. I've seen other messages related to this point on the ML but has anyone found a solution to this problem ? Regards, -- Luc ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] ARM IDLE mode and JTAG scan chain interrogation failed
On 6 July 2011 10:02, Luc ANTOLINOS wrote: > Hi, > I'm working with an LPC2388 (arm7tdmi-s core). I use the "IDLE" power mode > to stop the arm core to reduce power consumption. All IT and peripheral are > still ON in this mode, only the arm core is sleeping. > Have you tried reducing the jtag clock? Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] ARM IDLE mode and JTAG scan chain interrogation failed
Hi, I'm working with an LPC2388 (arm7tdmi-s core). I use the "IDLE" power mode to stop the arm core to reduce power consumption. All IT and peripheral are still ON in this mode, only the arm core is sleeping. I the software running on the CPU doesn't use the power reduction mode (arm core is still ON in this case) then I have no problem with the jtag. The problem seams to be related only to the power mode. Whatever the openocd command I use (reset, halt, soft_reset_halt, resume 0x00) openocd error is like : "Halt timed out, wake up GDB. timed out while waiting for target halted in procedure 'halt'" If I try to directly write to the CPU register to disable the IDLE mode, i get (a normal error message): "Target not halted" So I can not disable the IDLE mode with my jtag. I have to use the CPU integrated bootloader to reload a software with no IDLE mode through the RS232 link before I can use my Jtag again. I've seen other messages related to this point on the ML but has anyone found a solution to this problem ? Regards, -- Luc Try to reduce the JTAG frequency or use a JTAGkey-2 with RTCK feature enabled since you have a ARM -s (arm7tdmi-s core). The RTCK will help to have your JTAG interface synchronized with the target frequency. Regards, Laurent Gauch http://www.amontec.com/jtagkey.shtml ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] ARM IDLE mode and JTAG scan chain interrogation failed
On 6 July 2011 11:08, Spencer Oliver wrote: > > I'm working with an LPC2388 (arm7tdmi-s core). I use the "IDLE" power > mode > Have you tried reducing the jtag clock? > > Hi, I've try the following settings : - jtag_khz 1 ==> Still can not halt or reset the board - jtag_rclk 1 ==> "RCLK not supported - fallback to 1 kHz" - adapter_khz 0 ==> "in procedure 'adapter_khz'" (I suppose this is an incomplete error message displayed), but when requesting "adpater_khz" I get "RCLK", but I suppose the settings has not really been changed. Here is a sequence of try : (gdb) monitor jtag_khz 1 1 kHz (gdb) monitor halt Halt timed out, wake up GDB. timed out while waiting for target halted in procedure 'halt' (gdb) monitor jtag_rclk 1 RCLK not supported - fallback to 1 kHz (gdb) monitor adapter_khz 0 in procedure 'adapter_khz' (gdb) monitor adapter_khz RCLK - adaptive (gdb) monitor halt Halt timed out, wake up GDB. timed out while waiting for target halted in procedure 'halt' -- Luc ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] ARM IDLE mode and JTAG scan chain interrogation failed
On 6 July 2011 11:29, Laurent Gauch wrote: > I'm working with an LPC2388 (arm7tdmi-s core). I use the "IDLE" power mode >> > Try to reduce the JTAG frequency or use a JTAGkey-2 with RTCK feature > enabled since you have a ARM -s (arm7tdmi-s core). > > The RTCK will help to have your JTAG interface synchronized with the target > frequency. > I've try to reduce the jtag_khz and jtag_rclk with no effect on my problem. I don't have a JTAGkey-2 probe, so can not test. So can I conclude to "no solution with my olimex probe" ? Are you sure a probe will full RTCK support can do the job ? -- Luc ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] ARM IDLE mode and JTAG scan chain interrogation failed
On 06/07/2011 10:53, Luc ANTOLINOS wrote: On 6 July 2011 11:08, Spencer Oliver mailto:s...@spen-soft.co.uk>> wrote: > I'm working with an LPC2388 (arm7tdmi-s core). I use the "IDLE" power mode Have you tried reducing the jtag clock? Hi, I've try the following settings : - jtag_khz 1 ==> Still can not halt or reset the board - jtag_rclk 1 ==> "RCLK not supported - fallback to 1 kHz" - adapter_khz 0 ==> "in procedure 'adapter_khz'" (I suppose this is an incomplete error message displayed), but when requesting "adpater_khz" I get "RCLK", but I suppose the settings has not really been changed. Here is a sequence of try : (gdb) monitor jtag_khz 1 1 kHz (gdb) monitor halt Halt timed out, wake up GDB. timed out while waiting for target halted in procedure 'halt' (gdb) monitor jtag_rclk 1 RCLK not supported - fallback to 1 kHz (gdb) monitor adapter_khz 0 in procedure 'adapter_khz' (gdb) monitor adapter_khz RCLK - adaptive (gdb) monitor halt Halt timed out, wake up GDB. timed out while waiting for target halted in procedure 'halt' Can you provide a full openocd log? It may be worth at this point to use telnet until we get a better idea of the issue. Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] ARM IDLE mode and JTAG scan chain interrogation failed
On Wed, Jul 6, 2011 at 11:02 AM, Luc ANTOLINOS wrote: > Hi, > I'm working with an LPC2388 (arm7tdmi-s core). I use the "IDLE" power mode > to stop the arm core to reduce power consumption. All IT and peripheral are > still ON in this mode, only the arm core is sleeping. > > The problem is when we want to use our probe (Olimex ARM-USB-OCD) with > OpenOCD (0.5.0 from git 2011-05-20) we obtain an error message if the > software already running on the board is using the IDLE mode : > JTAG scan chain interrogation failed: all zeroes > Check JTAG interface, timings, target power, etc. > Trying to use configured scan chain anyway... > Bypassing JTAG setup events due to errors > > I the software running on the CPU doesn't use the power reduction mode (arm > core is still ON in this case) then I have no problem with the jtag. The > problem seams to be related only to the power mode. > > Whatever the openocd command I use (reset, halt, soft_reset_halt, resume > 0x00) openocd error is like : > "Halt timed out, wake up GDB. > timed out while waiting for target halted > in procedure 'halt'" > > If I try to directly write to the CPU register to disable the IDLE mode, i > get (a normal error message): > "Target not halted" > So I can not disable the IDLE mode with my jtag. > > I have to use the CPU integrated bootloader to reload a software with no > IDLE mode through the RS232 link before I can use my Jtag again. > > I've seen other messages related to this point on the ML but has anyone > found a solution to this problem ? >From OpenOCD Manual Chapter 5.6 Target Software Changes : ARM Wait-For-Interrupt... Many ARM chips synchronize the JTAG clock using the core clock. Low power states which stop that core clock thus prevent JTAG access. Idle loops in tasking environments often enter those low power states via the WFI instruction (or its coprocessor equivalent, before ARMv7). You may want to disable that instruction in source code, or otherwise prevent using that state, to ensure you can get JTAG access at any time. For example, the OpenOCD halt command may not work for an idle processor otherwise. As a more polite alternative, some processors have special debug-oriented registers which can be used to change various features including how the low power states are clocked while debugging. The STM32 DBGMCU CR register is an example; at the cost of extra power consumption, JTAG can be used during low power states. Chapter 6.2.4 Warning: On most ARMs, JTAG clock detection is coupled to the core clock, so software using a ‘wait for interrupt’ operation blocks JTAG access. Adaptive clocking provides a partial workaround, but a more complete solution just avoids using that instruction with JTAG debuggers. Chapter 15.2 Target State handling Warning: On ARM cores, software using the wait for interrupt operation often blocks the JTAG access needed by a halt command. This is because that operation also puts the core into a low power mode by gating the core clock; but the core clock is needed to detect JTAG clock transitions. One partial workaround uses adaptive clocking: when the core is interrupted the operation completes, then JTAG clocks are accepted at least until the interrupt handler completes. However, this workaround is often unusable since the processor, board, and JTAG adapter must all support adaptive JTAG clocking. Also, it can’t work until an interrupt is issued. A more complete workaround is to not use that operation while you work with a JTAG debugger. Tasking environments generaly have idle loops where the body is the wait for interrupt operation. (On older cores, it is a coprocessor action; newer cores have a ‘wfi’ instruction.) Such loops can just remove that operation, at the cost of higher power consumption (because the CPU is needlessly clocked). Chapter 22 FAQ You can still debug the ’low power’ situations - you just need to either use a fixed and very slow JTAG clock rate ... or else manually adjust the clock speed at every step. (Adjusting is painful and tedious, and is not always practical.) It is however easy to “code your way around it” - i.e.: Cheat a little, have a special debug mode in your application that does a “high power sleep”. If you are careful - 98% of your problems can be debugged this way. Note that on ARM you may need to avoid using the wait for interrupt operation in your idle loops even if you don’t otherwise change the CPU clock rate. That operation gates the CPU clock, and thus the JTAG clock; which prevents JTAG access. One consequence is not being able to halt cores which are executing that wait for interrupt operation. BR, Drasko ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] ARM IDLE mode and JTAG scan chain interrogation failed
On 6 July 2011 12:05, Spencer Oliver wrote: > Can you provide a full openocd log? > > Attached to this mail. Debug level 3. > It may be worth at this point to use telnet until we get a better idea of > the issue. > Ok. Here is the sequence of commands (telnet on port ): Open On-Chip Debugger > jtag_khz 1 1 kHz > halt Halt timed out, wake up GDB. timed out while waiting for target halted in procedure 'halt' > jtag_rclk 1 ThumbEE -- incomplete support target state: halted target halted in ThumbEE state due to debug-request, current mode: System cpsr: 0x pc: 0xfff9 RCLK not supported - fallback to 1 kHz > adapter_khz 0 in procedure 'adapter_khz' > adapter_khz RCLK - adaptive > halt Halt timed out, wake up GDB. timed out while waiting for target halted in procedure 'halt' -- Luc Debug: 15 85 configuration.c:45 add_script_search_dir(): adding /home/lantolin/.openocd Debug: 16 90 configuration.c:45 add_script_search_dir(): adding /usr/local/share/openocd/site Debug: 17 93 configuration.c:45 add_script_search_dir(): adding /usr/local/share/openocd/scripts Debug: 18 105 configuration.c:87 find_file(): found openocdflashok.cfg Debug: 19 111 command.c:151 script_debug(): command - ocd_command ocd_command type ocd_telnet_port Debug: 20 115 command.c:151 script_debug(): command - telnet_port ocd_telnet_port Debug: 22 124 command.c:151 script_debug(): command - ocd_command ocd_command type ocd_gdb_port Debug: 23 125 command.c:151 script_debug(): command - gdb_port ocd_gdb_port Debug: 25 126 command.c:151 script_debug(): command - ocd_command ocd_command type ocd_interface ft2232 Debug: 26 126 command.c:151 script_debug(): command - interface ocd_interface ft2232 Debug: 28 127 command.c:364 register_command_handler(): registering 'ocd_ft2232_device_desc'... Debug: 29 127 command.c:364 register_command_handler(): registering 'ocd_ft2232_serial'... Debug: 30 127 command.c:364 register_command_handler(): registering 'ocd_ft2232_layout'... Debug: 31 128 command.c:364 register_command_handler(): registering 'ocd_ft2232_vid_pid'... Debug: 32 128 command.c:364 register_command_handler(): registering 'ocd_ft2232_latency'... Info : 33 128 transport.c:123 allow_transports(): only one transport option; autoselect 'jtag' Debug: 34 128 command.c:364 register_command_handler(): registering 'ocd_jtag_flush_queue_sleep'... Debug: 35 129 command.c:364 register_command_handler(): registering 'ocd_jtag_rclk'... Debug: 36 129 command.c:364 register_command_handler(): registering 'ocd_jtag_ntrst_delay'... Debug: 37 129 command.c:364 register_command_handler(): registering 'ocd_jtag_ntrst_assert_width'... Debug: 38 129 command.c:364 register_command_handler(): registering 'ocd_scan_chain'... Debug: 39 130 command.c:364 register_command_handler(): registering 'ocd_jtag_reset'... Debug: 40 146 command.c:364 register_command_handler(): registering 'ocd_runtest'... Debug: 41 146 command.c:364 register_command_handler(): registering 'ocd_irscan'... Debug: 42 146 command.c:364 register_command_handler(): registering 'ocd_verify_ircapture'... Debug: 43 147 command.c:364 register_command_handler(): registering 'ocd_verify_jtag'... Debug: 44 147 command.c:364 register_command_handler(): registering 'ocd_tms_sequence'... Debug: 45 147 command.c:364 register_command_handler(): registering 'ocd_wait_srst_deassert'... Debug: 46 148 command.c:364 register_command_handler(): registering 'ocd_jtag'... Debug: 47 148 command.c:364 register_command_handler(): registering 'ocd_jtag'... Debug: 48 148 command.c:364 register_command_handler(): registering 'ocd_jtag'... Debug: 49 148 command.c:364 register_command_handler(): registering 'ocd_jtag'... Debug: 50 149 command.c:364 register_command_handler(): registering 'ocd_jtag'... Debug: 51 149 command.c:364 register_command_handler(): registering 'ocd_jtag'... Debug: 52 149 command.c:364 register_command_handler(): registering 'ocd_jtag'... Debug: 53 149 command.c:364 register_command_handler(): registering 'ocd_jtag'... Debug: 54 150 command.c:364 register_command_handler(): registering 'ocd_jtag'... Debug: 55 150 command.c:364 register_command_handler(): registering 'ocd_jtag'... Debug: 56 150 command.c:364 register_command_handler(): registering 'ocd_jtag'... Debug: 57 150 command.c:364 register_command_handler(): registering 'ocd_jtag'... Debug: 58 150 command.c:364 register_command_handler(): registering 'ocd_jtag'... Debug: 59 165 command.c:364 register_command_handler(): registering 'ocd_svf'... Debug: 60 169 command.c:364 register_command_handler(): registering 'ocd_xsvf'... Debug: 61 170 command.c:151 script_debug(): command - ocd_command ocd_command type ocd_ft2232_device_desc Olimex OpenOCD JTAG Debug: 62 171 command.c:151 script_debug(): command - ft2232_device_desc ocd_ft2232_device_desc Olimex OpenOCD JTAG Debug: 64 172 command.c:151 script_debug(): command - ocd_command ocd_command type ocd_ft2232_layout olimex-j
Re: [Openocd-development] ARM IDLE mode and JTAG scan chain interrogation failed
On 6 July 2011 11:58, Luc ANTOLINOS wrote: > On 6 July 2011 12:05, Spencer Oliver wrote: >> >> Can you provide a full openocd log? >> > Attached to this mail. Debug level 3. > I really need to see a log of the actual problem, eg. you connect ok then when the target enters low power it all fails etc. Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] ARM IDLE mode and JTAG scan chain interrogation failed
On 6 July 2011 12:37, Drasko DRASKOVIC wrote: > From OpenOCD Manual Thanks for all the pointers to the documentation. From these informations, I understand the better way is to not use the wait for IRQ or other related low power consumption mode. It is off course possible to remove the IDLE mode for my software in debug configuration. > As a more polite alternative, some processors have special > debug-oriented registers which can be used to > change various features including how the low power states are clocked > while debugging. The STM32 > DBGMCU CR register is an example; at the cost of extra power > consumption, JTAG can be used during > low power states. I've not seen such settings in the LPC2388 manual. I'll check to be sure. -- Luc ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] ARM IDLE mode and JTAG scan chain interrogation failed
On Wed, Jul 6, 2011 at 1:08 PM, Luc ANTOLINOS wrote: > On 6 July 2011 12:37, Drasko DRASKOVIC wrote: >> From OpenOCD Manual > Thanks for all the pointers to the documentation. From these > informations, I understand the better way is to not use the wait for > IRQ or other related low power consumption mode. > It is off course possible to remove the IDLE mode for my software in As a rule of the thumb, stay away from ARMS "wfi" (wait for interrupt) instruction in your DEBUG more (in idle loop). This will prevent low-power mode, but at least you will be able to debug. However, normal behavior would be to use slow JTAG speed that ARM can handle in low-power mode and everything should work, even without adaptive clocking (you will be doomed to debug everything verly slow, though). BR, Drasko ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] ARM IDLE mode and JTAG scan chain interrogation failed
On 6 July 2011 12:14, Drasko DRASKOVIC wrote: > On Wed, Jul 6, 2011 at 1:08 PM, Luc ANTOLINOS wrote: >> On 6 July 2011 12:37, Drasko DRASKOVIC wrote: >>> From OpenOCD Manual >> Thanks for all the pointers to the documentation. From these >> informations, I understand the better way is to not use the wait for >> IRQ or other related low power consumption mode. >> It is off course possible to remove the IDLE mode for my software in > > As a rule of the thumb, stay away from ARMS "wfi" (wait for interrupt) > instruction in your DEBUG more (in idle loop). This will prevent > low-power mode, but at least you will be able to debug. > Openocd did work ok for wfi as long as the jtag clock was slow enough. However this was broken in HEAD last time i tested it - it has been on my look at list for a while Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] ARM IDLE mode and JTAG scan chain interrogation failed
On 6 July 2011 13:17, Spencer Oliver wrote: > Openocd did work ok for wfi as long as the jtag clock was slow enough. > However this was broken in HEAD last time i tested it - it has been on > my look at list for a while I'm not using 'WFI' instruction, I've found this one in the instruction set. I suppose this arm (Armv4T architecture) has not. I'm using a LPC2388 specific register to command entering low power mode (IDLE) (up to the next IRQ, so I obtain an same behavior that with WFI). -- Luc ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] ARM IDLE mode and JTAG scan chain interrogation failed
On 6 July 2011 13:17, Spencer Oliver https://lists.berlios.de/mailman/listinfo/openocd-development>> wrote: >/ Openocd did work ok for wfi as long as the jtag clock was slow enough. />/ However this was broken in HEAD last time i tested it - it has been on />/ my look at list for a while /I'm not using 'WFI' instruction, I've found this one in the instruction set. I suppose this arm (Armv4T architecture) has not. I'm using a LPC2388 specific register to command entering low power mode (IDLE) (up to the next IRQ, so I obtain an same behavior that with WFI). -- Luc Are you sure your Target JTAG interface is active in your low power mode ? Regards, Laurent http://www.amontec.com/jtagkey.shtml Amontec USB JTAG 30MHz / RTCK / 4 on-boards Status LEDs / 1.4V to 5.5V auto-sense. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] ARM IDLE mode and JTAG scan chain interrogation failed
On Wed, Jul 6, 2011 at 1:40 PM, Andreas Fritiofson wrote: > How could this work if the core clock is stopped? This should work, as host JATG inteface embedded in the ARM core has a procedure to remove WFI when it gets debug request from the dongle (if everything is well conetcted on AMBA bus and ARM's state machine procedures are well respected, which I do not doubt in LPC case). After this moment core is awaken, and you can JTAG can halt it. BR, Drasko ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] ARM IDLE mode and JTAG scan chain interrogation failed
On Wed, Jul 6, 2011 at 1:36 PM, Luc ANTOLINOS wrote: > On 6 July 2011 13:17, Spencer Oliver wrote: >> Openocd did work ok for wfi as long as the jtag clock was slow enough. >> However this was broken in HEAD last time i tested it - it has been on >> my look at list for a while > I'm not using 'WFI' instruction, I've found this one in the > instruction set. I suppose this arm (Armv4T architecture) has not. > > I'm using a LPC2388 specific register to command entering low power > mode (IDLE) (up to the next IRQ, so I obtain an same behavior that > with WFI). For the sake of experiment, can you try with WFI, and tell us what you are getting ? BR, Drasko ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] ARM IDLE mode and JTAG scan chain interrogation failed
On 6 July 2011 12:36, Luc ANTOLINOS wrote: > On 6 July 2011 13:17, Spencer Oliver wrote: >> Openocd did work ok for wfi as long as the jtag clock was slow enough. >> However this was broken in HEAD last time i tested it - it has been on >> my look at list for a while > I'm not using 'WFI' instruction, I've found this one in the > instruction set. I suppose this arm (Armv4T architecture) has not. > > I'm using a LPC2388 specific register to command entering low power > mode (IDLE) (up to the next IRQ, so I obtain an same behavior that > with WFI). > I know, just updating Drasko on the wfi status for armv7m arch. Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] ARM IDLE mode and JTAG scan chain interrogation failed
On 6 July 2011 13:52, Laurent Gauch wrote: > Are you sure your Target JTAG interface is active in your low power mode ? You seams to be right (even if I have not found this information in the user manual of the LPC2388 for the moment) : >From http://www.keil.com/support/man/docs/mcb2300/mcb2300_fp_ulink.htm I found : "The Embedded ICE in the LPC2000 core is disabled when the device is in Power Down or Idle" "ULINK stops working if your code puts the ARM device into Idle or Power Down mode" (here "ULINK" is the name of their usb-jtag adapter) -- Luc ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] ARM IDLE mode and JTAG scan chain interrogation failed
On 6 July 2011 13:55, Drasko DRASKOVIC wrote:
> For the sake of experiment, can you try with WFI, and tell us what you
> are getting ?
asm("wfi;");
==> /tmp/cctkCVDM.s: Assembler messages:
/tmp/cctkCVDM.s:5275: Error: selected processor does not support ARM mode `wfi'
'wfi' seams not to be part of the arm7tdmi-s instruction set.
--
Luc
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] ARM IDLE mode and JTAG scan chain interrogation failed
On Wed, Jul 6, 2011 at 1:57 PM, Spencer Oliver wrote: > On 6 July 2011 12:36, Luc ANTOLINOS wrote: >> On 6 July 2011 13:17, Spencer Oliver wrote: >>> Openocd did work ok for wfi as long as the jtag clock was slow enough. >>> However this was broken in HEAD last time i tested it - it has been on >>> my look at list for a while >> I'm not using 'WFI' instruction, I've found this one in the >> instruction set. I suppose this arm (Armv4T architecture) has not. >> >> I'm using a LPC2388 specific register to command entering low power >> mode (IDLE) (up to the next IRQ, so I obtain an same behavior that >> with WFI). >> > > I know, just updating Drasko on the wfi status for armv7m arch. LPC2388 has ARM7TDMI-S which should be ARMv4, right ? ARMv7 are little Cortexes ;). BR, Drasko ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] ARM IDLE mode and JTAG scan chain interrogation failed
On 6 July 2011 13:52, Laurent Gauch https://lists.berlios.de/mailman/listinfo/openocd-development>> wrote: >/ Are you sure your Target JTAG interface is active in your low power mode ? /You seams to be right (even if I have not found this information in the user manual of the LPC2388 for the moment) : >/From http://www.keil.com/support/man/docs/mcb2300/mcb2300_fp_ulink.htm /I found : "The Embedded ICE in the LPC2000 core is disabled when the device is in Power Down or Idle" "ULINK stops working if your code puts the ARM device into Idle or Power Down mode" (here "ULINK" is the name of their usb-jtag adapter) -- Luc Happy to know I point you to the right . The Power Down are specific to the target vendor not to the ARM arch. ;-) For me it is normal the target vendor disable the arm Embedded ICE core during the Power Down, by default. Regards, Laurent http://www.amontec.com/jtagkey.shtml USB JTAG programmer debugger for ARM7 ARM7tdmi-s ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] MIPS target, big endian host
Hi Øyvind, Did you see problems with host endianness or why did you commit this patch: http://openocd.git.sourceforge.net/git/gitweb.cgi?p=openocd/openocd;a=commit;h=2482244b0788c007dd789c21a4416379c229ea5c This patch brokes endianness on big endian host. "mips32_pracc_read_mem" and "mips32_pracc_write_mem" return values (buffer[i]) are already in host endianness, so le_to_h_u32 fails on big endian hosts. I already mentioned this in previous discussions. Best regards Stefan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] MIPS target, big endian host
> "mips32_pracc_read_mem" and "mips32_pracc_write_mem" return > values (buffer[i]) are already in host endianness, so le_to_h_u32 fails on > big endian hosts. I already > mentioned this in previous discussions. Ouch. Did you see this by testing or by inspection? The problem is that I mis-interpreted a warning from the compiler. The compiler warned me that I shouldn't cast a uint8_t * to a uint32_t * as this increases alignment. Do we even have the right macros here? It would be something like unaligned uint32_t access macros, which will have to exist in host endian versions. -- Øyvind Harboe - Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 87 40 27 http://www.zylin.com/ ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Windows 7 & J-Link Problems
I'm having a pile of bad times here getting J-Link to work with OpenOCD under Windows 7 for use on the AM1808 EVM. I've learned a few lessons; at least, I hope they're lessons, or I may have done many things very wrong. 1. In Windows 7, I had to set the LibUSB-Win32-0.1 installer to run in Windows XP compatibility mode or it would completely disable my USB ports: mouse, keyboard, all non-functional. 2. I have an aversion to depending on cygwin1.dll, but when Cygwin 1.7 was released, the -mno-cygwin flag didn't work. mingw-gcc-core is a gcc4 compiler that can make non-Cygwin executables. (Maybe this is old news, but it's news to me) 3. I copied the installed LibUSB-Win32-0.1 usb.h and libusb.a to include and lib, respectively, under /usr/i686-pc-mingw32/sys-root. 4. The configure options I used were: --enable-maintainer-mode --enable-dummy --enable-jlink --enable-ft2232_ftd2xx --with-ftd2xx-win32-zipdir=$HOME/local/src/ftd2xx --prefix=$HOME/local CC="i686-pc-mingw32-gcc" note 4a: I'd rather be using libftdi, but I didn't want to fight with it in Windows note 4b: I also wanted Bus Pirate support, but it requires termios.h which the MinGW-targeted gcc didn't provide This built cleanly, and I got an openocd.exe that doesn't segfault immediately and ldd says doesn't depend on cygwin1.dll. Those seem like positive things. The trouble comes when I try to use it. I'm using the target/omapl138.cfg because they're comparable chips (the OMAP-L138 is an AM1808 with a sequencer and a DSP), and I need something to get ICEpick to enable the debug ports. The same thing happens with no target specified and J-Link disconnected from the board. openocd.exe -c "source [find interface/jlink.cfg]" -c "source [find target/omapl138.cfg]" Open On-Chip Debugger 0.5.0-dev-00941-gff640f1 (2011-06-28-10:38) Licensed under GNU GPL v2 For bug reports, read http://openocd.berlios.de/doc/doxygen/bugs.html Warn : Adapter driver 'jlink' did not declare which transports it allows; assuming legacy JTAG-only Info : only one transport option; autoselect 'jtag' RCLK - adaptive fast memory access is enabled dcc downloads are enabled force hard breakpoints use of EmbeddedICE dbgrq instead of breakpoint for target halt enabled Info : J-Link initialization started / target CPU reset initiated Info : J-Link ARM V8 compiled Apr 27 2011 20:42:35 Info : J-Link caps 0xb9ff7bbf Info : J-Link hw version 8 Info : J-Link hw type J-Link Info : J-Link max mem block 8384 Info : J-Link configuration Info : USB-Address: 0x0 Info : Kickstart power on JTAG-pin 19: 0x0 Info : Vref = 3.319 TCK = 1 TDI = 0 TDO = 1 TMS = 0 SRST = 0 TRST = 0 Info : J-Link JTAG Interface ready Info : RCLK (adaptive clock speed) Error: usb_bulk_read failed (requested=1, result=0) Error: jlink_tap_execute, wrong result -107 (expected 1) Error: usb_bulk_read failed (requested=1, result=0) Error: jlink_tap_execute, wrong result -107 (expected 1) in procedure 'transport' in procedure 'init' It's clearly able to communicate with the J-Link to get the hardware information, version string, pin states (including Vref on the target). But then some USB reads fail. Afterwards, the J-Link becomes unresponsive for about 2 minutes; its LED is off, but it is still present in Device Manager, and repeated openocd attempts fail to get J-Link info: openocd.exe -c "source [find interface/jlink.cfg]" -c "source [find target/omapl138.cfg]" Open On-Chip Debugger 0.5.0-dev-00941-gff640f1 (2011-06-28-10:38) Licensed under GNU GPL v2 For bug reports, read http://openocd.berlios.de/doc/doxygen/bugs.html Warn : Adapter driver 'jlink' did not declare which transports it allows; assuming legacy JTAG-only Info : only one transport option; autoselect 'jtag' RCLK - adaptive fast memory access is enabled dcc downloads are enabled force hard breakpoints use of EmbeddedICE dbgrq instead of breakpoint for target halt enabled Info : J-Link initialization started / target CPU reset initiated Error: J-Link command 0x01 failed (-116) Error: J-Link command EMU_CMD_VERSION failed (0) Info : J-Link JTAG Interface ready Info : RCLK (adaptive clock speed) Error: J-Link command 0xdf failed (-116) Error: usb_bulk_write failed (requested=6, result=-116) Error: jlink_tap_execute, wrong result -107 (expected 1) Error: usb_bulk_write failed (requested=6, result=-116) Error: jlink_tap_execute, wrong result -107 (expected 1) in procedure 'transport' in procedure 'init' Is anyone else having problems with J-Link under Windows 7? Or just Windows 7? Or just J-Link? Thanks, ~Eric ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Windows 7 & J-Link Problems
On Wed, Jul 6, 2011 at 10:02 PM, Eric Wetzel wrote: > I'm having a pile of bad times here getting J-Link to work with > OpenOCD under Windows 7 for use on the AM1808 EVM. I've learned a few > lessons; at least, I hope they're lessons, or I may have done many > things very wrong. > 1. In Windows 7, I had to set the LibUSB-Win32-0.1 installer to run in > Windows XP compatibility mode or it would completely disable my USB > ports: mouse, keyboard, all non-functional. No no no! Please do not use the 0.1.x version of libusb-win32! Please use libusb-win32 1.2.4.0 release. It supports Windows 7 32bit and 64bit. Please remove the 0.1.12.x filter drivers before you install the 1.2.4.0 release. http://sourceforge.net/apps/trac/libusb-win32/wiki Then you can use the inf-wizard to replace the FTDI driver with libusb-win32. Or you can keep the FTDI driver but use the GUI Filter Wizard to install the device filter for the FTDI device. The device filter is safe to use, but not the class filter. If you use the GUI Filter Driver Wizard, you can attach the filter to the specific device which will not affect your other USB device. > 2. I have an aversion to depending on cygwin1.dll, but when Cygwin 1.7 > was released, the -mno-cygwin flag didn't work. mingw-gcc-core is a > gcc4 compiler that can make non-Cygwin executables. (Maybe this is old > news, but it's news to me) If you want to compile under Cygwin, you can use the latest MinGW cross compiler. > 3. I copied the installed LibUSB-Win32-0.1 usb.h and libusb.a to > include and lib, respectively, under /usr/i686-pc-mingw32/sys-root. > 4. The configure options I used were: --enable-maintainer-mode > --enable-dummy --enable-jlink --enable-ft2232_ftd2xx > --with-ftd2xx-win32-zipdir=$HOME/local/src/ftd2xx --prefix=$HOME/local > CC="i686-pc-mingw32-gcc" > note 4a: I'd rather be using libftdi, but I didn't want to fight with > it in Windows You can use libftdi. You can use Freddie's pre-built binary. Or if you prefer to build by yourself, I provide the libusbftdi-0.19 binaries for MinGW here. http://code.google.com/p/picusb/downloads/list > note 4b: I also wanted Bus Pirate support, but it requires termios.h > which the MinGW-targeted gcc didn't provide > > This built cleanly, and I got an openocd.exe that doesn't segfault > immediately and ldd says doesn't depend on cygwin1.dll. Those seem > like positive things. The trouble comes when I try to use it. I'm > using the target/omapl138.cfg because they're comparable chips (the > OMAP-L138 is an AM1808 with a sequencer and a DSP), and I need > something to get ICEpick to enable the debug ports. The same thing > happens with no target specified and J-Link disconnected from the > board. -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Windows 7 & J-Link Problems
On Wed, Jul 6, 2011 at 10:38 PM, Xiaofan Chen wrote: > On Wed, Jul 6, 2011 at 10:02 PM, Eric Wetzel wrote: >> 3. I copied the installed LibUSB-Win32-0.1 usb.h and libusb.a to >> include and lib, respectively, under /usr/i686-pc-mingw32/sys-root. >> 4. The configure options I used were: --enable-maintainer-mode >> --enable-dummy --enable-jlink --enable-ft2232_ftd2xx >> --with-ftd2xx-win32-zipdir=$HOME/local/src/ftd2xx --prefix=$HOME/local >> CC="i686-pc-mingw32-gcc" >> note 4a: I'd rather be using libftdi, but I didn't want to fight with >> it in Windows > > You can use libftdi. You can use Freddie's pre-built binary. http://www.freddiechopin.info/index.php/pl/download/category/10-openocd-dev > Or if you prefer to build by yourself, I provide the libusbftdi-0.19 > binaries for MinGW here. > http://code.google.com/p/picusb/downloads/list Reference: it is talking about cross under Linux. But you can do similar thing under Cygwin (much slower than Linux, say 10 times slower). https://lists.berlios.de/pipermail/openocd-development/2011-July/019923.html -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Windows 7 & J-Link Problems
On Wed, Jul 6, 2011 at 10:02 PM, Eric Wetzel wrote: > > This built cleanly, and I got an openocd.exe that doesn't segfault > immediately and ldd says doesn't depend on cygwin1.dll. Those seem > like positive things. The trouble comes when I try to use it. I'm > using the target/omapl138.cfg because they're comparable chips (the > OMAP-L138 is an AM1808 with a sequencer and a DSP), and I need > something to get ICEpick to enable the debug ports. The same thing > happens with no target specified and J-Link disconnected from the > board. > > openocd.exe -c "source [find interface/jlink.cfg]" -c "source [find > target/omapl138.cfg]" > Open On-Chip Debugger 0.5.0-dev-00941-gff640f1 (2011-06-28-10:38) > Licensed under GNU GPL v2 > For bug reports, read > http://openocd.berlios.de/doc/doxygen/bugs.html > Warn : Adapter driver 'jlink' did not declare which transports it > allows; assuming legacy JTAG-only > Info : only one transport option; autoselect 'jtag' > RCLK - adaptive > fast memory access is enabled > dcc downloads are enabled > force hard breakpoints > use of EmbeddedICE dbgrq instead of breakpoint for target halt enabled > Info : J-Link initialization started / target CPU reset initiated > Info : J-Link ARM V8 compiled Apr 27 2011 20:42:35 > Info : J-Link caps 0xb9ff7bbf > Info : J-Link hw version 8 > Info : J-Link hw type J-Link > Info : J-Link max mem block 8384 > Info : J-Link configuration > Info : USB-Address: 0x0 > Info : Kickstart power on JTAG-pin 19: 0x0 > Info : Vref = 3.319 TCK = 1 TDI = 0 TDO = 1 TMS = 0 SRST = 0 TRST = 0 > Info : J-Link JTAG Interface ready > Info : RCLK (adaptive clock speed) > Error: usb_bulk_read failed (requested=1, result=0) > Error: jlink_tap_execute, wrong result -107 (expected 1) > Error: usb_bulk_read failed (requested=1, result=0) > Error: jlink_tap_execute, wrong result -107 (expected 1) > in procedure 'transport' > in procedure 'init' > > It's clearly able to communicate with the J-Link to get the hardware > information, version string, pin states (including Vref on the > target). But then some USB reads fail. Afterwards, the J-Link becomes > unresponsive for about 2 minutes; its LED is off, but it is still > present in Device Manager, and repeated openocd attempts fail to get > J-Link info: > > openocd.exe -c "source [find interface/jlink.cfg]" -c "source [find > target/omapl138.cfg]" > Open On-Chip Debugger 0.5.0-dev-00941-gff640f1 (2011-06-28-10:38) > Licensed under GNU GPL v2 > For bug reports, read > http://openocd.berlios.de/doc/doxygen/bugs.html > Warn : Adapter driver 'jlink' did not declare which transports it > allows; assuming legacy JTAG-only > Info : only one transport option; autoselect 'jtag' > RCLK - adaptive > fast memory access is enabled > dcc downloads are enabled > force hard breakpoints > use of EmbeddedICE dbgrq instead of breakpoint for target halt enabled > Info : J-Link initialization started / target CPU reset initiated > Error: J-Link command 0x01 failed (-116) > Error: J-Link command EMU_CMD_VERSION failed (0) > Info : J-Link JTAG Interface ready > Info : RCLK (adaptive clock speed) > Error: J-Link command 0xdf failed (-116) > Error: usb_bulk_write failed (requested=6, result=-116) > Error: jlink_tap_execute, wrong result -107 (expected 1) > Error: usb_bulk_write failed (requested=6, result=-116) > Error: jlink_tap_execute, wrong result -107 (expected 1) > in procedure 'transport' > in procedure 'init' > > Is anyone else having problems with J-Link under Windows 7? Or just > Windows 7? Or just J-Link? Try to update the libusb-win32 version to see if that helps. On the other hand, this may have something to do with either your J-Link version or your target. I just tried J-Link V7 and LPC-2148 target under Windows 7 32bit and it is okay. I am using libusb-win32 1.2.4.7 snapshot edition and Freddie's latest development version binary. So it is not the latest git version but you can try it. I also tried the same binary under Windows 7 64bit a few days ago without an issue. -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Windows 7 & J-Link Problems
On 6 July 2011 15:41, Xiaofan Chen wrote: > On Wed, Jul 6, 2011 at 10:38 PM, Xiaofan Chen wrote: >> On Wed, Jul 6, 2011 at 10:02 PM, Eric Wetzel wrote: >>> 3. I copied the installed LibUSB-Win32-0.1 usb.h and libusb.a to >>> include and lib, respectively, under /usr/i686-pc-mingw32/sys-root. >>> 4. The configure options I used were: --enable-maintainer-mode >>> --enable-dummy --enable-jlink --enable-ft2232_ftd2xx >>> --with-ftd2xx-win32-zipdir=$HOME/local/src/ftd2xx --prefix=$HOME/local >>> CC="i686-pc-mingw32-gcc" >>> note 4a: I'd rather be using libftdi, but I didn't want to fight with >>> it in Windows >> >> You can use libftdi. You can use Freddie's pre-built binary. > http://www.freddiechopin.info/index.php/pl/download/category/10-openocd-dev > >> Or if you prefer to build by yourself, I provide the libusbftdi-0.19 >> binaries for MinGW here. >> http://code.google.com/p/picusb/downloads/list > > Reference: it is talking about cross under Linux. But you can > do similar thing under Cygwin (much slower than Linux, say > 10 times slower). > https://lists.berlios.de/pipermail/openocd-development/2011-July/019923.html > > just to help a little under cygwin, they have only just moved onto the mingw cross compiler so make sure you update your cygwin tools. ./configure --enable-maintainer-mode --build=i686-pc-cygwin --host=i686-pc-mingw32 --enable-jlink Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Building local bootstrap jimsh0 failed
I pulled from origin and now my process is failing during configure.
On ac43d7a69fca52df1ad287b51c44013653ad2f61, comping under Cygwin with
MinGW compiler, I get this:
=== configuring in jimtcl (/home/ericwetz/local/src/openocd.git/build/jimtcl)
configure: running /bin/sh ../../jimtcl/configure.gnu
--disable-option-checking '--prefix=/home/ericwetz/local'
'--enable-maintainer-mode' '--build=i686-pc-cygwin'
'--host=i686-pc-mingw32' '--enable-dummy' '--enable-jlink'
'--enable-ft2232_ftd2xx'
'--with-ftd2xx-win32-zipdir=/home/ericwetz/local/src/ftd2xx'
'build_alias=i686-pc-cygwin' 'host_alias=i686-pc-mingw32'
--cache-file=/dev/null --srcdir=../../jimtcl
No installed jimsh or tclsh, building local bootstrap jimsh0
../../jimtcl/autosetup/find-tclsh: line 10: cc: command not found
configure: error: ../../jimtcl/configure.gnu failed for jimtcl
The line in question is:
${CC_FOR_BUILD:-cc} -o "$d/jimsh0" "$d/jimsh0.c" || exit 1
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] MIPS target, big endian host
> Did you see this by testing or by inspection? Both :) > Do we even have the right macros here? > > It would be something like unaligned uint32_t access macros, which will have > to > exist in host endian versions. "mips32_pracc_read_mem" casts uint32 to void, so we need to cast it back to uint32. I found no suitable macro in actual sources. -Ursprüngliche Nachricht- Von: Øyvind Harboe [mailto:oyvind.har...@zylin.com] Gesendet: Mittwoch, 6. Juli 2011 15:02 An: Mahr, Stefan Cc: openocd-development@lists.berlios.de Betreff: Re: MIPS target, big endian host > "mips32_pracc_read_mem" and "mips32_pracc_write_mem" return > values (buffer[i]) are already in host endianness, so le_to_h_u32 fails on > big endian hosts. I already > mentioned this in previous discussions. Ouch. Did you see this by testing or by inspection? The problem is that I mis-interpreted a warning from the compiler. The compiler warned me that I shouldn't cast a uint8_t * to a uint32_t * as this increases alignment. Do we even have the right macros here? It would be something like unaligned uint32_t access macros, which will have to exist in host endian versions. -- Øyvind Harboe - Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 87 40 27 http://www.zylin.com/ ___ 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
On Wed, Jul 6, 2011 at 12:45 AM, Drasko DRASKOVIC
wrote:
> On Wed, Jul 6, 2011 at 12:33 AM, Igor Skochinsky wrote:
>> 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.
Yes, not very logical, but actually it seems to be quite fine -
because in the same config reg, CP0 CONFIG0, we find K0, KU and K23
field which tel us reachability of KUSG, KSEG0 and KSEG23
respectively. This is good, because it saves us from another CP0 read
(which must be done by executing miniprogram).
I did some progress implementing all these selections and
mips32_cp0_read/write() functions and I am in the process of testing -
so far so good.
I just wanted to verify one thing : how we exactly discover which
segment we should treat (which segment we are in) ?
What I am currently doing in the mips32_pracc_write_mem, which has a
signature like this :
int mips32_pracc_write_mem(struct mips_ejtag *ejtag_info, uint32_t
addr, int size, int count, void *buf)
is
/**
* If we are in the cachable regoion and cache is activated,
* we must clean D$ + invalidate I$ after we did the write,
* so that changes do not continue to live only in D$, but to be
* replicated in I$ also (maybe we wrote the istructions)
*/
uint32_t conf = 0;
int cached = 0;
mips32_cp0_read(ejtag_info, &conf, 16, 0);
switch (KSEGX(addr))
{
case KUSEG:
cached = (conf & MIPS32_CONFIG0_KU_MASK) >>
MIPS32_CONFIG0_KU_SHIFT;
break;
case KSEG0 :
cached = (conf & MIPS32_CONFIG0_K0_MASK) >>
MIPS32_CONFIG0_K0_SHIFT;
break;
case KSEG1:
/* uncachable segment - nothing to do */
break;
case KSEG2:
case KSEG3:
cached = (conf & MIPS32_CONFIG0_K23_MASK) >>
MIPS32_CONFIG0_K23_SHIFT;
break;
default:
/* what ? */
break;
}
where I borrowed KSEGX(addr) macro from Linux :
/** Returns the kernel segment base of a given address */
#define KSEGX(a)((a) & 0xe000)
So, as you see, for segment discovery I use addr variable, but that is
the write destination address. Can it be in the different segment that
the one from we are currently in ?
What should I look for to discover appropriate segment of execution,
so I can look for the appropriate cacheability flags (KU, K0 or K23) ?
BR,
Drasko
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Windows 7 & J-Link Problems
On 23:05 Wed 06 Jul , Xiaofan Chen wrote: > On Wed, Jul 6, 2011 at 10:02 PM, Eric Wetzel wrote: > > > > This built cleanly, and I got an openocd.exe that doesn't segfault > > immediately and ldd says doesn't depend on cygwin1.dll. Those seem > > like positive things. The trouble comes when I try to use it. I'm > > using the target/omapl138.cfg because they're comparable chips (the > > OMAP-L138 is an AM1808 with a sequencer and a DSP), and I need > > something to get ICEpick to enable the debug ports. The same thing > > happens with no target specified and J-Link disconnected from the > > board. > > > > openocd.exe -c "source [find interface/jlink.cfg]" -c "source [find > > target/omapl138.cfg]" > > Open On-Chip Debugger 0.5.0-dev-00941-gff640f1 (2011-06-28-10:38) > > Licensed under GNU GPL v2 > > For bug reports, read > > http://openocd.berlios.de/doc/doxygen/bugs.html > > Warn : Adapter driver 'jlink' did not declare which transports it > > allows; assuming legacy JTAG-only > > Info : only one transport option; autoselect 'jtag' > > RCLK - adaptive > > fast memory access is enabled > > dcc downloads are enabled > > force hard breakpoints > > use of EmbeddedICE dbgrq instead of breakpoint for target halt enabled > > Info : J-Link initialization started / target CPU reset initiated > > Info : J-Link ARM V8 compiled Apr 27 2011 20:42:35 > > Info : J-Link caps 0xb9ff7bbf > > Info : J-Link hw version 8 > > Info : J-Link hw type J-Link > > Info : J-Link max mem block 8384 > > Info : J-Link configuration > > Info : USB-Address: 0x0 > > Info : Kickstart power on JTAG-pin 19: 0x0 > > Info : Vref = 3.319 TCK = 1 TDI = 0 TDO = 1 TMS = 0 SRST = 0 TRST = 0 > > Info : J-Link JTAG Interface ready > > Info : RCLK (adaptive clock speed) > > Error: usb_bulk_read failed (requested=1, result=0) > > Error: jlink_tap_execute, wrong result -107 (expected 1) > > Error: usb_bulk_read failed (requested=1, result=0) > > Error: jlink_tap_execute, wrong result -107 (expected 1) > > in procedure 'transport' > > in procedure 'init' > > > > It's clearly able to communicate with the J-Link to get the hardware > > information, version string, pin states (including Vref on the > > target). But then some USB reads fail. Afterwards, the J-Link becomes > > unresponsive for about 2 minutes; its LED is off, but it is still > > present in Device Manager, and repeated openocd attempts fail to get > > J-Link info: > > > > openocd.exe -c "source [find interface/jlink.cfg]" -c "source [find > > target/omapl138.cfg]" > > Open On-Chip Debugger 0.5.0-dev-00941-gff640f1 (2011-06-28-10:38) > > Licensed under GNU GPL v2 > > For bug reports, read > > http://openocd.berlios.de/doc/doxygen/bugs.html > > Warn : Adapter driver 'jlink' did not declare which transports it > > allows; assuming legacy JTAG-only > > Info : only one transport option; autoselect 'jtag' > > RCLK - adaptive > > fast memory access is enabled > > dcc downloads are enabled > > force hard breakpoints > > use of EmbeddedICE dbgrq instead of breakpoint for target halt enabled > > Info : J-Link initialization started / target CPU reset initiated > > Error: J-Link command 0x01 failed (-116) > > Error: J-Link command EMU_CMD_VERSION failed (0) > > Info : J-Link JTAG Interface ready > > Info : RCLK (adaptive clock speed) > > Error: J-Link command 0xdf failed (-116) > > Error: usb_bulk_write failed (requested=6, result=-116) > > Error: jlink_tap_execute, wrong result -107 (expected 1) > > Error: usb_bulk_write failed (requested=6, result=-116) > > Error: jlink_tap_execute, wrong result -107 (expected 1) > > in procedure 'transport' > > in procedure 'init' > > > > Is anyone else having problems with J-Link under Windows 7? Or just > > Windows 7? Or just J-Link? > > Try to update the libusb-win32 version to see if that helps. > > On the other hand, this may have something to do with either > your J-Link version or your target. > > I just tried J-Link V7 and LPC-2148 target under Windows 7 32bit > and it is okay. I am using libusb-win32 1.2.4.7 snapshot > edition and Freddie's latest development version binary. > So it is not the latest git version but you can try it. > > I also tried the same binary under Windows 7 64bit a few > days ago without an issue. Check the firmware version maybe too recent Best Regards, J. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [OpenOCD] Defined but not used
Hi all, I'd like to add a function that is not necesarely used today, but most probably will be in a recent future. How do we handle these ? Do I put it between #if 0 / #endif and commit like that ? Currently, compilation breaks because of strict error checking (werror) cc1: warnings being treated as errors mips32_pracc.c:658: error: ‘mips32_cp0_write’ defined but not used make[5]: *** [mips32_pracc.lo] Error 1 BR, Drasko ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] MIPS target, big endian host
On Wed, Jul 6, 2011 at 6:35 PM, Mahr, Stefan wrote: > > > Did you see this by testing or by inspection? > > Both :) > > > > Do we even have the right macros here? > > > > It would be something like unaligned uint32_t access macros, which will > > have to > > exist in host endian versions. > > "mips32_pracc_read_mem" casts uint32 to void, so we need to cast it > back to uint32. I found no suitable macro in actual sources. Hmm then I think we ought to define one to get this put to bed once and for all... -- Øyvind Harboe - Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 87 40 27 http://www.zylin.com/ ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [OpenOCD] Defined but not used
Split it into a separate patch and push it off into a "iwillusethissoon" branch? -- Øyvind Harboe - Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 87 40 27 http://www.zylin.com/ ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [OpenOCD] Defined but not used
On Wed, Jul 6, 2011 at 9:16 PM, Øyvind Harboe wrote: > Split it into a separate patch and push it off into a "iwillusethissoon" > branch? So we can not have code that is currently is not used but is useful by all means in master ? For example, I created mips32_c0_read() function that reads C0 coprocesor registers. I also created it's pair, mips32_c0_write(), and tested. Now, for the current needs, I only want to read configuration, but I can see well that someone (me, soon, for example) might use this function, already tested and proven to be working. But it can not end up in a master... I thought that there might be a method of leaving this stuff into the code but preceding it wit some macro NOT_USED, or something... BR, Drasko ___ 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
Hi all,
based on the previous discussions about this subject, I came up with this patch.
It :
1) Looks if the segment is cacheable
2) If yes, Adds cache sync via synci, if REV is 2
3) If REV1, it uses "cache" instruction
Now it should work for both Revisions.
I also added mips32_c0_read/write() functions which can really help
developer - we can now read and write all C0 coprocessor regs !
I used these helper functions to find out Release number, and also to
read cacheability bits on a given segment, but also to find cache line
size.
I tested all this, and it seems to work. I have Revision 2 CPU, but I
forced it to use both "synci" and "cache" verisons in a different
tests - all PASSes.
Open questions are :
1) As I mentioned before, is this KSEG discovery good ? Do I get well
which segment we are (look my previous post on the subject)
2) mips32_c0_write() is not used for the moment, so it can not be
commited to master. I will have to finish all before posting PULL
request. My idea is to create some kind of interface towards these
mips32_cp0_read/write() functions, so that we can R/W CP0 regs
directly from the Telnet client, similar as we can do for ARM's CP15.
That would be something !
In the meanwhile it would be great if you can comment on this
implementation (or even better if somebody can integrate it and test
it - remember --disable-werror), so that I can improve it (it looks
like a quite a piece to be added). Once it is polished I'll post PULL
request from my MIPS github branch.
BR,
Drasko
From 9b5e82b2df6a3de4b8a5e178ffd5bd2c0e8fbbd3 Mon Sep 17 00:00:00 2001
From: Drasko DRASKOVIC
Date: Tue, 5 Jul 2011 17:20:33 +0200
Subject: [PATCH] mips32: Sync Caches to Make Instr Writes Effective
Pprogram that loads another program into memory is actually writing the
D- side cache.
The instructions it has loaded can't be executed until they reach the
I-cache.
After the instructions have been written, the loader should arrange to
write back any containing D-cache line and invalidate any locations
already in the I-cache.
For the MIPS Architecture Release2 cores, we can use synci command
that does this job.
For Release1 we must use "cache" instruction.
This patch also adds mips32_cp0_read() and mips32_cp0_write()
functions that can be used to discover various parameters
of the CPU, like cacheablity, Release number or cache line size.
---
src/target/mips32.h | 115 ---
src/target/mips32_pracc.c | 351 -
2 files changed, 437 insertions(+), 29 deletions(-)
diff --git a/src/target/mips32.h b/src/target/mips32.h
index 4f0f0ef..cb9712c 100644
--- a/src/target/mips32.h
+++ b/src/target/mips32.h
@@ -4,6 +4,8 @@
* *
* Copyright (C) 2008 by David T.L. Wong *
* *
+ * Copyright (C) 2011 by Drasko DRASKOVIC*
+ * *
* This program is free software; you can redistribute it and/or modify *
* it under the terms of the GNU General Public License as published by *
* the Free Software Foundation; either version 2 of the License, or *
@@ -28,6 +30,39 @@
#define MIPS32_COMMON_MAGIC 0xB320B320
+/**
+ * Memory segments (32bit kernel mode addresses)
+ * These are the traditional names used in the 32-bit universe.
+ */
+#define KUSEG 0x
+#define KSEG0 0x8000
+#define KSEG1 0xa000
+#define KSEG2 0xc000
+#define KSEG3 0xe000
+
+/** Returns the kernel segment base of a given address */
+#define KSEGX(a) ((a) & 0xe000)
+
+/** CP0 CONFIG regites fields */
+#define MIPS32_CONFIG0_KU_SHIFT 25
+#define MIPS32_CONFIG0_KU_MASK (0x7 << MIPS32_CONFIG0_KU_SHIFT)
+
+#define MIPS32_CONFIG0_K0_SHIFT 0
+#define MIPS32_CONFIG0_K0_MASK (0x7 << MIPS32_CONFIG0_K0_SHIFT)
+
+#define MIPS32_CONFIG0_K23_SHIFT 28
+#define MIPS32_CONFIG0_K23_MASK (0x7 << MIPS32_CONFIG0_K23_SHIFT)
+
+#define MIPS32_CONFIG0_AR_SHIFT 10
+#define MIPS32_CONFIG0_AR_MASK (0x7 << MIPS32_CONFIG0_AR_SHIFT)
+
+#define MIPS32_CONFIG1_DL_SHIFT 10
+#define MIPS32_CONFIG1_DL_MASK (0x7 << MIPS32_CONFIG1_DL_SHIFT)
+
+#define MIPS32_ARCH_REL1 0x0
+#define MIPS32_ARCH_REL2 0x1
+
+
/* offsets into mips32 core register cache */
enum
{
@@ -92,10 +127,14 @@ struct mips32_algorithm
enum mips32_isa_mode isa_mode;
};
+#define MIPS32_OP_ADDIU 0x21
+#define MIPS32_OP_ANDI 0x0C
#define MIPS32_OP_BEQ 0x04
+#define MIPS32_OP_BGTZ 0x07
#define MIPS32_OP_BNE 0x05
#define MIPS32_OP_ADDI 0x08
#define MIPS32_OP_AND 0x24
+#define MIPS32_OP_CACHE 0x2F
#define MIPS32_OP_COP0 0x10
#define MIPS32_OP_JR 0x08
#define MIPS32_OP_LUI 0x0F
@@ -106,12 +145,21 @@ struct mips32_algorithm
#define MIPS32_OP_MTHI 0x11
#define MIPS32_OP_MFLO 0x12
#define MIPS32_OP_MTLO 0x13
+#define MIPS32_OP_RDHWR 0x3B
#define MIPS32_OP_
Re: [Openocd-development] [OpenOCD] Defined but not used
#if 0 + comment is fine. But if you have code that you will start using soon, then it's better if you keep it around and submit it along with your next patches when it is ready. There is always *something* to tinker with in a fn that hasn't been tested... -- Øyvind Harboe - Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 87 40 27 http://www.zylin.com/ ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] MIPS target, big endian host
>> "mips32_pracc_read_mem" casts uint32 to void, so we need to cast it
>> back to uint32. I found no suitable macro in actual sources.
>
> Hmm then I think we ought to define one to get this put to
> bed once and for all...
static inline uint32_t uint32_read_unaligned(const void *data)
{
uint32_t t;
// Let's trust the compiler to do something very clever here.
memcpy(&t, data, sizeof(t));
return t;
}
?
--
Øyvind Harboe - Can Zylin Consulting help on your project?
US toll free 1-866-980-3434 / International +47 51 87 40 27
http://www.zylin.com/
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [OpenOCD] Defined but not used
On Wed, Jul 6, 2011 at 3:21 PM, Drasko DRASKOVIC wrote: > I thought that there might be a method of leaving this stuff into the > code but preceding it wit some macro NOT_USED, or something... > You can use the following GCC attribute for your purpose. unused This attribute, attached to a function, means that the function is meant to be possibly unused. GCC will not produce a warning for this function. However, I don't think it's a good idea to leave unused function in source code. Such functions will soon rot and finally become useless and maintenance burden since it's not used anywhere. Regards, Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [OpenOCD] Defined but not used
On Wed, Jul 6, 2011 at 9:34 PM, Øyvind Harboe wrote: > #if 0 + comment is fine. But if you have code that you will > start using soon, then it's better if you keep it around and > submit it along with your next patches when it is ready. OK, I'll see... Maybe it will be more convenient to post it as a comment, if I have not time to implement Telnet interface to this command (in order to actually use it). > There is always *something* to tinker with in a fn that hasn't > been tested... Everything has been tested. I tested the implementation during the development process, but in the end I just do not use "write" function, just "read" (but like to commit "write" one also, in a pair). BR, Drasko ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] MIPS target, big endian host
>>> "mips32_pracc_read_mem" casts uint32 to void, so we need to cast it
>>> back to uint32. I found no suitable macro in actual sources.
>>
>> Hmm then I think we ought to define one to get this put to
>> bed once and for all...
>
> static inline uint32_t uint32_read_unaligned(const void *data)
> {
> uint32_t t;
> // Let's trust the compiler to do something very clever here.
> memcpy(&t, data, sizeof(t));
> return t;
> }
Do we really need a memcpy? Could we ever run into an alignment issue when
simply cast void *back* to uint32 ? If not, I would prefer the simplifed
solution.
static inline uint32_t h_to_h_u32(const void *data)
{
return (uint32_t)*data;
}
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] MIPS target, big endian host
On Wed, Jul 6, 2011 at 11:28 PM, Mahr, Stefan wrote:
"mips32_pracc_read_mem" casts uint32 to void, so we need to cast it
back to uint32. I found no suitable macro in actual sources.
>>>
>>> Hmm then I think we ought to define one to get this put to
>>> bed once and for all...
>>
>> static inline uint32_t uint32_read_unaligned(const void *data)
>> {
>> uint32_t t;
>> // Let's trust the compiler to do something very clever here.
>> memcpy(&t, data, sizeof(t));
>> return t;
>> }
>
> Do we really need a memcpy?
Trust the compiler:
oyvind@fierce:~$ cat test.c
#include
#include
uint32_t uint32_read_unaligned(const void *data)
{
uint32_t t;
// Let's trust the compiler to do something very clever here.
memcpy(&t, data, sizeof(t));
return t;
}
oyvind@fierce:~$ gcc -O3 -S test.c
oyvind@fierce:~$ cat test.s
.file "test.c"
.text
.p2align 4,,15
.globl uint32_read_unaligned
.type uint32_read_unaligned, @function
uint32_read_unaligned:
.LFB22:
.cfi_startproc
movl(%rdi), %eax
ret
.cfi_endproc
.LFE22:
.size uint32_read_unaligned, .-uint32_read_unaligned
.ident "GCC: (Ubuntu/Linaro 4.5.2-8ubuntu4) 4.5.2"
.section.note.GNU-stack,"",@progbits
> Could we ever run into an alignment
> issue when simply cast void *back* to uint32 ? If not, I would prefer
> the simplifed solution.
The below does not work in all cases. It will break on architectures that
do not support unaligned access.
That's why GCC is complaining. Sometimes...
--
Øyvind Harboe - Can Zylin Consulting help on your project?
US toll free 1-866-980-3434 / International +47 51 87 40 27
http://www.zylin.com/
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] MIPS target, big endian host
> Trust the compiler NO ! :-) $ gcc -O3 -S test.c $ cat test.s .file "test.c" .text .p2align 4,,15 .globl uint32_read_unaligned .type uint32_read_unaligned, @function uint32_read_unaligned: pushl %ebp movl%esp, %ebp subl$16, %esp movl8(%ebp), %eax movl(%eax), %eax leave ret .size uint32_read_unaligned, .-uint32_read_unaligned .ident "GCC: (Ubuntu/Linaro 4.4.4-14ubuntu5) 4.4.5" .section.note.GNU-stack,"",@progbits - $ mips-linux-gcc -O3 -S test.c $ cat test.s .file 1 "test.c" .section .mdebug.abi32 .previous .abicalls .text .align 2 .globl uint32_read_unaligned .entuint32_read_unaligned .type uint32_read_unaligned, @function uint32_read_unaligned: .frame $sp,24,$31 # vars= 8, regs= 1/0, args= 0, extra= 8 .mask 0x1000,-8 .fmask 0x,0 .setnoreorder .cpload $25 .setreorder subu$sp,$sp,24 .cprestore 0 lwl $2,0($4) lwr $2,3($4) swl $2,8($sp) swr $2,11($sp) lw $2,8($sp) sw $28,16($sp) .setnoreorder .setnomacro j $31 addu$sp,$sp,24 .setmacro .setreorder .enduint32_read_unaligned .ident "GCC: (GNU) 3.3.6" - $ mips-linux-gnu-gcc -O3 -S test.c $ cat test.s .file 1 "test.c" .section .mdebug.abi32 .previous .gnu_attribute 4, 1 .abicalls .option pic0 .text .align 2 .globl uint32_read_unaligned .entuint32_read_unaligned .type uint32_read_unaligned, @function uint32_read_unaligned: .setnomips16 .frame $sp,8,$31 # vars= 8, regs= 0/0, args= 0, gp= 0 .mask 0x,0 .fmask 0x,0 .setnoreorder .setnomacro lwl $2,0($4) addiu $sp,$sp,-8 addiu $sp,$sp,8 j $31 lwr $2,3($4) .setmacro .setreorder .enduint32_read_unaligned .ident "GCC: (Sourcery G++ Lite 4.3-154) 4.3.3" - $ arm-none-eabi-gcc -O3 -S test.c $ cat test.s .cpu arm7tdmi .fpu softvfp .eabi_attribute 20, 1 .eabi_attribute 21, 1 .eabi_attribute 23, 3 .eabi_attribute 24, 1 .eabi_attribute 25, 1 .eabi_attribute 26, 1 .eabi_attribute 30, 2 .eabi_attribute 18, 4 .file "test.c" .text .align 2 .global uint32_read_unaligned .type uint32_read_unaligned, %function uint32_read_unaligned: @ Function supports interworking. @ args = 0, pretend = 0, frame = 8 @ frame_needed = 0, uses_anonymous_args = 0 str lr, [sp, #-4]! sub sp, sp, #12 mov r1, r0 mov r2, #4 add r0, sp, #4 bl memcpy ldr r0, [sp, #4] add sp, sp, #12 ldr lr, [sp], #4 bx lr .size uint32_read_unaligned, .-uint32_read_unaligned .ident "GCC: (GNU) 4.5.1" ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] MIPS target, big endian host
On Wed, Jul 6, 2011 at 11:35 PM, Øyvind Harboe wrote:
> On Wed, Jul 6, 2011 at 11:28 PM, Mahr, Stefan
> wrote:
> "mips32_pracc_read_mem" casts uint32 to void, so we need to cast it
> back to uint32. I found no suitable macro in actual sources.
> >>>
> >>> Hmm then I think we ought to define one to get this put to
> >>> bed once and for all...
> >>
> >> static inline uint32_t uint32_read_unaligned(const void *data)
> >> {
> >> uint32_t t;
> >> // Let's trust the compiler to do something very clever here.
> >> memcpy(&t, data, sizeof(t));
> >> return t;
> >> }
> >
> > Do we really need a memcpy?
>
> Trust the compiler:
>
> oyvind@fierce:~$ cat test.c
> #include
> #include
>
> uint32_t uint32_read_unaligned(const void *data)
> {
> uint32_t t;
> // Let's trust the compiler to do something very clever here.
> memcpy(&t, data, sizeof(t));
> return t;
> }
> oyvind@fierce:~$ gcc -O3 -S test.c
>
And with the default optimization level (O2, isn't it)?
> > Could we ever run into an alignment
> > issue when simply cast void *back* to uint32 ? If not, I would prefer
> > the simplifed solution.
>
> The below does not work in all cases. It will break on architectures that
> do not support unaligned access.
>
No, casting a pointer-to-any-type to a pointer-to-void and back will never
cause alignment issues. The question is who makes the guarantee that the
function is only ever called with uint32-aligned generic pointers. If it
just happens to be so that all *current* callers pass a uint32 pointer cast
to void pointer, it would be a terribly bad idea to suddenly assume that. If
it is guaranteed by design/contract, why is a void pointer used at all? Just
use a pointer to uint32 then.
I have no experience with the MIPS code or arch at all, but if it was up to
me I'd prefer if a *_read_mem function didn't interpret the data and thus it
should deal with void pointers. It would by design be totally free from all
endian issues and conversions. Moreover, a function accepting a
pointer-to-void should be prepared to handle any kind of alignment thrown at
it (unless explicitly stated). That excludes direct casts to uint32_t*.
> That's why GCC is complaining. Sometimes...
>
It should never complain when casting a generic pointer to another pointer,
right? You shouldn't even need an explicit cast IIRC.
/Andreas
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] eclipse indigo (pipe usage)
On Fri, Jul 1, 2011 at 12:47 PM, Spencer Oliver wrote:
> On 1 July 2011 00:41, Andrew Leech wrote:
>
> One other point, do you know whether you can get openocd to add it's own
> > program directory to the search path for the source [find ...] lines?
> It'd
> > be great to only need the openocd.cfg file in the eclipse project dir,
> and
> > have it reference the interface and target files from the common openocd
> > folder. Otherwise I'll likely copy the contents of the files into my
> > openocd.cfg rather than have a copy of target and interface folders in
> all
> > my project folders.
> >
>
> try something like:
> add_script_search_dir {c:\cygwin\home\soliver\openocd\openocd\tcl}
>
> Cheers
> Spen
>
I wrote a patch to fix this a long time ago, pre 0.4.0 i think. However i
didn't test it under cygwin because I don't use it, only msys. It may need
some adjustments. Andrew, you didn't say what platform you're on and how you
built/installed openocd? The search path should be printed in the debug log,
can you look there and see how it differs from where you have the files
installed?
/Andreas
Found the relevant thread(s):
http://www.mail-archive.com/openocd-development@lists.berlios.de/msg10145.html
http://www.mail-archive.com/openocd-development@lists.berlios.de/msg11678.html
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Building local bootstrap jimsh0 failed
On 07/07/2011, at 2:13 AM, Eric Wetzel wrote:
> I pulled from origin and now my process is failing during configure.
> On ac43d7a69fca52df1ad287b51c44013653ad2f61, comping under Cygwin with
> MinGW compiler, I get this:
>
> === configuring in jimtcl (/home/ericwetz/local/src/openocd.git/build/jimtcl)
> configure: running /bin/sh ../../jimtcl/configure.gnu
> --disable-option-checking '--prefix=/home/ericwetz/local'
> '--enable-maintainer-mode' '--build=i686-pc-cygwin'
> '--host=i686-pc-mingw32' '--enable-dummy' '--enable-jlink'
> '--enable-ft2232_ftd2xx'
> '--with-ftd2xx-win32-zipdir=/home/ericwetz/local/src/ftd2xx'
> 'build_alias=i686-pc-cygwin' 'host_alias=i686-pc-mingw32'
> --cache-file=/dev/null --srcdir=../../jimtcl
> No installed jimsh or tclsh, building local bootstrap jimsh0
> ../../jimtcl/autosetup/find-tclsh: line 10: cc: command not found
> configure: error: ../../jimtcl/configure.gnu failed for jimtcl
>
> The line in question is:
> ${CC_FOR_BUILD:-cc} -o "$d/jimsh0" "$d/jimsh0.c" || exit 1
jimtcl doesn't (yet) support building on mingw/msys
It will at some point, though.
Cheers,
Steve
--
µWeb: Embedded Web Framework - http://uweb.workware.net.au/
WorkWare Systems Pty Ltd
W: www.workware.net.au P: +61 434 921 300
E: ste...@workware.net.au F: +61 7 3391 6002
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Windows 7 & J-Link Problems
On Thu, Jul 7, 2011 at 1:27 AM, Jean-Christophe PLAGNIOL-VILLARD wrote: > On 23:05 Wed 06 Jul , Xiaofan Chen wrote: >> Try to update the libusb-win32 version to see if that helps. >> >> On the other hand, this may have something to do with either >> your J-Link version or your target. >> >> I just tried J-Link V7 and LPC-2148 target under Windows 7 32bit >> and it is okay. I am using libusb-win32 1.2.4.7 snapshot >> edition and Freddie's latest development version binary. >> So it is not the latest git version but you can try it. >> >> I also tried the same binary under Windows 7 64bit a few >> days ago without an issue. > Check the firmware version > maybe too recent Indeed. I do not have a V8 for testing right now. I will try to borrow one. We have many J-Links at work, some of them V6, some of them V8, and there is a J-Link Pro. Info : J-Link initialization started / target CPU reset initiated Info : J-Link ARM V8 compiled Apr 27 2011 20:42:35 Info : J-Link caps 0xb9ff7bbf Info : J-Link hw version 8 Info : J-Link hw type J-Link Info : J-Link max mem block 8384 -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] tcl_server TCP/IP commands usage?
On Mon, Jul 4, 2011 at 4:13 PM, Maxim Cournoyer wrote: > On Jul 2, 2011 6:15 PM +0200, Øyvind Harboe wrote: > > Use the Source Luke. The end of the command is not linefeed but 0x??. There > ought to be updated docs. Patch? > > Great tip! I found it inside the tcl_server.c file; the end of character > used by the openocd tcl server is 0x1a. > I managed to get the result I was looking for, a simple application which > usage goes like: > > program > > The objective was to automate the ROM flashing procedure from Eclipse IDE > when working with the LM3S8962 kit. The app can be configured as an > "external tool" and launched at the touch of a button. It could also be > called inside a custom makefile. The use of the tcl_server is a great > feature to me, because an openocd daemon is already running most of the > time, to provide debugging facility. > > I have made a C version and a BASH (w/ netcat) version of such a small app. > I also toyed with tcl to make a telnet-like utility to test openocd's tcl > server. > > I also gathered a LM3S8962.cfg file on the internet and refactored it in to > a similar way to what could be seen inside the /usr/share/openocd/scripts > folder. I can post all that stuff if anyone is interested. > i'm working on something similar. would you mind posting your stuff? thanks! > I'd like to see if I can produce a patch for the user manual, but first I'll > have to get the doc building. From current git, when I type "make pdf", it > fails with the following message: > > This is `epsf.tex' v2.7.4 <14 February 2011> > ) localization, formatting, and turning on texinfo input format.) > (./openocd.aux) > ./../../doc/openocd.texi:12: I can't find file `version.texi'. > @temp ->@input version.texi > > @includezzz ...and @input #1 }@expandafter }@temp > @popthisfilestack > l.12 @include version.texi > > (Press Enter to retry, or Control-D to exit) > Please type another input file name > ./../../doc/openocd.texi:12: Emergency stop. > @temp ->@input version.texi > > @includezzz ...and @input #1 }@expandafter }@temp > @popthisfilestack > l.12 @include version.texi > > ./../../doc/openocd.texi:12: ==> Fatal error occurred, no output PDF file > prod > uced! > > Transcript written on openocd.log. > > I have attached the openocd.log file. > > Salutations! > > > ___ > Openocd-development mailing list > Openocd-development@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/openocd-development > > -- Rodrigo. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] MIPS target, big endian host
I should have said uint8_t * to uint32_t *. The problem is that that
there is a lot of distance between where the conversion to uint8_t *
happens and where the cast back to uint32_t * happens.
It is not obvious at all from the context that there is an alignment
guarantee.
Hence the simplest solution is to write a fn(the one that I wrote is
correct), to handle unaligned uint32_t access.
The version below yields decent code across architectures after
Stefan showed that the mileage varies greatly with intrinsic memcpy().
#include
#include
uint32_t uint32_read_unaligned(const uint8_t *data)
{
uint32_t t;
// Let's trust the compiler to do something very clever here.
int i;
for (i = 0; i < sizeof(t); i++)
{
((uint8_t *)&t)[i] = data[i];
}
return t;
}
--
Øyvind Harboe - Can Zylin Consulting help on your project?
US toll free 1-866-980-3434 / International +47 51 87 40 27
http://www.zylin.com/
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
