Re: [Openocd-development] bitbanging ft2232 dongle port from TCL is TOO DANGEROUS : PLEASE COMMENT
On Fri, 24 Jun 2011 16:32:54 +, Tomek CEDRO wrote: Cool, I will add new field into layout structure that will indicate forbidden bits to bitbang, this field will be zero by default so all bits are allowed, driver author can add some value of this field to the specific layout - that value AND port mask to set/bitbang will be checked in ft2232_bitbang(), if non-zero then error will be returned as user tried to access restricted port pins. Should be simple, elegant and safe enough..? Thank you Tomek for understanding the importance of bitbang filter mechanism implemented at low level. That's a great news Tomek ! This will do the bitbang safe, and now I can accept your idea having TCL bitbang features. Have a nice week-end. Regards, Laurent http://www.amontec.com/jtagkey.shtml Amontec JTAGkey-2 USB JTAG CABLE with 4 status LEDs This update should appear in my fork repository after weekend.. soo have a great weekend! :-) Best regards :-) Tomek ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] bitbanging ft2232 dongle port from TCL is TOO DANGEROUS : PLEASE COMMENT
Cool, I will add new field into layout structure that will indicate forbidden bits to bitbang, this field will be zero by default so all bits are allowed, driver author can add some value of this field to the specific layout - that value AND port mask to set/bitbang will be checked in ft2232_bitbang(), if non-zero then error will be returned as user tried to access restricted port pins. Should be simple, elegant and safe enough..? This update should appear in my fork repository after weekend.. soo have a great weekend! :-) Best regards :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] bitbanging ft2232 dongle port from TCL is TOO DANGEROUS : PLEASE COMMENT
The best is to standardize at a lower level ... and to forget the idea to have the possibility to bitbang from the TCL of the openocd. >/ />/That's as for the SWD, we have to standardize some function call in the ft2232, and avoiding bitbang access from higher-level. />/ />/That's not simple to dev, but safe for end-user. />/ />/ /It is necessary to expose the feature though TCL. Otherwise it is not possible to use it as the telnet TCL interface is the primary (only?) way for you to control OpenOCD. Furthermore, this is the interface to use if you want to use OpenOCD from another program. Hi, Please do not confuse. I am not talking about to remove the TCL itself, but I talking to avoid the possibility to bitbang the ft2232 port from TCL in a non safe way ! It is really not the same. Please read all my comments. The bitbang of the ft2232 via TCL MUST pass via a filter in the ft2232.c associated to the layout. The filter must mask the ft2232 inputs related to the layout. The filter must apply the mask when the bitbang try to write these ft2232 input. If this mechanism is integrated in ft2232.c by Tomek, then yes, and only in this case we can bitbang the ft2232 via TCL user interface. If Tomek want to provide the bitbang from TCL, he must first provide the filter mechanism . Actually the filter bitbang filter mechanism is not implemented in ft2232.c . That's all. Again, what happen if the RTCK input is driven low or high from TCL bitbang, by the end-user. You have lot of chance to break he ft2232 or the buffer (between the ft2232 and the target) or the target, since you have chance to generate a short-circuit of the RTCK wire ;-( . That's the same for all the ft2232 Input . That's why I have write a big DANGEROUS ! I do not understand the opposition to making OpenOCD more flexible by reducing the need to modify the source and re-building to achieve some functionality. You can already do plenty of "unsafe" things with OpenOCD like erasing the entire flash of your target. I am not opposed to make the OpenOCD more flexible. But I do not want to see OpenOCD as dangerous for the hardware signal/wire for the target and/or the adapter. Yes, we can do "unsafe" things with OpenOCD. But the actual unsafe thing are not related to the JTAG / SWD hardware / signal / wire, but related to the how we use upper debug protocol and that's really not the same. Phil Regards, Laurent http://www.amontec.com/jtagkey.shtml ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] bitbanging ft2232 dongle port from TCL is TOO DANGEROUS : PLEASE COMMENT
The best is to standardize at a lower level ... and to forget the idea to have the possibility to bitbang from the TCL of the openocd. > >That's as for the SWD, we have to standardize some function call in the >ft2232, and avoiding bitbang access from higher-level. > >That's not simple to dev, but safe for end-user. > > It is necessary to expose the feature though TCL. Otherwise it is not possible to use it as the telnet TCL interface is the primary (only?) way for you to control OpenOCD. Furthermore, this is the interface to use if you want to use OpenOCD from another program. I do not understand the opposition to making OpenOCD more flexible by reducing the need to modify the source and re-building to achieve some functionality. You can already do plenty of "unsafe" things with OpenOCD like erasing the entire flash of your target. Phil ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] bitbanging ft2232 dongle port from TCL is TOO DANGEROUS : PLEASE COMMENT
Simple and true :-) Each interface has its own config file anyway, so this file can contain also signal definition for that interface. If interface has no signals defined, no signals will be defined, so there is no worry. Here we have to select between Simple and Safe ! We know that a large part of TCL are copy past from tcl examples to end-user dedicated TCL file (That's not what we really want, but the TCL is the end-user interface). My experience tell me that a lot of users are copy pasting to one file for the specifc use. "What happen if a user force a '0' or '1' to RTCK input of the interface, using your bitbang TCL. The problem with your bitbang approach via TCL, is a REAL risk for the end user to copy paste your TCL signal definition specific to a layout and copy it for an other layout. You will tell me, the user needs to know what he do ... Anyway, you have to implement a mechanism to filter the bitbang in the ft2232. Please provide first a mechanism allowing to filter/mask the access of the ft2232 IO port for each specific layout. Then we can test and see if the bitbang port from TCL are enough safe to be merged. User can define his/hers own signals by hand, but it is then his/hers choice :-) There can be some standard signals to be used by general TCL scripts as signals are recognised by name string :-) The best is to standardize at a lower level ... and to forget the idea to have the possibility to bitbang from the TCL of the openocd. That's as for the SWD, we have to standardize some function call in the ft2232, and avoiding bitbang access from higher-level. That's not simple to dev, but safe for end-user. Best regards! :-) Tomek Laurent http://www.amontec.com/jtagkey.shtml Amontec JTAGkey-2 USB JTAG CABLE ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] bitbanging ft2232 dongle port from TCL is TOO DANGEROUS : PLEASE COMMENT
On Tue, Jun 21, 2011 at 3:57 PM, Phil Fong wrote: > I think there is an misunderstanding here. My reading of Tomek's emails > indicates there is a layout specific mechanism to filter which pins can be > bitbanged. The interface config file will define which pins can be > bitbanged and how. > Is this correct? Simple and true :-) Each interface has its own config file anyway, so this file can contain also signal definition for that interface. If interface has no signals defined, no signals will be defined, so there is no worry. User can define his/hers own signals by hand, but it is then his/hers choice :-) There can be some standard signals to be used by general TCL scripts as signals are recognised by name string :-) Best regards! :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] bitbanging ft2232 dongle port from TCL is TOO DANGEROUS : PLEASE COMMENT
>/My objective is not to block feature.Never,never,never ... But we have />/to avoid any trouble in generic ft2232 driver regarding specific layout. />/That's all. />/Your TCL bitbang will control the port of the FTDI from an higher level />/than FT2232.c. OK but you TCL bitbang is specific to the layout used. />/How do you accept or not the use of the TCL procedure, if you do not />/have the notion of layout in this function ??? />/You have two solutions: You need to write a specifc driver (), or you />/need to filter the TCL bitbang action in the ft2232 generic driver. The />/filter must be specifc to the open layout ... />/The same is for SRST TRST control. The ft2232.c driver has specific />/functions for SRST TRST regarding layout used ... we have to do this for />/ANY other specific layout signal in the ft2232.c or write a specific />/driver. />/ />/I think there is an misunderstanding here. My reading of Tomek's emails indicates there is a layout specific mechanism to filter which pins can be bitbanged. The interface config file will define which pins can be bitbanged and how. /Is this correct? It should be, but it is not actually implemented. Tomek, please confirm. The bitbang filter mechanism is my suggestion, to avoid any bad io port configuration. To make the thing robust, the bitbang filter mechanism must be implemented in the ft2232.c and related to the layout enabled at onpenocd initialization. The filter must not be a simple TCL itself, since the selected layout at initialization can be bypassed. Laurent http://www.amontec.com/jtagkey.shtml Amontec JTAGkey-2 USB JTAG Dongles Phil ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] bitbanging ft2232 dongle port from TCL is TOO DANGEROUS : PLEASE COMMENT
> >My objective is not to block feature.Never,never,never ... But we have >to avoid any trouble in generic ft2232 driver regarding specific layout. >That's all. >Your TCL bitbang will control the port of the FTDI from an higher level >than FT2232.c. OK but you TCL bitbang is specific to the layout used. >How do you accept or not the use of the TCL procedure, if you do not >have the notion of layout in this function ??? >You have two solutions: You need to write a specifc driver (), or you >need to filter the TCL bitbang action in the ft2232 generic driver. The >filter must be specifc to the open layout ... >The same is for SRST TRST control. The ft2232.c driver has specific >functions for SRST TRST regarding layout used ... we have to do this for >ANY other specific layout signal in the ft2232.c or write a specific >driver. > >I think there is an misunderstanding here. My reading of Tomek's emails >indicates there is a layout specific mechanism to filter which pins can be >bitbanged. The interface config file will define which pins can be bitbanged >and how. Is this correct? Phil___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] bitbanging ft2232 dongle port from TCL is TOO DANGEROUS : PLEASE COMMENT
Tomek CEDRO wrote: On Mon, Jun 20, 2011 at 9:19 PM, amotec-laurent_gauch wrote: Your TCL bitbang will control the port of the FTDI from an higher level than FT2232.c. OK but you TCL bitbang is specific to the layout used. How do you accept or not the use of the TCL procedure, if you do not have the notion of layout in this function ??? Let's assume we want to use our specific interface to quickly flash the SPI memory because we have no time to get familiar with source code and complex program internals... You say yourself : a specific interface. The specific interface, for a ft2232 based dongle is in the layout. some_very_specific_interface.cfg: (..) interface_signal MOSI 0x01 interface_signal MISO 0x02 interface_signal SCK 0x04 interface_signal EN 0x08 interface_signal SPI0 TCL script then can check if signal SPI is defined (no mask value, so no pin is driven, it is only informational), if so check if other signals are defined and proper value, if so work the SPI operation, if not return error because interface does not define/support necessary signals. If no such signals are defined by interface configuration file, there is no option to drive those signals on that specific interface, so there is no worry anything get broken. Again - signals are to be defined inside interface configuration file, so the signals are also layout specific. This is far more better solution than hardcoding them into source code... Better for what ? Yes, for a easy bitbanged pin access, but this will be dangerous for end-user, and you bypass the ft2232.c where the specific layout is controlled. And, you have to check the signal interface ??? Btw. I have to add signal check interface to TCL command :-) How to make tcl command return some value that can be used for later calculation (i.e. "interface_signal mask" returns 0 for SPI signal, 1 for MOSI, 2 for MISO, ...) ? Again, you have a notion of check ... that you should do hardcoded in the source code. How does the ADC controlled from K T ? It is connected somehow to free IO pinf on the FT2232H port. So it is specific to a given layout ... but you do no let know which pin to the end-user ... Best regards! :-) Tomek Regards, Laurent http://www.amontec.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] bitbanging ft2232 dongle port from TCL is TOO DANGEROUS : PLEASE COMMENT
On Mon, 20 Jun 2011 16:37:32 +, Tomek CEDRO wrote: > Laurent, > > 1. If you create cable that have ADC onboard (like KT-LINK) then it > is > easier to write simple TCL script to read ADC than rewrite whole > driver in the source code. Yes, easy but dangerous, because you are layout specific !!! > > 2. If you need to program I2C, SPI, or other kind of memory, you > simply write simple TCL script to do so, no need to rewrite source > code from scratch. Again, layout specific > > 3. If you care not to short-cirtuit your internal buffers, put 27R > resistor in series between FT2232 and buffer output. 27R as protection is not enough ... U=RI P=UI ... at 5V ??? 27R are as serial resistor termination not protection ... do not confuse. > > 4. No interface has hardcoded signals by default, Wrong ... it is depending on the configuration of the ft2232 UART or FIFO ... so noone is > obligated to use ANY pin configuration for their device. This > functionality is meant to be placed inside interface configuration, > or > work on generic signals defined by the interface configuration (ie > LED, RnW, MOSI, MISO, CLK, ...), so yes in fact external scripts also > can work with interface-specific configuration :-) Yes ... > > 5. I see no reason that non-aware users should block functionalities > for people that need them and know how to use them, otherwise we need > no development. My objective is not to block feature.Never,never,never ... But we have to avoid any trouble in generic ft2232 driver regarding specific layout. That's all. Your TCL bitbang will control the port of the FTDI from an higher level than FT2232.c. OK but you TCL bitbang is specific to the layout used. How do you accept or not the use of the TCL procedure, if you do not have the notion of layout in this function ??? You have two solutions: You need to write a specifc driver (), or you need to filter the TCL bitbang action in the ft2232 generic driver. The filter must be specifc to the open layout ... The same is for SRST TRST control. The ft2232.c driver has specific functions for SRST TRST regarding layout used ... we have to do this for ANY other specific layout signal in the ft2232.c or write a specific driver. > > If you have any additional questions of doubts feel free to ask :-) How does the ADC controlled from K T ? > > Regards, > Tomek Laurent http://www.amontec.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] bitbanging ft2232 dongle port from TCL is TOO DANGEROUS : PLEASE COMMENT
On Mon, Jun 20, 2011 at 9:19 PM, amotec-laurent_gauch wrote: > Your TCL bitbang will control the port of the FTDI from an higher level than > FT2232.c. OK but you TCL bitbang is specific to the layout used. How do you > accept or not the use of the TCL procedure, if you do not have the notion of > layout in this function ??? Let's assume we want to use our specific interface to quickly flash the SPI memory because we have no time to get familiar with source code and complex program internals... some_very_specific_interface.cfg: (..) interface_signal MOSI 0x01 interface_signal MISO 0x02 interface_signal SCK 0x04 interface_signal EN 0x08 interface_signal SPI0 TCL script then can check if signal SPI is defined (no mask value, so no pin is driven, it is only informational), if so check if other signals are defined and proper value, if so work the SPI operation, if not return error because interface does not define/support necessary signals. If no such signals are defined by interface configuration file, there is no option to drive those signals on that specific interface, so there is no worry anything get broken. Again - signals are to be defined inside interface configuration file, so the signals are also layout specific. This is far more better solution than hardcoding them into source code... Btw. I have to add signal check interface to TCL command :-) How to make tcl command return some value that can be used for later calculation (i.e. "interface_signal mask" returns 0 for SPI signal, 1 for MOSI, 2 for MISO, ...) ? > How does the ADC controlled from K T ? It is connected somehow to free IO pinf on the FT2232H port. Best regards! :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] bitbanging ft2232 dongle port from TCL is TOO DANGEROUS : PLEASE COMMENT
Hi Tomek, as I said, I don't know enough about this to say that this is a feature that we shouldn't have. It sounds like your primary concern is to get SWD done and to do that we need some bits and bobs in place first. I can accept that some bit-banging capability is required, but whether this is a feature we use to implement SWD or it is a feature that we want to promote to end users is another matter. I guess I'm focused on SWD and prerequisites with the time that I have available. -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 87 40 27 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] bitbanging ft2232 dongle port from TCL is TOO DANGEROUS : PLEASE COMMENT
On Mon, Jun 20, 2011 at 6:14 PM, Øyvind Harboe wrote: > (..) I would dearly like to see SWD done before > opening the floodgates to GPIO and other serial protocols. SWD is packed-based half-duplex bus that defines TRN operation for bus direction change and buffers reconfiguration. There is no SWD without bitbanging the pins responsible for that TRN switch. It can be implemented per-interface in a source code, or it can be more general and bring even more use to existing code/hardware. The main reason for writing the bitbang was driving RnW pin that is responsible for TRN bus operation. This RnW can be implemented as one bit, or as bitmask, and even more bitmask that require setting one bits high and other bits low. This is must-have for transport other than JTAG. I will not hardcore this functionality only for one interface, if it can be used for all others with even more elegant solution, because I don't like this approach and I find it too much in current source code - if it was already there I would not have to write it from scratch! With presented signal/bitbang API it is possible to easily create other transports using smart interfaces, I bet even JTAG-only interfaces will score, and it is totally backward compatibile. It will be possible to quickly write custom TCL scripts that will provide lots of more new features than hardcoding them for some specific solution with specific hardware. Do you need anything more? Just let me know and give some time! :-) Best regards! :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] bitbanging ft2232 dongle port from TCL is TOO DANGEROUS : PLEASE COMMENT
On Mon, Jun 20, 2011 at 8:31 PM, Michael Schwingen wrote: > Am 06/20/2011 08:14 PM, schrieb Øyvind Harboe: >>> Please explain the dangers. >> If a driver can't implement a sane feature safely, then the driver shouldn't >> implement that feature > Fine. > > I *do* think hardware should be designed in a way that it can not be > damaged by software, Couldn't agree more. > but if existing hardware has such problems, then > the driver needs to protect the hardware and restrict the user from > doing something stupid. Or minimally don't add support for features that are badly broken in the hardware >> One of the reasons I'm not excited about adding the IO features to OpenOCD >> is that we have barely enough maintainer resources as is. If a maintainer >> came out of the woodwork that would review, design and direct these efforts, >> then I wouldn't be in the way. I would dearly like to see SWD done before >> opening the floodgates to GPIO and other serial protocols. > I can agree to that. However, I do not think we should categorically > exclude such extensions on the simple basis that "this should not be done". I would love to do so, but I don't know enough about it We can exclude it from the point of view that none of the maintainers are currently giving this due attention, even to the point of canning the feature for good or saying that this might be something for the future. -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 87 40 27 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] bitbanging ft2232 dongle port from TCL is TOO DANGEROUS : PLEASE COMMENT
Am 06/20/2011 08:14 PM, schrieb Øyvind Harboe: >> Please explain the dangers. > If a driver can't implement a sane feature safely, then the driver shouldn't > implement that feature Fine. I *do* think hardware should be designed in a way that it can not be damaged by software, but if existing hardware has such problems, then the driver needs to protect the hardware and restrict the user from doing something stupid. > One of the reasons I'm not excited about adding the IO features to OpenOCD > is that we have barely enough maintainer resources as is. If a maintainer > came out of the woodwork that would review, design and direct these efforts, > then I wouldn't be in the way. I would dearly like to see SWD done before > opening the floodgates to GPIO and other serial protocols. I can agree to that. However, I do not think we should categorically exclude such extensions on the simple basis that "this should not be done". cu Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] bitbanging ft2232 dongle port from TCL is TOO DANGEROUS : PLEASE COMMENT
On Mon, Jun 20, 2011 at 8:26 PM, Phil Fong wrote: > (Resending since I forgot to cc the list) > > There is at least one useful end-user use case for bitbanging. There is no end of useful and possible to implement features. As a maintainer I draw the line at what we can follow up on in any reasonable fashion. Oftentimes great patches will be sufficient to add support for small new features, but for larger features we need matching time and skills on the maintainer side. SWD is a stretch, but with Tomek's persistent efforts, I think we can get there. -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 87 40 27 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] bitbanging ft2232 dongle port from TCL is TOO DANGEROUS : PLEASE COMMENT
(Resending since I forgot to cc the list) There is at least one useful end-user use case for bitbanging. There are many IO lines unused on the FTDI port that can be used for GPIO. Some dongles expose these and of course a custom FTDI interface that you integrate with your prototype can expose these. If the generic FTDI code does not expose this functionality, the alternative is to modify the layout specific parts to support this. The downside is that if you make a custom FTDI interface on your prototype you may need to write your own layout driver. Phil___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] bitbanging ft2232 dongle port from TCL is TOO DANGEROUS : PLEASE COMMENT
> Please explain the dangers. If a driver can't implement a sane feature safely, then the driver shouldn't implement that feature One of the reasons I'm not excited about adding the IO features to OpenOCD is that we have barely enough maintainer resources as is. If a maintainer came out of the woodwork that would review, design and direct these efforts, then I wouldn't be in the way. I would dearly like to see SWD done before opening the floodgates to GPIO and other serial protocols. -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 87 40 27 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] bitbanging ft2232 dongle port from TCL is TOO DANGEROUS : PLEASE COMMENT
Am 06/20/2011 02:44 PM, schrieb Laurent Gauch: >> only one transport option; autoselect 'jtag' >> > interface_signal list >> interface_signal list >> Interface Signal Name |Mask| Value >> -- >> > interface_signal add led 8000 >> interface_signal add led 8000 >> There are no signals defined yet. >> > interface_signal list >> interface_signal list >> Interface Signal Name |Mask| Value >> -- >> led | 0x8000 | 0x8000 >> >> > bitbang led=lo >> bitbang led=lo >> ftdi_write_data: USB device unavailable >> Unable to write signal: led >> in procedure 'bitbang' >> >> > bitbang led >> bitbang led >> ftdi_write_data: USB device unavailable >> Unable to read signal: led >> in procedure 'bitbang' > Does OpenOCD need to handle this kind of bitbang fonction from TCL ? > > For me, it does not, because it is too DANGEROUS for both the dongle > and target ... Please explain the dangers. Do you sell hardware that can be damaged by misbehaving software? I think this can be a very useful feature for dongles that have I/Os beside the JTAG/SWD ones - for LEDs, or other additional hardware (Tomek mentioned an ADC). If there is hardware that can be damaged by wrong programming of the I/Os, then the layout for that dongle should provide a mask that disables bitbang access to those signals that are critical. Completely disabling that functionality for everyone is no solution IMHO. > Also, we should not use and/or provide the possibility to the end-user > to manage himself the bitbang of the dongle port, from TCL or from any > other access. > This is JUST not the JOB of openocd but the job of other pieces of > software (as manufacturer post-production test program ...). What if I need to access those pins *while* OpenOCD is running? I don't think you can put this of as a production-only feature. This may be true for your dongles, but not for everyone. > ALL dongle port access should be controlled and checked in the > FT2232.c. The FT2232 should not give to higher layer the possibility > to have an direct access to the dongle port. I can agree that the driver should filter the access and only allow access to those pins that are deemed safe for the specific dongle. cu Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] bitbanging ft2232 dongle port from TCL is TOO DANGEROUS : PLEASE COMMENT
Laurent, 1. If you create cable that have ADC onboard (like KT-LINK) then it is easier to write simple TCL script to read ADC than rewrite whole driver in the source code. 2. If you need to program I2C, SPI, or other kind of memory, you simply write simple TCL script to do so, no need to rewrite source code from scratch. 3. If you care not to short-cirtuit your internal buffers, put 27R resistor in series between FT2232 and buffer output. 4. No interface has hardcoded signals by default, so noone is obligated to use ANY pin configuration for their device. This functionality is meant to be placed inside interface configuration, or work on generic signals defined by the interface configuration (ie LED, RnW, MOSI, MISO, CLK, ...), so yes in fact external scripts also can work with interface-specific configuration :-) 5. I see no reason that non-aware users should block functionalities for people that need them and know how to use them, otherwise we need no development. If you have any additional questions of doubts feel free to ask :-) Regards, Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] bitbanging ft2232 dongle port from TCL is TOO DANGEROUS : PLEASE COMMENT
Hi Øyvind Harboe, Please refrain from shouting(using uppercase). It's more likely that people will ignore your email than read it. Thank you for the advice. As a maintainer, I'm not terribly excited about bitbanging and other non-CPU related protocols. Projects like UrJTAG pursue this sort of avenue. I'd like to see OpenOCD focusing on CPUs. Yes, you're right and I join you. I'd like to see openocd as an on-chip debugger, as a robust software implementing jtag swd trace solution. I'd like to see urjtag as a universal jtag solution, as a robust software implementing boundary scan solution. I'd not like to see openocd nor urjtag as a generic software allowing the users to bitbang an usb io port. That's the better way to have long term issues, and more support for nothing usable. Regards, Laurent http://www.amontec.com/jtagkey.shtml Amontec JTAGkey-2 High-Speed USB JTAG. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] bitbanging ft2232 dongle port from TCL is TOO DANGEROUS : PLEASE COMMENT
Please refrain from shouting(using uppercase). It's more likely that people will ignore your email than read it. As a maintainer, I'm not terribly excited about bitbanging and other non-CPU related protocols. Projects like UrJTAG pursue this sort of avenue. I'd like to see OpenOCD focusing on CPUs. -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 87 40 27 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] bitbanging ft2232 dongle port from TCL is TOO DANGEROUS : PLEASE COMMENT
Sergey Lapin wrote: On Mon, Jun 20, 2011 at 4:44 PM, Laurent Gauch wrote: only one transport option; autoselect 'jtag' > interface_signal list interface_signal list Interface Signal Name |Mask| Value -- > interface_signal add led 8000 interface_signal add led 8000 There are no signals defined yet. > interface_signal list interface_signal list Interface Signal Name |Mask| Value -- led | 0x8000 | 0x8000 > bitbang led=lo bitbang led=lo ftdi_write_data: USB device unavailable Unable to write signal: led in procedure 'bitbang' > bitbang led bitbang led ftdi_write_data: USB device unavailable Unable to read signal: led in procedure 'bitbang' Does OpenOCD need to handle this kind of bitbang fonction from TCL ? For me, it does not, because it is too DANGEROUS for both the dongle and target ... PLEASE COMMENT The problem is that the result of a bit-bang procedures will be dongle and layout specific. There are too many chances for the end-user to create short-circuit in the dongle or on the dongle port to the target board. Also, we should not use and/or provide the possibility to the end-user to manage himself the bitbang of the dongle port, from TCL or from any other access. This is JUST not the JOB of openocd but the job of other pieces of software (as manufacturer post-production test program ...). ALL dongle port access should be controlled and checked in the FT2232.c. The FT2232 should not give to higher layer the possibility to have an direct access to the dongle port. Regards, Laurent http://www.amontec.com/jtagkey.shtml Amontec JTAGkey-2 : HIGH SPEED USB JTAG CABLE ADAPTER DONGLE DRIVER I don't think this is heavily an issue here. As you say, this feature is not a issue. But I send a BIG WARNING HERE ! This functionality might be disabled by default and not recommended for inclusion in distributions. WE HAVE TO MAKE SURE TO DO NOT *release* ANY OPENOCD WITH THIS FEATURE ENABLED !!! CEDEROM, do you have add an explicit define to enable this feature at compilation. If not please send a patch. But easy way to write drivers for custom dongles in config files heavily reduces costs of development and production. True, for development & prototyping. False, for production. I am certain this kind of bitbang TCL features, as it is now, will make the OpenOCD unstable at long term, since it bypass layout specification at higher software level. There are big differences between the "How to bitbang the FT2232" and "How to bitbang a specific dongle layout-port". Yes, it is easy but NOT SAFE for the end-user. S. Regards, Laurent http://www.amontec.com/jtagkey.shtml Amontec JTAGkey-2 : HIGH SPEED USB JTAG CABLE ADAPTER DONGLE DRIVER ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] bitbanging ft2232 dongle port from TCL is TOO DANGEROUS : PLEASE COMMENT
On Mon, Jun 20, 2011 at 4:44 PM, Laurent Gauch wrote: >> only one transport option; autoselect 'jtag' >> > interface_signal list >> interface_signal list >> Interface Signal Name | Mask | Value >> -- >> > interface_signal add led 8000 >> interface_signal add led 8000 >> There are no signals defined yet. >> > interface_signal list >> interface_signal list >> Interface Signal Name | Mask | Value >> -- >> led | 0x8000 | 0x8000 >> >> > bitbang led=lo >> bitbang led=lo >> ftdi_write_data: USB device unavailable >> Unable to write signal: led >> in procedure 'bitbang' >> >> > bitbang led >> bitbang led >> ftdi_write_data: USB device unavailable >> Unable to read signal: led >> in procedure 'bitbang' > > Does OpenOCD need to handle this kind of bitbang fonction from TCL ? > > For me, it does not, because it is too DANGEROUS for both the dongle and > target ... > > PLEASE COMMENT > > The problem is that the result of a bit-bang procedures will be dongle and > layout specific. There are too many chances for the end-user to create > short-circuit in the dongle or on the dongle port to the target board. > > Also, we should not use and/or provide the possibility to the end-user to > manage himself the bitbang of the dongle port, from TCL or from any other > access. > This is JUST not the JOB of openocd but the job of other pieces of software > (as manufacturer post-production test program ...). > > ALL dongle port access should be controlled and checked in the FT2232.c. The > FT2232 should not give to higher layer the possibility to have an direct > access to the dongle port. > > Regards, > Laurent > http://www.amontec.com/jtagkey.shtml > Amontec JTAGkey-2 : HIGH SPEED USB JTAG CABLE ADAPTER DONGLE DRIVER > I don't think this is heavily an issue here. This functionality might be disabled by default and not recommended for inclusion in distributions. But easy way to write drivers for custom dongles in config files heavily reduces costs of development and production. S. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] bitbanging ft2232 dongle port from TCL is TOO DANGEROUS : PLEASE COMMENT
only one transport option; autoselect 'jtag' > interface_signal list interface_signal list Interface Signal Name |Mask| Value -- > interface_signal add led 8000 interface_signal add led 8000 There are no signals defined yet. > interface_signal list interface_signal list Interface Signal Name |Mask| Value -- led | 0x8000 | 0x8000 > bitbang led=lo bitbang led=lo ftdi_write_data: USB device unavailable Unable to write signal: led in procedure 'bitbang' > bitbang led bitbang led ftdi_write_data: USB device unavailable Unable to read signal: led in procedure 'bitbang' Does OpenOCD need to handle this kind of bitbang fonction from TCL ? For me, it does not, because it is too DANGEROUS for both the dongle and target ... PLEASE COMMENT The problem is that the result of a bit-bang procedures will be dongle and layout specific. There are too many chances for the end-user to create short-circuit in the dongle or on the dongle port to the target board. Also, we should not use and/or provide the possibility to the end-user to manage himself the bitbang of the dongle port, from TCL or from any other access. This is JUST not the JOB of openocd but the job of other pieces of software (as manufacturer post-production test program ...). ALL dongle port access should be controlled and checked in the FT2232.c. The FT2232 should not give to higher layer the possibility to have an direct access to the dongle port. Regards, Laurent http://www.amontec.com/jtagkey.shtml Amontec JTAGkey-2 : HIGH SPEED USB JTAG CABLE ADAPTER DONGLE DRIVER ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
