[Openocd-development] AU1100 (MIPS) problems

[Nico Coesel]

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!

[Nico Coesel]

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!

[Nico Coesel]

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!

[Nico Coesel]

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 &#x

[Openocd-development] Chip width / bus width bug in cfi driver

[Nico Coesel]

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!

[Nico Coesel]

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

[Nico Coesel]

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

[Nico Coesel]

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

[Nico Coesel]

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

[Nico Coesel]

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

[Nico Coesel]

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

[Nico Coesel]

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

[Nico Coesel]

> -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

[Nico Coesel]

> -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

[Nico Coesel]

> -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) :(

[Nico Coesel]

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

[Nico Coesel]

>
>-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))

[Nico Coesel]

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))

[Nico Coesel]

> Ø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

[Nico Coesel]

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

[Nico Coesel]

> 
>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)

[Nico Coesel]

> -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.

[Nico Coesel]

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.

[Nico Coesel]

> -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!

[Nico Coesel]

> -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

[Nico Coesel]

 
> -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]

[Nico Coesel]

> -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

[Nico Coesel]

> -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

[Nico Coesel]

> -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

[Nico Coesel]

 
>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

[Nico Coesel]

> -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

[Nico Coesel]

> -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

[Nico Coesel]

> -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

[Nico Coesel]

> -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

[Nico Coesel]

> -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

[Nico Coesel]

>> Ø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

[Nico Coesel]

> 
> 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)

[Nico Coesel]

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

[Nico Coesel]

> -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

[Nico Coesel]

> -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

[Nico Coesel]

>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

[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 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

[Nico Coesel]

>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

[Nico Coesel]

>
>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

[Nico Coesel]

>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?

[Nico Coesel]

> -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

[Nico Coesel]

> -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?

[Nico Coesel]

> -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

[Nico Coesel]

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

[Nico Coesel]

> -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

[Nico Coesel]

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

[Nico Coesel]

> -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

[Nico Coesel]

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

[Nico Coesel]

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

[Nico Coesel]

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

[Nico Coesel]

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

[Nico Coesel]

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

[Nico Coesel]

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

[Nico Coesel]

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

[Nico Coesel]

> -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

[Nico Coesel]

> -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

[Nico Coesel]

> -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

[Nico Coesel]

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

[Nico Coesel]

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

[Nico Coesel]

> -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

[Nico Coesel]

> -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

[Nico Coesel]

> 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

[Nico Coesel]

> 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

[Nico Coesel]

> -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

[Nico Coesel]

> -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

[Nico Coesel]

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

[Nico Coesel]

> -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

[Nico Coesel]

> -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)

[Nico Coesel]

>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

[Nico Coesel]

> -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.

[Nico Coesel]

> -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

[Nico Coesel]

> -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

[Nico Coesel]

> -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

[Nico Coesel]

-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?

[Nico Coesel]

> -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

[Nico Coesel]

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

[Nico Coesel]

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

[Nico Coesel]

> -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

[Nico Coesel]

-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

[Nico Coesel]

> -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

[Nico Coesel]

> -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

[Nico Coesel]

> -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

[Nico Coesel]

> -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

[Nico Coesel]

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

[Nico Coesel]

Ø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

[Nico Coesel]

> -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.

[Nico Coesel]

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

[Nico Coesel]

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