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